ilmila / j2eescan

J2EEScan is a plugin for Burp Suite Proxy. The goal of this plugin is to improve the test coverage during web application penetration tests on J2EE applications.

J2EEScan - J2EE Security Scanner Burp Suite Plugin

What is J2EEScan

J2EEScan is a plugin for Burp Suite Proxy. The goal of this plugin is to improve the test coverage during web application penetration tests on J2EE applications.

How does it works?

The plugin is fully integrated into the Burp Suite Scanner; it adds more than 80+ unique security test cases and new strategies to discover different kind of J2EE vulnerabilities.

How to install ?

• From "Cookie jar" section in "Options" -> "Sessions" enable the Scanner and Extender fields
• Load the J2EEscan jar in the Burp Extender tab
• The plugin requires at least Java 1.7

Contributors:

Special thanks to

• @h3xstream
• @martinbydefault
• @ikki
• @Caligin35
• @greenfile

Release Notes

Version 2.0.0beta.2

• Added check for AJP Tomcat GhostCat (CVE-2020-1938)
• Improve detection for Apache Tomcat EoL
• Improved Jackson CVE-2017-7525 deserialization flaw
• Improved EL Injection detection to minimize FP
• Improved JBoss Seam 2 Remote Command Execution (thanks to https://github.com/greenfile)
• Added check for Spring Cloud Path Traversal CVE-2020-5410

Version 2.0.0beta (9 Jan, 2020):

• Major improved on scan time performance
• Added check for Spring Data Commons Remote Code Execution (CVE-2018-1273)
• Added check for PrimeFaces Expression Language Injection (CVE-2017-1000486)
• Added check for Spring Data REST - Remote Command Execution (CVE-2017-8046)
• Added check for Eclipse Mojarra Path Traversal (CVE-2018-14371)
• Added check for Tomcat URI Normalization found by @orange_8361
• Added check for Fastjson RCE (CVE-2017-7525)
• Added check for Apache SOLR (CVE-2017-12629)
• Added check for EL3 Injection
• Added check for Apache Struts Showcase
• Added check for Apache Struts2 S2-043
• Added check for Apache Struts2 S2-052
• Added strategy to bypass weak ACL URI restrictions
• Added check for SSRF Scanner
• Added check for REST API Swagger Scanner
• Added check for Oracle EBS SSRF Vulnerabilities (CVE-2018-3167, CVE-2017-10246)
• Added check for Next.js Path Traversal Vulnerability (CVE-2018-6184)
• Added check for NodeJs Path Traversal (2017-14849)
• Added check check for Session Fixation
• Added check for session id in url
• Added check for Javascript PostMessage detection
• Added check for JBoss HTTP Invoker ReadOnlyAccessFilter CVE-2017-12149
• Added check for NodeJS Path Traversal CVE-2017-14849
• Added check for new base check for EL issue
• Added check for JBoss WS JUDDI console
• Added check for Oracle iDOC Injection (CVE-2013-3770)
• Added check for HTTP Open Proxy Detection
• Improved detection for XXE attacks on xml parameters
• Improved detection on local file include/path traversal on J2EE env
• Improve detection for CVE-2014-3625 - Spring Directory Traversal
• Improve detection for LFI attacks
• Improve detection for Java Server Faces Path Traversal
• Improved detection for Infrastructural Path Traversal
• Improved Spring Boot Actuator
• Improved check for Apache Axis Admin Console

Version 1.2.5 (29 May, 2016):

• Added check for UTF8 Response Splitting
• Added check for JBoss Undertow Directory Traversal (CVE-2014-7816)
• Added check for NodeJS HTTP Redirect (CVE-2015-1164)
• Added check for NodeJS HTTP Response Splitting (CVE-2016-2216)
• Added check for JK Management Endpoints
• Added check for Pivotal Spring Traversal (CVE-2014-3625)
• Added check for JBoss jBPM Admin Consoles
• Adedd check for Apache Struts 2 S2-032 (CVE-2016-3081)
• Improved LFI payloads
• Improved EL Injection tests
• Improved WS Axis security checks

Version 1.2.4 (26 Nov, 2015):

• Added check for Spring Boot Actuator console
• Improved LFI module with new UTF-8 payloads
• Improved EL Injection with new payloads
• Added check for Apache Roller OGNL Injection (CVE-2013-4212)
• Added check for Apache Struts 2 S2-023 - thanks to @h3xstream
• Added check for Weblogic Admin Console Weak Password
• Added check for Oracle Application Server multiple file disclosure issues
• Added check for Oracle Log Database Accessible
• Added check for AJP service identification
• Added check for Weblogic UDDI Explorer SSRF (CVE-2014-4210)
• Improved performance for passive checks
• Improved Apache Wicket Information Disclosure
• Improved J2EE incorrect exception handling
• Added check for End Of Life Software - Jetty
• Added check for End Of Life Software - Tomcat
• Added check for End Of Life Software - Oracle Application Server
• Added check for Oracle Application Server version
• Added check for Oracle Glassfish version
• Added check for Oracle Weblogic version
• Added check Apache Struts OGNL Console
• Added check for Happy Axis

Version 1.2.3dev (26 Feb, 2015):

• Added check for Jetty Remote Leak Shared Buffers (CVE-2015-2080) found by @gdssecurity
• Improved check for Information Disclosure Issues - Remote JVM version
• Added check for Apache Wicket Arbitrary Resource Access
• Added check for Incorrect Error Handling - Apache Tapestry
• Added check for Incorrect Error Handling - Grails
• Added check for Incorrect Error Handling - GWT
• Fixed references for EL Injection issue

Version 1.2.2dev (23 Feb, 2015):

• Added check for Information Disclosure Issues - Remote JVM version
• Added check for Information Disclosure Issues - Apache Tomcat version
• Added check for weak password on HTTP Authentication
• Fix some bugs on issues reporting

Version 1.2.1dev (16 Feb, 2015):

• Improved LFI checks
• Added initial support for compliance checks

Version 1.2 (25 Jan, 2015):

• Added checks for Apache Axis2
• Added checks for Jboss Admin Console Weak Password
• Added checks for Jboss JMX Invoker
• Added checks for Status Servlet
• Added checks for Snoop Resources
• Added checks for Apache Tomcat Host Manager Console
• Multiple bug fixes
• Pushed BApp Store.

Version 1.1.2 (18 Oct, 2014):

• Initial Public Release

j2eescan's Issues

HTTP Auth Basic not supported

The plugin does not support applications that employ HTTP Auth Basic.

The Authentication header should be copied to the structure of the issued requests, just like any other header originally used by the tested application.

Defect Jetty 11.x and 10.x End of Life checks

Defect Jetty 11.x and 10.x End of Life checks
The Jetty EoL check does not work correctly. It only checks for the major version and thus generates a scan issue for Jetty 11.X.X and 10.X.X

Tested on Burp Pro version:
-Tested J2EEScan-1.2.6-jar-with-dependencies.jar version

-Tested public J2EEScan-2.0.1-dev-jar-with-dependencies.jar version

Defect Jetty 11.x.x

Defect Jetty 10.x.x

Defect 9.4.48,v202206.22 <= 9.4.x is now EoL References
https://github.com/eclipse/jetty.project/releases
https://www.eclipse.org/jetty/download.php

J2EEScan/src/main/java/burp/SoftwareVersions.java

Lines 70 to 94 in 1936af8

	/**
	* Jetty
	*/
	if (software.equalsIgnoreCase("Jetty")) {
	/**
	* End of Life - Jetty
	*/
	if ( Integer.parseInt(release.substring(0, 1)) < 9 ) {
	callbacks.addScanIssue(new CustomScanIssue(
	baseRequestResponse.getHttpService(),
	requestInfo.getUrl(),
	baseRequestResponse,
	"End of Life Software - Jetty " + release,
	"J2EEScan identified an unsupported release of Jetty <b>" + release + "</b>.<br />"
	+ "No more security updates for this version will be released by the vendor <br /><br />"
	+ "<b>References</b><br />"
	+ "https://wiki.eclipse.org/Jetty/Starting/Jetty_Version_Comparison_Table<br />",
	"Update the Jetty Container with the last stable release",
	Risk.High,
	Confidence.Certain
	));
	}
	}

Apache Struts S2-20 classLoader manipulation improvement

J2EEScan scans for Struts class loader manipulation ( https://github.com/ilmila/J2EEScan/blob/master/src/main/java/burp/j2ee/issues/impl/ApacheStrutsS2020.java ) with the type of payload engineered AFTER the first fix which is Class.classLoader Ex:
Class.classLoader.URLs[0]=testClassloaderManipulation1509723031
During testing I've seen that most of the times this payload will not trigger anything/any reaction , but the original one , class.classLoader would . I did class.classLoader.classAssertionStatus=test , this , in turn , would either generate a beanutils error regarding the fact that classAssertionStatus has no setter or give a 404 in the response. J2EEScan didn't detect anything wrong with the application even though it was vulnerable to this issue .

My suggestion is the following : Adding class.classLoader and class['classLoader'] to the list of payloads for S2-20 scanning . I really think that this will improve the detection of this issue !
There is also a pretty well explained list of payload for struts vulns here :
https://github.com/lanjelot/kb/blob/master/struts

Extension causes Burp scanner to freeze sometimes

For some reason, this extension can cause Burp scanner to lock up. I am not the author of the below thread, just found it when I was having this problem. Disabling the J2EEScan extension solved my problem.

https://support.portswigger.net/customer/portal/questions/11323602-freezes-in-scanner

CVE-2017-9805: Apache Struts

Hi,

I am wondering if this can be checked for?

Examples:

• https://github.com/rapid7/metasploit-framework/pull/8924/files
• https://github.com/mazen160/struts-pwn_CVE-2017-9805/blob/master/struts-pwn.py

Thx, Dirk

CVE-2013-3770 exploit

Using this useful extension I found CVE-2013-3770 (Oracle IDoc Injection) vulnerability but unfortunately can't find a way/exploit/payload to exploit it successfully. Can you please help? I have already tried 'exploitdb' and google but no luck.

about generics

In this project;
why use "List<IScanIssue> issues = new ArrayList<>()";
when I take it in Elipse ,this will come a error; why not use "List<IScanIssue> issues = new ArrayList<IScanIssue>()" or "List<IScanIssue> issues = new ArrayList()"

My eclipse's verison is 10.0 and java version is 1.7.x

`java.util.ConcurrentModificationException`

The following exceptions are thrown during a scan. This is due to the use of non-thread-safe collection containers in the various scan checkers. You may want to use something like a ConcurrentHashMap instead of an ArrayList or use Java's ugly mutual exclusion/multi-threading model to ensure critical regions are only entered by one thread at a time. The latter is uglier to implement whilst the former is more elegant but requires some refactoring on your end.

java.util.ConcurrentModificationException
    at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
    at java.util.ArrayList$Itr.next(ArrayList.java:851)
    at burp.WeakPasswordBruteforcer.HTTPBasicBruteforce(WeakPasswordBruteforcer.java:49)
    at burp.j2ee.issues.impl.JBossWebConsole.scan(JBossWebConsole.java:130)
    at burp.BurpExtender.doActiveScan(BurpExtender.java:130)
    at burp.sq.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:745)
java.util.ConcurrentModificationException
    at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
    at java.util.ArrayList$Itr.next(ArrayList.java:851)
    at burp.WeakPasswordBruteforcer.HTTPBasicBruteforce(WeakPasswordBruteforcer.java:49)
    at burp.j2ee.issues.impl.JBossJMXInvoker.scan(JBossJMXInvoker.java:127)
    at burp.BurpExtender.doActiveScan(BurpExtender.java:130)
    at burp.sq.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:745)
