[2251] in bugtraq
Netscape SSL implementation cracked! (fwd)
daemon@ATHENA.MIT.EDU (sameer)
Tue Sep 19 10:38:52 1995
Date: Mon, 18 Sep 1995 12:17:24 -0700
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: sameer <sameer@c2.org>
X-To: bugtraq@CRIMELAB.COM
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
I'm surprised this hasn't made it here by now:
Forwarded message:
> From owner-cypherpunks@toad.com Sun Sep 17 21:38:21 1995
> From: Ian Goldberg <iang@CS.Berkeley.EDU>
> Message-Id: <199509180441.VAA16683@lagos.CS.Berkeley.EDU>
> Subject: Netscape SSL implementation cracked!
> To: cypherpunks@toad.com
> Date: Sun, 17 Sep 1995 21:41:01 -0700 (PDT)
> X-Mailer: ELM [version 2.4 PL23]
> Mime-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Content-Length: 4098
> Sender: owner-cypherpunks@toad.com
> Precedence: bulk
>
> 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.
> */
>
--
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
