When I started PWK, I initially only signed up for 1 month access. I was putting in a huge amount of time in the labs, learning what I thought would be enough to get through the exam, without completing the buffer overflow section of the exam.
I was scared of buffer overflows, all that hex and assembly, shellcode, memory addresses, endianness… I tried to skip it.
This was a bad idea.
Of course, I didn’t get through the exam. Afterwards I realised that this was a major bag of points on offer, and that it was really just something I didn’t need to be scared of, that it could be learned, that I would need to learn it, and I would have to understand it!
After that exam, in addition to practicing my other weak areas I spent a number of weekends learning the processes behind a simple stack buffer overflow so that I had a very good understanding of the process.
The first thing I did was to, believe it or not, ignore the OSCP buffer overflow guide!
In the local infosec community I’d heard a lot of great things about Justin Steven’s ‘dostackbufferoverflowgood‘, which I believe was a workshop at CrikeyCon 3 in 2016. People who’d never done a buffer overflow before were able to read, follow, and complete the exercise. This sounded like a good place to start!
The full documentation is on GitHub at this link: dostackbufferoverflowgood – and it’s remarkably complete, well formatted and, just perfect for your first saved return pointer buffer overflow. It includes a pre-compiled vulnerable Windows binary, source code for the vulnerable binary, Visual Studio solution files, documentation in Markdown format and the ultimate PDF guide to step through the entire process. You really can’t ask for anything more when learning this stuff.
I read the PDF cover to cover over a couple of nights, then on the following weekend setup a Windows 7 VM on my laptop, installed Immunity, python and Mona then the re-read the PDF and performed each step manually as I followed along.
Before very long at all:
— vortex (@vortexau) February 26, 2017
I took some very important things out of dostackbufferoverflowgood – the first is to ‘pop calc’ – generating shellcode with msfvenom to execute a binary on the system, generally calc.exe, which proves the concept of the shellcode executing correctly. As Justin says, this can save hours of frustration and debugging when you can’t get a reverse shell to work, and you’re not sure what the problem is. If you can pop calc, you can be reasonably certain the issues aren’t with the exploit itself (but, this isn’t always the case!).
The second, was to use opcodes like ‘sub eax,0x10’ where possible, rather than using ‘nops’ (\x90). This is important when there is precious little buffer space, it subtracts 16 bytes from the memory address in EAX, moving the pointer up the stack so that when GetPC executes (the decompression routine in the msfvenom shellcode) it doesn’t overwrite anything important in our buffer.
Once that was out of the way, I thought I should take a look at the OSCP buffer overflow video walk through.
I watched the OSCP video which is voiced by Muts from Offensive Security. I added a page to my private GitHub Gist, and noted everything down. Everything! I would watch a section, pause, write some notes then check the notes against the video again. I re-watched sections over and over to make sure I was truly understanding the concepts that were being presented, organising them into lists under each major section.
Once I had completed the notes, I re-watched again, this time working on the code as I went. I also started something I’ve done for every buffer overflow since, copied the previous file at each step into its own new file:
I don’t think I’m giving too much away by posting that, given there is working exploits on Exploit-DB.
So, you’ve done ‘dostackbufferoverflow’, and manually exploited ‘slmail’. What do you do next? I looked for a list of practice applications – and came up short. There were a few other constructed binaries designed for exploitation practice and learning, but personally I wanted real programs.
What to do?
I spent some time going through the OffSec forums and Exploit-DB, downloading and installing all kinds of applications which looked like they were a simple buffer overflow. Additionally, Exploit-DB provides downloadable copies of the vulnerable app in many cases – these were the ones I looked for primarily.
The list of applications I used to practice was:
SLMail: https://www.exploit-db.com/exploits/638/ – The application covered in the OSCP guides. Additional practice can be had with the C code in https://www.exploit-db.com/exploits/646/, this will challenge your understanding of the process, and by making it work – you’ll learn some C!
FreeFloatFTP Server 1.0: https://www.exploit-db.com/exploits/17546/ – I didn’t realise this at the time, but this application actually appears to have many many vulnerabilities in different commands; there could be a lot of practice mileage from this one if you follow the buffer overflow process for each vulnerability that the program has. Exploit-DB knows about quite a few from what I can see.
Minishare 1.4.1: https://www.exploit-db.com/exploits/636/ – Nothing too much to write home about, fairly standard BoF.
Savant 3.1: https://www.exploit-db.com/exploits/10434/ – Straight up BoF once again, but there is a couple of gotchas on this one where you might need to think outside the box.
WarFTPD 1.6.5: https://www.exploit-db.com/exploits/3570/ – This one is olllllllddddd! I tried running it on Windows 7 with Admin privs, enabling compatibility mode, and a few other tricks but every time it would exit with a WinSock error. I ended up having to run it on Windows XP 32 bit to get it to work.
Another way of getting more practice is to run these on Windows 7 AND Windows XP and then build exploits to target these, or possibly even later versions of Windows. Depending on the vulnerability and the program, this could cause changes in memory addresses used internally, meaning you might need to go through the whole exploit development process for each once again, giving you some more practice!
In any case, when you set up your VM – once you have the basics installed, immunity, python and Mona – snapshot it at this point. This way you can install anything you please, then revert once you’re done. SLMail for example is actually a trial version too, reverting makes it simple to get rid of.
So, I think that’s a reasonable starting point. That’s a few nights of hacking right there, so get practicing!