Hi again and a happy new year 2013!
Lets continue were I left you the last time.
The CTL is basically a binary TLV file with 1 byte type, followed by 2 bytes length and finally the data. But as this is far to easy, some special fields omit the length field and just place the data after the type (I guess those are fields with a fixed length). Here is an example CTL file:
Red fields are the types (counting up), green fields are the length (note the missing length on some fileds) and the purple field contains the data (in this case data with a length of 8 bytes and a type 0x05, which is the signing cert serial number btw. [and yes, this is a real example; Cisco signs phone loads with this ‘random’ cert]).
The CTL contains a header with types from 0x01 to 0x0f which is padded with 0x0d. The same header is used for the signed files .sgn from the TFTP server later on. The header describes the file version, the header length, the certificate the file is signed by (further called Signing Cert), the corresponding Certificate Authority, the file name, the files time stamp and finally the signature. The header is followed by multiple cert entries, which again use types 0x01 to 0x0f. The cert entry contains a role field 0x04 which describes the use of the cert. We are interested in the CAPF cert (0x04) and the Call Manager cert (0x02).
So, after parsing the CTL we got 3 certificates:
- The Signing Cert
- The CAPF Cert
- The Call Manager Cert
These are all the certs we worried about the last time. Now that we know how the CTL is build, it’s just a little more than a finger exercise to write a tool that extracts the valid certificates, replace the public key embedded and recreates the signature of the CTL (remember, the public key of the Signing Cert is included in the CTL, so by replacing the public key we can create a valid signature).
To deliver the CTL we need to become Man-in-the-Middle of the TFTP stream. We could have used a spoofed DHCP response, but decided to use ARP-spoofing and some rather ugly ebtables / iptables magic. Also a TFTP-Proxy which downloads the original files and modifies them on the fly comes in handy as we also need to update the signature of every .sgn file downloaded by the phone later on. Given the attack is successful the phone expects the files to be signed with our updated Signing Cert key.
So…. given we set up everything the right way: We are Man-in-the-Middle in the Phone <-> Call Manager communication, we got the TFTP-Proxy running and finally reboot the phone so it requests our modified CTL, what happens?
Well…. If the phone is not provisioned yet, it has no other choice than to believe in the information we sent, as no Root of Trust has been established on the phone yet. If the phone is provisioned it already got a CTL on the local memory and, at least that’s what Cisco’s documentation says, checks if the Signing Cert of the updated CTL is in the local trust store (which our modified Signing Cert isn’t) and decides on that information if the previous CTL is updated. That is true for at least some phones.
Still, this is not quite a real attack scenario, as we need to reboot the phone manually. Since if we could do so, we could also hold # and type the 123456789*0 to clear the local trust store. But by the time we had the CTL structure analyzed, we also found that simple SYN-flooding will reboot a phone after 30-60 seconds. In the end we found some phones that resisted the attack (as they were provisioned and did the validation right) but we also found a very willingly target which by accident made a good demo subject, the Cisco IP Communicator. In fact it was so willingly as a target, that the attack worked every time, no matter if the Communicator was provisioned or not. Also the Denial of Service vulnerability was present in the software, so win-win here (; .
The next step was to MitM the CAPF communication and again exchange the Certificate Signing Request sent from the client with our own, send our own CSR to the CAPF server and reply to the client with his CSR signed by our modified CAPF Cert. Reaching this point,everything becomes quite straight forward, as we got both, a client cert accepted by the Call Manager and a server certificate injected into the client, making him believe we are the valid Call Manager. Clear text SIP for the win! Now we are in the signalling channel and can push config updates to the phone, abort incoming or outgoing calls and of course we get the crypto material for all calls. Finally SRTP MitM appears as the next logical step…
And this is how we broke a Cisco high secure Enterprise Solution. In fact not all (hard-)phones and not all (hard-)phone firmwares are vulnerable, but as we know by now, the IP Communicator totally is. In the process of Responsible Disclosure we were told that on shutdown the phone deletes its local trust store and remains in a kind of unprovisioned state m( . In other words: It always trusts the CTL seen first…
The tools we used are free for publishing now.But please be aware, they were written while reversing the file format of the CTL and that’s how they look like (; . Also I didn’t manage to package them for release, which will take some more time. If you want or need them right now, just drop me an email. I hope to see you all @ TROOPERS13 and I’m looking forward to get into a lot of constructive discussions on that topic.