After reading this information, the first thing that came to my mind was DLL hijacking. If the service only runs signed binaries by WebEx, then I might be able to find a binary capable of loading a malicious DLL.The easiest way to do that is by moving the signed binary to another directory in order to force the loading of our DLL. 

 

I decided to test the patch. After reading the advisory provided by Cisco –  which stated that the fixed version was 33.5.6 –  I discovered this wasn't quite accurate, since the installer for version 33.5.1.7 was not vulnerable to the attack. That made version 33.4.5.5 the last version vulnerable to CVE-2018-15442. 

 

So, I downloaded version 33.6.2.16 (which was the latest version at the time) and tried my idea to bypass the patch. 

To do this, I launched a Windows 10 x86-64 VM, with the latest version installed, Process Explorer and Process Monitor running (and logging only File System Activity) and tried the known attack in the console: 

sc start webexservice install software-update 1 "C:\Windows\System32\notepad.exe"

Of course, no notepad with SYSTEM privileges was executed, since this version is patched. But, after checking the Process Monitor's log, I saw something strange:

Image

The service binary (WebExService.exe) was trying to open the file "C:\Windows\SysWOW64\notepad.exe\ptupdate.exe." I tried the attack again, this time using the following command: 

sc start webexservice install software-update 1 "C:\Windows\System32\"

This resulted in the following: 

Image

The service tried to add "\ptupdate.exe" to the passed argument path. That meant that the binary file passed to the service needed to be signed and needed to be named "ptupdate.exe". 

 

To confirm, I tried:

sc start webexservice install software-update 1 "C:\Windows\System32"

and the result was: 

Image

That's it. Now I needed to find a binary that could be used to perform our attack. The first thing I searched was the binary whose name was appended to our path: ptupdate.exe. I found it in "C:\Program Files(x86)\Webex\Webex\Applications\ptUpdate.exe" 

 

So I wrote a little batch script as follows: 

mkdir %tmp%\hijack 


cd %tmp%\hijack 


copy "%ProgramFiles(x86)%\Webex\Webex\Applications\ptUpdate.exe" . 

Again, I tested the service by executing: 

sc start webexservice install software-update 1 "C:\Users\McFly\AppData\Local\Temp\hijack"

Note that we could not use environment variables in the path parameter passed to the service. 

 

And the signed binary was found:

Image

But it was not yet executed. 

 

After reviewing Ron's blogpost, I noticed his statement about the numeric parameter. He stated that the only number that would work in the third parameter was the number 1. But he didn't know why or what the number meant. As he used trial and error to "be lucky," I decided to do the same by performing a quick test: 

sc start webexservice install software-update 2 "C:\Users\McFly\AppData\Local\Temp\hijack"

Process Monitor showed the following:

Image

The outcome was that the signed binary executed! We also got lucky and the number 2 worked. Later, I found out that number 1 works with the previous version (33.6.0.655), so it was important to try with both numbers. 

Now it was time to perform our DLL hijacking. 

 

I created a small i386 DLL in ASM that executed notepad.exe on load. After looking in Process Monitor's log for "NAME NOT FOUND" for DLL files in our controlled path, I chose the name wbxtrace.dll:

Image

After naming our DLL as wbxtrace.dll, I placed it into our controlled folder and executed it again for an attack. Consequently, I got: 

Image

Our notepad.exe running as SYSTEM bypassed the patch. 

You can read our full advisory here.