ActiveX + XSS = ActiveXSS Pwnage!

On a recent web application penetration test, the in-scope web apps were running several ActiveX plugins. I’ve seen several ActiveX exploits published, but never looked into them. In this particular engagement, I found several XSS vulnerabilities. I thought it would be interesting to see if I could combine or chain a XSS vuln with an ActiveX exploit to illustrate ultimate client-side pwnage in a targeted attack. I decided to research and target one of the ActiveX plugins based soley on the vendor…and their reputation for bad programming.

First of all, a little background on ActiveX. When an ActiveX plugin is installed, a unique class ID for that ActiveX object is created and installed in the registry. You can look up this class ID by simply viewing the HTML of the web page calling the ActiveX object. We’ve all seen the pop-up or permission request to install an ActiveX plugin in IE. After installing the plugin, an OCX, EXE or DLL is installed and using vbscript, the web page can call the C/C++ functions exported by the OCX or DLL, or run the EXE. Here’s an example of what you might see in the HTML.

<OBJECT CLASSID="CLSID:FD0991-6411-49CB-91C0-6AAFEF7411AA" ID="TARGET" HEIGHT="0" WIDTH="0">
<script language='vbscript'>
    arg1 = "HelloWorld"
    TARGET.FunctionToCall ArgToPass
</script>

In this example, we call the ActiveX plugin using the OBJECT tag and specifying the CLASSID attribute. The ID attribute is later used in the vbscript to access the ActiveX object and call the exported functions. So, what can we do with this? Let’s find out.

First, I fired up ComRaider. ComRaider is a cool little fuzzer that will load ActiveX objects and fuzz each function that it exports. It requires the DLL/OCX that you’d like to fuzz. To find the appropriate DLL/OCX/EXE, I checked the HTML for the class ID and did a quick registry search to find which file is referenced through the class ID. Based on the previous HTML, the registry key would be:

HKEY_CLASSES_ROOTCLSID{FD0991-6411-49CB-91C0-6AAFEF7411AA}InprocServer32

Within that key, there’s a string value named (Default) showing the DLL that is loaded when the class ID is called. So, using the location of the DLL, we can go to ComRaider, feed it the location of the DLL, and start fuzzing the exported functions and libraries. ComRaider is a pretty easy program to use, so I won’t spend time reviewing how to use it, but the screenshot of my results. I blacked out the details of the DLL being fuzzed because as far as I know it has not been reported and is still unpatched.

The main things to note are the Exceptions column listing the exceptions from running the specified test case, and then below you can see the ACCESS_VIOLATION at address 0x41414141!  So it looks like ComRaider fuzzed the function by passing a bunch of A’s (0x41) as arguments causing a buffer overflow and the access violation.

The next step was to weaponize the exploit and make a cool demo video! First, to weaponize the exploit I decided to stick with XP SP3. I know, I know…it’s old, but my goal was to illustrate the effect, not be a ninja. ComRaider saves all the test case files (.wsf files), so I pulled out the code causing the crash, converted it to HTML, and threw it at IE.

BOOM! EIP = 0x4141414 and the stack is full of 0x41’s as well. Looks like a classic buffer overflow, and should be fairly straight forward to weaponize. Again, I won’t spend a lot of time on weaponizing the exploit. The best tutorials around on exploit development are over at the Corelan blog. But as a quick rundown, I used Metasploit’s pattern_create Ruby script to generate a unique string to replace the long, obvious A’s. After running the HTML file again, EIP became 0x67423667 and using the corresponding Ruby script pattern_offset in Metasploit, I was able to determine where the overwrite of EIP begins. In case these scripts are unfamiliar, the usage is pretty straight forward.

root@bt:/opt/metasploit# /opt/metasploit/apps/pro/msf3/tools/pattern_create.rb 2000
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3...
root@bt:/opt/metasploit# /opt/metasploit/apps/pro/msf3/tools/pattern_offset.rb 67423667
979

From here, it was pretty easy. I generated the traditional, but sexy calc popping shellcode. There are multiple ways to embed shellcode into HTML. You can call the unescape function in VBScript (or Javascript) and feed it your shellcode hex string, or use an alpha-numeric encoder and embed the shellcode directly in the HTML. I chose the latter. From here, it was some simple math to ensure the stack was setup properly, adding some NOPs for the slide, and finding addresses for the necessary pivots.

Obviously, the target has to have the ActiveX plugin installed to be exploited, but in a targeted attack a very high percentage of employees will have the plugin installed. Combining the client-side ActiveX vuln with a XSS vuln in the organization’s website, and I suspect you’ll get some extremely high click through rates, resulting in a lot of shells.

I’ll be the first to admit, I’m not the best exploit developer out there, but this was a fun experiment/PoC that can really illustrate the dangers of ActiveX as targeted attacks rage on. And here’s the finished product!