full-disclosure - Re: Default SSL Keys in Multiple Routers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 20 Dec 2010 19:47:01 -0500
From: Jeffrey Walton <noloader@...il.com>
To: BMF <badmotherfsckr@...il.com>
Cc: Craig Heffner <cheffner@...ttys0.com>, full-disclosure@...ts.grok.org.uk
Subject: Re: Default SSL Keys in Multiple Routers

On Mon, Dec 20, 2010 at 7:04 PM, BMF <badmotherfsckr@...il.com> wrote:
> On Sat, Dec 18, 2010 at 7:13 PM, Craig Heffner <cheffner@...ttys0.com> wrote:
>> The LittleBlackBox project contains a database of over 2,000 (and growing)
>> private SSL keys that are correlated with their respective public
>> certificates, and hardware/firmware versions. While most of these
>> certificates are from DD-WRT firmware, there are also private keys from
>> other vendors including Cisco, Linksys, D-Link and Netgear.
>
> Most of what I have read so far indicates that these secret keys can
> be used to sniff only administrative traffic to the device itself.
>
> I have a client who uses a bunch of WRV200's for corp VPN access. They
> are configured with a shared secret. Wouldn't they use DH with the
> built in private key to exchange the shared secret which would make
> the VPN traffic itself vulnerable?
When using DH for the exchange of the random values, the random value
is raised to the group base, ie, g^a (or g^b) where 'a' is one side's
random {16|32|x} bytes. The private key would be used to sign the
messages used in the exchange of the material. This scheme is referred
to as Ephemeral Diffie Hellman or DH2.

An intermediate with knowledge of a private key could play the role of
man in the middle since he/she could forge a signature. So the
security properties of the signature over the exchange would be
destroyed, and the system would be no more secure than standard DH.
And standard DH is vulnerable to MITM.

If the attacker is passive and cannot intercept the messages or assume
the role of MITM, then the confidentiality of messages are probably
safe. The bad guy would probably not be able to inject messages since,
for bulk encryption (ie, after key exchange), the protocol would
switch to a HMAC rather than digital signatures. But I would not feel
good knowing a private key used for signing was in the hands of a
[malicious?] third party.

Jeff

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/