Data Field of an ICMP ECHO REQUEST

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 :)