logo
DATABASE RESOURCES PRICING ABOUT US

SpringShell RCE vulnerability: Guidance for protecting against and detecting CVE-2022-22965

Description

**_April 11, 2022 update_** – __Azure Web Application Firewall (WAF) customers with Regional WAF with Azure Application Gateway now has enhanced protection for critical Spring vulnerabilities - [CVE-2022-22963](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22963>), [CVE-2022-22965](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965>), and [CVE-2022-22947](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22947>)._ _See [](<https://www.microsoft.com/security/blog/wp-admin/post.php?post=110715&action=edit#detectandprotect>)Detect and protect with Azure Web Application Firewall (Azure WAF) section for details__. On March 31, 2022, vulnerabilities in the Spring Framework for Java were [publicly disclosed](<https://www.springcloud.io/post/2022-03/spring-framework-rce-early-announcement/#gsc.tab=0>). Microsoft is currently assessing the impact associated with these vulnerabilities. This blog is for customers looking for protection against exploitation and ways to detect vulnerable installations on their network of the critical remote code execution (RCE) vulnerability [CVE-2022-22965](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965>) (also known as SpringShell or Spring4Shell). The Spring Framework is the most widely used lightweight open-source framework for Java. In Java Development Kit (JDK) version 9.0 or later, a remote attacker can obtain an _AccessLogValve _object through the framework’s parameter binding feature and use malicious field values to trigger the pipeline mechanism and write to a file in an arbitrary path, if certain conditions are met. The vulnerability in Spring Core—referred to in the security community as SpringShell or Spring4Shell—can be exploited when an attacker sends a specially crafted query to a web server running the Spring Core framework. Other vulnerabilities disclosed in the same component are less critical and not tracked as part of this blog. Impacted systems have the following traits: * Running JDK 9.0 or later * Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and earlier versions * Apache Tomcat as the Servlet container: * Packaged as a traditional Java web archive (WAR) and deployed in a standalone Tomcat instance; typical Spring Boot deployments using an embedded Servlet container or reactive web server are not impacted * Tomcat has _spring-webmvc_ or _spring-webflux_ dependencies Any system using JDK 9.0 or later and using the Spring Framework or derivative frameworks should be considered vulnerable. The following nonmalicious command can be used to determine vulnerable systems: $ curl host:port/path?class.module.classLoader.URLs%5B0%5D=0 A host that returns an HTTP 400 response should be considered vulnerable to the attack detailed in the proof of concept (POC) below. Note that while this test is a good indicator of a system’s susceptibility to an attack, any system within the scope of impacted systems listed above should still be considered vulnerable. The [](<https://www.microsoft.com/microsoft-365/security/microsoft-365-defender>)[threat and vulnerability management](<https://docs.microsoft.com/azure/defender-for-cloud/deploy-vulnerability-assessment-tvm>) console within [Microsoft 365 Defender](<https://www.microsoft.com/microsoft-365/security/microsoft-365-defender>) provides detection and reporting for this vulnerability. This blog covers the following topics: 1. Observed activity 2. Attack breakdown 3. The vulnerability and exploit in depth * Background * Request mapping and request parameter binding * The process of property binding * The vulnerability and its exploitation * Prelude: CVE-2010-1622 * The current exploit: CVE-2022-22965 * From ClassLoader to AccessLogValve 4. Discovery and mitigations * How to find vulnerable devices * Enhanced protection with Azure Firewall Premium * Detect and protect with Azure Web Application Firewall (Azure WAF) * Global WAF with Azure Front Door * Regional WAF with Azure Application Gateway * Patch information and workarounds 5. Detections * Microsoft 365 Defender * Endpoint detection and response (EDR) * Antivirus * Hunting * Microsoft 365 Defender advanced hunting queries * Microsoft Sentinel ## Observed activity Microsoft regularly monitors attacks against our cloud infrastructure and services to defend them better. Since the Spring Core vulnerability was announced, we have been tracking a low volume of exploit attempts across our cloud services for Spring Cloud and Spring Core vulnerabilities. For CVE-2022-22965, the attempts closely align with the basic web shell POC described in this post. Microsoft’s continued monitoring of the threat landscape has not indicated a significant increase in quantity of attacks or new campaigns at this time. ## Attack breakdown CVE-2022-22965 affects functions that use request mapping annotation and Plain Old Java Object (POJO) parameters within the Spring Framework. The POC code creates a controller that, when loaded into Tomcat, handles HTTP requests. The only publicly available working POC is specific to Tomcat server's logging properties via the _ClassLoader_ module in the _propertyDescriptor_ cache. The attacker can update the _AccessLogValve_ class using the module to create a web shell in the Tomcat root directory called _shell.jsp_. The attacker can then change the default access logs to a file of their choosing. ![Screenshot of an application UI with lines of code. One of said code lines is highlighted, with an annotation written in a non-English language.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/04/fig1-poc-screenshot.png)Figure 1. Screenshot from the original POC code post The changes to _AccessValveLog_ can be achieved by an attacker who can use HTTP requests to create a _.jsp_ file in the service’s root directory. In the example below, each GET parameter is set as a Java object property. Each GET request then executes a Java code resembling the example below, wherein the final segment “setPattern” would be unique for each call (such as setPattern, setSuffix, setDirectory, and others): ![Screenshot of Java codes of an actual exploit.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/04/springshell-code-snippet1.png) ![Screenshot of several lines of HTTP URLs.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/04/fig2-poc-screenshot.png)Figure 2. Screenshot from the original POC code post ![Screenshot of an application UI with lines of code.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/04/fig3-poc-screenshot.png)Figure 3. Screenshot from the original POC code post The _.jsp_ file now contains a payload with a password-protected web shell with the following format: ![Screenshot of the payload's web shell code.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/04/springshell-code-snippet3.png) The attacker can then use HTTP requests to execute commands. While the above POC depicts a command shell as the inserted code, this attack could be performed using any executable code. ## The vulnerability and exploit in depth The vulnerability in Spring results in a client's ability, in some cases, to modify sensitive internal variables inside the web server or application by carefully crafting the HTTP request. In the case of the Tomcat web server, the vulnerability allowed for that manipulation of the access log to be placed in an arbitrary path with somewhat arbitrary contents. The POC above sets the contents to be a JSP web shell and the path inside the Tomcat's web application ROOT directory, which essentially drops a reverse shell inside Tomcat. For the web application to be vulnerable, it needs to use Spring’s request mapping feature, with the handler function receiving a Java object as a parameter. ### Background #### Request mapping and request parameter binding Spring allows developers to map HTTP requests to Java handler methods. The web application's developer can ask Spring to call an appropriate handler method each time a user requests a specific URI. For instance, the following web application code will cause Spring to invoke the method _handleWeatherRequest_ each time a user requests the URI _/WeatherReport_: @RequestMapping("/WeatherReport") public string handleWeatherRequest(Location reportLocation) { … } Moreover, through request parameter binding, the handler method can accept arguments passed through parameters in GET/POST/REST requests. In the above example, Spring will instantiate a _Location_ object, initialize its fields according to the HTTP request’s parameters, and pass it on to _handleWeatherRequest_. So, if, for instance, _Location_ will be defined as: class Location { public void setCountry(string country) {…} public void setCity(string city) {…} public string getCountry() {…} public string getCity() {…} } If we issue the following HTTP request: example.com/WeatherReport?country=USA&city=Redmond The resulting call to _handleWeatherRequest_ will automatically have a _reportLocation_ argument with the country set to USA and city set to Redmond. If _Location_ had a sub-object named _coordinates_, which contained _longitude_ and _latitude_ parameters, then Spring would try and initialize them out of the parameters of an incoming request. For example, when receiving a request with GET params _coordinates.longitude=123&coordinate.latitude=456_ Spring would try and set those values in the _coordinates_ member of _location_, before handing over control to _handleWeatherRequest_. The SpringShell vulnerability directly relates to the process Spring uses to populate these fields. #### The process of property binding Whenever Spring receives an HTTP request mapped to a handler method as described above, it will try and bind the request’s parameters for each argument in the handler method. Now, to stick with the previous example, a client asked for: example.com/WeatherReport?x.y.z=foo Spring would instantiate the argument (in our case, create a _Location_ object). Then it breaks up the parameter name by dots (.) and tries to do a series of steps: 1. Use Java introspection to map all accessors and mutators in _location_ 2. If location has a getX_()_ accessor, call it to get the _x_ member of location 3. Use Java introspection to map all accessors and mutators in the_ x_ object 4. If the _x_ object has a _getY_() accessor, call it to get the _y_ object inside of the _x_ object 5. Use Java introspection to map all accessors and mutators in the_ y_ object 6. If the _y_ object has a _setZ()_ mutator, call it with parameter _“foo”_ So essentially, ignoring the details, we get _location.getX().getY().setZ(“foo”)_. ### The vulnerability and its exploitation #### Prelude: CVE-2010-1622 In June 2010, a CVE was [published](<https://nvd.nist.gov/vuln/detail/CVE-2010-1622>) for the Spring framework. The crux of the CVE was as follows: 1. All Java objects implicitly contain a _getClass()_ accessor that returns the _Class_ describing the object's class. 2. _Class_ objects have a _getClassLoader()_ accessor the gets the _ClassLoader_ object. 3. Tomcat uses its own class loader for its web applications. This class loader contains various members that can affect Tomcat’s behavior. One such member is _URLs_, which is an array of URLs the class loader uses to retrieve resources. 4. Overwriting one of the URLs with a URL to a remote JAR file would cause Tomcat to subsequently load the JAR from an attacker-controlled location. The bug was fixed in Spring by preventing the mapping of the _getClassLoader()_ or _getProtectionDomain()_ accessors of _Class_ objects during the property-binding phase. Hence _class.classLoader_ would not resolve, thwarting the attack. #### The current exploit: CVE-2022-22965 The current exploit leverages the same mechanism as in CVE-2010-1622, bypassing the previous bug fix. Java 9 added a new technology called Java Modules. An accessor was added to the _Class_ object, called _getModule()_. The _Module_ object contains a _getClassLoader()_ accessor. Since the CVE-2010-1622 fix only prevented mapping the _getClassLoader()_ accessor of _Class_ objects, Spring mapped the _getClassLoader()_ accessor of the _Module_ object. Once again, one could reference the class loader from Spring via the _class.module.classLoader_ parameter name prefix. #### From _ClassLoader_ to _AccessLogValve_ The latest exploit uses the same accessor chaining, via the Tomcat class loader, to drop a JSP web shell on the server. This is done by manipulating the properties of the _AccessLogValve_ object in Tomcat’s pipeline. The _AccessLogValve _is referenced using the _class.module.classLoader.resources.context.parent.pipeline.first_ parameter prefix. The following properties are changed: 1. **Directory: **The path where to store the access log, relative to Tomcat’s root directory. This can be manipulated to point into a location accessible by http requests, such as the web application’s directory. 2. **Prefix: **The prefix of the access log file name 3. **Suffix: **The suffix of the access log file name. The log file name is a concatenation of the prefix with the suffix. 4. **Pattern: **A string that describes the log record structure. This can be manipulated so that each record will essentially contain a JSP web shell. 5. **FileDateFormat:** Setting this causes the new access log settings to take effect. Once the web shell is dropped on the server, the attacker can execute commands on the server as Tomcat. ## Discovery and mitigations ### How to find vulnerable devices [Threat and vulnerability management](<https://www.microsoft.com/security/business/threat-protection/threat-vulnerability-management>) capabilities in [Microsoft Defender for Endpoint](<https://www.microsoft.com/security/business/threat-protection/endpoint-defender>) monitor an organization’s overall security posture and equip customers with real-time insights into organizational risk through continuous vulnerability discovery, intelligent prioritization, and the ability to seamlessly remediate vulnerabilities. Customers can now search for CVE-2022-22965 to find vulnerable devices through the [Weaknesses](<https://securitycenter.microsoft.com/vulnerabilities?search=CVE-2022-22965>) page in threat and vulnerability management. ![Screenshot of the Weaknesses page where one can search for CVE-2022-22965 to find vulnerable devices.](https://www.microsoft.com/security/blog/uploads/securityprod/2022/04/image.png)Figure 4. Weaknesses page in Microsoft Defender for Endpoint ### Enhanced protection with Azure Firewall Premium Customers using [Azure Firewall Premium](<https://docs.microsoft.com/azure/firewall/premium-migrate>) have enhanced protection from the SpringShell CVE-2022-22965 vulnerability and exploits. Azure Firewall Premium Intrusion Detection and Prevention System (IDPS) provides IDPS inspection for all east-west traffic, outbound traffic to the internet, and inbound HTTP traffic from the internet. The vulnerability rulesets are continuously updated and include vulnerability protection for SpringShell since March 31, 2022. The screenshot below shows all the scenarios which are actively mitigated by Azure Firewall Premium. Configure Azure Firewall Premium with both IDPS Alert & Deny mode and TLS inspection enabled for proactive protection against CVE-2022-22965 exploit. ![](https://www.microsoft.com/security/blog/uploads/securityprod/2022/04/image-6254b5e76dfa5-1024x214.png)Figure 5. Azure Firewall Premium portal detecting CVE-2022-22965 exploitation attempts. Customers using Azure Firewall Standard can migrate to Premium by following [these directions](<https://docs.microsoft.com/azure/firewall/premium-migrate>). Customers new to Azure Firewall Premium can learn more about [Firewall Premium](<https://docs.microsoft.com/azure/firewall/premium-features>). ### Detect and protect with Azure Web Application Firewall (Azure WAF) Azure Web Application Firewall (WAF) customers with Azure Front Door and Azure Application Gateway deployments now have enhanced protection for the SpringShell exploit - [CVE-2022-22965](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965>), and other high impact Spring vulnerabilities [CVE-2022-22963](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22963>) and [CVE-2022-22947](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22947>). To help detect and mitigate these critical Spring vulnerabilities, we have released four new rules. #### Global WAF with Azure Front Door Azure WAF has updated Default Rule Set (DRS) versions 2.0/1.1/1.0. * Rule group: _MS-ThreatIntel-WebShells_, Rule Id: 99005006 - Spring4Shell Interaction Attempt * Rule group: _MS-ThreatIntel-CVEs_, Rule Id: 99001014 - Attempted Spring Cloud routing-expression injection (CVE-2022-22963) * Rule group: _MS-ThreatIntel-CVEs_, Rule Id: 99001015 - Attempted Spring Framework unsafe class object exploitation (CVE-2022-22965) * Rule group: _MS-ThreatIntel-CVEs_, Rule Id: 99001016 - Attempted Spring Cloud Gateway Actuator injection (CVE-2022-22947) WAF rules on Azure Front Door are disabled by default on existing Microsoft managed rule sets. ![Screenshot of WAF Spring vulnerabilities](https://www.microsoft.com/security/blog/uploads/securityprod/2022/04/image-62509b118c13f.png)Figure 6. Screenshot of WAF Spring vulnerabilities #### Regional WAF with Azure Application Gateway Azure WAF has updated OWASP Core Rule Set (CRS) versions for Azure Application Gateway WAF V2 regional deployments. New rules are under _Known_CVEs_ rule group: * Rule Id: 800110 - _Spring4Shell Interaction Attempt_ * Rule Id: 800111 - _Attempted Spring Cloud routing-expression injection_ - CVE-2022-22963 * Rule Id: 800112 - _Attempted Spring Framework unsafe class object exploitation_ - CVE-2022-22965 * Rule Id: 800113 - _Attempted Spring Cloud Gateway Actuator injection_ - CVE-2022-22947 WAF rules on Azure Application Gateway are _enabled_ by default for supported CRS versions. ![Screenshot of Spring vulnerability rules for Azure Application Gateway OWASP Core Rule Set \(CRS\) ](https://www.microsoft.com/security/blog/uploads/securityprod/2022/04/image-6254b545679bb-1024x465.png)Figure 7. Spring vulnerability rules for Azure Application Gateway OWASP Core Rule Set (CRS) **Recommendation**: Enable WAF SpringShell rules to get protection from these threats. We will continue to monitor threat patterns and modify the above rules in response to emerging attack patterns as required. For more information about Managed Rules and Default Rule Set (DRS) on Azure Front Door, see the [Web Application Firewall DRS rule groups and rules documentation](<https://docs.microsoft.com/azure/web-application-firewall/afds/waf-front-door-drs>). For more information about Managed Rules and OWASP Core Rule Set (CRS) on Azure Application Gateway, see the [Web Application Firewall CRS rule groups and rules documentation](<https://docs.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules?tabs=owasp32>) ### Patch information and workarounds Customers are encouraged to apply these mitigations to reduce the impact of this threat. Check the recommendations card in Microsoft 365 Defender threat and vulnerability management for the deployment status of monitored mitigations. * An [update](<https://spring.io/blog/2022/03/31/spring-boot-2-6-6-available-now>) is available for CVE-2022-22965. Administrators should upgrade to versions 5.3.18 or later or 5.2.19 or later. If the patch is applied, no other mitigation is necessary. If you’re unable to patch CVE-2022-22965, you can implement this set of workarounds published by [Spring](<https://www.springcloud.io/post/2022-03/spring-framework-rce-early-announcement/#gsc.tab=0>): * Search the @InitBinder annotation globally in the application to see if the dataBinder.setDisallowedFields method is called in the method body. If the introduction of this code snippet is found, add `{"class.*","Class.*","*.class.*", "*.Class.*"}` to the original blacklist. (**Note:** If this code snippet is used a lot, it needs to be appended in each location.) * Add the following global class into the package where the Controller is located. Then recompile and test the project for functionality: import org.springframework.core.annotation.Order; import org.springframework.web.bind.WebDataBinder; import org.springframework.web.bind.annotation.ControllerAdvice; import org.springframework.web.bind.annotation.InitBinder; @ControllerAdvice @Order(10000) public class GlobalControllerAdvice{ @InitBinder public void setAllowedFields(webdataBinder dataBinder){ String[]abd=new string[]{"class.*","Class.*","*.class.*","*.Class.*"}; dataBinder.setDisallowedFields(abd); } } ## Detections ### Microsoft 365 Defender #### Endpoint detection and response (EDR) Alerts with the following title in the security center can indicate threat activity on your network: * Possible SpringShell exploitation The following alerts for an observed attack, but might not be unique to exploitation for this vulnerability: * Suspicious process executed by a network service #### Antivirus Microsoft Defender antivirus version **1.361.1234.0** or later detects components and behaviors related to this threat with the following detections: * Trojan:Python/SpringShellExpl * Exploit:Python/SpringShell * Backdoor:PHP/Remoteshell.V ### Hunting #### Microsoft 365 Defender advanced hunting queries Use the query below to surface exploitation of CVE-2022-22965 on both victim devices and devices performing the exploitation. Note that this query only covers HTTP use of the exploitation and not HTTPS. DeviceNetworkEvents | where Timestamp > ago(7d) | where ActionType =~ "NetworkSignatureInspected" | where AdditionalFields contains ".jsp?cmd=" | summarize makeset(AdditionalFields, 5), min(Timestamp), max(Timestamp) by DeviceId, DeviceName #### Microsoft Sentinel Microsoft Sentinel customers can use the following queries to look for this threat activity: * [Possible SpringShell exploitation attempt (CVE-2022-22965)](<https://github.com/Azure/Azure-Sentinel/blob/master/Hunting Queries/AzureDiagnostics/SpringShellExploitationAttempt.yaml>) – This hunting query looks in Azure Web Application Firewall data to find possible SpringShell exploitation attempt (CVE-2022-22965) to drop a malicious web shell in a location accessible by HTTP requests. Attackers then make requests to the malicious backdoor to run system commands. * [Possible web shell usage attempt related to SpringShell (CVE-2202-22965)](<https://github.com/Azure/Azure-Sentinel/blob/master/Hunting Queries/AzureDiagnostics/SpringshellWebshellUsage.yaml>) – This hunting query looks in Azure Web Application Firewall data to find possible web shell usage related to SpringShell RCE vulnerability (CVE-2022-22965). * [AV detections related to SpringShell Vulnerability](<https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SecurityAlert/AVSpringShell.yaml>) – This query looks for Microsoft Defender for Endpoint hits related to the SpringShell vulnerability. In Microsoft Sentinel, the _SecurityAlerts _table includes only the device name of the affected device. This query joins the _DeviceInfo _table to clearly connect other information such as device group, IP address, signed in users, and others. This allows the Microsoft Sentinel analyst to have more context related to the alert, if available. **Revision history** _[04/11/2022] – _Application Gateway now has enhanced protection for critical Spring vulnerabilities - [CVE-2022-22963](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22963>), [CVE-2022-22965](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965>), and [CVE-2022-22947](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22947>)._ _See _Detection and Mitigation section for details_. _[04/08/2022] – Azure Web Application Firewall (WAF) customers with Azure Front Door now has enhanced protection for Spring4Shell exploits - CVE-2022-22963, CVE-2022-22965, and CVE-2022-22947. See Detection and Mitigation section for details. [04/05/2022] – We added Microsoft Sentinel hunting queries to look for SpringShell exploitation activity._ The post [SpringShell RCE vulnerability: Guidance for protecting against and detecting CVE-2022-22965](<https://www.microsoft.com/security/blog/2022/04/04/springshell-rce-vulnerability-guidance-for-protecting-against-and-detecting-cve-2022-22965/>) appeared first on [Microsoft Security Blog](<https://www.microsoft.com/security/blog>).


Related