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.
It all works as follows: The service proxy payload is delivered to the victim. It creates an outbound sockets connection to the broker. Client programs are loaded with library wrapper. When a client attempts to open a socket or perform a DNS lookup, a message is routed instead to the broker which forwards the request to the proxy via the existing socket. The proxy performs the function using the local resource such as DNS resolution on the victim and replies to the broker. The broker finally passes responses back to the client. In the case of a new socket connection, a forwarding relation is established in the broker and the proxy to continue passing messages and socket events like close() for the life of the client connection.
A hypothetical situation: We have a file upload vulnerability on a webserver, and have uploaded a basic webshell, which we can use, fetch and execute the service proxy payload. The server can make outbound connections on port 443. The attacker is at 172.16.235.140.
First, we setup a few environment variables on the attacking computer, which the broker and library wrapper will use:
Then we will make the broker component ready:
The payload is executed on the victim:
In this case, the victim machine is on TrustedSec’s internal network. As the attacker, I don’t know much about the internal network but fortunately because my proxy offers me DNS resolution using the victims resolver, I will guess that there is an “intranet.companyname.local”.
Great! Looks like an IIS server there, which is a place to start anyway. Maybe I’ll start iceweasel with the wrapper and explore that for a while!