Bugtraq mailing list archives
Netscape SSL implementation cracked! (fwd)
From: sameer () c2 org (sameer)
Date: Mon, 18 Sep 1995 12:17:24 -0700
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
Current thread:
- Livingston bugs..., (continued)
- Livingston bugs... Jay 'Whip' Grizzard (Sep 12)
- Re: Livingston bugs... Phillip Moore (Sep 12)
- Re: Livingston bugs... Dave Andersen (Sep 12)
- Re: Livingston bugs... Mike A Lyons (Sep 12)
- LACC Julian Assange (Sep 13)
- Livingston bugs... Jay 'Whip' Grizzard (Sep 12)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Charles Sumner (Sep 14)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Goetz von Escher (Sep 18)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Doug Hughes (Sep 18)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Scott Barman (Sep 18)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Karl Strickland (Sep 18)
- Netscape SSL implementation cracked! (fwd) sameer (Sep 18)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Paul Ashton (Sep 18)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 andy () btc uwe ac uk (Sep 19)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Goetz von Escher (Sep 19)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Ian MacPhedran (Sep 20)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Casper Dik (Sep 21)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Pat The Friendly RedNeck (Sep 22)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Casper Dik (Sep 25)
- Random seed (fwd) Darrell Fuhriman (Sep 25)
- Ray Cromwell: YET ANOTHER BAD NETSCAPE HOLE! Perry E. Metzger (Sep 22)
- Re: [8lgm]-Advisory-22.UNIX.syslog.2-Aug-1995 Sten Gunterberg (Sep 21)