Monday, April 08, 2013

Buffer Overflows with Bowcaster Part 4

In part 1 of the Bowcaster tutorial I showed how to generate an overflow string with the OverflowBuffer class. In part 2, I showed how to populate your your overflow string with ROP gadgets. In part 3, I showed how to add Bowcaster's connect-back payload for MIPS Linux to your overflow string. I also showed how to encode your payload using Bowcaster's MIPS Linux-specific XOR encoder in order to sanitize restricted bytes.

Part 3 ended by using a netcat listener to serve a connect-back root shell. In this part I'll show how to use one of Bowcaster's server modules to replace netcat.

Bowcaster provides a couple of server modules to receive connections from connect-back payloads. The one we're interested in for this tutorial is imaginatively called ConnectbackServer.

Import it into your exploit code like so:

frombowcaster.servers.connectback_serverimportConnectbackServer

In part 3, we create a payload object by first creating a ConnectbackHost object and passing it to ConnectbackPayload(). Creating the server works the same way. Using the same host for both payload and server ensure the payload connects back to the right IP address and port.

The ConnectBack server class provides some features that you don't get with a simple netcat listener. First, it gives you the ability to automatically execute a command on the target upon connection. More on this in a bit.

More importantly, by forking into the background and operating asynchronously, ConnectbackServer gives you the ability to serve a connection right from your exploit script rather than having to fire up a listener in a separate session. For example:

Like I mentioned above, the ConnectbackServer class takes an optional 'startcmd' argument to its constructor. This is useful in a few ways. First, I like to use /bin/sh -i just because it looks nicer to have that familiar root '#'. But you may want to issue a command to restart the exploited service, that way your target is automatically prepped for re-exploitation.

But, there's another optional argument to ConnectbackServer that, when combined with startcmd, is pretty cool. You can optionally specify connectback_shell=False. If you do this, then ConnectbackServer will not provide an interactive shell. Instead it will send the start command if you provided one, and then immediately close the connection. Why is this useful? Say you wanted to exploit a list of ten targets and have them automatically prepped for interactive login whenever you're ready. You could do: