[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nmap-hackers
Subject:    ICMP Echoing Integrity Problems with the IP Header's 3Bits flags and Offset Fields
From:       "Ofir Arkin" <ofir () sys-security ! com>
Date:       2001-07-07 14:43:06
[Download RAW message or body]


When sending back an ICMP error message, some stack implementations may
alter the offending packet’s IP header and the underlying protocol’s
data, which is echoed back with the ICMP error message.
 
If a malicious computer attacker examines the types of alternation that
have been made to the offending packet’s IP header and the underlying
protocol’s data, he may be able to make certain assumptions about the
target operating system.
 
The only two field values we expect to be changed are the IP
time-to-live field value and the IP header checksum. The IP TTL field
value changes because the field is decreased by one, each time the IP
Header is being processed. The IP header checksum is recalculated each
time the IP TTL field value is decreased.
 
The fields that are usually being used in order to take advantage of
this echoing integrity fingerprinting method are: IP Total Length, IP
ID, IP Header Checksum, and if using UDP, the UDP header checksum.
 
During my research on X (to be published at the Black Hat Briefings 2001
July 11-12) I have found a new field value that can be used with this
method. The next example is with NetBSD 1.3:
 
21:46:07.489298 eth0 > 172.18.2.201.1144 > 172.18.2.20.re-mail-ck: udp
80 (DF) [tos 0x11]  (ttl 64, id 44586)
                         4511 006c ae2a 4000 4011 2f44 ac12 02c9
                         ac12 0214 0478 0032 0058 cfc4 5858 5858
                         5858 5858 5858 5858 5858 5858 5858 5858
                         5858 5858 5858 5858 5858 5858 5858 5858
                         5858 5858 5858 5858 5858 5858 5858 5858
                         5858 5858 5858 5858 5858 5858 5858 5858
                         5858 5858 5858 5858 5858 5858
21:46:07.489298 eth0 < 172.18.2.20 > 172.18.2.201: icmp: 172.18.2.20 udp
port re-mail-ck unreachable Offending pkt: 172.18.2.201 > 172.18.2.20:
(frag 10926:88@512) [tos 0x11]  (ttl 64, bad cksum 0!) (DF) (ttl 255, id
56)
                         4500 0038 0038 4000 ff01 1e8b ac12 0214
                         ac12 02c9 0303 ea7b 0000 0000 4511 006c
                         2aae 0040 4011 0000 ac12 02c9 ac12 0214
                         0478 0032 0058 0000
 
Looking closely at the trace above, we can see that the DF bit is set
with the offending UDP datagram. Look at the ICMP Port Unreachable error
message at the echoed data part, the Bit order has changed from 4000 to
0040. This made the offending packet look like a fragmented datagram
that tried to access a closed UDP port.
 
Who share the same behavioral pattern?
NetBSD 1.3.x branch (probably the 1.x-1.2 branch as well, but I could
not test this on these platforms), FreeBSD 2.2.x-4.1.
 
It might affect some versions of BSDI, and MaxOS X as well.
 
Other operating systems and networking devices that were checked did not
produce the same behavioral pattern.
 
 
See you all in Vegas!
 
 
Ofir Arkin [ofir@sys-security.com]
Founder
The Sys-Security Group
http://www.sys-security.com
PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA
 


[prev in list] [next in list] [prev in thread] [next in thread]