RE: Breaking the checksum (a new TCP/IP blind data injection technique)

[John Brightwell <brightwell_151 () yahoo co uk>]

It's not exactly a blind data injection technique if
you're relying on capturing a fragmented packet.

Capturing a packet (fragmented or otherwise) isn't
trivial ... ok, it's certainly possible, but it at
least reduces the exposure to an attacker who has
access to either end of the connection or (less
likely) the Internet routers in between. Someone with
this level of access can do a lot worse than simply
inject packets ... they can hijack the whole
connection if they like (unless full encryption is
being used).

Or am I missing the point of the argument?


> -----Original Message-----
> From: Michal Zalewski [mailto:lcamtuf () ghettot org]
> Sent: 14 December 2003 14:39
> To: bugtraq () securityfocus com
> Cc: full-disclosure () netsys 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).


________________________________________________________________________
BT Yahoo! Broadband - Save £80 when you order online today. Hurry! Offer ends 21st December 2003. The way the internet 
was meant to be. http://uk.rd.yahoo.com/evt=21064/*http://btyahoo.yahoo.co.uk

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html