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:[EMAIL PROTECTED] > Sent: 14 December 2003 14:39 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > 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
