A new TCP/IP blind data injection technique?

From: Michal Zalewski (lcamtuf_at_ghettot.org)
Date: 12/11/03

  • Next message: Mandrake Linux Security Team: "MDKSA-2003:114 - Updated ethereal packages fix multiple remotely exploitable vulnerabilities" 
    Date: Thu, 11 Dec 2003 00:28:28 +0100 (CET)
To: bugtraq@securityfocus.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/
  • Next message: Mandrake Linux Security Team: "MDKSA-2003:114 - Updated ethereal packages fix multiple remotely exploitable vulnerabilities"

    Relevant Pages

    • [Full-Disclosure] A new TCP/IP blind data injection technique?
      ... Blind spoofing, hijacking and data insertion into TCP/IP sessions, ... Closing all the attack venues by deploying "proper" cryptography is not ... Bob's packet exceeds the MTU somewhere en route (be it on some WAN ... The other fragment of Bob's packet carry the remaining section ...
      (Full-Disclosure)
    • Re: [Full-Disclosure] A new TCP/IP blind data injection technique?
      ... For example the BorderWare Firewall will not accept fragmented packets, ... Then pass or drop the packet. ... > should be fairly easy to turn this into a practical attack. ... The other fragment of Bob's packet carry the ...
      (Full-Disclosure)
    • Re: [Full-Disclosure] A new TCP/IP blind data injection technique?
      ... >data payload and within an established session, ... >Bob's packet exceeds the MTU somewhere en route (be it on some WAN ... fragment at the place you mention. ... All in all, an interesting attack vector, but I'm not sure how practical ...
      (Full-Disclosure)
    • [NEWS] GnuPG and GnuPG Clients Unsigned Data Injection Vulnerability
      ... GnuPG and GnuPG Clients Unsigned Data Injection Vulnerability ... directly using GnuPG from the command line may be fooled by this attack. ... A packet is a chunk of data that has a tag specifying ... Symmetrical Encryption: ...
      (Securiteam)
    • Re: Fwd: [IPv4 fragmentation --> The Rose Attack]
      ... Which limits such an attack to 800 packets overall and 16 fragments ... The first fragment is the ... > dropped at high packet rates if there aren't enough buffers allocated. ...
      (freebsd-net)