I realized that while buffer overruns are very common in my world, most of my tech friends had actually never seen one. As such, I decided to put together a demo. I found someone that did a really decent demo just a few years ago on a centos virtual box MadIrish. I attempted to pull the same exact thing off in an Ubuntu server (it’s really easy for me to spin these up in my test environment - perhaps I need to put together a post on ubuntu-vm-builder another time). As you will see, I am just following his guide, but making changes as needed for my Ubuntu 14.04 LTS Server I just spun up…

Required Tools

So, for the most part I was able to just apt-get install these things. Interestingly enough the ld application that I couldn’t install his way is just part of binutils from an Ubuntu 14.04 perspective. Also I found I needed nano, but then again I was doing this all over ssh…

sudo apt-get install gcc gdb nasm binutils python
sudo apt-get install nano

Introduction

This part worked great on my box… ;)

Turning Off Stack Randomization

So instead of editing the sysctl.conf file, I just ran the below command to disable the aslr(address space layout randomization). Changing it to echo a 2 instead of 0 will turn it back on. The other nice thing I like about this, is that a reboot will also turn it back on. There is a different DEP thing going on in Ubuntu called NX that doesn’t seem as easy to turn off - I am going to go through the example and see if it will work with it turned on (it did)…

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Other Fine Tuning

Checking and setting the core dump works the same way, and I certainly have no SELinux on this machine.

A Further Look at Stack

No changes here…

A Look at the Victim

Same exact code here.

gcc -fno-stack-protector -z execstack blame.c -o blame

Overflowing the Buffer

This where I got into trouble. My default machine was 64 bit and his is 32. 64 bits adds a bit of complications into all this. Everything was a little different and I was really struggling to write anything past rip (64 bit equivalent to eip). As such, I went ahead and re-rolled my machine 32 bit and started over… Once that was done, this moved along quite well…

A Simple Fix

Yep, I created a second version with the fix in here and it worked great.

Back to Our Regularly Scheduled Exploit

No worries here..

Generating Shellcode

This was new and different for me. I have always ganked shellcode off the internets script-kiddie style, I really appreciated this walkthrough, and it worked great on my box - no modifications.

Injecting the Shellcode

This was spot on. Obviously my machine landed at a different memory address, but this was perfect.

Release the ‘Sploit

This didn’t work for me so well. The address space I got from my program was close to what I needed, but far enough off that it just bombed out. After it bombed, I was able to look at the memory after it x/256xb $eip and that got me where I needed to be. Also his example was completely missing any memory address or eip overrun - I am thinking this was an oversight.

python -c 'print "\x90"*212 + "\xeb\x19\x31\xc0\x31\xdb\x31\xd2\x31\xc9\xb0\x04\xb3\x01\x59\xb2\x18\xcd\x80\x31\xc0\xb0\x01\x31\xdb\xcd\x80\xe8\xe2\xff\xff\xff\x6e\x6f\x77\x20\x49\x20\x70\x30\x77\x6e\x20\x79\x6f\x75\x72\x20\x63\x6f\x6d\x70\x75\x74\x65\x72" + "\x82\xf6\xff\xbf"' | ./blame

Final Thoughts

That’s about all I got for this one. I have to come back to it and put together a powerpoint… I may clean this up or add to it later.

Finaler Thoughts?

Huh - I put together the powerpoint, and demo c code, but never really cleaned this up. If anyone wants the presentation with demo code hit me up on the twitter.