ActiveX Kill Bit Can Be Bypassed - Another Reason to Apply MS05-054?
ISC reader Juha-Matti Laurio pointed out a new vulnerability note VU#998297, published by US-CERT on January 26, 2006, which states that a malicious website can bypass an ActiveX kill bit by taking advantage of a bug in Internet Explorer.
A kill bit is a registry setting that prevents Internet Explorer from running the corresponding ActiveX control even if the control is installed on the system. It is not uncommon to proactively set kill bits for known malicious ActiveX controls as part of a spyware-prevention effort. For example, the SpywareGuide website provides a freely downloadable .REG file for setting kill bits of many "dubious" ActiveX controls.
The VU#998297 vulnerability demonstrates the limitation of relying on kill bits as the sole mechanism for protection against malicious ActiveX controls.
The US-CERT article implies that this vulnerability was fixed by the MS05-054 patch, which was released in December 2005. Strangely, Microsoft's MS05-054 advisory did not mention any bugs related to kill bits. Perhaps the kill bit flaw is a specific problem related to the COM Object Instantiation Memory Corruption Vulnerability (CAN-2005-2831), which was covered in MS05-054. Strangely, US-CERT lists a different CVE number (CVE-2006-0057) when discussing the kill bit problem.
So, as far as I can tell, you can address the kill bit vulnerability by installing Microsoft's MS05-054 patch, though I am not quite sure of that.
Update: The MS05-054 bulletin contains the following phrase, which reinforces the theory that this patch addresses the kill bit vulnerability: "This cumulative security update also includes the checks that were introduced in Microsoft Security Bulletin MS05-052 before a COM object is allowed to run in Internet Explorer. The intent of this change is to prevent COM objects that were not designed to be instantiated in Internet Explorer from being instantiated in Internet Explorer."
Lenny Zeltser
ISC Handler on Duty
www.zeltser.com
A kill bit is a registry setting that prevents Internet Explorer from running the corresponding ActiveX control even if the control is installed on the system. It is not uncommon to proactively set kill bits for known malicious ActiveX controls as part of a spyware-prevention effort. For example, the SpywareGuide website provides a freely downloadable .REG file for setting kill bits of many "dubious" ActiveX controls.
The VU#998297 vulnerability demonstrates the limitation of relying on kill bits as the sole mechanism for protection against malicious ActiveX controls.
The US-CERT article implies that this vulnerability was fixed by the MS05-054 patch, which was released in December 2005. Strangely, Microsoft's MS05-054 advisory did not mention any bugs related to kill bits. Perhaps the kill bit flaw is a specific problem related to the COM Object Instantiation Memory Corruption Vulnerability (CAN-2005-2831), which was covered in MS05-054. Strangely, US-CERT lists a different CVE number (CVE-2006-0057) when discussing the kill bit problem.
So, as far as I can tell, you can address the kill bit vulnerability by installing Microsoft's MS05-054 patch, though I am not quite sure of that.
Update: The MS05-054 bulletin contains the following phrase, which reinforces the theory that this patch addresses the kill bit vulnerability: "This cumulative security update also includes the checks that were introduced in Microsoft Security Bulletin MS05-052 before a COM object is allowed to run in Internet Explorer. The intent of this change is to prevent COM objects that were not designed to be instantiated in Internet Explorer from being instantiated in Internet Explorer."
Lenny Zeltser
ISC Handler on Duty
www.zeltser.com
Keywords:
0 comment(s)
Detecting BlackWorm Without Signatures
An article in a German magazine PC-WELT describes a study of anti-virus vendors' ability to detect BlackWorm when it first hit the Net. The analysis, performed by AV-Test lab, points out that some vendors were able to detect the worm without the need for BlackWorm-specific signatures, while others needed to release new signatures.
Signature-based detection mechanisms have been essential to anti-virus products' ability to recognize malicious code. Over the past several years, anti-virus vendors have made strides in heuristic and behavioral detection algorithms, and I am glad to see that these measures in several products were effective at stopping this worm.
I'd like to extend kudos to eSafe, Fortinet, McAfee, NOD32, and Panda, whose anti-virus products, according to the AV-Test study, were able to recognize that BlackWorm was malware heuristically, without requiring a specialized signature. Also, congrats to ISS, Kaspersky, and Panda for being able to recognize it through behavioral means without a signature.
Take a look at the article for additional details. Even if you don't understand German, you may find the tables, which document the study's findings, interesting. The first table lists behavioral methods, the second heuristic ones, and the third one signature-based tools.
Lenny Zeltser
ISC Handler on Duty
www.zeltser.com
Signature-based detection mechanisms have been essential to anti-virus products' ability to recognize malicious code. Over the past several years, anti-virus vendors have made strides in heuristic and behavioral detection algorithms, and I am glad to see that these measures in several products were effective at stopping this worm.
I'd like to extend kudos to eSafe, Fortinet, McAfee, NOD32, and Panda, whose anti-virus products, according to the AV-Test study, were able to recognize that BlackWorm was malware heuristically, without requiring a specialized signature. Also, congrats to ISS, Kaspersky, and Panda for being able to recognize it through behavioral means without a signature.
Take a look at the article for additional details. Even if you don't understand German, you may find the tables, which document the study's findings, interesting. The first table lists behavioral methods, the second heuristic ones, and the third one signature-based tools.
Lenny Zeltser
ISC Handler on Duty
www.zeltser.com
Keywords:
0 comment(s)
KbHook.dll is Not Always Spyware
I am a fan of Microsoft AntiSpyware tool for several reasons:
- It's relatively easy to use
- It's feature set is very comprehensive
- It's free
Like all malware scanners that use signatures to identify malicious code, Microsoft AntiSpyware can raise false alarms. I was recently reminded of this after a scheduled scan of a Windows workstation produced the following crticical alert:
Whoa! Key loggers are a particularly nasty type of malware, because they are created to monitor and record keyboard activities. They are often designed to capture the victim's interactions with a login form of some kind, frequently targeting logon credentials for banking websites. NetSpy, identified by this spyware scan, is known to be able to log the victim's key strokes, take screen shots, and transmit captured data to the attacker. No wonder a spyware scanner typically categorizes it as a severe threat.
Although many malware-scanning tools identify the kbhook.dll file itself as spyware, its presence alone is not sufficient. The infected system also needs to have additional software components that make use of the DLL's key stroke-monitoring features. In case of the workstation that I was analyzing, I could not find any additional suspicious components. Although that, alone, would not be sufficient to calm me, additional evidence reinforced the theory that I was dealing with a false positive.
The creation date of the offending file c:\windows\system32\kbhook.dll matched the day when the workstation's user happened to install drivers for his BenQ keyboard. Repeating the driver installation process confirmed that the kbhook.dll file is supplied by the keyboard vendor, presumably to enable non-standard keyboard features such as hot keys.
A web search revealed several discussions of false positives associated with files named kbhook.dll. One such discussion stated that Genius Wireless Keyboard drivers used this file without malicious intent. Another discussion of an unknown-to-me keyboard reached a similar conclusion.
The kbhook.dll file on the workstation I examined was a Microsoft Visual C++ 6.0 DLL, with MD5 hash 68ef310fdb7788a8ea8841c8fe80e66e. It exported two functions: EnableHook() and DisableHook(); this is how an external program can make use of the DLL's keyboard-controlling functionality.
Personally, I am not crazy about having a DLL with this functionality installed on a system, because one never knows which program will attempt to take advantage of its EnableHook() and DisableHook() functions. I was able to delete the file from the workstation, because the user did not make use of the BenQ hot keys that the driver was meant to enable. Other reports on web forums suggest that removing the file for certain keyboards may prevent the device from working properly.
If you encounter a kbhook.dll file on your system, please remain vigilant. This file is often associated with dangerous key loggers, presence of which may require a full system reinstall. However, keep in mind that malware scanning tools sometimes mis-identify this file. Specifically, the file named kbhook.dll is sometimes used by keyboard driver authors without malicious intent.
Lenny Zeltser
ISC Handler on Duty
www.zeltser.com
Keywords:
0 comment(s)
×
Diary Archives
Comments