Saturday, July 14, 2012

Opening closed ports on NAT device and bypassing stateful firewalls with BeEF

Today's guest post comes from Bart Leppens. Thank you!

In 2010 Samy Kamkar discovered a method that he called "NAT Pinning."  The idea was, an attacker lures a victim to a web page and that web page forces the victim's router or firewall to forward any port number back to the user's machine.  The router, firewall, NAT-device must support connection tracking.  Samy Kamkar has successfully tested this on a Belkin N1 Vision Wireless Router.

Now, IRC NAT Pinning is integrated in BeEF as a module. It requires the victim to use Firefox due to blocked port number 6667 in most other browsers.  In this example, iptables is used to demonstrate how it actually works.

Let's imagine the following network:

And the configuration for iptables on the NAT/firewall:
 
#! /bin/sh

# DEFs
OUTIF=eth0
LANIF=eth1
LAN=192.168.1.0/24

# MODULES
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe iptable_nat

# Cleaning
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain

# Kernel vars
echo 1 > /proc/sys/net/ipv4/ip_forward

# Allow unlimited traffic on the loopback interface
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Set default policies
iptables --policy INPUT DROP
iptables --policy OUTPUT DROP
iptables --policy FORWARD DROP

# Previously initiated and accepted exchanges bypass rule checking
# Allow unlimited outbound traffic
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow inbound traffic on LAN
iptables -A INPUT -i $LANIF -j ACCEPT

# NAT
##########
iptables -t nat -A POSTROUTING -o $OUTIF -j MASQUERADE

# initiated and accepted exchanges from WAN to LAN
iptables --append FORWARD -m state --state ESTABLISHED,RELATED -i $OUTIF -o $LANIF -j ACCEPT

# Allow unlimited outbound traffic from LAN to WAN
iptables --append FORWARD -m state --state NEW,ESTABLISHED,RELATED -o $OUTIF -i $LANIF -j ACCEPT


iptables -A INPUT -j LOG --log-level debug
iptables -A INPUT -j DROP
iptables -A FORWARD -j LOG --log-level debug
iptables -A FORWARD -j DROP


Iptables must accept RELATED inbound connections and the IRC connection tracking modules must be loaded.

Suppose that machine with IP 192.168.1.100 has an Apache-webserver running on port 80 to serve some intranet, and that this site is normally not reachable from the outside (probably the Internet).

When the attack is executed, BeEF creates a temporary socket that listens on port 6667 for incoming TCP connections. The demo used netcat for this "nc -l -p 6667", but thanks to Antisnatchor, this isn't needed anymore!

Once this is done, we must fill in the correct parameters in BeEF and then try if the port has been opened. 

This can be seen on the following video:



The same can be attempted without NAT.  In this case a stateful firewall (e.g. iptables) also needs to accept RELATED inbound connections and the IRC Connection Tracking module must be loaded.


Imagine now that telnetd is running on the victims machine, but it isn't reachable due to the packet filtering of the firewall.  In BeEF, you can do this exactly as shown before. But, in this case, the private IP is the victim's public IP and the private port is the telnet port (probably 23).

If you're using iptables and you want to avoid problems with connection tracking, please refer to the secure use of iptables and connection tracking helpers.  These are the best practices to make use of connection trackers.

5 comments:

  1. I think in the top image the gateway ip's address should be 72.12.13.4, is that correct? at least that's what i see in the video at the end....

    So...You can control the internal ip also on which the forward is done?

    ReplyDelete
  2. Yes, the gateway ip should be 72.12.13.4. My bad!
    The internal IP can be fully controlled and doesn't need to be the victims IP one.

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Hi,

    I have contributed a script for Nmap a while back that checks for vulnerable firewalls based on Eric Leblond's work on opensvc ( https://home.regit.org/2012/06/opensvp-a-new-tool-to-analyse-the-security-of-firewalls-using-algs/ ). You can find the script here, http://nmap.org/nsedoc/scripts/firewall-bypass.html

    Cheers,
    Hani.

    ReplyDelete
    Replies
    1. That's just fantastic Hani! I'll look at it more in detail.

      Delete