June 05, 2015
Scaling New Walls with Old Ladders
Written by
Geoff Walton
The security landscape is always changing. Both attackers and defenders are constantly facing new challenges. The content of the pentester’s toolbox today is very different from just a few short years ago, as has the array of technologies, network administrators, and security practitioners have at this disposal to defend against increasingly capable threat agents. With that out of the way, sometimes there is value in looking back.
I have been reflecting on some of my recent experiences attempting to escalate privileges on contemporary Windows platforms. The conclusion I have come to is: I frequently cannot. Having a meterpreter shell with some unprivileged service account on Server 2008, 2012 or Windows 8.x in no way guarantees I am going to get anywhere with a simple “getsystem” - far from it, in fact. Happily, I am probably not even that lucky from the outside, often the best I am going to get is some klutzy web shell. So I am left with choices: I can pour a bunch of effort and risk of detection into gaining greater access to the webserver, or I could just move on. I like that latter option because let’s face it - all the goods are in the backend database or otherwise on your internal network; your front end webhost is boring.
In the previous millennium before NATs were everywhere, there was a useful bit of software called a socks proxy, or sockets proxy. Host A would contact Host B asking to connect to Host C on a network that B could reach but A could not, usually because B was dual homed; B would relay transport layer messages for A and C. This was and is in more recent forms like SSH a good method for firewall bypass. Most of the time though firewalls, software or otherwise, they won’t let traffic through to the listening port form the outside, and your HIPS software is going to freak when it sees something new listening anyway.
Actually, SSH’s own dynamic port forwarding can do this, but since Windows servers don’t usually run SSH, I would need to authenticate with daemon sshd which probably isn’t configured to allow port forwarding if it is there. If I try to deploy my own SSH client or daemon, various software restriction controls are likely to block any common binaries.
What I need to do to solve this is to split my proxy into a few parts: the service proxy, a connection broker, and a library I can dynamically link. The library will wrap calls to connect(), getaddrinfo(), gethostinfo(), gethostbyname(), and a few others so I can run my favorite tools through it. That will be enough to give me basic DNS and TCP on your network while satisfying a few conditions.
- The service proxy need only make a single outbound sockets connections to me the attacker
- The connection can be made on arbitrary port
- The payload is small (13K and should be easily reduced from there) and can possibly be loaded without hitting disk, through reflective injection via Powershell or Windows Scripting Host to evade application policies if needed.
- No elevated privileges should be required
- It needs to support a number of simultaneous connections so more complex software like web browsers can be supported.
for I in $( seq 1 254 ); do LD_PRELOAD=./proxify.o nc -z -v 10.10.10.$I 445 & doneand
nc –v –z 10.10.10.10 20-512Here is another thought for you: The victim was a virtual machine that shared a gateway with the attacker, not a requirement in the compromised web host example but not uncommon in a coffee shop or hotel. TrustedSec’s VPN does not allow split tunnel traffic that is all traffic on the client is sent into the VPN, except the VPN traffic itself of course. Like most VPN clients, it accomplishes that by replacing the route to the gateway with a host route via the gateway for the VPN pier, and changing the default gateway to the VPN pier’s inside address. Consequently, non-tunneled connections can still be made to the gateway’s address directly. Considering the pwnd gateway scenario, an attacker might use tools like site cloner in the SET Toolkit to compromise an endpoint, especially if he can redirect HTTP or DNS traffic. After compromising the endpoint and injecting the service proxy payload the attacker simply waits for the victim to connect to their VPN and voila! The service proxy can still call the attacker back at the gateway IP and every connection it proxies will route via the VPN! If your endpoint security and client firewall configurations are not up to task, your datacenter might be a lot less isolated from everyone else at the coffee shop than you guessed. Do you know who is really on your VPN? Want to know more? Want to see some source code? Come out to DefCon where TrustedSec will be presenting this and more! Details to follow! This article was written by Geoff Walton of TrustedSec