Jan 9
Hping3 to Meet You on the Other Side of the Firewall
*Note: This article was originally published by the author on September 24, 2020.
If you’ve ever needed to customize data packets or test a network then you may already be familiar with the network packet crafting tools hping or Scapy, the most current version of hping being hping3. You can use hping3 to custom craft virtually any type of packet. Network security engineers sometimes use tools like hping3 to test their networks. I’ve used it many times in the performance of my job. Penetration testers might also be familiar with it as a network reconnaissance tool or may have even used hping3 to send custom packets past a firewall. Its usefulness is not limited to one purpose. Hping3 is commonly used for actions such as:
-Firewall testing
-Advanced port scanning
-Network testing
-Using different protocols, TOS, and fragmentation
-Manual path MTU discovery
-Remote OS fingerprinting
-Advanced traceroute under all the supported protocols
-TCP/IP stacks auditing
-Remote uptime guessing [1]
Now, before I get into some of the useful applications of the hping3 tool, I’d be remiss not to cover a few networking basics. For instance, it helps to know what a firewall is and the most common firewall types. The diagram below depicts a common implementation of a firewall on a network to protect against external threats but they can be used internally as well to segment networks. Of course, we also need a public-facing router to access the internet or none of this remote scanning or testing stuff would work.
Firewalls are used for a lot of different purposes, but generally, they are strategically emplaced on network perimeters, throughout internal networks, and as well as on host machines as logical barriers that control network traffic flow as well as to protect against certain types of malicious or forbidden traffic. An organization might use a firewall with Data Loss Prevention (DLP) software to protect against employees sending proprietary or sensitive information externally.
The short explanation as to why you need firewalls is that there are 65,535 TCP and UDP ports (131,070 total) that are like little swiss cheese holes in each computer system whether it’s connected to the internet or it’s a standalone system. Each open port is a potential attack surface waiting to be exploited by an attacker. Firewalls will block ports, protocols, and services that you tell it to when once you configure it properly. Or, you can rely on the default firewall settings to do this for you (psst! Don’t do this). It’s always best to look at the rules in place on your firewall and the last rule should always be Deny All, Permit by Exception.
Now, pretend that you are a penetration tester and you were hired by a company and given permission in writing to test their network defenses. As a pentester, you likely have a decent understanding of network protocols and how data packets are constructed. If not, this is something you’ll want to become familiar with. A quick refresher on a TCP/IP packet architecture can be seen in the image below. It is beyond the scope of this article to cover what every field within a packet consists of but the image gives a thoroughly detailed visual. We want to use Transmission Control Protocol (TCP) because we, the attacker, want to know if our custom packets were successfully received by the target host.
If we used User Datagram Protocol (UDP) packets, there would be no feedback for us to know if the test packets were successful or not. Understand the TCP 3-way handshake process and the types of packets: SYN, SYN-ACK, ACK, and of course you should also be familiar with the other packet types: URG, PSH, RST, and FIN.
The operating environment I am running for this virtual demo is Windows 10 Pro OS with VirtualBox 6.1 where I have installed the Kali Linux 2020.3 distro. Once Kali is up and running, navigate to the 01-Information Gathering application folder. Next, click on the Live Host Identification sub-applications folder where you’ll find the hping3 application as demonstrated in the image below.
Kali changed to a non-root user policy by default since the release of 2020.1, which means you’ll need to add ‘sudo’ before each hping3 command or log in as root which is not advisable for normal operations. Once that tidbit is done and out of the way, you’ll see the hping3 help options list it automatically spits out.
Experiment with the different hping3 command options to gain familiarity with what you are to do with this tool. With the hping3 terminal open, we are ready to input commands to create customized packets for intended target IP addresses. Remember also that with Kali you have a whole host of other application tools such as Nmap. Let’s use a practice site such as https://www.hackthissite.org/ as our primary target site.
*DISCLAIMER: You could use these tools and techniques against real websites and you could be sent to prison for breaking the law. It’s your call, but I advise you to get written permission before attempting these techniques on anything but practice hack sites or virtual machines.
A basic nslookup reveals that hackthissite.org’s IP address range is: 137.74.187.100–104 (i.e., there are 5 separate registered domains). I chose to target 137.74.187.100 just to see if I could figure out what it was. The Net lookup dsgetdcname command quickly confirmed that it’s not a Domain Controller server.
Using Nmap to scan for vulnerabilities and open ports on 137.74.187.100 yields the following results:
The Nmap scan revealed a potentially exploitable unpatched Slowloris vulnerability (CVE-2007–6750) which is essentially a Distributed Denial of Service (DDoS) exploit that attempts to overwhelm a targeted server by opening and maintaining many simultaneous HTTP connections to the target. However, we’re not looking to crash any servers. We’re specifically looking for firewalls to test our hping3 packet crafting chops on. For stealth purposes, it’s important to note that hping3 is a better option than Nmap but either tool is good and will work. Both tools perform similar functions. Given the fact that only TCP ports 80 and 443 (HTTP/HTTPS) are open and after a quick search of the CVE details, it is evident that we are likely dealing with an unpatched Apache Web server that could be susceptible to DoS attack. Being that this is a “hack this site” type of website, however, this is most likely by design. Otherwise, why would such a site that is specifically designed by security professionals to hone their hacking skills be left unpatched and vulnerable? It seems highly unlikely so it’s what I like to call ‘hack bait’. So, don’t get too excited about that.
Let’s drill down some more with Nmap before switching over to hping3. Running a Nmap bad sum check confirms that 998 of the first 1,000 TCP ports are filtered ports. Filtered is another way of saying they’re closed by a firewall.
We can also use Nmap NSE’s “firewalk” script to probe the firewall with random packets and see what returns. In this case, it didn’t yield anything substantially useful other than we know we’re dealing with a firewall on the target Web server because we’ve clearly got blocked ports.
If we perform a simple ICMP echo test (below) we see that the packet was received with 0% packet loss. That means ICMP is enabled on the target Web server. Oftentimes, ICMP is enabled for discoverability and network diagnostic purposes such as for ‘traceroute’ or ‘ping’ (ICMP echo). Having ICMP enabled does introduce a denial of service attack liability to a server that can be mitigated via rate limits. If the ICMP echo is rejected or dropped without a response then you can safely assume that the port is filtered by a firewall.
The Nmap scan results showed that TCP ports 80 (HTTP) and 443 (HTTPS) so we can safely assume that our target is most likely a Web server. I can think of different ways to hack a Web server, especially one with a known, unpatched vulnerability. However, let’s stick to the script of hping3 packet crafting on this occasion.
Next, we’ll use hping3 to test the half-open connection on port 80 by sending a simple SYN packet to the target server. If it is open, then we should receive an SYN-ACK packet in return. I selected to use local port 5151 to send the packet to the destination IP address port 80. A SYN-ACK packet (flags=SA) indicates the port is open. An RST-ACK (flags=RA) indicates the port is closed.
An SYN-ACK packet was received confirming what we already suspected based on the Nmap scan, Port 80 is open for business. So, what happens if we bypass the initial steps 1 and 2 of the TCP 3-way handshake and just skip straight to sending an ACK packet to trick the Web server into sending us an SYN-ACK packet?
The Web server replied to my ACK packet with an RST flag which means it is properly configured not to accept random ACK packets. Wait, what? We were rejected? The audacity of this server! Does it not know who I am? I could crush this server with the weight of a thousand gigaflops (however much that weighs?). Ok, whew! Settle down keyboard commando, focus. Very well then, we have to get more creative and change our approach up a bit. We could flip the selector switch to go full-auto amateur hour and just try to DoS flood attack the target, but what would that accomplish? Not much, it might cause the Web server to reboot or knock it offline for a short while. In extreme cases, it could brick a server but that’s not likely to result from a basic Layer 3 DoS attack.
We could also send a TCP Xmas scan with all flags set but that is sure to be detected by an Intrusion Detection System or Intrusion Prevention System (IDS/IPS). So, let’s not do that. Alternative methods consist of spacing out the timing of your packet tests and scans to minimize suspicion. If one day I test a port from (not my home computer IP address), then the next day I send packets to the same target IP address from a different computer (i.e., I changed my IP address using a VPN or proxychains), then it’s much less likely to be noticed than if I light up the system with Xmas scans and started lobbing packets in massive volleys. But that also depends on what you’re targeting and how aggressive you are. Certain probing and scans will draw more attention than others.
With hping3, you can also use -a switch that enables us to spoof our IP address. We could spoof our IP address to mirror the IP address of the target. That way if someone or something like an IDS is monitoring our activity, it won’t appear to originate from the same origin IP address. Stealth is the name of the game with hacking. As you can see from the above snippet, that method didn’t work in this situation. IP address authentication is most likely enabled which would preclude a spoofed IP address attack. Sometimes things work, other times not so much. It’s just about being persistent and trying different approaches. Learn the tools inside and out.
Another method of bypassing firewalls is to fragment packets through the firewall. Below, I show how I was able to successfully fragment 120 bytes of data in the form of SYN packets to port 80 (HTTP) on the target host. You can vary the type and size of fragmented packets to different ports to determine the outcome. Fragmenting packets is kind of fun to play around with because it is a good way to evade detection.
You can also conceivably use hping3 to send a malware file containing a payload through a firewall if you were able to fragment it. Assuming that works, which is a long shot since most newer (Next Generation) firewalls and IDS can detect fragmented packets. They might have an iptables setting that drops fragmented packets. Even if you were able to get all of your fragmented file packets through to the other side of the firewall, you would still need to figure out a way to then execute the payload. That could be done in several ways but I am not going to elaborate for obvious reasons. You could also launch Metasploit and try to attack the firewall but that’s not what this article is about. Besides, that is the easy way. I am more about doing things using a stealthier approach. It’s about learning tools and cool things you can do with them. It’s not always about breaking stuff, sometimes it’s just about learning stuff.
That’s it for this short intro to some useful applications of hping3. In the end, the administrators at hackthissite.org did a decent job of hardening their Web server for that particular IP address. There were other IP addresses we could’ve also targeted that might not have been and there are plenty of servers that are not properly patched or configured that are easily exploitable. Just because we didn’t find success with bypassing the firewall on this target doesn’t mean that it won’t work against a different target. As has been famously stated before, “My only crime is that of curiosity.”
References:
Ferrell, R.G. (2019, May). The 5 different types of firewalls. Retrieved from https://searchsecurity.techtarget.com/feature/The-five-different-types-of-firewalls
https://helpmanual.io/help/hping3/
Alternate Resources:
[1] Hping3 — -> http://www.hping3.org
[2] Nmap — -> http://www.insecure.org/nmap
[3] Scanlogd — -> http://www.openwall.com/scanlogd
[4] OpenBSD — -> http://www.openbsd.org
[5] OpenBSD PF — -> http://www.benzedrine.cx/pf.html
[6] Ettercap — -> http://ettercap.sourceforge.net
[7] DSniff — -> http://monkey.org/~dugsong/dsniff
[8] RFC1141 — -> http://www.ietf.org/rfc/rfc1141.txt
[9] RFC1340 — -> https://tools.ietf.org/html/rfc1340