java.util.ConcurrentModificationException
    at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
    at java.util.ArrayList$Itr.next(ArrayList.java:851)
    at burp.WeakPasswordBruteforcer.HTTPBasicBruteforce(WeakPasswordBruteforcer.java:49)
    at burp.j2ee.issues.impl.JBossWS.scan(JBossWS.java:113)
    at burp.BurpExtender.doActiveScan(BurpExtender.java:130)
    at burp.sq.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:745)

Update extension

Please update the extension with latest vulnerabilities

No jar file in recent version

Hello,
Subject says it all. Expanded the zip file and no .jar files.
I did install J2EEScan from the BApp store but that is an older version.
Sorry for the headache.
Thanks!

Defect Apache Tomcat End of Life check

The Apache Tomcat EoL check does not work correctly. It only checks for the major version and thus generates a scan issue for Apache 8.5.X.

J2EEScan/src/main/java/burp/SoftwareVersions.java

Lines 36 to 37 in 0cbeed3

	vulnerableTomcatReleases = Arrays.asList(4, 5, 6, 8);
	if ( vulnerableTomcatReleases.contains(Integer.parseInt(release.substring(0, 1)))) {

Apache Axis 2 - Weak Admin Password

Hey,

I think the Apache Axis 2 - Weak Admin Password part might need a change as it still flags on a page where the user and password are being asked for causing a false positive.

Robbie

Syntax Highliting

I noticed that this extender doesn't highlight payloads; and the information in Advisory is always identical.
When I have an issue discovered, and press "Move to the next match" in both Request and Response; it would be very nice to see the payload as well as identified response highlighted.
Also, the Advisory tab for found issue could be more specific -> e.g. "Referer: ${9*2}" resulted in "blablabla18blabla" in response; so that false positives could be found faster.

UI not combining multiple findings

I noticed a few findings on my assessment were 'missing' and working with portswigger we narrowed it down to J2EEScan finding similar issues in different injection points in the same application. It was confirmed with Logger++ that J2EEScan doesn't roll up the finding in a similar manner to other extensions.

In the the attached screen shot you can see that NoSQL Injection Detected (from a different extension) rolls up mutiliple findings in different requests and injection points.

Even though this project has multiple findings for the same XXE in different locations i only see one finding. This makes it hard to validate the other findings (apart from the first ) as the Request and Response aren't logged anywhere (unless you are using additional logging which you need to go search through the find the other effected injection points).
This issue also presents itself as an inconsistency throughout the UI (especially when using mutiple Audit tasks) as additional findings are shown in some areas but not others e.g.

e.g. Details page of audit screen shows 0 high severity issues:

Audit Items page shows 3 high severity issues (i confirmed these were J2EEScan issues)

Issue activity page shows no issue:

Issue activity summary page shows only one High severity issue for a different task.

Is this just me or is this a possible improvement that could be made to how mutliple issues are combined in J2EEScan

Let me know if you need any other info

Possible False Positive in EL Injection

I'm not sure whether this value is static or variable, but noticed a couple of false positives when the #{584*540} payload is submitted. The result of this expression being evaluated would be 315360. Unfortunately this is a substring of 31536000, which is the number of seconds in a year and, also, quite common as a value for max-age in the Strict-Transport-Security header.

EL Injection false positive

Hi,

I came across some false positives today, where the payload was #{305*3}. I assume the plugin detected "915" in the response (which I also found as part of a SHA1 sum). Could the multiplication be of larger numbers to prevent such false positives?

Cheers.

BApp Store update

Hi,

Can you please send us a message on [email protected] so that we can process your latest update? The BApp Store version has not been updated for over 3 years.

Thank you!

J2EESCAN FOR ZAP proxy

Do you have a plan to create a J2EEScan version for ZAP proxy??

struts with different file extensions

Hey, while scanning a struts app it was not picking up issues that should have been identified. While looking though the code i realized it only triggers on the common file extensions like .do and .action. These extensions are often customized for the organization. I manually updated the code to add the extensions that we use but it would be great if this could be configurable or even allowed to scan regardless of the file extension. For instance you don't even need to put a file extension on struts like www.example.com/test.action and www.example.com/test will work the same.