Data Field of an ICMP ECHO REQUEST

Hey Hey,

This really won't spur much of a discussion... it's just more of an FYI for those that like interesting facts, and those who are bored.

We were sitting in class the other day, doing a DHCP lab I believe, and we were sniffing ICMP ECHOs. I was bored and scrolling through the packet contents and found the data field rather amusing.

Quote:

---

abcdefghijklmnopqrstuvwabcdefghi

---

These are the contents of the data field on both Windows XP and Windows 98.

I decided to come home and compare this with the data field contents from an ICMP ECHO Request originating from my linux box (SuSE 9.1 w/ a 2.6.4 kernel). The contents were as follows.

Quote:

---

D^¶@b<


 !"#$%&'()*+,-./01234567

---

Again a pattern is evident, there are 10 bytes of data, followed by an apparent pattern. The characters start counting at hex value 0a and continue on, counting up numerically.

I decided to give my buddy a call and have him ping me with his Mac (Running Mac OS 10.3).

Quote:

---

@¶~Ê
æ

 !"#$%&'()*+,-./01234567

---

The initial 10 bytes differ from the first 10 bytes of the Linux ICMP Echo Request data field, however the data that follows is the exact same.

So MS systems start at a and move to w before starting the cycle over and repeated themselves. I'm actually kind of curious as to why they didn't go all the way to Z, so if anyone knows I'd love to hear about it. *nix based systems seem to follow their own pattern... 10 seemingly random bytes and then starting at 0a. I'm curious about this system. The count ends up dead on because the bytes preceding 0A would be 00,01,02,03,04,05,06,07,08,09 (10 bytes), yet seemingly random bytes are used instead. Another question that I would love to see the answer to.

I thought I'd share this because little things like this tend to amuse me. I get bored easily and I'm amused by most things... hehe :)

Anyways I'm going to play with a few more operating systems and since I've been trying to learn snort more in depth, I may attempt to write a series of rules that will identify ICMPs and the operating system they originated from (unless this already exists.. if so... let me know so I don't waste my time).

Also if anyone wants to capture packets from their machines operating systems and either paste the data field, or the packet... or post a capture file here, it'd be greatly appreciated... I'm going to attempt to compile a rather complete list if possible.

Anyways that's my sharing for the evening.....

Peace,
HT

Interesting how in common the result's from the ICMP ECHO Request are between the Mac OS and the Linux box. Isn't that interesting how there result's are quite similiar and the window's is a little more farther apart? Hrmm.. Also, if your going to variate the different OS'es, you should also variate the connections and speeds of it as well. See if new character's or even more character's come up (for instance, in the Window's set maybe it'll go all the way? who know's..).

Quote:

---

Originally posted here by Spyder32
Interesting how in common the result's from the ICMP ECHO Request are between the Mac OS and the Linux box. Isn't that interesting how there result's are quite similiar and the window's is a little more farther apart? Hrmm.. Also, if your going to variate the different OS'es, you should also variate the connections and speeds of it as well. See if new character's or even more character's come up (for instance, in the Window's set maybe it'll go all the way? who know's..).

---

Hey Hey,

Mac is similar because it's based on Darwin.... however I'd love to see a packet capture from an older Mac <= 9.... technically the connections and speeds shouldn't affect the generate of the packet, due to the level that it's actual created at, but you never know... I may look into it...

Peace,
HT

[Edit]

Here's the data from a Cisco Router running IOS 12.3.7T, which has been provided for us by phishphreek.

Quote:

---

d@´«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í«Í

---

The pattern contains 8 bytes of seemingly random data followed by "ab cd"... someone testing their typing abilities while programming?

[/Edit]

code:
a..@..
........ .........
........ .. !"#$%
&'()*+,- ./012345
67

freebsd 5.2.1

Look throught the Snort ICMP signatures and you will see that it is these differences that allows Snort to report "ICMP: Ping Type BSD" etc.

Just thought I'd throw that in.... ;)

The data in an echo_request is not actually important - the server just returns it without modification (unless it's broken).

The data exist, because icmp echo_request (aka ping) can be used to test that larger packets (perhaps requiring fragmentation) get through a network successfully. They have to pad it out with something.

On another slightly worse note, that means that icmp echo_request (and indeed reply) can be used to send data, as a "covert" channel, because any data can be inside the packets.

Slarty

Hey Hey,

Thanks for the data lumpy :)

Quote:

---

