[bodski]

Hi just thought I'd post a query about what you guys think about this:

http://code.google.com/p/littleblackbox/

It seems that there are over 6000 entries in this tools DB that are for for DD-WRT firmwares where the private SSL key is hardcoded into DDWRT firmware images.

Just thought that if this is for real people should be warned about exposing SSL services such as HTTPS etc to the internet from DDWRT as this tool claims to make it trivial to intercept such connections.

Either way you guys need to clarify the situation on this.

further info:

http://it.slashdot.org/story/10/12/20/1414210/Database-of-Private-SSL-Keys-Published

https://threatpost.com/en_us/blogs/group-publishes-database-embedded-private-ssl-keys-122010

[I Use Dial]

Seems clear to me: don't access the admin panel from outside your network or over unencrypted wireless (access to admin panel through wireless can be disabled Wireless->Advanced Settings->Advanced Settings->Wireless GUI Access->Disable).

[I Use Dial]

I just noticed that the mod locked a dup of this post that had a much better title (SSL Compromised on DD-WRT), then redirected users to the same post that he closed.

This post, titled 'littleblackbox', will probably get little interest from the random users seeking help, as evidenced by the substantially smaller view count.

[phuzi0n]

Meh, it doesn't matter too much which thread is left open...

First of all, in other duplicate threads people have been saying some inaccurate things I want to clear up. DD-WRT is not 'the most affected' by this, the database consists mostly of DD-WRT keys because although DD-WRT bakes a static key into the firmware, it uses a different key for each build. It does not affect any of your normal HTTPS/SSL traffic to websites, only traffic to the router's GUI using HTTPS. Also in order for it to occur they have to be listening to traffic between you and the router.

I can't imagine any situation where an attacker would be able to capture the encrypted traffic and expect to get anyone to login to their router via HTTPS.

If you want to fix/avoid it then there are some solutions. To fix it you can use the firmware mod kit to put your own cert.pem and key.pem files in /etc. If you want to avoid the problem then you can use SSH tunneling to tunnel (my MOD: or any other vpn solution) to the GUI which is a very simple alternative.

http://www.dd-wrt.com/wiki/index.php/Easy_SSH_tunnels

[crashfly]

Thank you for clearing that up phuzi0n. I myself use the SSH tunneling method. I believe this problem would then not affect me. Besides .... that "little black box" would have to be regularly updated with the newer keys from the 'beta' firmware. A lot of hype over nothing if you ask me.

[bodski]

Thanks for clarifying this, it seems that the risk for most users is pretty low. Like others say this appears not to affect SSH based connections.

I suppose the most likely affected would be administrators of networks that use the HTTPS to configure routers over insecure networks. Maybe an announcement with a warning for those possibly affected would be a responsible move though.

Is there any scenario where an HTTPS proxy running from dd-wrt would use this key for the SSL?

Out of interest, why would a pre-generated key that is available to anyone who looks in the firmware be considered more secure than a unique key generated on first boot? Yes, this key would have less entropy but is surely stronger than one that is publicly available to anyone who knows where to look!

[buddee]

This smells of the likes of the DNS rebind exploit that faded away back in the summer, I wonder alot of times why these discoverers of nothing still have jobs.