Greetings! Over the course of the next few posts, I'm going to walk you through my current approach to buffer overflow (BOF) exploit development in Python. My core goal with this exercise was to gain experience with BOF exploitation in preparation for my upcoming OSCP test, but a friend of mine encouraged me to document the steps I took. (Great idea, thanks @3t3rn4l P4r4d0x!)

The next few posts will cover the entire process, from zero-knowledge to fully-working exploit. (That being said, the target I chose to exploit was trickier than I expected, so this will be a little bit more involved than your average first-timer's SLMail exploit.)

This series of tutorials was made possible by generous (software and tutorial) contributions from Offensive Security, Microsoft, VirtualBox, Immunity, Inc., Corelan Consulting, Stephen Bradshaw, Justin Steven, and hackers like you. Thank you.

Let's get started!


« prev. [Table of Contents] .next »


Setting up the Target Machine

(Note: For the target and victim machines, I have chosen to use VirtualBox formats, but you'll want to choose whichever format best suits the hypervisor you're using.)

For my target machine, I'll use a 32-bit Windows 7 VM from Microsoft. (I chose IE11 on Win7 (x86).)

On the target machine (Win7) I install Immunity Debugger and Mona.py (following the set-up instructions found in Justin Steven's BOF Tutorial). Next, I download the Vulnserver application, which will be the target of my exploitation attempts. I place the vulnserver.exe and essfunc.dll files on my desktop:

desktop files

With that complete, I change the target machine's network configuration to use a host-only adapter, so that it is quarantined on a private network:

host only

Finally, I run ipconfig to get the IP of my target machine:

ipconfig

My target machine is on 10.10.12.4.

Setting up the Attacker Machine

For the attacker machine, I'll use a Kali Linux VM from Offensive Security. All I need is Python 3.7, since that's my language of choice for writing my exploit code. Fortunately, the latest version of Kali includes this by default, so I don't need to download anything.

I change the attacker machine's network configuration to use the same host-only adapter that the target machine is using. That way, the two machines can communicate with each other, but not with the outside world.

Finally, I run ifconfig to get the IP of my attacker machine:

ifconfig

My attacker machine is on 10.10.12.3.

Note: This IP is assigned to eth1 on my VM because I have two network adapters on the machine. The second network adapter, eth1 is my host-only network. My first adapter, eth0, is a bridged network. I can switch between these networks when I need access to the internet, but I never have them both connected simultaneously.

Starting Vulnserver

Now that the attacker and victim machines are configured, I'll start Immunity Debugger and load the vulnserver.exe file. To start Immunity, I right-click on the icon and select Run as administrator:

run as admin

Once the application has loaded, I select File > Open (or hit F3) and open the vulnserver.exe application:

open vulnserver

Once the software is loaded, Immunity pauses execution (as evidenced by the “Paused” message in the status bar):

paused

To begin execution, I select Debug > Run (or hit F9):

run server

If I need to restart the service, I can select Debug > Restart (or hit Ctrl-F2):

restart

I use the Run and Restart functions regularly, so I prefer to use their keyboard shortcuts to save time.

Checking Connectivity

Now that I've got vulnserver.exe up and running on the target machine, it's time to test whether I can reach it from the attacker machine. In Kali, I use nmap to check whether the server is listening on port 9999:

root@haxys:~/bof/pt0# nmap -PN -p 9999 10.10.12.4
Starting Nmap 7.70 ( https://nmap.org ) at 2019-07-15 15:34 EDT
...
Nmap scan report for 10.10.12.4
Host is up (0.00098s latency).

PORT     STATE SERVICE
9999/tcp open  abyss
MAC Address: 08:00:27:10:B8:D0 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds

Great! I'm ready to begin… Almost.

One Final Step

Now that I've got everything set up and ready for exploitation, I terminate all programs, shut down both machines, and create snapshots of their current state. That way, should something catastrophic happen, I can easily revert either machine back to a pristine state.

snapshot

The End of the Beginning

Thanks for reading, and stay tuned for the rest of this tutorial series! As each part gets released, I'll link them all together for easy navigation.