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.
