11082950 2003-12-11 00:28 +0100 /124 rader/ Michal Zalewski <lcamtuf@ghettot.org>
Importerad: 2003-12-11 01:22 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: full-disclosure@netsys.com
Mottagare: Bugtraq (import) <30283>
Ärende: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@ghettot.org>
To: bugtraq@securityfocus.com
Cc: full-disclosure@netsys.com
Message-ID: <Pine.LNX.4.58.0312110022340.8651@nimue.bos.bindview.com>
Good morning,
I am not quite sure there was no prior discussion of this problem,
but I could not find anything even remotely related, and so I think
it makes sense to post here. This post roughly describes a thought I
had recently - and I have to admit this is pure theory, even though
it should be fairly easy to turn this into a practical attack.
Blind spoofing, hijacking and data insertion into TCP/IP sessions,
although considered by some folks to be a threat of the past, still
has some impact potential; I have provided some arguments to support
this belief in my followup TCP/IP ISN analysis, in section 2, and I
bet there it is just the top of an iceberg [
http://lcamtuf.coredump.cx/newtcp/#risks ].
Closing all the attack venues by deploying "proper" cryptography is
not always feasible and easy, and even then, the protection is not
complete - the DoS potential remains. Without cryptography, the
integrity of TCP/IP sessions is protected only by a small set of
parameters that are - hopefully - not known to a person not involved
in the communications, and offer enough possible values to make
brute-force attacks usually not feasible. In practice, the Internet
largely relies on the correctness and unpredictability of the initial
sequence number generation algorithms used in TCP/IP stacks on
various systems and devices.
I have done some research on the quality of those implementations, as
some of you may recall; so did others, and the situation have greatly
improved in the past 5 years or so, although it is still not quite
what we would like it to be. It is, however, expected that all
mainstream operating systems offer a reasonable ISN strength, and
thus are not susceptible to trivial TCP/IP stream invasion.
There seems to be a more fundamental problem, however, a problem that
renders sequence numbers and their quality practically irrelevant in
certain common scenarios.
Consider the following: Bob sends a TCP/IP ACK packet to Alice, with
a data payload and within an established session, of which session
the attacker is aware (attacker-induced or server to server traffic,
perhaps). Bob's packet exceeds the MTU somewhere en route (be it on
some WAN interface, or on a local PPPoA, PPPoE or VPN interface), a
situation not quite unheard of; the IP packet gets fragmented in
order to be delivered successfully.
The first IP fragment would carry the beginning of the TCP packet,
including port numbers, sequence number, and other information that
may be relatively difficult for a third party (the attacker) to guess
otherwise. The other fragment (fragments) of Bob's packet carry the
remaining section of the TCP/IP payload, and would be put back
together with the headers and previous sections of the packet once
received by Alice. Here is where the attacker strikes: he may spoof
the second IP fragment, instead of attempting to determine the
sequence number, and insert data into the TCP payload.
There are only two problems he would face:
1. Figuring out the IP ID value. Usually a minor inconvenience, since a
majority of systems use sequential numbers, and so it is possible to
guess the next value with no effort.
2. Sending a fragment that would, after reassembly, still validate against
TCP/IP checksum in the headers. The only real unknown is the sequence
(and perhaps acknowledgment) number in there - the remainder can be
usually either predicted to a degree, or simply overwritten with
overlapping fragments, but the sequence number cannot be, for obvious
reasons.
There are two approaches to the latter problem. Since the checksum is
only 16 bits, it might be reasonable to simply trust your luck, rinse
and repeat. Also, since it is possible to overwrite the checksum
field with an overlapping IP fragment, and it is possible to control
the packet payload, perhaps it is also trivial to come up with such
an input to have the (trivial!) checksum depend less on the unknown
part of the packet, and more on the known payload. The TCP/IP
checksum is designed to be very fast and detect accidental bit flips
and other snafus, not to provide any security - so I have a strong
feeling it is possible to bias it this way or another; on the other
hand, I do not have time to give it more thought at the moment
(honestly), any thoughts?
To summarise... the attack seems to be fairly practical, at the very
least significally decreasing the search space, at the very best,
effectively disabling any session integrity protection gained from
unpredictable ISNs. There are two major mitigating factors for this
kind of attacks:
1. Path MTU discovery (DF set) prevents fragmentation [*]; some modern
systems (Linux) default to this mode - although PMTU discovery is
also known to cause problems in certain setups, so it is not always
the best way to stop the attack.
[*] Also note that certain types of routers or tunnels tend to
ignore DF flag, possibly opening this vector again.
2. Random IP ID numbers, a feature of some systems (OpenBSD?), although also
risky (increasing reassembly collission probability), make the attack
more difficult.
In the situation when it is necessary to brute-force all bits of
the checksum, and all bits of the IP ID, the complexity of this
data injection method starts to be comparable to full 32-bit ISN
brute-force - usually not feasible.
In the likely situation it is not necessary to brute force all
checksum variants, the feature becomes only an inconvenience,
raising the bar only slightly.
Note that this has nothing to do with old firewall bypassing
techniques and other tricks that used fragmentation to fool IDSes and
so on - mandatory defragmentation of incoming traffic on perimeter
devices will not solve the problem.
Cheers,
--
------------------------- bash$ :(){ :|:&};: --
Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
--------------------------- 2003-12-11 00:22 --
http://lcamtuf.coredump.cx/alpha/
(11082950) /Michal Zalewski <lcamtuf@ghettot.org>/(Ombruten)
Kommentar i text 11086713 av Nick Cleaton <nick@cleaton.net>
Kommentar i text 11087063 av Kris Kennaway <kris@FreeBSD.org>
Kommentar i text 11087320 av David Gillett <gillettdavid@fhda.edu>
11086713 2003-12-11 07:37 +0000 /33 rader/ Nick Cleaton <nick@cleaton.net>
Importerad: 2003-12-11 17:55 av Brevbäraren
Extern mottagare: Michal Zalewski <lcamtuf@ghettot.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <30294>
Kommentar till text 11082950 av Michal Zalewski <lcamtuf@ghettot.org>
Ärende: Re: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: Nick Cleaton <nick@cleaton.net>
To: Michal Zalewski <lcamtuf@ghettot.org>
Cc: bugtraq@securityfocus.com
Message-ID: <20031211073701.GG12342@lt1.cleaton.net>
On Thu, Dec 11, 2003 at 12:28:28AM +0100, Michal Zalewski wrote:
[SNIP]
> Also, since it is possible to overwrite the checksum field with an
> overlapping IP fragment, and it is possible to control the packet payload,
> perhaps it is also trivial to come up with such an input to have the
> (trivial!) checksum depend less on the unknown part of the packet, and
> more on the known payload.
No, I don't think so, so long as at least one 16 bit word of the
sequence number is properly random and uncorrelated with anything else
in the packet.
As a thought experiment, let us pretend that 16 bits of the unknown
sequence number are added last when computing the 16 bit ones
complement checksum. This won't change the outcome since ones
complement addition is both commutative and associative.
Even if the attacker knows or controls every other byte in the packet
and thus controls the checksum before the final 16 bits go in, the
final checksum is as unpredictable as those 16 bits.
--
Nick Cleaton
nick@cleaton.net
(11086713) /Nick Cleaton <nick@cleaton.net>/(Ombruten)
Kommentar i text 11087259 av <Valdis.Kletnieks@vt.edu>
Kommentar i text 11103988 av Michal Zalewski <lcamtuf@ghettot.org>
11087259 2003-12-11 12:06 -0500 /25 rader/ <Valdis.Kletnieks@vt.edu>
Importerad: 2003-12-11 20:04 av Brevbäraren
Extern mottagare: Nick Cleaton <nick@cleaton.net>
Extern kopiemottagare: Michal Zalewski <lcamtuf@ghettot.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <30302>
Kommentar till text 11086713 av Nick Cleaton <nick@cleaton.net>
Ärende: Re: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: Valdis.Kletnieks@vt.edu
To: Nick Cleaton <nick@cleaton.net>
Cc: Michal Zalewski <lcamtuf@ghettot.org>, bugtraq@securityfocus.com
Message-ID: <200312111706.hBBH6QKh011380@turing-police.cc.vt.edu>
On Thu, 11 Dec 2003 07:37:02 GMT, Nick Cleaton said:
> Even if the attacker knows or controls every other byte in the packet
> and thus controls the checksum before the final 16 bits go in, the final
> checksum is as unpredictable as those 16 bits.
However, it's a trivial matter to take the original text, the
replacement text, and compute an original such that the checksum
comes out "the same".
1) Read the RFCs on how to do incremental update of the checksum when
decrementing the TTL - that provides some big hints.
2) Walk across the old and new texts, computing the delta to the
checksum.
3) Smash two spare bytes in the new text with the correct delta to
make it come out the same.
Remember, it's a checksum, not a hash.
(11087259) /<Valdis.Kletnieks@vt.edu>/----(Ombruten)
Bilaga (application/pgp-signature) i text 11087260
Kommentar i text 11096072 av Marius Huse Jacobsen <mahuja@c2i.net>
11087260 2003-12-11 12:06 -0500 /10 rader/ <Valdis.Kletnieks@vt.edu>
Importerad: 2003-12-11 20:04 av Brevbäraren
Extern mottagare: Nick Cleaton <nick@cleaton.net>
Extern kopiemottagare: Michal Zalewski <lcamtuf@ghettot.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <30303>
Bilaga (application/pgp-signature) till text 11087259
Ärende: Bilaga till: Re: A new TCP/IP blind data injection technique?
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQE/2KQScC3lWbTT17ARAsVaAJ0f+J2iiVE4ndyU20sO7BjcM7e1QACg74kN
2/0s7uq3htI3jWQC9O6tOXQ=
=EIcu
-----END PGP SIGNATURE-----
(11087260) /<Valdis.Kletnieks@vt.edu>/--------------
11096072 2003-12-13 01:59 -0800 /36 rader/ Marius Huse Jacobsen <mahuja@c2i.net>
Importerad: 2003-12-14 00:29 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: mahuja@c2i.net
Mottagare: Bugtraq (import) <30346>
Kommentar till text 11087259 av <Valdis.Kletnieks@vt.edu>
Ärende: Re[2]: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: Marius Huse Jacobsen <mahuja@c2i.net>
To: bugtraq@securityfocus.com
Message-ID: <12216304156.20031213015956@c2i.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Valdis,
Thursday, December 11, 2003, 9:06:26 AM, you wrote:
VKve> However, it's a trivial matter to take the original text, the
replacement text, VKve> and compute an original such that the
checksum comes out "the same".
Only this is a scenario where we don't have the "original text". If we
had, we could have just ripped out the sequence numbers and skipped
the whole problem.
As long as we don't know anything of the original data we have to
guess the correct checksum.
Still, 1 of 65535 is a lot better than... what is it, 2**64 ?
- --
Best regards,
Marius mailto:mahuja@c2i.net
-----BEGIN PGP SIGNATURE-----
iQA/AwUBP9rjLJfZ2CSWpu1rEQIDnwCeI0wMODSSAJLgob1jSl+IDFw3uWMAoLhM
zR9zJ8TPn/0lOWXgJvBq2lZG
=CvFw
-----END PGP SIGNATURE-----
(11096072) /Marius Huse Jacobsen <mahuja@c2i.net>/(Ombruten)
11103988 2003-12-14 15:38 +0100 /87 rader/ Michal Zalewski <lcamtuf@ghettot.org>
Importerad: 2003-12-15 20:54 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: full-disclosure@netsys.com
Mottagare: Bugtraq (import) <30351>
Kommentar till text 11086713 av Nick Cleaton <nick@cleaton.net>
Ärende: Breaking the checksum (a new TCP/IP blind data injection technique)
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@ghettot.org>
To: bugtraq@securityfocus.com
Cc: full-disclosure@netsys.com
Message-ID: <20031214150105.C45081@dekadens.coredump.cx>
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/
(11103988) /Michal Zalewski <lcamtuf@ghettot.org>/(Ombruten)
11087063 2003-12-10 15:59 -0800 /16 rader/ Kris Kennaway <kris@FreeBSD.org>
Importerad: 2003-12-11 19:12 av Brevbäraren
Extern mottagare: Michal Zalewski <lcamtuf@ghettot.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: full-disclosure@netsys.com
Mottagare: Bugtraq (import) <30295>
Kommentar till text 11082950 av Michal Zalewski <lcamtuf@ghettot.org>
Ärende: Re: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: Kris Kennaway <kris@FreeBSD.org>
To: Michal Zalewski <lcamtuf@ghettot.org>
Cc: bugtraq@securityfocus.com, full-disclosure@netsys.com
Message-ID: <20031210235933.GA32037@hub.freebsd.org>
On Thu, Dec 11, 2003 at 12:28:28AM +0100, Michal Zalewski wrote:
> 2. Random IP ID numbers, a feature of some systems (OpenBSD?), although also
> risky (increasing reassembly collission probability), make the attack
> more difficult.
FreeBSD also has the option of randomizing the IP ID.
Kris
(11087063) /Kris Kennaway <kris@FreeBSD.org>/-------
Kommentar i text 11087263 av Casper Dik <casper@holland.sun.com>
11087263 2003-12-11 18:17 +0100 /22 rader/ Casper Dik <casper@holland.sun.com>
Importerad: 2003-12-11 20:04 av Brevbäraren
Extern mottagare: Kris Kennaway <kris@FreeBSD.org>
Extern kopiemottagare: Michal Zalewski <lcamtuf@ghettot.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: full-disclosure@netsys.com
Mottagare: Bugtraq (import) <30304>
Kommentar till text 11087063 av Kris Kennaway <kris@FreeBSD.org>
Ärende: Re: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: Casper Dik <casper@holland.sun.com>
To: Kris Kennaway <kris@FreeBSD.org>
Cc: Michal Zalewski <lcamtuf@ghettot.org>, bugtraq@securityfocus.com,
full-disclosure@netsys.com
Message-ID: <200312111717.hBBHHfa04916@sunnl.Holland.Sun.COM>
>On Thu, Dec 11, 2003 at 12:28:28AM +0100, Michal Zalewski wrote:
>
>> 2. Random IP ID numbers, a feature of some systems (OpenBSD?), although also
>> risky (increasing reassembly collission probability), make the attack
>> more difficult.
>
>FreeBSD also has the option of randomizing the IP ID.
Solaris uses a different IP ID sequence for each system it
communicates with; you'll need to be able to see the packets
go by (in which case TCP splicing is child's play).
Casper
(11087263) /Casper Dik <casper@holland.sun.com>/----
11087320 2003-12-11 08:38 -0800 /32 rader/ David Gillett <gillettdavid@fhda.edu>
Importerad: 2003-12-11 20:19 av Brevbäraren
Extern mottagare: 'Michal Zalewski' <lcamtuf@ghettot.org>
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: full-disclosure@netsys.com
Externa svar till: gillettdavid@fhda.edu
Mottagare: Bugtraq (import) <30306>
Kommentar till text 11082950 av Michal Zalewski <lcamtuf@ghettot.org>
Ärende: RE: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: "David Gillett" <gillettdavid@fhda.edu>
To: "'Michal Zalewski'" <lcamtuf@ghettot.org>,
<bugtraq@securityfocus.com>
Cc: <full-disclosure@netsys.com>
Message-ID: <08cc01c3c005$2471c0b0$6e811299@HURON>
> -----Original Message-----
> From: Michal Zalewski [mailto:lcamtuf@ghettot.org]
>
<snip>
> 1. Path MTU discovery (DF set) prevents fragmentation [*]; some modern
> systems (Linux) default to this mode - although PMTU discovery is
> also known to cause problems in certain setups, so it is not always
> the best way to stop the attack.
>
> [*] Also note that certain types of routers or tunnels tend to
> ignore DF flag, possibly opening this vector again.
<snip>
> Note that this has nothing to do with old firewall bypassing techniques
> and other tricks that used fragmentation to fool IDSes and so on -
> mandatory defragmentation of incoming traffic on perimeter devices will
> not solve the problem.
I concluded some time back -- coming at it from an entirely
different angle from either of these -- that IP-layer fragmentation
and reassembly was fatally flawed. All sane implementations should
set DF, and all but the most secure of tunnels should honour it.
David Gillett
(11087320) /David Gillett <gillettdavid@fhda.edu>/(Ombruten)
11087516 2003-12-11 10:21 -0800 /38 rader/ Michael Wojcik <Michael.Wojcik@microfocus.com>
Importerad: 2003-12-11 20:57 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: Michal Zalewski <lcamtuf@ghettot.org>
Extern kopiemottagare: Valdis.Kletnieks@vt.edu
Extern kopiemottagare: Nick Cleaton <nick@cleaton.net>
Mottagare: Bugtraq (import) <30313>
Ärende: RE: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: Michael Wojcik <Michael.Wojcik@microfocus.com>
To: bugtraq@securityfocus.com
Cc: Michal Zalewski <lcamtuf@ghettot.org>, Valdis.Kletnieks@vt.edu,
Nick Cleaton <nick@cleaton.net> Message-ID:
<75C025AE395F374B81F6416B1D4BDEFB0146C3E2@mtv-corpmail.microfocus.com>
> From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
> Sent: Thursday, December 11, 2003 12:06 PM
>
> On Thu, 11 Dec 2003 07:37:02 GMT, Nick Cleaton said:
>
> > Even if the attacker knows or controls every other byte in
> > the packet and thus controls the checksum before the final 16
> > bits go in, the final checksum is as unpredictable as those 16
> > bits.
> However, it's a trivial matter to take the original text, the
> replacement text, and compute an original such that the checksum
> comes out "the same".
True, but irrelevant to the problem at hand, where the attacker has
neither the original checksum nor the original text. Michal's
question was whether an attacker who controls
- the checksum
- part, but not all, of the text
can set the checksum so as to have a better than 1/65536 possibility
of having it correct. Nick's response was no, if the attacker cannot
control as little as 16 bits of the text. As you pointed out
yourself, any partial checksum value can be mapped to any final
checksum value by adding the final two bytes.
--
Michael Wojcik
Principal Software Systems Developer, Micro Focus
(11087516) /Michael Wojcik <Michael.Wojcik@microfocus.com>/(Ombruten)
Kommentar i text 11091793 av stanislav shalunov <shalunov@internet2.edu>
11091793 2003-12-11 15:58 -0500 /46 rader/ stanislav shalunov <shalunov@internet2.edu>
Importerad: 2003-12-12 17:48 av Brevbäraren
Extern mottagare: Michael Wojcik <Michael.Wojcik@microfocus.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <30315>
Kommentar till text 11087516 av Michael Wojcik <Michael.Wojcik@microfocus.com>
Ärende: Re: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: stanislav shalunov <shalunov@internet2.edu>
To: Michael Wojcik <Michael.Wojcik@microfocus.com>
Cc: bugtraq@securityfocus.com
Message-ID: <86isknm5q0.fsf@abel.internet2.edu>
Michael Wojcik <Michael.Wojcik@microfocus.com> writes:
> > From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
> > However, it's a trivial matter to take the original text, the
> > replacement text, and compute an original such that the checksum
> > comes out "the same".
>
> True, but irrelevant to the problem at hand, where the attacker has neither
> the original checksum nor the original text.
There's clearly an attack here; the attacker can replace known bits in
some parts of the stream with bits of his choice. This can be useful
to replace, e.g., a username here or there, or a predictable URL
(perhaps in a request for a news site to a proxy server). It is a
weakness.
What mitigates the attack is that if pMTUd is used, it won't work
because all packets will have the DF bit set. Practically all modern
OSes will use pMTUd. Michal pointed out in private communication that
some broken firewalls will strip the DF bit off packets. Some of
these same firewalls will also reduce MSS and do other things designed
to prevent fragmentation; it's not clear to me how frequently
fragmentation of TCP packets happens in practice. But in any case,
``broken firewalls have negative net effect on security'' is not
exactly a newsflash; we knew that. Broken firewalls can also hurt
performance badly and interfere with deployment of new features in the
IP protocol (think ECN) and new applications.
Now, UDP in its default state will not set DF and, in some cases,
systems and applications are intentionally (mis)configured to send
packets that will be fragmented. NFS, with frequently used block size
of 4kB or 8kB, would be an important example.
P.S. Since IPv6 has no notion of en-route fragmentation, it is immune.
This is actually the first known to me example of a security issue
where IPv6 design actually improves security.
--
Stanislav Shalunov http://www.internet2.edu/~shalunov/
(11091793) /stanislav shalunov <shalunov@internet2.edu>/
11092050 2003-12-12 01:41 +0100 /101 rader/ Michal Zalewski <lcamtuf@ghettot.org>
Importerad: 2003-12-12 19:11 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: full-disclosure@netsys.com
Mottagare: Bugtraq (import) <30320>
Ärende: Re: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@ghettot.org>
To: bugtraq@securityfocus.com
Cc: full-disclosure@netsys.com
Message-ID: <20031212011652.T66813@dekadens.coredump.cx>
I would like to quickly summarise some of the responses I have
received to my original message to BUGTRAQ and Full-Disclosure:
1. Checksum brute-force and attack feasibility
After actually giving it some thought, I do agree the ability to
successfully attack the checksumming algorithm in presence of
unknown ISNs is generally impossible. This means that the
fragmentation attack vector, with perfectly unpredictable ISNs,
offers a significant search space reduction compared to ISN
brute-forcing (a transition from "practically not feasible" to
"sometimes feasible"), but still requires some effort or time to
succeed. In some situations, time is not a problem, in some
scenarios, it is.
A note on the exposure: I think there is plenty of
server-to-server communications and some long client sessions that
can be either induced or are easy to detect and attack; but then,
DNS cache poisoning by spoofing UDP responses would also fall in
this category (with a comparable search space and time constrains)
- and yet attacks are very rare, in absence of universal
point-and-click tools and no immediately obvious benefits. To me,
this is a targeted attack that should work in some situations, and
is not likely to become a serious threat to all humanity [*].
The most notable consequence of this observation is that strong
ISNs combined with strong IP IDs on both endpoints are _usually_
sufficient to prevent the attack, bringing the complexity back to
2^32, which is probably more than needed for a traditional ISN
brute-force - but see comment B.
Comments:
A. Statistical imperfections of the ISN generation algorithm that were
still beneath the attack feasibility level and thus did not pose an
immediate threat in the traditional ISN brute-force scenario, may
simplify fragmentation attacks on TCP.
In particular, on systems that had just a handful of
unpredictable ISNs bits to start with, just enough to
discourage immediate attacks, may be be an easy prey. Windows
comes to mind.
B. Although checksum is *NOT* optional in TCP packets (unlike with UDP), it
seems that there is a notable (albeit unidentified at the moment)
population of systems that do consider it to be optional when set to
zero, or do not verify it at all. I have conducted a quick check
as follows:
- I have acquired a list of 300 most recent unique IPs that
had established a connection to a popular web server.
- I have sent a SYN packet with a correct TCP checksum to all
systems on the list, receiving 170 RST replies.
- I have sent a SYN packet with zero TCP checksum to all systems on
the list, receiving 12 RST replies (7% of the pool).
As such, there seems to be a reason for some concern, even with
random IP IDs, since it only takes one RFC-ignorant party for
the attack against a session to succeed.
2. Path Maximum Transfer Unit Discovery as a solution
I do stand by my observation that PMTU discovery, even if enabled
on some systems by default and not switched off for reliability
reasons, is not a guarantee of no en-route fragmentation.
While developing p0f, I have observed a noticable population of
several percent of origin networks that have DF zeroed on all
outbound packets, even though OS signatures otherwise match
PMTUD-enabled OSes. I have also received plenty of both anectodal
and detailed reports of certain types of routers, firewalls and
tunnel software trashing or ignoring the flag altogether
(including a very detailed report of the situation with Cisco VPN
software).
Note that, while many modern end-user systems may indeed come with
PMTU discovery enabled, a number of commercial firewalls, proxies
and so on have DF disabled on all outgoing traffic. A quick
glimpse at p0f database reveals that devices such as Nokia IPSO,
CacheFlow devices, Cisco Content Engine, Dell PowerApp caches and
so on do not deploy PMTUD - and not without a reason, given some
notorious problems with this feature.
--
------------------------- bash$ :(){ :|:&};: --
Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
-----------------------------------------------
http://lcamtuf.coredump.cx/photo/current/
[*] Let's just say I do not have time to poke random software with a large
stick, and as such, I tend to post about things I thought of while
away from keyboard, most of which is more of a hyphotetical threat
than anything else - but neat, nevertheless.
(11092050) /Michal Zalewski <lcamtuf@ghettot.org>/(Ombruten)
Kommentar i text 11092678 av Barney Wolff <barney@databus.com>
Kommentar i text 11092715 av Stephen Frost <sfrost@snowman.net>
11092678 2003-12-12 12:14 -0500 /33 rader/ Barney Wolff <barney@databus.com>
Importerad: 2003-12-12 22:43 av Brevbäraren
Extern mottagare: Michal Zalewski <lcamtuf@ghettot.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: full-disclosure@netsys.com
Mottagare: Bugtraq (import) <30327>
Kommentar till text 11092050 av Michal Zalewski <lcamtuf@ghettot.org>
Ärende: Re: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: Barney Wolff <barney@databus.com>
To: Michal Zalewski <lcamtuf@ghettot.org>
Cc: bugtraq@securityfocus.com, full-disclosure@netsys.com
Message-ID: <20031212171444.GA31845@pit.databus.com>
On Fri, Dec 12, 2003 at 01:41:13AM +0100, Michal Zalewski wrote:
>
> B. Although checksum is *NOT* optional in TCP packets (unlike with UDP), it
> seems that there is a notable (albeit unidentified at the moment)
> population of systems that do consider it to be optional when set to
> zero, or do not verify it at all. I have conducted a quick check
> as follows:
>
> - I have acquired a list of 300 most recent unique IPs that
> had established a connection to a popular web server.
> - I have sent a SYN packet with a correct TCP checksum to all
> systems on the list, receiving 170 RST replies.
> - I have sent a SYN packet with zero TCP checksum to all systems on
> the list, receiving 12 RST replies (7% of the pool).
>
> As such, there seems to be a reason for some concern, even with
> random IP IDs, since it only takes one RFC-ignorant party for the
> attack against a session to succeed.
I suspect that in these cases the RSTs may be coming from firewalls
rather than end-hosts. It would be more impressive and surprising if
one ever got a SYN-ACK in response.
--
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.
(11092678) /Barney Wolff <barney@databus.com>/(Ombruten)
Kommentar i text 11092797 av Michal Zalewski <lcamtuf@ghettot.org>
11092797 2003-12-12 18:24 +0100 /26 rader/ Michal Zalewski <lcamtuf@ghettot.org>
Importerad: 2003-12-12 23:09 av Brevbäraren
Extern mottagare: Barney Wolff <barney@databus.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: full-disclosure@netsys.com
Mottagare: Bugtraq (import) <30330>
Kommentar till text 11092678 av Barney Wolff <barney@databus.com>
Ärende: Re: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@ghettot.org>
To: Barney Wolff <barney@databus.com>
Cc: bugtraq@securityfocus.com, full-disclosure@netsys.com
Message-ID: <20031212181851.V6830@dekadens.coredump.cx>
> I suspect that in these cases the RSTs may be coming from firewalls
> rather than end-hosts. It would be more impressive and surprising if
> one ever got a SYN-ACK in response.
Not really. A variant of the same test addressed to common ports such
as 139 resulted in four SYN+ACKs coming back, compared to 50 SYN+ACKs
when the checksum was correct - which is roughly similar to the
previous figure. Quite surprisingly, some of this comes from what
seems to be Windows XP SP1 - but maybe an intermediate device
rewrites the packet instead.
--
------------------------- bash$ :(){ :|:&};: --
Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
--------------------------- 2003-12-12 18:18 --
http://lcamtuf.coredump.cx/photo/current/
(11092797) /Michal Zalewski <lcamtuf@ghettot.org>/(Ombruten)
11092715 2003-12-12 12:32 -0500 /40 rader/ Stephen Frost <sfrost@snowman.net>
Importerad: 2003-12-12 22:50 av Brevbäraren
Extern mottagare: Michal Zalewski <lcamtuf@ghettot.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: full-disclosure@netsys.com
Mottagare: Bugtraq (import) <30328>
Kommentar till text 11092050 av Michal Zalewski <lcamtuf@ghettot.org>
Ärende: Re: A new TCP/IP blind data injection technique?
------------------------------------------------------------
From: Stephen Frost <sfrost@snowman.net>
To: Michal Zalewski <lcamtuf@ghettot.org>
Cc: bugtraq@securityfocus.com, full-disclosure@netsys.com
Message-ID: <20031212173216.GZ24094@ns.snowman.net>
* Michal Zalewski (lcamtuf@ghettot.org) wrote:
> B. Although checksum is *NOT* optional in TCP packets (unlike with UDP), it
> seems that there is a notable (albeit unidentified at the moment)
> population of systems that do consider it to be optional when set to
> zero, or do not verify it at all. I have conducted a quick check
> as follows:
>
> - I have acquired a list of 300 most recent unique IPs that
> had established a connection to a popular web server.
> - I have sent a SYN packet with a correct TCP checksum to all
> systems on the list, receiving 170 RST replies.
> - I have sent a SYN packet with zero TCP checksum to all systems on
> the list, receiving 12 RST replies (7% of the pool).
>
> As such, there seems to be a reason for some concern, even with
> random IP IDs, since it only takes one RFC-ignorant party for the
> attack against a session to succeed.
Is it possible the RSTs you're seeing are from firewalls which send
an RST due to rules in the firewall? It could be that those 12 hosts
wouldn't actually accept a connection where the SYN packet has a zero
TCP checksum. Admittedly, this is still RFC ignorance but it may not
be an actual attackable vector. Could a test be made by modifying an
active web server to send SYN+ACK's w/ TCP checksum of 0 after having
received a SYN and see if any of the clients respond? This would
likely make the server unreachable for most people, of course.
Perhaps construct a setup where a SYN+ACK w/ an invalid TCP checksum
is sent and one with a valid TCP checksum and have some method to
determine if the 0 checksum is accepted.
Just some thoughts.
Stephen
(11092715) /Stephen Frost <sfrost@snowman.net>/(Ombruten)
Bilaga (application/pgp-signature) i text 11092716
11092716 2003-12-12 12:32 -0500 /9 rader/ Stephen Frost <sfrost@snowman.net>
Bilagans filnamn: "signature.asc"
Importerad: 2003-12-12 22:50 av Brevbäraren
Extern mottagare: Michal Zalewski <lcamtuf@ghettot.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: full-disclosure@netsys.com
Mottagare: Bugtraq (import) <30329>
Bilaga (application/pgp-signature) till text 11092715
Ärende: Bilaga (signature.asc) till: Re: A new TCP/IP blind data injection technique?
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/2fufrzgMPqB3kigRAmZgAJ9YLGIImreIbFH0/LFyO7GizvfXywCbBBq1
kbvK0+SOFQ4RAc1i79PNkkM=
=1xeV
-----END PGP SIGNATURE-----
(11092716) /Stephen Frost <sfrost@snowman.net>/-----
11104498 2003-12-15 20:07 +0100 /36 rader/ Michal Zalewski <lcamtuf@ghettot.org>
Importerad: 2003-12-15 23:22 av Brevbäraren
Extern mottagare: LARSJ@inel.gov
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <30359>
Ärende: re:Breaking the checksum (a new TCP/IP blind data injection technique
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@ghettot.org>
To: LARSJ@inel.gov
Cc: bugtraq@securityfocus.com
Message-ID: <20031215200223.R45081@dekadens.coredump.cx>
On Mon, 15 Dec 2003 LARSJ@inel.gov wrote:
> This is a good line of thought that needs to be re-addressed every now
> and then, but I can remember discussing this exact attack ten years ago.
> There's even an RFC on it. RFC 1858 if memory serves.
Lars,
Nope. The set of attacks discussed in RFC1858 is indeed old, but has
nothing to do with the TCP/IP injection vector I have described. The
RFC1858 attacks describe firewall-bypassing attacks: "tiny fragment
attack", where a malicious TCP or UDP packet is sent in chunks too
small to be properly analyzed by the device; and "source porting",
where the header of a previously analyzed packet is modified by an
overlapping chunk.
Both techniques are old, well known and easy to prevent (and, indeed,
prevented by all modern implementations). The attack I described, for
a change, is not aimed at bypassing a firewall, and seems to be
pretty damn impossible to fix without breaking some functionality.
Cheers,
--
------------------------- bash$ :(){ :|:&};: --
Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
--------------------------- 2003-12-15 20:02 --
http://lcamtuf.coredump.cx/photo/current/
(11104498) /Michal Zalewski <lcamtuf@ghettot.org>/(Ombruten)
11104558 2003-12-15 12:03 -0700 /12 rader/ anon <anonpoet@inconnu.isu.edu>
Importerad: 2003-12-15 23:42 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <30362>
Ärende: re: Breaking the checksum (a new TCP/IP blind data injection technique)
------------------------------------------------------------
From: anon <anonpoet@inconnu.isu.edu>
To: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.53.0312151201190.27063@inconnu.isu.edu>
This is a good line of thought that needs to be re-addressed every
now and then, but I can remember discussing this exact attack ten
years ago. There's even an RFC on it. RFC 1858 if memory serves.
anonpoet
larsj [at] inel (dot) gov
(11104558) /anon <anonpoet@inconnu.isu.edu>/(Ombruten)