Welcome back!
I’ve had an interesting weekend to say the least. For the first time in maybe 3 weeks of goose-eggs my fuzzer lights up with an “Exploitable” bug. I can’t say that there’s any type of logic or structure to this – some might call it pretty painful. It consist of me randomly downloading freeware and simply trying to find vulnerabilities by fuzzing. It’s sorta what I do for fun now when I’m tried of reading, watching courseware videos, or getting my ass kicked by a binary (most of the time this).
Before jumping into the details I want to briefly describe the setup. You can download from there Peach x86 it comes packaged as a zip. After you download it you may need to right click the zip, click properties and check “Unblock” which is basic protection since it’s downloaded from the internet. Go Windows! That’s pretty much it, everything including the main binary is packaged up nicely. The tough part about Peach is creating the “pits” – which model whatever file format you’re trying to fuzz. It also has the capability to fuzz any network connection. I’m not going to go into details of creating a pit it’s poorly documented online & you’ll have to learn just like I did lol.
Software: XMPlay Media Player 3.8.3
OS: XP/7
Format: m3u
Here’s a excerpt of the pit for M3u format it’s very simple
After maybe 3 minute I start to see the faults accumulating in the log
Fun fact: This was first time I’d ever seen EXPLOITABLE ever after like 3 weeks, I screamed so loud my wife thought I hurt myself. After punching the couch with all my might, dropping a few choice words, a few air punches, a tons of “LET’S GO’s” !! I was ready to begin investigating the crashes. It didn’t take long for me to become humbled again. I find myself looking at crash data and saying “WTF”. Here’s an excerpt
Here’s the file that the debugger generated that crashed it
Pretty narly stuff. How do I recreate this ? Enter Hell …
Now first off this taught me that not all overflows consist of excessive characters – sometimes it’s the type of character within the context of whatever your overflowing. In this case it’s a URL path. Theoretically if I copy the same amount of characters that the fuzzer generated in the crash file along w/ the headers I should be able to reproduce the crash. This wasn’t the case. So it took me using a hex editor and doing byte by byte comparisons on the crash file vs my file. Eventually I discovered the special character … A pipe | …. Without this – no matter the amount of bytes you send the application will never crash. [FML] OK whatever let’s keep going.
So I go through the normal process & determine this is going to be an SEH overwrite. I update my PoC and send over my buffer
Life seems very good I control nSEH & SEH .. Pass the exception to the program
EIP controlled so at the point I’m thinking it should take me around 10 more minutes and I’m done with this thing. When I updated SEH with a valid address I realized what I entered came out on the stack mangled. No where near close to what I entered (pop pop rtn). So after fighting for maybe a few more hours I realized I was dealing with a limited character set, and my buffer was chopped up throughout memory. Generating shellcode for alphanumeric situations is trivial .. generating a alphanumeric instructions to attempt to jump to your shellcode not so much. Along with safeseh protection on I washed my hands with this one & settled for the DoS and that I couldn’t gain code execution. It wasn’t a nice feeling but I remained happy because it forced me to think outside the box and learn new things.
Software:Winamp 3.8.3
OS: XP/7
Format: m3u
Alright so it’s later on in the day & I Google “programs similar to xmplayer” and Winamp comes up in the results. Winamp is pretty popular so it naturally feels like don’t waste your time this guy has to be safe. I check exploitedb before I start and don’t see anything – so I take a stab at it. Fun thing is once you develop the Peach Pit you can fuzz anything that consumes that file type – just modifying a few lines to point it to the new binary.
Not in a million years would I have thought my first two EXPLOITABLE crashes would brain fuck me. Both of them. Enter more hell.
I go through the same exact thing as the first one although I was feeling more seasoned this time I only spent about half hour recreating the crash and determining the funky character that causes the crash. In this case it’s an ‘@’ … Here’s the PoC
Now don’t ask how I determined the potential EIP it was straight up fight.. Check out what I see in the buffer after I send this PoC which is a bunch of A’s B’s & C’S
I LITERALLY SAID OUTLOUD “C’MON GIMME A BREAK HERE” … It took me a while to understand what was actually happening. Since my buffer again is in a URL path and this is a false path to a playlist my buffer was overflowing into the authentication piece of the request which was basic. So this is my buffer basically base64 encoded in hex. FML. Again alphanumeric only. I figured the only way for me to exploit this was to find a string that get base64 encoded & the hex value of that string points to a valid memory address. Ha. I wish I was that clever. So again this is a case of denial of service an no code execution. I spend so much time with both of these I decided to still shoot the DoD’s off for CVE’s let’s see what happens.
I decided to blog about these for transparency. Not everything you do is fruitful, some is just pain, but it’s worth it. This usually leads to tremendous learning and it stretches your thinking. This still stands true – there was no tutorial or prior write up to use. So the cleverness is all on you. When I felt myself complaining I said hey, you wanted to learn exploit development, well this is exploit development! You can’t complain when you get what you ask for. I think both of these made me a stronger and more clever thinker. The fight goes on!
