6718219 2001-07-07 06:52 -0800 /73 rader/ Ofir Arkin <ofir@sys-security.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-07 23:46 av Brevbäraren
Extern mottagare: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
Mottagare: Bugtraq (import) <17845>
Ärende: ICMP Echoing Integrity Problems with the IP Header's 3Bits flags and Offset Fields
------------------------------------------------------------
From: "Ofir Arkin" <ofir@sys-security.com>
To: "Bugtraq List" <BUGTRAQ@SECURITYFOCUS.COM>
Message-ID: <000f01c106f4$7b912060$01000001@godfather>
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
(6718219) /Ofir Arkin <ofir@sys-security.com>/(Ombruten)