Apache Struts Double OGNL Evaluation (S2-061 / CVE-2020-17530)
Today a new security bulletin was published by Apache Struts identified by S2-061 and CVE-2020-17530. This vulnerability is very similar to a one that we already discussed in a previous post, and also the same conditions must be met for a Struts application to be vulnerable. This new advisory was published because it was discovered that certain Struts tags which are rendered on the server side will still perform double OGNL evaluation despite of the previous fixes that attempted to prevent such condition. In order to find those tags we set up our Struts application to use an unpatched version of the Struts library, and we created a Struts server-side form tag that both applies forced OGNL evaluation (uses the %{} syntax) on the “id” attribute value and also allows the attribute value to be user controlled. Figure 1: Struts form tag set to perform forced OGNL evaluation with user-controlled input When we send a request that contains an OGNL expression in the “id” parameter we can see that our OGNL expression was not evaluated by the server which means double OGNL evaluation did not happen in this case, as expected. Figure 2: OGNL expression was not evaluated in the form tag id attribute value However, if we change our application to use an anchor tag instead of a form tag, we can see that on the same request that we previously sent was now evaluated, which means double OGNL evaluation occurred. Figure 3: Struts application modified to use an anchor tag instead of a form tag Figure 4: user specified OGNL expression was evaluated in the application anchor tag id attribute value In the fixing commit we can see that the calls to the “findString “and “findValue” methods that triggered one of the cycles of the OGNL expression evaluation were removed thus preventing our OGNL expression from beingdouble evaluated. Figure 5: “findString” method call was removed Mitigation with Advanced WAF Advanced WAF customers under any supported version are already protected against this vulnerability as exploitation attempts of this vulnerability are detected by existing Java code injection signatures. Figure 6: Exploit attempt blocked by signature id 200004224611Views0likes0CommentsApache Struts 2 Namespace Evaluation Remote Code Execution (CVE-2018-11776 / S2-057)
Today, a new Apache Struts 2 Remote Code Execution vulnerability was announced (S2-057) and CVE-2018-11776 was allocated. At the moment, there is no public Proof of Concept exploit available. for a Struts 2 application to be vulnerable, its configuration should meet 2 conditions: The value of the “struts.mapper.alwaysSelectFullNamespace” should be set to true. This means that Struts will consider the “namespace” to be everything before the last slash of the URI. Action declaration via <action> tag without “namespace” attribute. When the conditions are met, Struts will try to extract the “namespace” from the request URL by following the next logic: Example URL: http://struts2app.test/[Servlet Context]/[Namespace]/[Action].action It was found that if the namespace was extracted from the requested URL, and it contained an Object-Graph Navigation Library (OGNL) expression which is the expression language supported by the Struts framework, in some cases the extracted expression may be evaluated by Struts, which may lead to arbitrary code execution. Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by existing Java code injection attack signatures which can be found in signature sets that include the “Server Side Code Injection” attack type or “Java Servlets/JSP” System. Edit:We have released additional, more generic signatures to cover OGNL / JSP expressions injection attempts in the URL: 200004474 -JSP Expression Language Expression Injection (3) (URI) 200004475 - Object Graph Navigation Library Expression Injection (2) (URI Edit:Proof of Concept exploit for this vulnerability is now publicly available. The exploitcan be mitigated by the following signatures: Figure 1: Exploit blocked with attack signature 200004281 Figure 2: Exploit blocked with attack signature 200003439 Figure 3: Exploit blocked with attack signature 200004156 Figure 4: Exploit blocked with attack signature 200004368) Additional Reading https://lgtm.com/blog/apache_struts_CVE-2018-11776 https://semmle.com/news/apache-struts-CVE-2018-11776540Views0likes2CommentsLightboard Lessons: The Apache Struts 2 Remote Code Execution Vulnerability
The Apache Struts 2 framework is used extensively to build web applications. This framework has also been the victim of several vulnerabilities that dramatically affect users all over the world. Last year, Equifax was famously the victim of a vulnerability of the Apache Struts framework and, when they didn't implement the recommended patches, it cost them over $600 Million. Well, a new (even worse) vulnerability has been found on the Struts 2 framework. It's a Remote Code Execution vulnerability whereby an attacker can take control ofyour web server. In this video, John explains this new vulnerabilty and highlights some ways to keep your applications safe from attacks. Enjoy! Related Resources: Semmle Discovers Critical Remote Code Execution Vulnerability in Apache Struts Apache Struts 2 VulnerabilityExploited in CroniX Crypto-Mining Campaign319Views0likes0CommentsApache Struts 2 FreeMarker tag Remote Code Execution (CVE-2017-12611)
In the recent days, another 0-day remote code execution vulnerability in Apache Struts 2 has been published (CVE-2017-12611). This time the vulnerability’s root cause is not a bug in the Struts 2 framework, but a feature of the FreeMarker Template Language, which is a popular template language being commonly used in Apache Struts and other Java based projects, being misused by the application developers. The feature allows developers to bind the values of the parameters that are being passed to the server by the application users to the application inner declared variables. This evaluation of the user’s input allows attackers to send an Object Graph Navigation Language (OGNL) expressions which are supported by the Struts 2 framework to the server and their evaluation may lead to malicious code being executed on the server. Examples for such misuse of this feature can be found in the original bulletin posted by the Apache Struts 2 team (S2-053). A few proof of concept exploits for this vulnerability have already been published and are available for download over the web. Mitigating the 0-day with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this 0-day vulnerability, as the exploitation attempt will be detected by the existing JAVA code injection and command execution attack signatures which can be found in signature sets that include “Command Execution” and “Server Side Code Injection” attack types or “Java Servlets/JSP” System. The existing signatures are being proactive by detecting any attacker’s code injection or OS command execution attempts, without relying on specific 0day trigger that might allow the attacker to push this payload, making the application protection resistant to many future 0day vulnerabilities. At least 10 attack signatures were triggered by each attemptto exploit a protected Struts 2 application using the already available exploits, following are few of the ASM logs of the blocked attempts: Figure 1: Exploit blocked with Attack Signature (200004224) Figure 2: Exploit blocked with Attack Signature (200003458) Figure 3: Exploit blocked with Attack Signature (200003470) Mitigating the 0-day with F5 Silverline WAF Much like on-prem BIG-IP ASM customers, F5 Silverline WAF customers are already protected against this 0-day vulnerability. The exploitation attempt will be detected by the existing JAVA code injection and command execution attack signatures built within Silverline WAF standard policies. The following is a WAF Policy Violations Search that shows blocked requests that match the Signature IDs representative of CVE-2017-12611:653Views0likes0CommentsApache Struts 2 REST plugin Remote Code Execution (CVE-2017-9805)
In the recent days, a new critical Apache Struts 2 vulnerability was announced which allows remote attackers to execute arbitrary commands on the server. The original post (S2-052) has not published exploit details yet, most probably to allow organizations to properly patch their servers, though certain exploits are already available. Deserialization vulnerabilities in a nutshell Serialization is the process of converting an in-memory object to another format suitable for transportation over the network or outputting it to a disk. Deserialization is the opposite way around, instantiating an object in runtime from a data received over the network or read from a disk. Deserialization vulnerabilities occur when applications accept serialized objects from users without first validating the inputted data. CVE-2017-9805 JAVA deserialization vulnerabilities have been “making waves” since at least 2015. Recently, a new deserialization vulnerability was published affecting Apache Struts 2 REST plugin (CVE-2017-9805) which utilizes the JAVA XStream XML serialization library for deserializing the users input. The vulnerability is triggered when Apache Struts 2 REST plugin attempts to deserialize a specially crafted XML sent by the attacker and may consequently lead to Remote Code Execution. Multiple proof of concept exploits were already published including a dedicated Metasploit Framework module. Figure 1: Part of the specially crafted XML as sent by one of the POC exploits. Mitigating the 0-day with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this 0-day vulnerability, as the exploitation attempt will be detected by the existing JAVA code injection and command execution attack signatures which can be found in signature sets that include “Command Execution” and “Server Side Code Injection” attack types or “Java Servlets/JSP” System. The existing signatures are being proactive by detecting any attacker’s code injection or OS command execution attempts, without relying on specific 0day trigger that might allow the attacker to push this payload, making the application protection resistant to many future 0day vulnerabilities. Following are ASM logs of blocked attempts to exploit protected Struts 2 application using the already available exploits. Figure 2: Exploit blocked with Attack Signature (200004174) Figure 3: Exploit blocked with Attack Signature (200003440) Figure 4: Exploit blocked with Attack Signature (200100310) Mitigating the 0-day with F5 Silverline WAF Much like on-prem BIG-IP ASM customers, F5 Silverline WAF customers are already protected against this 0-day vulnerability. The exploitation attempt will be detected by the existing JAVA code injection and command execution attack signatures built within Silverline WAF standard policies. The following is a WAF Policy Violations Search that shows blocked requests that match the Signature IDs representative of CVE-2017-9805:834Views1like0CommentsApache Struts 2 Showcase Remote Code Execution (CVE-2017-9791)
In the recent days a new Apache Struts 2 vulnerability was published (S2-048) (CVE-2017-9791) and a POC code exploiting it was publicly released. The vulnerability lies in the Apache Stratus 2.3.x Showcase application when using the Struts 2 Struts 1 plugin which allows developers to use Struts 1 Actionand ActionFormobjects in Struts 2 applications. The application is using untrusted user input as part of a message presented to the user in the ActionMessage class which is the root cause of this vulnerability. Mitigation with BIG-IP ASM ASM customers under any supported BIG-IP versionare already protected against this vulnerability. While exploiting this vulnerability attacker will try to send a malicious HTTP POST request containing multiple JAVA code injections and Object Graph Navigation Library expressions injections. Figure 1: Request example containing the exploitation attempt The exploitation attempt will be detected by many existing Java Code Injection, Object Graph Navigation Library expressions and several OS command execution attack signatures which can be found in signature sets that include "Command Execution" and "Server Side Code Injection" attack types or "Java Servlets/JSP" system. Figure 2: Exploit blocked with Attack Signature (200004224) Figure 3: Exploit blocked with Attack Signature (200003458) Figure 4: Exploit blocked with Attack Signature (200003470)556Views0likes0CommentsApache Struts Remote Code Execution Vulnerability (CVE-2017-5638)
Update In the recent days we have noticed a new exploit variant related to this vulnerability. This new exploit attempts to inject Java code into the file name parameter of the multipart upload request. Figure 1: Request example containing the new exploitation vector. ASM is able to mitigate this new exploit variant using the following user-defined signature: content:"com"; content:"opensymphony"; distance:0; re2:"/\bcom[\.\/]opensymphony\b/"; An official ASM Security Update including this fix has already been released. An advisory has been published regarding a critical 0-day Remote Code Execution vulnerability in Apache Struts. The vulnerability resides in the Apache Jakarta multipart parser and is triggered when it tries to parse the Content-Type header of the HTTP request, allowing remote attackers to execute arbitrary code on the vulnerable server. An exploit for this vulnerability has already beenpublished. Mitigation with Big-IP ASM ASM customers are already protected against this vulnerability. While exploiting this vulnerability attacker will try to send a malicious HTTP multipart request containing multiple Java code injection payloads. Figure 2: An attempt to exploit this vulnerability as it was cought on our honeypot. The exploitation attempt will be detected by many existing Java Code Injection attack signatures and several OS command execution ones. Figure 3:Exploit blocked with Attack Signature (200003459) Figure 4:Exploit blocked with Attack Signature (200003471) Figure 5:Exploit blocked with Attack Signature (200004153) Figure 6:Exploit blocked with Attack Signature (200003450) Figure 7:Exploit blocked with Attack Signature (200003058) Figure 8:Exploit blocked with Attack Signature (200003441) Mitigating with iRules In the event you do not yet have ASM in your toolbelt,F5 has updated the official KB article to include an iRule that will protect your vulnerable web servers behind the BIG-IP. Mitigating the 0-day with F5 Silverline WAF Much like on-prem BIG-IP ASM customers, F5 Silverline WAF customers are already protected against this 0-day vulnerability. The exploitation attempt will be detected by the existing JAVA code injection and command execution attack signatures built within Silverline WAF standard policies. The following is a WAF Policy Violations Search that shows blocked requests that match the Signature IDs representative ofCVE-2017-5638:1KViews0likes2Comments