Netscape SSL implementation cracked!

As some of you may recall, a few weeks ago I posted a
reverse-compilation of the random number generation routine used by
netscape to choose challenge data and encryption keys.

Recently, one of my officemates (David Wagner <daw@cs.berkeley.edu>)
and I (Ian Goldberg <iang@cs.berkeley.edu>) finished the job
of seeing exactly how the encryption keys are picked.

What we discovered is that, at least on the systems we checked (Solaris
and HP-UX), the seed value for the RNG was fairly trivial to guess by
someone with an account on the machine running netscape (so much so
that in this situation, it usually takes less than 1 minute to find
the key), and not too hard for people without accounts, either.
See below for details.

I've included the header to a program we wrote to do this key-cracking
below.  I would like to get some information, though:

o Where should I put the full source (1 file, ~12k) so that ITAR lovers
  don't get mad at me?

o Where can I find a version of netscape that does RC4-128?  It is
  likely that it suffers from the same problem, and even a brute-force
  search of the entire seed space is _much_ less than 128 bits.

Happy hacking,

   - Ian "who just saw _Hackers_ today with some other Bay Area cypherpunks,
           and it put me in the mood"

/* unssl.c - Last update: 950917

   Break netscape's shoddy implementation of SSL on some platforms
   (tested for netscape running RC4-40 on Solaris and HP-UX; other
    Unices are probably similar; other crypt methods are unknown, but
    it is likely that RC4-128 will have the same problems).

   The idea is this: netscape seeds the random number generator it uses
   to produce challenge-data and master keys with a combination of the
   time in seconds and microseconds, the pid and the ppid.  Of these,
   only the microseconds is hard to determine by someone who
   (a) can watch your packets on the network and
   (b) has access to any account on the system running netscape.

   Even if (b) is not satisfied, the time can often be obtained from
   the time or daytime network daemons; an approximation to the pid can
   sometimes be obtained from a mail daemon (the pid is part of most
   Message-ID's); the ppid will usually be not much smaller than the pid,
   and has an higher than average chance of being 1.  Clever guessing
   of these values will in all likelihood cut the expected search space
   down to less than brute-forcing a 40-bit key, and certainly is less
   than brute-forcing a 128-bit key.

   Subsequent https: connections after the first (even to different hosts)
   seem to _not_ reseed the RNG.  This makes things much easier, once
   you've broken the first message.  Just keep generating 16 bytes of
   random numbers until you get the challenge-data for the next message.
   The next key will then be the 16 random bytes after that.

   main() and bits of MD5Transform1 by Ian Goldberg <iang@cs.berkeley.edu>
   and David Wagner <daw@cs.berkeley.edu>.  The rest is taken from the
   standard MD5 code; see below.

   This code seems to want to run on a big-endian machine.  There may be
   other problems as well.  This code is provided as-is; if it causes you
   to lose your data, sleep, civil liberties, or SO, that's your problem.

#include <std/disclaimer.h>

   On the command line, give the time in seconds, the pid, the ppid and
   the SSL challenge data (each byte in hex, separated by some non-hex
   character like a colon) of the _first_ SSL message generated by
   the instance of netscape.  This program will search through the
   microsecond values.  You may need to run it again with a slightly
   different value for the seconds, depending on how accurately you know
   the time on the system running netscape.  The output will be the
   master key (all 16 bytes; note you never even told the program the
   11 bytes you knew) and the value for the microseconds that produced it.

   As a benchmark, this code runs in just under 25 seconds real time
   (for an unsuccessful search through 1<<20 values for the microseconds)
   on an unloaded HP 712/80.
*/

Excellent work!



---
"In fact, had Bancroft not existed,       potestas scientiae in usu est
Franklin might have had to invent him."    in nihilum nil posse reverti
00B9289C28DC0E55  E16D5378B81E1C96 - Finger for Current Key Information

Ian Goldberg writes:
> What we discovered is that, at least on the systems we checked (Solaris
> and HP-UX), the seed value for the RNG was fairly trivial to guess by
> someone with an account on the machine running netscape (so much so
> that in this situation, it usually takes less than 1 minute to find
> the key), and not too hard for people without accounts, either.
> See below for details.

Why is this completely unsuprising?

I've said it before and I'll say it again -- Netscape's programmers
(with a few notable exceptions -- you know who you are) tend to be
sloppy about security critical details.  Experience with most of the
same people from back when they built Mosaic shows that they just
don't get the details right. (I wonder how many buffer overflow
security bugs lurk in Netscape waiting to be found. I wonder how many
such bugs lurk in their web servers, too...)

Anyway, congratulations to you and Dave on an excellent piece of
work. I say a bunch of us should buy you "I broke Netscape's security
and all I got was this lousy T-Shirt" shirts, if only someone would
design them!

(Two of those should be given to our friends in the U.K. and at INRIA
who brute forced Netscape before. A dozen more of the shirts should be
held for future breaks -- which are a "when", not an "if".)

> I've included the header to a program we wrote to do this key-cracking
> below.  I would like to get some information, though:
> 
> o Where should I put the full source (1 file, ~12k) so that ITAR lovers
>   don't get mad at me?

Give it to the folks at ftp.csua.berkeley.edu, I say.

> o Where can I find a version of netscape that does RC4-128?  It is
>   likely that it suffers from the same problem, and even a brute-force
>   search of the entire seed space is _much_ less than 128 bits.

They sell it in stores.

Perry

> 
> Anyway, congratulations to you and Dave on an excellent piece of
> work. I say a bunch of us should buy you "I broke Netscape's security
> and all I got was this lousy T-Shirt" shirts, if only someone would
> design them!
> 

	If someone would design them (i'll see if my graphic designer
is up to the task, but he's on vacation right now), Community
ConneXion will make/fund them. 

-- 
sameer						Voice:   510-601-9777
Network Administrator				FAX:	 510-601-9734
Community ConneXion: The NEXUS-Berkeley		Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

A little birdie told me that Ian Goldberg said:
> 
> As some of you may recall, a few weeks ago I posted a
> reverse-compilation of the random number generation routine used by
> netscape to choose challenge data and encryption keys.
> 
> Recently, one of my officemates (David Wagner <daw@cs.berkeley.edu>)
> and I (Ian Goldberg <iang@cs.berkeley.edu>) finished the job
> of seeing exactly how the encryption keys are picked.
> 
> What we discovered is that, at least on the systems we checked (Solaris
> and HP-UX), the seed value for the RNG was fairly trivial to guess by
> someone with an account on the machine running netscape (so much so
> that in this situation, it usually takes less than 1 minute to find
> the key), and not too hard for people without accounts, either.

Makes one wonder what the seed is on a Windows implementation...
If it's only the time, you can probably approximate what the
clock is set to within a couple of minutes (if the timezone of the
client is known). 

-- 
Kevin Prigge                        |  Holes in whats left of my reason, 
CIS Consultant                      |  holes in the knees of my blues,
Computer & Information Services     |  odds against me been increasin' 
email: klp@cis.umn.edu              |  but I'll pull through...

Kevin L Prigge wrote:
 
 A little birdie told me that Ian Goldberg said:

 > What we discovered is that, at least on the systems we checked (Solaris
 > and HP-UX), the seed value for the RNG was fairly trivial to guess by
 > someone with an account on the machine running netscape (so much so
 > that in this situation, it usually takes less than 1 minute to find
 > the key), and not too hard for people without accounts, either.
 
/ Makes one wonder what the seed is on a Windows implementation...
/ If it's only the time, you can probably approximate what the
/ clock is set to within a couple of minutes (if the timezone of the
/ client is known). 
 
Hah! Like a Cmos clock can *ever* keep a consistant time for more than
two minutes...