Revenge of the Bind Shell from Practical Exploitation on Vimeo.

BACKGROUND

At the April 2010 NoVA Hackers meeting I discussed some of the offensive uses of IPv6 on current networks. Well, around that time Microsoft issued a patch to all of the supported versions of Windows that broke my methodology. Obviously I wasn’t the only one doing this ;–)

Before I get ahead of myself lets explain what Teredo is. Teredo is a tunneling service built in to Windows. It’s intent, as far as I can tell, was to allow anyone to have access to the IPv6 enabled internet, free, and dead simple, no infrastructure changes needed. You can get into much more detail on the Teredo TechNet article, but essentially an internal host is asking a Teredo server/relay for an IPv6 IP address. It does this over UDP and which by default in Windows points to teredo.ipv6.microsoft.com over port 3544 (UDP).

When the tunnel is established, the host is given a 2001::/32 address. This address is a public IP. Before April this essentially meant that your Windows shares and any other listening service was publically available, despite your NAT and Firewall.

This isn’t as much of a problem as you might think as it’s virtually impossible to guess or scan for an IPv6 address. So, unless you displayed it publically by connecting to Freenode or posting it online somewhere (via a demonstration video). You’re pretty safe.

THE PATCH

Microsoft made this a certainty when they issued the patch. I was unable to locate the specific one, or even identify for certain that it was April 2010, but that’s when the initial article for IPV6_PROTECTION_LEVEL was published. This is a socket level option that says, unless this flag is set to “PROTECTION_LEVEL_UNRESTRICTED” on the binary that is doing the communication, deny all traffic from NAT Traversals (Teredo). (Even Netcat6 doesn’t have this flag set!)

Essentially, unless someone rebuilt their binary with the explicit intention to allow people to connect to it over NAT Traversals, the traffic was denied. You were still allowed to connect out, keeping in tact the initial idea for Teredo, but it broke my methodology damn it!

I used Teredo to connect to the SMB server so that I could psexec a shell back any time I wanted before (still possible on non-patched systems) but since Microsoft doesn’t want to add the PROTECTION_LEVEL_UNRESTRICTED flag to SMB you have to just upload and use a binary that does. Luckily, with the help of Stephen Fewer, the bind_ipv6_tcp payload in Metasploit does.

COMMANDS

The commands used in the video are below:

• netsh interface ipv6 install
• netsh interface ipv6 set teredo enterpriseclient
• ./mspfayload windows/meterpreter/bind_ipv6_tcp LPORT=9001 X > bind.exe

The only thing that was behind the scenes was giving my Metasploit host an IPv6 address. I used Miredo (Teredo for *nix/OSX):

1
2
3
4
5

# Install miredo
apt-get install miredo

#Remove it from starting automatically     
update-rc.d miredo -f remove

PROTECTION

Yes, it’s that easy. Now, some of the mitigating suggestions I’ve seen on the net is to blackhole the Microsoft Teredo server, or block the UDP port 3544. However, Miredo can act as a Teredo server/relay just fine, and can listen on any port you wish (53?). So unless you block ALL UDP outbound traffic, you are not protecting against this threat.