Apache Tomcat Remote Code Execution via JSP upload (CVE-2017-12615 / CVE-2017-12617)
In the recent days, a new vulnerability in Apache Tomcat has been published (CVE-2017-12615). The vulnerability allows attackers to upload arbitrary files to the Tomcat application server by utilizing the HTTP PUT method. By uploading a .JSP file to the Tomcat Application Server, an attacker may be able to execute malicious JAVA code on the remote machine.
Reproducing the vulnerability
By default, Apache Tomcat restricts the usage of the HTTP PUT method, but by modifying Tomcat’s web.xml configuration file it is possible to disable this restriction.
Figure 1: Configuring Apache Tomcat to allow the usage of the PUT method.
Once this configuration change is in place, attackers may send HTTP PUT requests to the server, and consequently create files on it.
Figure 2: Specially crafted PUT request exploiting the vulnerability sent to a preconfigured Apache Tomcat instance.
Figure 3: The uploaded file as can be found in the application root directory.
After the file has been successfully uploaded to the server by the attacker, he can access the uploaded file. As the uploaded file is a JSP file containing JAVA code, Apache Tomcat will execute this code while rendering the response.
Figure 4: Accessing the uploaded file.
Mitigating the vulnerability with BIG-IP ASM
BIG-IP ASM customers are already protected against this vulnerability. By default, BIG-IP ASM restricts the usage of the HTTP PUT method and will block any HTTP PUT request sent to the virtual server. The exploitation attempt will also be blocked by a Server Side Code Injection signature (Signature ID 200004048) which can be found in signature sets that include “Server Side Code Injection” attack type.
Figure 5: Exploitation attempt blocked with illegal HTTP method.
Figure 6: Exploit blocked with Attack Signature (200004048)
Update
CVE-2017-12617 is the same vulnerability as CVE-2017-12615. Additional Apache Tomcat patch was released as the previous patch did not resolve the remote code execution vulnerability described in CVE-2017-12615.
Therefore it is possible to mitigate CVE-2017-12617 using BIG-IP ASM as previously described.
1 Comment
What kind of security group is it; universal, global, or domain local? Is there a difference between the one that is working and one that isn't? Just throwing it out there if the scope of the group is possibly messing with the AD query nesting.
What version of BigIP are you running? There was a bug a while back where the memberOf attribute was cut short so if the group happened to be the last one returned then the session variable would not have it set when going to the resource assign logic of the VPE.
If that is not it then you can check to make sure using ldapsearch that the group is returned by AD (this could be an AD issue not an F5 issue).
ldapsearch -xLLL -H 'ldaps://x.x.x.x' -b "dc=fr,dc=del,dc=corp" -s sub -D "cn=Administrator,cn=Users,dc=fr,dc=del,dc=corp" -w mypassword' "(member:1.2.840.113556.1.4.1941:=cn=cal,CN=Users,DC=fr,DC=del,DC=corp)"
Modify the command above and I grep for "dn" to make the list easier to read.
[root@cooper-apm-11-6-0:Active:Standalone] rest ldapsearch -xLLL -H 'ldaps://x.x.x.x' -b "dc=fr,dc=del,dc=corp" -s sub -D "cn=Administrator,cn=Users,dc=fr,dc=del,dc=corp" -w mypassword' "(member:1.2.840.113556.1.4.1941:=cn=cal,CN=Users,DC=fr,DC=del,DC=corp)" | grep dn dn: CN=HwSales,CN=Users,DC=fr,DC=del,DC=corp dn: CN=Onsite,CN=Users,DC=fr,DC=del,DC=corp dn: CN=Sales,CN=Users,DC=fr,DC=del,DC=corp dn: CN=VEND1-QA,OU=VPN,DC=fr,DC=del,DC=corp dn: CN=VEND1-PROD,OU=VPN,DC=fr,DC=del,DC=corp dn: CN=VEND2-DEV,OU=VPN,DC=fr,DC=del,DC=corp dn: CN=Vendor A Prod,OU=VPN,DC=fr,DC=del,DC=corp [root@cooper-apm-11-6-0:Active:Standalone] rest
In this example "Sales" has member "HwSales" and "HwSales" has member of "cal".
The filter uses the "LDAP_MATCHING_RULE_IN_CHAIN" OID which AD will do the group traversing and return the groups. If this works and you see all groups then we can dig in further into how the APM works. If this doesn't work I would suggest keep looking on the AD side.
-Seth
So I was playing with this a bit last night myself as I saw some similar behavior. What seemed to rectify the issue was I added the memberOf attribute and two other attributes that I need to the "Required attributtes" section of the AD Query and then all my nested memberships showed up as expected. Are you using the required attributes section? I wonder if it doesn't get all the results when the return payload of the AD Query is above a certain size. When using the required attributes section you only get those attributes you want in the response significantly shrinking the AD Query response.