Discovering ActiveX Vulnerabilities -- Part 2 [Fuzzing]

So, continuing from where we left of last time, we will be looking at the Dranzer fuzzing tool in detail in this part. In case, you landed here directly and are wondering what this is all about, I suggest you have a look here first.

Dranzer is a well documented tool and I also suggest you have look at their documentation before starting with this so that you will be familiar with it in general. It's a very simple yet powerful tool. So, assuming you have read the first part, you should now have with you a fresh WinXP machine with Dranzer, OllyDbg, a text editor installed and the ActiveX "Classid" you want to fuzz. A note here, "Classid" is sometimes referred to as the "GUID", so do not get confused. They both mean the same thing.

All right, since Dranzer is a command line tool, fire up your command prompt and go to the Dranzer default directory which is "C:\Program Files\Dranzer\Dranzer\Release". Create a text file say "CLSID_to_test.txt" and add your ActiveX classid to that file. It should look something like this - "{EFB46ED3-8FD8-...}". If you have multiple classid's to fuzz you can add them one below the other in this file. Save the file.

Step 1: Run Dranzer with the following parameters - "Dranzer.exe -i CLSID_to_test.txt -t". You should get something like this on the screen -

Fig 1: Running Dranzer from command prompt

The "-t" switch basically tells Dranzer to test the "Interfaces Properties and Methods" for the ActiveX control. In my case all the tests passed, so nothing interesting here. Please note that I have purposely censored the ActiveX control information since the vulnerability has not been patched yet. In case you get a failed test here, you can directly go to step 3. You can also use the "-b" load in browser option, but frankly I haven't found it that useful.

Step2: Next, let's check the ActiveX control's "PropertyBag" using the following command - "Dranzer.exe -i CLSID_to_test.txt -p". This is what I got -

Fig 2: Dranzer detecting crash

Looks like we got a crash ! Now Dranzer tries to gather as much information about the crash as possible and prints it on the console. If you happen to find that cumbersome, you can always use the "-o filename.log" switch to save the output to a log file and view it later. Coming back to my crash, Dranzer says it's a "Exception Access Violation". Now as hackers or vulnerability researchers, a memory access violation is thing you really want to see, trust me ! ;) .. In lay mans terms it means something is abnormal and that some registers were arbitrarily overwritten with junk when IE tried to parse the file generated by Dranzer.

Step3: To see if the access violations can be exploited or not we need to use a debugger, which will allow us to debug the crash in detail as well as give us more information on what is being overwritten. Whenever Dranzer detects a crash, it conveniently saves the code that caused the crash in a html file in it's directory. The name of that file is the {classid}.html and is nothing but the Proof-of-Concept (PoC) for the vulnerability. In my case I have renamed the file as evil.html. Since it will be tedious to explain working of Olly using screenshots, I decided to make a small flash movie of it. Hopefully, it will be much easier to understand by watching how it's done.

What I am doing here is basically opening IE from within the debugger which will help us see the state of various registers as IE crashes. As you can see, along with the registers the Structured Exception Handler (SEH) as well as Execution pointer (EIP) gets overwritten. Those are typical symptoms of a classic stack based Buffer overflow vulnerability. In the video I also showed you how to use the "Call Stack" command in Olly to trace the vulnerable function which in this case is wcscpy() and which also happens to be the unicode version of strcpy(). These functions are known to cause overflows when used improperly. By adding breakpoints and repeating the same steps you can further trace the vulnerable code.

So, now you have seen how Dranzer can be used discover flaws in ActiveX components as well as how to use Olly to debug crashes. There are some other options with Dranzer as well which I will leave it to you to explore. In Part 3, I will show how we can use this information and convert the PoC into a real world exploit.

Hope you found this useful. Remember, discovering vulnerabilities needs tremendous amounts of patience. It may not be so easy for you to find a vulnerability every time or even to debug it for that matter, so keep trying !

Happy fuzzing :) !