Originally posted here by Tiger Shark
Look throught the Snort ICMP signatures and you will see that it is these differences that allows Snort to report "ICMP: Ping Type BSD" etc.

Just thought I'd throw that in....

---

That's what I was looking for :) well that'll save me a lot of work... Thanks..

Quote:

---

The data in an echo_request is not actually important - the server just returns it without modification (unless it's broken).

The data exist, because icmp echo_request (aka ping) can be used to test that larger packets (perhaps requiring fragmentation) get through a network successfully. They have to pad it out with something.

On another slightly worse note, that means that icmp echo_request (and indeed reply) can be used to send data, as a "covert" channel, because any data can be inside the packets.

Slarty

---

I know it's not important.. it's just to pad it... I just found it interesting how different OS's choose to pad it.

I find it amusing that in a world where security and stealth are now so important, they haven't changed the default data so that you couldn't pick out the OS based on the data in a ping.

However sending data, I know you could send it through ICMP, however I guess I'd never realized how overly simply that was.... thanks for adding the info

Peace,
HT

Slarty nice info about using echo packets for covert channel.
Do you know any implementation of that?
Is someone able to do bi directional conversation using that? I mean, can i send diferent information thru echo response?
Never thought about that

Experiments I've done show that you can just use echo_response rather than echo, applications (running as root / admin) can receive all ICMP packets, and just look for the ones they want. Sending packets is pretty easy too.

On Windows, it seems difficult for an app to receive echo packets, as the kernel gets them and intercepts them first. Most other ICMP types can be seen by apps though.

Slarty

It's odd that MS just chose a through w which is a range of 23 bytes. Hex-wise it's 0x61 through 0x77. Seems pretty arbitrary to me, although maybe the number 23 has some special meaning to whomever originally decided on it. It resets the loop and begins again for the 9 remaining bytes needed to fill out the packet.

As for the unix boxes, it would seem to me that it is simply starting at ASCII 0x00 and incrementing up through 0x37 (which is "7"). This constitutes 55 bytes of data with a null appended, meaning 56 octets of data (which is what my linux box defaults to using ping). Unless you are seeing that the first 10 bytes are *NOT* 0x00, 0x01, 0x02, et. al., I don't get why you think it's at all random. Sometimes the host OS will replace certain NPCs with PCs for the sake of displaying them instead of the grey NPC boxes, which is what it looks like here.

My bet would be that it simply goes through all 128 ASCII standard characters before beginning the loop again. Likely the first few codes are being interpreted using extended ascii, which is why MacOS and Linux would show different values.

Quote:

---

Do you know any implementation of that?
Is someone able to do bi directional conversation using that? I mean, can i send diferent information thru echo response?
Never thought about that

---

Yes, there is a tool that can be used to transport data via ICMP. The tool is called LOKI and has been around for quite some time. I've tested it many times and I have to tell you that it is very scary to see how *all* vendors miss this.

Quote:

---

Most admins will block ICMP Type 8 and ICMP Type 0 packets, but still, some will not. ICMP Tunneling wraps commands and data in ICMP Headers. A Program, Loki/Lokid, executes this technique in the most simple form. As quoted here:

"The concept of the Loki Project is simple: arbitrary information tunneling in the data portion of ICMP_ECHO and ICMP_ECHOREPLY packets. Loki exploits the covert channel that exists inside of ICMP_ECHO traffic. This channel exists because network devices do not filter the contents of ICMP_ECHO traffic. They simply pass them, drop them, or return them. The trojan packets themselves are masqueraded as common ICMP_ECHO traffic. We can encapsulate (tunnel) any information we want. From here on out, Loki traffic will refer to ICMP_ECHO traffic that tunnels information. (Astute readers will note that
Loki is simply a form of steganography)."

---

One nasty little feature not noted above is that the service can be renamed which makes it a little harder to find.

LOKI (client) and LOKID (server/service) run on *nix systems. I know that the Hacking Exposed people used to have this tool on their site eons ago so I'm not sure where to grab it.

You can read more about it here:
http://phrack.org/phrack/49/P49-06

Quote:

---

