Bypass hardware firewalls - DEF CON 22

This is a follow-up post in connection with my DEF CON 22 presentation.

TL;DR: attackers having admin privileges on Linux/Windows systems can mess with the hardware firewall between the attacker and the server, and use the same ports for backdoor communication as it is allowed in the firewall (e.g. 22, 80, 443, 3389, etc). First, the attacker has¬†to exploit the server, and only after that can bypass the firewall. If you are looking for a tool to bypass a firewall before exploiting a server, this tool won’t help you. If you are still interested, here is the tool: http://github.com/MRGEffitas/hwfwbypass

And there are some cool photos about DEF CON at the end of this post.

Introduction (the problem)

Penetration testers (or black hat hackers) sometimes face the problem of restrictive firewalls blocking the backdoor C&C communication. Sometimes it is possible to hack the server service (and get webshell, or temporary C&C via socket reuse exploits), and install the attacker tools/backdoors. But the hardware firewall between the attacker and the victim server might block the bind/reverse shell, and covert channels like ICMP/DNS/IPv6/UDP/proxy-hops might be blocked as well. There is in-the-wild malware solving this problem, e.g. the Hikit rootkit. This rootkit creates a new network interface (like software firewalls do), “catches” the traffic sent to the legit server service, and if the backdoor communication is found in the traffic, this data flow is handled differently, not by the legit service. At the hardware firewall level, the traffic will be allowed, as it is using the same destination TCP port as the legit service. Thus attackers can bypass hardware firewall restrictions, but not penetration testers. This is a gap between attackers and testers, which had to be closed. The idea of the hwfwbypass tool was born.

Details (the solution)

We developed a tool called hwfwbypass. The tool is a network filter kernel driver, based on the Windivert project. Admin level privileges are needed to install the tool. The kernel driver is digitally signed with a trusted signature, thanks to Nemea software development and the Windivert project.

After starting the hwfwbypass tool, when a client (attacker) connects from the TCP source port specified in the client_sourceport command line parameter, to the TCP destination port original_dstport, the kernel driver will redirect the traffic to the new_dstport on the server. The kernel driver first filters for traffic which has the TCP source and destination ports supplied in the command line argument, and if the packet matches, the packet is removed from the network flow, modified by changing the TCP destination port, and the packet is finally reinjected. If this packet is a TCP SYN packet, the (backdoor) service listening on new_dstport will handle the connection, and reply with SYN/ACK. The hwfwbypass tool will rewrite the TCP source port in this case from new_dstport to original_dstport, and reinject the new packet. The result is that we have a bidirectional TCP traffic, which uses the same port from a network perspective as the legitim service (e.g. webserver, RDP server, etc.), but is handled by a different process – which can be our backdoor server process. It is important to note that bind shells can be used with this tool, and not reverse shells.

hwfwbypass

There are additional use cases for the hwfwbypass tool:
1. The server can be used to be a hop/proxy to other servers in the same network segment, or to other servers which are not blocked by the firewall.

2. Even if the firewall allows the backdoor C&C communication without any hwfwbypass tricks, it might be useful to hide the traffic, thus log analysis/incident response won’t reveal that port 4444 on the webserver has an abnormal traffic peak.

usage:
hwfwbypass.exe client_sourceport original_dstport new_dstport [disablechecksum] [debug]

examples:
hwfwbypass.exe 1337 3389 31337
hwfwbypass.exe 1337 3389 31337 disablechecksum debug

Here is a youtube video about the tool:

And if you are lazy, there is a metasploit post module, controlling the netcat start, uploading and starting the hwfwbypass tool, creating the new session with the stealth port, making cofee etc.

metasploit

Benefits of the solution

  • It is using Windows supported network filter, thus this functionality will work in the future.
  • It ships with valid signed driver.
  • Any kind of backdoor traffic can be used with the tool. I have tested it with Netcat, Meterpreter TCP bind shell and a RAT with bind shell.
  • The server side does not need any specific tools, only the hwfwbypass and the RAT/bind shell. On the client side, one might need NetCat.

Drawbacks of the solution

  • If there is a network address translation (NAT)¬†between the attacker and the server, the tool won’t work. Deal with it.
  • NG (next generation) firewalls, which check the protocol, can block the backdoor communication. See improvement possibilities for the solution.

Hints:

From the attacker side, one have to set the TCP source port for the backdoor client application, which can be done with netcat. We used the netcat from the Nmap project. The following command makes netcat to listen on localhost TCP port 4444, and forward all traffic to RDP.SER.VER.IP and RDP port, but with the source port set 1337.

ncat -kl 4444 -c “ncat -p 1337 RDP.SER.VER.IP 3389”

Improvement possibilities

1. My first idea was that the backdoor bind shell should listen on localhost only, thus even the local software firewall can be bypassed, if any. Unfortunately, it turned out that it is not as easy as I thought. The Windivert project (and the official Microsoft Network filter driver) allows the rewrite of the interfaces during packet reinject to do this trick, but it is not working. This might be because there is no real loopback interface on Windows. I’m not sure how to solve this, at the moment I have added new firewall rules to my metasploit scripts to solve this issue – but this only supports Windows firewall.

2. Packing the whole solution into one (static) binary. I also tried this, but some solutions were not compatible with newer platforms (e.g. Windows 2012). I also had to solve to drop the kernel driver on demand, but I had no time to do that. If you feel, you can send me a quick patch and compilation instructions to solve these problems.

3. The code is a bit of a mess. It is a POC, and it worked at least once. There is some ugly code reuse in the code, which needs some object-oriented refactoring.

4. It would be nice to have some kind of wrapper code, which can encapsulate the backdoor traffic in different protocols, e.g. SSH, HTTP, HTTPS, RDP. This has to be implemented on both client and server side, as some kind of proxy tool. If you are aware of any projects (python, Java, anything) doing something like this, let me know! For example stunnel is a good solution to encapsulate the traffic in SSL.

Conclusion

Firewalls has been blocking network attackers in the last 20 years. Although there are ways to find holes in the firewall, a real restricted environment could block the whole attack chain. So far, there was no solution for this problem. Our tool requires admin level privileges on the attacked server to bypass the firewall, but if it is possible, the tool can be used to bypass firewalls, harden log analysis or incident response, confuse defenders.

 

2014-08-07

2014-08-07

2014-08-07

2014-08-07

2014-08-08

2014-08-09

2014-08-09

IMG_1596

IMG_1598

IMG_1607

IMG_1822

IMG_1868

IMG_1878

IMG_1913

 

 

Comments

  1. JOhn says:

    The problem has already been
    http://http-tunnel.sourceforge.net/
    or even better:
    http://www.nocrew.org/software/httptunnel/
    With this tools you can:
    request->localsocks>HTTPproxyOnAnyPort->HomeServer->Internet

    So if you are only allowed to use port 22 you just install a HTTPproxy on your HomeServer, listening to that part.

  2. Hi John,

    I know about HTTPTunnel. Thing is in my case neither SSH nor HTTP was not allowed through the firewall, only RDP.

    Zoltan

Leave reply

 

Our partners