Breaking SSL on Embedded Devices

No, this is not some new SSL vulnerability. In fact, it’s a really old vulnerability, as old as cryptography itself: keep your secret keys secret.

A lot of embedded devices provide HTTPS support so that administrators can administer the devices securely over untrusted networks. Some devices, such as SSL VPNs, center their entire functionality around SSL encryption. OK, well SSL isn’t perfect, but it’s still the de facto standard for Web-based encryption. So far, so good.

Here’s where it gets fun: many of these devices use hard-coded SSL keys that are baked into the firmware. That means that if Alice and Bob are both using the same router with the same firmware version, then both of their routers have the same SSL keys. All Eve needs to do in order to decrypt their traffic is to download the firmware from the vendor’s Web site and extract the SSL private key from the firmware image.

 

However, there are some practical limitations to this attack. If Eve doesn’t know what router or firmware version Alice and Bob are using, it will be difficult to impossible for her to identify which firmware image to extract the SSL keys from. A good example of this is DD-WRT. There are several versions of DD-WRT available for each router supported by DD-WRT. And for each of those versions, there are several different “flavors”: micro, standard, VPN, etc. Even if Eve knows that Alice and Bob are running DD-WRT, that’s a lot of firmware images to work through. This becomes even more difficult when dealing with vendors whose firmware is not as standardized between releases.

That’s where the LittleBlackBox project comes in. It has a database of known default SSL private keys and associates those keys with their corresponding public keys. All Eve has to do is look up the public key of Alice and Bob’s router in the database, and she instantly has the rotuer’s private key.

She can also look up keys based on the device model, vendor, or firmware versions.

She can feed it a network capture file of Alice and Bob’s router traffic and it will find the public certificate exchange and automatically look up the corresponding private key for her.

She can give it the host name or IP address of Alice and Bob’s router, and it will retrieve the public certificate from the router and look up the corresponding private key for her.

She can…well, you get the picture. Of course, the keys have to be in the database in order for all this to work. Currently LittleBlackBox has over 2,000 unique private SSL keys and growing, primarily belonging to routers and VPNs. Although at the moment the vast majority of the keys belong to various DD-WRT firmware, there are keys from Cisco, Linksys, D-Link and Netgear as well.

LittleBlackBox can be downloaded here. If you have default SSL keys that are not currently in the database and wish to add them to the project, please download the latest version of LittleBlackBox and follow the submission guidelines in the docs/FAQ page.

  • Pingback: DD-WRT Powers the Home Network | My Mind In Bytes()

  • Thakur

    Good work.

    Most of the people have misconception that SSL uses asymmetric cryptography to exchange data ( even i had :P ). Actually, there is high CPU usage in asymmetric cryptography, and to over come this a master key is generated and exchanged between sever and client during SSL handshake. This new master key is used encrypted and decrypted data.

    http://tools.ietf.org/html/rfc5246#section-7.3

    The TLS Handshake Protocol involves the following steps:

    – Exchange hello messages to agree on algorithms, exchange random
    values, and check for session resumption.

    – Exchange the necessary cryptographic parameters to allow the
    client and server to agree on a premaster secret.

    – Exchange certificates and cryptographic information to allow the
    client and server to authenticate themselves.

    – Generate a master secret from the premaster secret and exchanged
    random values.

    – Provide security parameters to the record layer.

    – Allow the client and server to verify that their peer has
    calculated the same security parameters and that the handshake
    occurred without tampering by an attacker.

    One more reference from RSA laboratories:

    http://www.rsa.com/rsalabs/node.asp?id=2293

    The SSL Handshake Protocol consists of two phases: server authentication and an optional client authentication. In the first phase, the server, in response to a client’s request, sends its certificate and its cipher preferences. The client then generates a master key, which it encrypts with the server’s public key, and transmits the encrypted master key to the server. The server recovers the master key and authenticates itself to the client by returning a message authenticated with the master key. Subsequent data is encrypted and authenticated with keys derived from this master key. In the optional second phase, the server sends a challenge to the client. The client authenticates itself to the server by returning the client’s digital signature on the challenge, as well as its public-key certificate.