Some of you may have heard the topic before, as we have spoken about on this years BlackHat Europe, TROOPERS12 and HES12, so this is nothing completely new, but as we’re done with responsible disclosure (finally (-; ) and all the stuff should be fixed, we’re going to publish the code that brought us there. I will split the topic into two blog posts, this one will wrap up the setup, used components and protocols, the next one [tbd. till EOY, hopefully] will get into detail on the tools and techniques we used to break the enterprise grade security.
The Components
First lets take a look on all the components involved in the setup:
As you can see in the picture, there are a lot of components and even more certificates involved. From left to right:
- The VoIP Phone: A Cisco phone, obviously. For this kind of setup a special series of phones (e.g. 7906G) is needed, as they ship with a MIC (Manufacturer Installed Certificate) installed. Later on (in the initial phone setup) they will receive a LSC (Local Significant Certificate).
- The Cisco Unified Communications Manager: The central call routing and phone controlling entity.
- Certificate Authority Proxy Function: This is more a service, than a physical component, often seen running on the same hardware as the CUCM. It’s acting as a Certificate Authority which issues the LSCs for all VoIP Phones.
- The Certificate Trust List: This is where the fun begins 😉 The CTL is a collection of all server-certificates used in the VoIP setup. It’s used by the phones as a Root of Trust, think of all the CA certificates located on your computer. The CTL is retrieved by the VoIP Phone during initial setup.
In addition to the described components a pair of Cisco USB Tokens ( KEY-CCM-ADMIN-K9= ) is needed. They are actually Aladdin Token, relabeled with a Cisco logo. They contain a (yet another) certificate, signed by the Cisco Manufacturer Certificate Authority (as the MICs are). The Tokens are needed to enable the CAPF service on the CUCM and the certificates stored on the Tokens are added to the CTL. Finally the CTL is signed with one of the Tokens private keys.
The Setup
There is a lot of configuration on the CUCM side needed to get the whole thing running. As I’m no Call Manager expert, i’ll just rudimentarily describe which actions are required:
- The TFTP Server needs to be configured as Secure-TFTP Server, which means it automatically signs files and also encrypts configuration files.
- The CTL must be pushed to the CUCM using a Windows software called CTL-Client.
- The CAPF Service has to be enabled.
- For the VoIP Phones a security profile which uses SIP-TLS is needed.
Last but not least, the VoIP Phones needs a Phone Load (firmware) which supports SIP-TLS (in our case SIP11.9-2-1ESIS).
The Protocols
There are 4 protocols in use here at which we need to take a look in this setup:
- TFTP, is used by the VoIP Phones to download the CTL and the Phones configuration file (also a lot of other files, like phone book fancy logos for the phone screen and a lot more, but they don’t bother us).
- CAPF, which is not only the name of the service, but also of the (proprietary) protocol used to deploy the LSCs to the phones.
- SIP-TLS, the signalling channel between the VoIP Phone and the CUCM (this is the holy grail, as here are the keys for the next protocol exchanged).
- SRTP, encrypted RTP which contains the voice data.
As this is a ‘high secure’ setup, each and every protocol named above has to do some crypto in a very special manner, obviously 😉 I’ll explain them inside-out:
SRTP is what we want, but its encrypted with keys from SIP-TLS, which itself is encrypted (and authenticated), using the CUCM’s Certificate on the Server side and the LSC on the client side (yes they do client auth!). OK, so for a SIP-TLS Man-in-the-Middle we somehow need to mess with two Certificates. We cant change the CUCM’s Cert, as this one is generated during setup and we (hopefully) can’t get its private key. But we can change the LSC, as it is deployed to the VoIP Phones, using the CAPF protocol. So, CAPF is next. It uses TLS for encryption and authentication as well and even it being proprietary, once seen in clear text its just some hello PKGs, then a CSR from phone to server and finally a certificate from the server to the phone. But as CAPF also uses TLS we’re in the same situation as with SIP-TLS again, can’t change the server certificate and this time we also can’t change the client certificate. But wait, what? Which client certificate? Isn’t this the protocol used to deploy the certificate to the client? Yes it is. But still the phone got a certificate right from the assembly line, the MIC. So this time the client authentication isn’t an IP-Address to certificate validation, but an ‘is this cert signed by Cisco Manufacturing’ validation, so every Cisco Manufacturing cert will work here (as I wasn’t able to extract the MIC from a phone and also neighborly help hasn’t arrived, yet, I’m using a cert and it’s private key, extracted from a Cisco IP-Communicator). That solves the client cert problem, but we still need to exchange the server certificate and this finally leads to the CTL. Each time a phone boots, it requests the CTL from the TFTP-Server, either to install a root of trust (if no previous one was found on the phone) or to check for an updated CTL. Inside the CTL are all the server certificates we need to replace, so the circle is complete.
The CTL itself is signed again, but more on this next time, when i’ll describe the structure of the mainly binary CTL as well as releasing Proof of Concept code.
Next stop Hamburg, see you @29C3, cheers and happy holidays
/daniel