[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20031214150105.C45081@dekadens.coredump.cx>
Date: Sun, 14 Dec 2003 15:38:46 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ttot.org>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...sys.com
Subject: Breaking the checksum (a new TCP/IP blind data injection technique)
First, let me apologize to all readers of the list who have no particular
interest in the subject; I should not have generated so many posts, and I
solemnly swear this is the last one. I posted my first thoughts on the
subject perhaps a bit prematurely, and agreed with Nick Cleaton's response
to my question on the (in)ability to bypass IP checksums while preparing
the summary of the feedback I have received. This assumption, in turn,
downgraded the feasibility of the attack significantly, requiring an
attacker to brute-force a 16-bit checksum in order to succeed.
Ivan Arce, however, gave me a reason to rethink this assumption, and I am
glad to conclude that the ability to bypass checksumming indeed
exists,just as I suspected initially. This means the attack is quite
feasible, and can be accomplished in one shot, and provides a very
attractive alternative to a traditional TCP/IP injection attack,
undermining the effectiveness of ISN-based protection, and rendering
random IP IDs not a sufficient protection against this attack.
The attack has but one prerequisite - a section (and only a section!) of a
TCP/IP packet the attacker wants to replace is known to the attacker in
advance. This holds true for cases such as FTP or WWW file downloads and
other situations that are most likely to cause fragmentation to start
with. It is possible to tweak the packet so that the checksum remains
valid, even though portions of the packet such as the sequence number (or
the checksum, for that matter) are not known in advance.
The checksum algorithm used in TCP/IP is fairly trivial (a form of an
16-bit sum), and position- and ordering- insensitive, we can perform a
simple trick:
- Pick a known fragment of the packet (at 16-bit boundaries) and
compute it checksum,
- Construct a malicious replacement for this block, of arbitrary
contents, closing with two bytes used to compensate the checksum
so that it comes out the same as for the original block - this
is trivial with this type of an algorithm,
- Replace the old block with the malicious one.
The checksum of an entire packet would remain the same, even though we did
not know what it was in the first place, and did not know the entire
packet (port numbers and sequence / acknowledgment numbers are, once
again, not known to the attacker).
So, in short:
- The attack DOES NOT require any brute-force and can be
conducted using a single packet.
- The attack requires the traffic exchanged between two endpoints
to be fragmented at some point; this is most likely to happen
on file downloads, etc.
- The attack may be used to bypass ISN-based integrity protection of
TCP streams (such as the solution suggested in RFC1948).
- The attack has to be targeted against a specific connection
the attacker either induced or knew about. The attack is also
time-sensitive.
- The impact is insertion of malicious data into an existing
stream.
- A knowledge of some of the plaintext is necessary.
- Random IP IDs enabled on both endpoints make the attack more
difficult, but still relatively feasible. Sequential IP IDs
make the attack trivial.
- Path MTU Discovery enabled on both endpoints may prevent the
attack, but only as long as there are no DF-ignoring
devices en route (and no proxies that do not use PMTUD).
--
------------------------- bash$ :(){ :|:&};: --
Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
--------------------------- 2003-12-14 15:01 --
http://lcamtuf.coredump.cx/photo/current/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Powered by blists - more mailing lists