Usually when I analyze a protocol or a file-format I spend a few hours or days mapping out targets. The first step towards really understanding what you’re dealing with is to really get to know your target.
- Search for old vulnerabilities, find a common motive.
- Attempt to find signatures of third party libraries. If found, check if they are indeed the last version
- Map out the types of data that the application parses. (for example, on internet explorer you could attempt to attack jpg images, the java-script interpreter, and many other components that are being parsed by internet explorer or passed on to the operating system)
Suppose that you actually did all that and couldn’t find any old vulnerabilities in the target application (at least not public ones), third party libraries are all up-to date, and you mapped out a single format but there is no documentation available.
Before firing-up IDA and starting to reverse engineer the format, there is one more thing you can try. You can try “bit-flipping” the format. Bit-flipping is a nice way of saying do an extremely dumb process of fuzzing. A stateless fuzzer without any accuracy and knowledge of the underlying format, which is the best you can do without any knowledge of the format. There are multiple ways of doing bit-filliping based fuzzing.
- You can use some hex-editor to try and detect data-types that could cause problems (usually a “length of” or an “offset of” integer field), compose a list of these element’s offsets and sizes and use a basic python script to fuzz them.
- You can try and fuzz every single entry of X bytes into 0xFFFFFFFF and other potentially problematic sizes.
- You can manually edit the bits according to whatever you think is right.
Most of you are probably thinking that this method is a waste of time, well… in most cases it is, but not always. It’s something you should probably keep in mind for these rare cases when it’s useful. In this post I’ll show one of these cases when it *is* useful – Winamp. Winamp in its default installation supports a variety of formats besides the normal mp3 and wave. I decided to try and find a vulnerability in one of these formats, I went over a list of unknown and undocumented formats I have never heard of, acquired sample files for the ones I could find online, acquired format specifications for the ones I could find online. At this point I couldn’t find a quick way of finding a vulnerability without resorting to reverse engineering. So I tried bit-flipping the files. I went over several files until I reached the impulse-tracker format (.IT) and found several heap overflow vulnerabilities pretty quickly. When editing the sample file and modifying the value at offset 0x1287 from 0x47 to 0x7F you start noticing some strange crashes.
Viewing the call-stack (ALT + K) indicates that this crash is at “RtlpCoalesceFreeBlocks” which is called from “RtlFreeHeap”.
In other words, this is a heap-based buffer overflow. Searching the file for the value 0xACE3019E indicates that it does exist at offset 0x2C52D. We modify the values at 0x2C52D and execute winamp again.
As you can see we actually control these values. And this is indeed a heap-base buffer overflow. The operating system it was executed on is a Windows XP Service Pack 2. This version of Windows XP has several heap protections I’m not going to address at this post. At this point we can try and find a good allocation pattern that will lead the overflow to overwrite a virtual function table or keep on debugging the application to see what actually caused the vulnerability.
When I found this vulnerability I used manual bit-flipping, tried multiple combinations of faults at different locations that looked interesting. I wrote a small python-script for bit-flipping. I implemented two bit-flipping techniques in this script. The first technique allows you to choose the locations you want to bit-flip and then let the script generate the faults and fuzz the file.
The second technique just goes over the entire file while modifying every X bytes into the currently generated fault. The example above applies to winamp v5.56, a quick test showed that winamp v5.57 is vulnerable as well but winamp v5.57.2 is immune to the vulnerability. There are several other vulnerabilities hiding in this file format, but i’ll leave it up to you to find them :)
About the Author
Tal zeltzer (zelik) is a security researcher from israel, focusing on reverse engineering both software and hardware. He spends most of his free time developing private security tools and exploits for fun.