Re: Large ICMP Packets with strange payload

From: Eric Landuyt (eric@datarescue.com)
Date: 01/09/02


Date: Wed, 9 Jan 2002 18:21:04 +0100
From: Eric Landuyt <eric@datarescue.com>
To: incidents@securityfocus.com, bbakke@solcon.nl

Hello Brennan,

BB> I do not like seeing strings like "arpspoof", "frag/defrag",
BB> "stream_reassemble", "portscan", "rpc_decode", and "telnet_decode" in Large
BB> ICMP Packets.

BB> Is this a Loki style covert communication channel, or just normal traffic?

Fortunately, I think that this is not the case here.
If I remember some preceding browsing in Snort's source code ;),
most of the strings we found at the END OF THE DUMP (not the end of the
packet... I'll explain further) are identifiers/function
names/params/... from Snort's itself.
For example, we can find "stream4_reassemble" (relative to stream
reassembling engine), or "spade-homenet" (relative to Spade -
Statistical Packet Anomaly Detection Engine, a Snort preprocessor
plugin).

In the same way, we also observe some strings usually relative to
DNS traffic, like "A.ROOT-SERVERS.NET", for example.

If we look carefully at informations from the header, we can observe
IpLen = 20 and DgmLen = 28: we can thus deduce that the exact ICMP
datagram size was in fact 8 bytes.
Probably, your ICMP packet was simply something like:
00 00 00 00 00 00 00 00

My personal opinion is that an eventual bug (??!!) exists in Snort's
dump function (dumping too many bytes), and thus gave us those extra
dump bytes, resulting in printing bytes from packets/informations
previously stored at the address of your ICMP datagram in memory,
and overwriten by this datagram.

Hope this helps,

--
Eric Landuyt, Developper - mailto:eric@datarescue.com
DataRescue sa/nv, Home of the IDA Pro Disassembler - http://www.datarescue.com

---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com



Relevant Pages

  • Re: [Full-Disclosure] ICMP Covert channels question
    ... if your packet does manage to reach it the destination ... > packets and a bounce server and so far everything worked fine. ... > contact my web server through a bounce server outside of my network ... > (that is not blocking icmp packets) and my machine is say, ...
    (Full-Disclosure)
  • Re: specific type of Hex conversion
    ... >>(please go to bottom for code) ... >>I tried to manipulate the values, but it still showed the numbers as a ... I managed to convert the packet into the way i want, ... Now it works fine,and the proxying of the icmp packets works ...
    (comp.lang.c)
  • Re: Problem with detecting the reception of a datagram
    ... packet monitor you are blind and have no idea what's actually going on. ... but the listen module is not at all ... executing if there is no datagram sent from a remote host.. ...
    (comp.unix.programmer)
  • Re: Can recvfrom() return more than 1 packet?
    ... There is only a "whole IP packet" if the whole datagram fits in one ... recvfrom() on a SOCK_DGRAM socket is the ... SOCK_DGRAM socket causes you to receive datagrams. ...
    (comp.unix.programmer)
  • Re: UDP example
    ... > (can be veriable length and very big, bigger than MTU). ... > amount of data to get one exact packet worth of data. ... Reliability is not of great importance to me. ... The maximum datagram size is 65,536 bytes. ...
    (comp.unix.programmer)