Breaking
by Daniel Mende

A Word on Cisco Jabber

Recently we took a look on Ciscos XMPP client, called Cisco Jabber. The Client is used in combination with Ciscos Unified Communication Server (CUCM) and Ciscos Unified Presence Server (CUPS). Only the latter one is used for XMPP communication.

We built a small lab setup with this components (CUCM, CUPS and the Win7 Client) and watched the client working.

First the client connects to a web service at https://CUPS:8443/EPASSoap/service/v80. We intercepted this connection with the Burp Proxy and had no problems getting into the SSL. Inside we found a SOAP request containing the users authentication credentials and a SOAP response with a onetime password, which is used for authentication in the XMPP stream later on. Phew, the users credentials _and_ unlimited onetime passwords _that_ easy? Thanks Cisco!

Next we simply sniffed the XMPP communication:


<?xml version='1.0' ?><stream:stream to='domain.not.set' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'  xml:lang='en' version='1.0'>

<stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' xml:lang='en-US.UTF-8' id='1C5A9228B1' from='domain.not.set' version='1.0'><stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'><required/></starttls></stream:features>

<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

.h....?.....k..j..:..9..8..5.............g..@..4..3..2../.
..................~..P..../.ZfhF...[.k.R..Wi4.

....Q...M..Q,..4.........%/.|......'ww.PH...w...l...
oM.dB.Y<;.BWh&..K..>..4.5.......................0.
..0..........P .... J.h......0

Data sent by the client is displayed in red and data sent by the server is displayed in blue. As XMPP is a XML based protocol, we can easily read the messages exchanged in the beginning. In the first message the client requests a stream to out lab domain ‘domain.not.set’. The second message assigns a stream to the client with the stream id ‘1C5A9228B1’ and also signals that TLS is required for further communication, which is signaled in the next two messages. After that the TLS handshake occurs and we see the binary TLS messages. This messages can be read in wireshark, if decoded as SSL, and contain the client and server hello. After the TLS handshake the hole stream is encrypted and not longer readable.

So far so good. After simply sniffing the communication we got in a Man-in-the-Middle position via ARP spoofing and built a simple xmpp_proxy to modify the XMPP data on the fly. We tried to simply strip the STARTTLS message from the client [remember IMAP ? (-: ] but that didn’t succeed, as the server is waiting for a STARTLS and does not go on without.

The next thing to do was get a MitM in the TLS stream as well. So we enhanced our xmpp_proxy to act on the starttls packet and set up two different TLS streams, one to the client and one to the server. This worked out quite well, even better than expected, given that I just used some random cert found on my hard disk for the server side. Here is what it looked like:

xmpp_proxy

You see the Burp Proxy with the onetime password in the back, the xmpp_proxy with clear text XMPP in the front and the happily connected Cisco XMPP Client on the right.

So all in all this was a quite easy one 😀

cheers

/daniel

Comments

  1. Nice work. What versions of CUCM, CUP and Win7 Jabber client? Did you test Cisco’s Jabber client for Mac? Any others? Did you notify Cisco?

    1. Hi,

      the following components were used in the lab:

      CUCM 8.0.3,
      Presence Server 8.6.1,
      Jabber client Version 9.1.0 Build 12296

      Of course we’re quite interested to hear if other versions of any of those entities behave differently from what we observed (in particular re the – lack of – certificate validation).

      take care

      Daniel

  2. Thanks for the versions. Looking at the Cisco website, those are all very old versions. There have been many updates.

    Have you tested with the latest?

    Did you notify Cisco before going public?

  4. I would be interested to see what happens with later versions of Jabber 9.2 and CM9/CM10.

    The most recent versions of Jabber 9.2 attempt to validate certificates and prompt the user if they cannot be validated with CA root certificates found in the OS store.

    It is certainly true that a user could blindly click through or have a false root in their store, but at least it is something.

    1. Hi,

      we have not looked at the newer versions of Cisco Jabber, yet. Its good to hear they implemented some kind of certificate validation but i can not say from here if its sufficient (as in do they validate certs on all connection, are they verifying correctly, etc.)

      cheers

      /daniel

Comments are closed.