Date: Fri, 12 Dec 2003 01:41:13 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ttot.org>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...sys.com
Subject: Re: A new TCP/IP blind data injection technique?



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.

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

Powered by blists - more mailing lists