Originally posted here by chsh
It's odd that MS just chose a through w which is a range of 23 bytes. Hex-wise it's 0x61 through 0x77. Seems pretty arbitrary to me, although maybe the number 23 has some special meaning to whomever originally decided on it. It resets the loop and begins again for the 9 remaining bytes needed to fill out the packet.
As for the unix boxes, it would seem to me that it is simply starting at ASCII 0x00 and incrementing up through 0x37 (which is "7"). This constitutes 55 bytes of data with a null appended, meaning 56 octets of data (which is what my linux box defaults to using ping). Unless you are seeing that the first 10 bytes are *NOT* 0x00, 0x01, 0x02, et. al., I don't get why you think it's at all random. Sometimes the host OS will replace certain NPCs with PCs for the sake of displaying them instead of the grey NPC boxes, which is what it looks like here.

My bet would be that it simply goes through all 128 ASCII standard characters before beginning the loop again. Likely the first few codes are being interpreted using extended ascii, which is why MacOS and Linux would show different values.

---

Hey Hey,

They're all being decoded on a Windows computer, so I'd expect them to use the same character set. However I'm looking at the hex and seeing that they are *NOT* 0x00, 0x01, 0x02, etc. The first thing I went with was hex and then I looked at the character interpretations afterwards.

Peace,
HT

Well, it looks like it randomizes the first ten bytes of data like you said, however when it wraps this randomization does not take place. Evidently this is so that each ping is somehwat unique. Linux also appears to wrap at 256 bytes, and reverts from 0xFF to 0x00. So basically it goes:
<10 random bytes><0x0A through 0xFF><0x00 through 0xFF, repeat as necessary to pad packet>

Hi all, this is my first post in the AO forums.

Sometimes when I see a live attack incoming to our systems here, I will send ICMP Echo Requests with a message encoded into the payload back at the attacker. Needless to say, I don't do this for every s-kiddie. However, if an attack looks interesting enough to be someone intelligent at the other end, I send back the message encoded payload, assuming that the attacker probably has a sniffer running and will see that I am watching. If they are really smart, they can decode my message and see what I think about it.

I realize this is only loosely related to this thread, but I thought I'd throw it out there.

--FZ

Fiddle:

Nice one.... I might have a play with that myself..... Even if they don't "get it" it would make me feel good to abuse them. ;) Why encode it BTW, why not just send a short, sharp "FU" in clear?

"Data Field of an ICMP ECHO REQUEST" -- I've actually said this before only to be laughed at by some. Since the IP Protocol doesn't allow directly for data encapsulation it doesn't really have an official "Data" field or "Payload". ICMP data past the 8 Byte header is actually data, but not actually deemed a "Payload" or "Data Field". I'll always call it that though... regardless of whether or not most view it as just an extension from the header and not an actual separate entity.

Tiger, I guess I just find it more fun to encode. Sometimes I use the hex alphabet, [0-9a-f], and sometimes not. The interesting thing is that sometimes (once in a blue moon :) ) just sending ICMP Echo Requests back at them stops the attack quicker than writing an ACL rule to block them. It's like saying, "Hey, I'm here and I am watching you try to break into my house."

Mark_Anderson, actually there is a data field in an ICMP Echo Request. Look in the RFC. The data field is supposed to be returned verbatim in the echo reply, which is why the field exists. There are other ICMP types that have data fields defined as well.

--FZ

Quote:

---

The data field is supposed to be returned verbatim in the echo reply, which is why the field exists. There are other ICMP types that have data fields defined as well.

---

Yep, I know. The original data sent from say an echo request is "acked" back to you in the form of an echo reply. When I said that it doesn't support direct data encapsulation I'm not talking about encapsulation using ICMP and some of the other network-layer protocols (so-called extensions carried over IP for routing/control/error reporting reasons etc) that have data in the body of the packet. I'm speaking of 'true' data encapsulation being used in the transport-layer protocols UDP and TCP. As I originally stated I know that IP does allow for it but only for specific reasons via extended ip-layer protocols. Without the other IP-layer protocols it wouldn't be able to pull off the encapsulation. With UDP and TCP, you can encapsulate data directly supporting whatever application-layer protocols or data that you like. Even multiple data encapsulation. This is why I see it as not really being direct data encapsulation much like others see it. I still call it that but it's just not really 'true' to the direct sense of the protocol. Can it encapsulate and route other network-layer protocols that support payloads? Yeah, generically speaking.

also note if your using freebsd (not sure about other nix variants) you can use the -p option for ping to insert your own data. ping -p20202020 yahoo.com should pad it with a bunch of spaces. when we were playing with sniffers at a lan party, people were commenting on the abcdefghi... in the ping packet, so i decided to send packets with my name embeded :)