Have you even wondered whether you Java application is secure enough before going to production ? Or how to uncover security vulnerabilities during the development lifecycle ? I am guessing the answer is YES and probably the first thing that comes to the Java developer’s mind is to introduce static analysis tool like SonarQube, PMD or FindBugs to the current CI/CD process with the hope to uncover certain issues (including security ones) in the codebase. While static analysis can discover and provide possibility to alleviate certain types of security issues like non validated input or outdated and potentially vulnerable versions of libraries being used it certainly cannot address security concerns related to the operational aspect of the application. This is where penetration testing tries to fill the gaps and provide more insights on potential vulnerabilities. However putting penetration testing into action requires more time and skills which for many projects (especially once for which security is not a critical concern) is out of budget. Conducting penetration tests can be deducted to several distinct phases which vary in their formulation in the different sources but can be summarized as follows:
- Preliminary analysis: This includes reconnaissance which refers to the act of gathering information about the target application that is pentested. This might be relevant information about the application such employee email addresses discovered through google for example (if the application is publicly available) or by means of social engineering (i.e. by conducting phishing attacks targeting to trick users into providing sensitive information). A subsequent step is scanning that can use different tools to extract additional knowledge from the application such as for example a list of available ports. A great tool for that purposes is Nmap that can be as a simple as running the following on the command line:
nmap <Java_application_address>
Many Java application servers and frameworks leave some default ports open unless they are disallowed or there are proper firewall rules in place. - Exploitation: refers to act of trying to exploit a known vulnerability based on the information gathered in the preliminary analysis and effective gain access to the target system. There might be numerous examples of such exploits that can be tried in the context of a typical Java application such as (to name a few):o DoS/DDoS attacks whereby the application is preventing normal access due to the lack of resources. This can be an large number of requests against a Spring REST controller for example that has a memory leak (potentially associated with a certain type of input passed to the API). This can also be a large number of requests against an exposed API that overflows the application with information to process resulting in larger response times for normal requests). In many cases this can be alleviated with proper hardware and software solutions in combination that might not even require modifications to the application. Preliminary analysis can provide more insights on faulty APIs that can be a subject of DoS/DDoS attacks;o Unauthorized access whereby credentials might be retrieved using brute force (i.e. dictionary) attacks in the case of weak or no access control applied on the authentication mechanism (such as for example maximum number of wrong attempts). Another flavor of gaining unauthorized access is by trying to login with default credentials (i.e. such as admin/admin for JBoss EAP);
o Privilege escalation whereby an already authorized user can exploit certain APIs that do not perform proper access control checks and gain more privileges that expected to certain types of features. Consider Spring security misconfiguration or a missing @RolesAllowed annotation on a restricted endpoint method in a JavaEE application for example;
o Man-in-the middle attacks made possible i.e. by a security misconfiguration such as not enabling SSL on dependent components (like the RSBMS or the message broker) in production;
o Data leaks occurring due to mistakenly exposing sensitive data in error messages or publicly available endpoints.
Many of these types of exploits can be automated by means of proper tools and we are going to review a few of them shortly throughout the rest of the article.
- Subsequent actions: This includes activities such as trying to make discovered vulnerabilities more persistent by maintaining access for an extended period of time by additional means (such as placing additional scripts that support the discovered vulnerability). Another activity might be the possibility to cover any tracks that might lead to the discovery of who did actually perform the attack. Results from the conducted penetration test may also be written to a proper report for subsequent analysis.
Depending on how critical security might be for a target organization penetration testing might be adopted by different roles in the organization such as:
- The development team – most of us are Java developers quite busy delivering new features and bugfixes and typically there is little-to-no time to think about security at all. Combining that with the lack of a good practice and expertise in penetration testing makes that activity even harder to achieve. As discussed at the beginning development teams tend to put in place static analysis tools like Sonarqube in their CI/CD pipelines but that can be further extended with a set of a few more tools for pentesting like OWASP ZAP that has a plugin for Jenkins. Even a limited set of tools applied in a typical Jenkins pipeline might save extra time and effort later on in the delivery process;
- QA team – typically quite busy preparing and executing manual and automation tests but they might also adopt the practice preparing a core set of automated security tests like for example checking for default credentials or trying to perform an SQL injection using an input expected from the user.
- Security team – especially in many organizations like banks where security is crucial pentesting is typically performed by skilled internal teams of security experts. In some cases these teams can make use of insider information about the organization or the application under test that can be used to conduct performance testing more accurately. These teams may also use and have vast knowledge of a broader category of tools that are applied for the purpose of penetration testing. A Linux distribution of choice for such teams that bundles a large number of industry-recommended tools for penetration testing is Kali Linux.
- Security consultants, researchers and attackers – in many cases when the organization cannot afford to hire an entire team of security experts or is willing to gain an ever higher degree of confidence in the security of a target application external entities can be hired in order to conduct proper pentesting.
Many organizations are willing to also pay for commercial security tools that may reduce costs and complexity in conducting penetration tests in-house. Such tools that may conduct penetration tests with a context knowledge of Java applications might be Veracode or Burp for example. If however the team conducting the performance tests is willing to step on a free and potentially open source set of tools there is also plenty to choose from such as OWASP ZAP or Metasploit that can conduct exploits specific to Java applications. A good list of free/commercial tools that can be used is available at: https://owasp.org/www-community/Vulnerability_Scanning_Tools. A detailed review of penetration testing tools bundled in the Kali Linux distribution is available at https://tools.kali.org/tools-listing.
It might be quite overwhelming to get a grasp on the majority of tools available for penetration testing by the general recommendation is to look for those covering certain security aspect and related exploits needed for the target application and start adopting a small set of tools initially with the possibility to gradually support the penetration testing process with more tools and practices based on the evolution of the application.
