Sometimes when I conduct a network penetration test it's just too easy to get to the "crown jewels". And sometimes I just hit the wall from the very start and have no idea how to proceed. It happened to me during my last test, when the client chose to decline the option to whitelist my penetration testing device on their Network Access Control (NAC) system.
Below I explain how when my IPv4 connections were blocked by the NAC system, I used IPv6 to compromise a number of hosts and some sensitive data during a recent test.
The pentesting device was located in the internal client network and I was connecting to it remotely over an SSH connection. And, as it turned out later, that was the only connection allowed for this device. So it was far from easy to test anything in that scenario. Since the client preferred an entirely black-box approach, it seemed the list of results might be empty. But where there's a will, there's a way…
At the beginning of the test I had started a port scan to find any active hosts with open ports. That was unsuccessful but I noticed something weird in those scans. They finished very fast, but too fast. A little investigation and I understood that there was some kind of active defense system in the network that was resetting all my connections that were going to active hosts. So at least I knew that I was not alone in the network and that I would need to find another way to access other machines.
I launched a sniffer and after a while of looking at the flowing traffic, I came up with an idea: If all my IPv4 connections are getting blocked, then why not try to use the IPv6!
So just a little refresher for those who are not familiar with this protocol:
- IPv6 is the latest version of the Internet communications protocol intended to replace IPv4, as IPv4 can only address about 4 billion unique IPs, and the 21st century Internet needs much more than that. IPv6 expands the number of available addresses to an almost limitless amount: 340 trillion trillion trillion addresses!
- Unlike the IPv4 address space, it is not easy to scan IPv6 addresses in order to discover active systems (due to wider address space). But just as with IPv4, you can ping the broadcast address (in IPv6, this is FF02::1) and all the systems on the local network should respond to this.
- IPv6 sometimes can be overlooked by the network engineers who are setting up the firewall/NAC rules. And because many firewall products might not block IPv6 traffic by default, we can use this gap for our penetration test.
- You can find more detailed information about IPv6 on Wikipedia or the IPv6 RFC.
A little bit of Googling and I find out that Nmap and Metasploit already have some nice modules to discover IPv6 addresses in the local network. The Metasploit module "ipv6_multicast_ping" worked fine for me and I was able to discover other IPV6 enabled hosts in the same subnet:
The next step was to find running services on the discovered hosts. Nmap has been offering basic IPv6 support (like connect port scans, basic host discovery and version detection) since 2002. So we can scan the IPv6 address with this command:
nmap -6 -sV <IPv6_address>
(You don't need to add the interface name e.g. "%eth0" at the end of the IPv6 address anymore if you are using one of the latest versions of nmap)
Wow, this phpMyAdmin on port 80 looks promising, but can we access this service running on IPv6 host with a normal web browser?
Yes we can! Many modern browsers support the IPv6 protocol by default. But in my scenario, when I was accessing this host over an SSH tunnel with port forwarding enabled, my Firefox browser couldn't load the website. With a little help from a more experienced pen tester, I ran "socat" to proxy IPv4 to IPv6 traffic. A sample socat command you can use to bind a remote 80 TCP port on the IPv6 host to your local 8080 TCP port:
socat TCP-LISTEN:8080,reuseaddr,fork TCP6:[IPv6_address%eth0]:80
Then we can easily load the website using our localhost address:
Bingo! It seems that someone forgot to set up a password for the root user on the phpMyAdmin web page. From here we can create a simple web shell and gain access to the operating system command shell in a few minutes:
And we have a remote code execution!
Conclusion
At the beginning of the test, I was thinking that there was no hope and that I would end up without any serious finding that I could include in the report. Knowing that there was a NAC system in the network was only adding to my frustration. I didn't believe that there was a way to bypass it, because after all it was a product made by a leading company in the IT security field. But in the end, with a little help from the IPv6 protocol, I was able to pwn some hosts and get access to the sensitive data.
So remember, when you are running a test and everything goes slowly and with little success, you just never give up, there's always a way.
