Zero Day Exploit Analysis for VX Search Enterprise

VX Search is an automated, rule-based file search solution allowing users to search files by various attributes. Recently, a remotely exploitable zero day was released for VX Search and the PoC is published on exploit-db. The exploit targets a vulnerability in VX Search Enterprise and attackers can execute code with SYSTEM privilege remotely. In this blog, I have analysed the root cause of the vulnerability and also the attacking techniques used in the exploit.

Vulnerability Analysis:

VX Search Enterprise starts a web server running on port 80. Users will be asked to input the username and password in the login form. After clicking the login butter, a POST request will be sent to the web server along with the username and password. As you can see below

2016-10-10-loginpage

We’ll put the plaintext username and password aside. The server has a function called “ParsePostData” to process this POST request from the client. This function will call another function “ExtractPostData” to extract the content out in the POST request. Both functions are in “libspp.dll” which is shown below

2016-10-10-postdata

In the exploit, what the payload sent is a super long string after the password field

evil += "username=admin"

evil += "&password=aaaaa\r\n"

evil += "\x41" * 12292 #subtract/add for payload

evil += "w00tw00t"

evil += "\x90" * 20

evil += buf

evil += "\x90" * 50

evil += "\x42" * 1614

evil += nseh

evil += seh

evil += "\x90" * 20

evil += egghunter

evil += "\x90" * 7000

 

This “evil” POST request will be processed by “ParsePostData” and “ExtractPostData”. Then finally reaches the vulnerable function “GetNextString” of “SCA_HttpParser” object in libspp.dll.

“GetNextString” will try to get the next string after password field. It compares each byte of the payload after password field and copy the byte into stack if It’s not “\r” or “\n” or “&”. But the function doesn’t check boundaries, It will keep the over write the whole stack if these characters are not found.

2016-10-10-overflow

The cl register has the each byte from the payload. The vulnerable function compares cl with these 3 characters and copies the content in cl to [ESI+EDX] if it’s not one of them. EDX will increase one without any condition in each loop. The whole stack is over flowed. So this is a typical stack overflow vulnerability in the VX Search Enterprise software.

 

Attacking Techniques Used
Now the whole stack is overwritten by the payload from attacker, But EDX won’t stop increasing one (no condition plus one). So at last it will try to write a memory address which is out of the stack. An exception will be raised and the SEH will be called. Structured exception handling (SEH) is a mechanism for handling both hardware and software exceptions in Windows. So the SEH will kick in and try to recover the server from this memory access exception. This is exactly what the attacker wants.

2016-10-10-seh

You can see that the exception handler is set to 0x100159BE which is a “pop pop ret”. So after the vulnerable function “GetNextString” tries to write out of the stack. The program will start execute the code located at that SEH address.  “pop pop ret” will make the first exception handler to return then the next SHE handler will be called.

2016-10-10-egg-hunter

The next SHE record is also overwritten by the attacker’s payload. It will transfer the EIP to the “egg hunter” code. Why not directly to the shell code? This is because from the SEH record to the end of the stack .There is limited memory space which can’t hold decent length of shell code. To work around this, a technique called “egg hunter “is used. The purpose of this “egg hunter” code is to search the shellcode in memory then jumps to it (with offset of the string). To implement this, a special string is added before the real shellcode

evil += "w00tw00t"

evil += "\x90" * 20

evil += buf

So here, the “egg hunter” code will find the special string “w00tw00t”, then jumps to the nop instructions after it. After this the final shellcode will be executed.

2016-10-10-finalshellcode

 

I modified the exploit code with a replaced shellcode.  The shell code I used here is executing “calc.exe”.

 

After modifying all the offset within the payload, send the “evil” package to the remote web server.
As you can see below .The calculator is launched remotely with the SYSTEM privilege.

2016-10-10-calc

Conclusion

There is no patch available for this remote code execution vulnerability yet. As you can see, it’s not hard to migrate this exploit to other versions or other Operating Systems. So we recommend all the users of this software blocking untrusted access to this server from untrusted sites at this time. QualysGuard customers can scan for QID: 370152 to detect this vulnerability in their networks.

 

References:


https://www.exploit-db.com/exploits/40455/

https://msdn.microsoft.com/enus/library/windows/desktop/ms680657(v=vs.85).aspx

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *