This almost has me curious enough to install DU4.0E just to get a tcpdump
to figure out what exactly a "constant" ISN is and how bad it is. If it
really is constant at least more-often-than-not then this makes blind IP
spoofing attacks really, really easy.
Everyone who doesn't understand how much a problem TCP sequences numbers
are should check out the phrack article P48-14 "IP-spoofing Demystified"
by daemon9/route/infinity. It explains it fairly well. The only things
that they neglect to mention is that you have to also worry about ARP and
if you're trying to exploit rsh/rlogin you need to worry about the
username verification connection which is opened up. This means that
you've got to spoof *two* connections now instead of just one -- however,
i've been working on this against a box which uses the 64k rule and have
nearly figured out how to make it work. I think you may need to run it a
few dozen times until it guesses the right port number and sequence number
but it is doable. If Digital Unix 4.0E uses constant ISNs instead of
using the 64k rule then this is going to be utterly trivial to exploit,
all you need to guess is which port the verification connection is being
opened up on, and you can just brute force that by searching down from
1023 -- even on a busy server it shouldn't take more than a hundred
guesses or so (actually i'd bet that a random search based on where you
think that the verification connection will open up, based on how busy you
think the machine is would do a whole lot better, but that's a detail...)
I don't quite understand how a "constant" ISN could work -- if I
understand correctly this would just break what the changing ISN is
supposed to do in the TCP protocol which is to protect against packets
from previous connections which arrive very late and such. Perhaps this
happens infrequently enough on today's networks that nobody notices (and
probably would only happen in conjunction with a router or something going
nutso). Anyway, I'm not sure I understand what this "constant" ISN means
and exactly how broken it is.
I'm really very, very tempted to write up some easy-to-use code to exploit
the 64k rule since so many systems still have it and release it to try
to get vendors to react. Relevent to the list I note that my 3.2C box
which has the latest jumbo patch applied still has 64k ISNs. This isn't
acceptable. Someone needs to call up the Compaq/Digital SSRT and get them
to fix this for 3.2C and any other revs for DU/Tru64 for which it still
exists (patched DU4.0D comes up as "Class=random positive increments
Difficulty=299 (Medium)" on nmap for me, so DU4.0D/BL11/PK3 seems to be
okay...). This attack has been known for a long, long, long, long time.
--
Lamont Granquist lamontg_at_raven.genome.washington.edu
Dept. of Molecular Biotechnology (206)616-5735 fax: (206)685-7344
Box 352145 / University of Washington / Seattle, WA 98195
PGP pubkey: finger lamontg_at_raven.genome.washington.edu | pgp -fka
Received on Fri Mar 05 1999 - 20:44:58 NZDT