Monday, January 21, 2013

Free RSA Private Key Lancom

UPDATE: I've heard back from LANCOM and they suggest, as did the person commenting below, that the problem lies with administrators selecting the wrong "slot" when uploading the key.

There is no security problem when using the certificate-based VPN
When uploading the certificate you have used the wrong certificate type.

You can undo this by creating a text file in which only one blank character
is available.
When you upload the file, please use the certificate type "Message Before
Login (plain text)".

While this would seem to be a true statement, it seems a like a particularly bad design choice if, while configuring the device, uploading a private key or a login banner are only a single click away from each other and could so easily result in the publication of the data. At least the Shodan database shows very few devices configured this way (currently 9) so it's hardly a wide-spread problem.

Original Post:

There's always a sense of excitement when I see that magic text "-----BEGIN RSA PRIVATE KEY----- ", and it's not  coming from a file on my computer. Anyone who even slightly understands public key cryptography knows that the key with the word "PRIVATE" doesn't get shared. Apparently, some Lancom router, VPN, and VoIP devices are having a hard time figuring out the difference between public and private keys.

While perusing the tubes of the internet today I stumbled upon an oddity in Shodan: a telnet login prompt that included the techincal details of a private key:

| LANCOM 8011 VPN 
| Ver. 8.00.0221RU2 / 07.10.2010 
| SN. 026730600191 
| Copyright (c) LANCOM Systems 

Private-Key: (1024 bit) 

Obviously this is a bit odd. Notice also that this device showing a private key is a VPN device. I looked for additional Lancom devices and searched for "private key". There were more. Some with verbose dumps of the key ("openssl rsa -text" format), others that simply showed the PEM-style public and private keys, and even one that showed a private RSA key that was encrypted. Now I was wondering how these ended up in Shodan.

Shodan *, for anyone needing a quick class, is a service that scans the internet constantly and logs the banners of internet facing services. This information is then databased and made searchable at the Shodan website. Shodan uses only public information and doesn't authenticate to any of the scanned devices. So how did RSA private keys of routers and VPNs end up at Shodan, an unauthenticated remote scanner? It seems that some Lancom routers, VPNs, and VoIP devices are printing the RSA private keys whenever any telnet session is started and without authentication. I connected to a random Lancom box with telnet just to see what was displayed:

Yes, just simply connecting to the service you are handed a RSA private key without authentication.

I initially tried to use the keys to decrypt SSL connections to the same devices over port 443, however, all the connections were using Diffie-Hellman key exchanges, so that wasn't going to work. But when I dug into the Wireshark traces I also found that the subject public key of the certificate presented by the HTTPS side of the devices didn't match the public key I generated from the private keys found via telnet connections. If these are in fact different keys, then what RSA keys exactly are the devices leaking?  Even if it's not the key to the HTTPS server, I'm not going to trust a VPN that hands out private RSA keys via telnet to strangers.

* - Update: It was pointed out to me that clicking the link to Shodan above doesn't show any results. In order to search through Shodan's telnet repository, and to find these devices by searching for private keys, you need to have a paid account and the Telnet Survey add-on.

1 comment:

  1. Hi,
    this is not a problem with the Lancom device, but with the admin configuring it...
    If you want to upload something to the device, e.g. a SSL certificate, you are prompted to choose the appropriate slot for uploading by the webinterface or config software. The admins of the shown devices simply didn't choose the right slot, but the 'login text' slot, which, when being filled with a private key or really anything, displays it at logon... just as it was designed ;)
    So, the problem in question here is really the admin. First, for uploading some private key as the login text, and second, for having telnet active on his obviously WAN accessible router. Ofc, the logon text wouldn't be displayed before logon if using SSH.