March 25, 2009
In This Issue
Tech Talk
News & Articles- The Best Business Networking Products
- BlackBerry Web loader has serious ActiveX flaw
- 10 tips to protect your company in a down economy
- View All Media Coverage
Reader Q&A
Announcements- eEye Digital Security Offers Unique “Any Means Possible” Penetration Testing Services
- eEye’s Web Server Protection Voted WindowsSecurity.com Reader’s Choice Award Winner – Second Runner-Up
- eEye Announces Industry First Appliance to Manage 200 Blink Security Agents
- View All Announcements
EtceteraActiveX: Understanding the Threat Spectrum
What is ActiveX?
ActiveX is a Microsoft technology based on COM (Component Object Model) that allows developers to create distributed applications. The encapsulated functionality allows container applications such as Internet Explorer to re-use and link ActiveX files (much like Java Applets) but are limited in that the control is only compatible with Microsoft Windows environments. To use an ActiveX, the control needs to be programmatically instantiated with a language such as JavaScript or VBScript.
ActiveX Threats
ActiveX controls are susceptible to the same type of vulnerabilities as any other type of application (e.g. buffer overflows, memory corruption, insecure methods, etc.). The problem is that any website (unless the ActiveX control uses the rarely used SiteLock) can attempt to instantiate the control with a common scripting language. If a vulnerable ActiveX control is not installed on the system then it cannot be instantiated, however there is no limit on how many controls can be instantiated—more specifically—an attacker can attempt to load a list of vulnerable controls until one is found.
In a previous VERSA article, we detailed the threat of browser add-ons and plug-ins. eEye's ongoing focus has been to keep pace with the quickly moving threat trends and in doing so we've noticed a spectrum of vulnerabilities and issues with ActiveX controls that users should be aware of.
Non-Memory-Based Vulnerabilities
Not all applications are exploited via traditional memory based vulnerabilities, but are exploited through inherently insecure design flaws. These flaws are often seen in controls that access local or remote resources, such as an ActiveX control used for database maintenance (e.g. Microsoft Snapshot Viewer), an ActiveX control that benchmarks your system (e.g. Husdawg), or an ActiveX control that is preinstalled by a device manufacturer (e.g. Gateway WebLaunch).
Impacts of common insecure methods may include:
Disclosure of File System Information (filenames, folder names, and file paths)
File Access (read, write, delete, execute)
Registry Access (read, write, delete)
Remote Downloads and/or Uploads (via URL)
Remote File Execution
Disclosure of Installed Applications
Many, if not all, of these non-memory based vulnerabilities could be leveraged to bypass traditional security protection and compromise a system directly, or perform reconnaissance for future attacks. For example, if an ActiveX control contains a vulnerability that allows arbitrary file downloads to arbitrary locations, then an attacker can use it to overwrite a system file or download a Trojan from another website into the Windows Startup folder.
Without due diligence, it is easy to overlook the obvious threats that can lay your system and network defenses to waste. Administrators however, have a variety of mechanisms at their disposal to restrict the use and behavior of ActiveX controls—the most common security mechanisms in Internet Explorer being:
“Gold Notification Bar” – Notification of when a site attempts to run scripting or ActiveX code. This notification asks for the user’s approval before running any code.
“Safe for Scripting” – A control is marked as safe for scripting if it is verifiably unable to take any harmful action on the user's computer. The control can also be executed without user approval.
“Signed Controls” – Code signing can guarantee that an ActiveX is from a trusted source.
Combined, each of the above settings are effective in protecting a user from malicious and untrusted code, but without proper configuration (e.g. allowing execution of controls marked safe for scripting without notification) could in fact make it easier for an attacker to exploit a vulnerability.
A more restrictive approach is to implement the policy based “Administrator Approved” setting which limits the execution of ActiveX controls to a particular Internet Explorer zone; thereby decreasing the likelihood of an ActiveX control being mistakenly executed by a user. An administrator approved list can be useful in restricting common attack vectors, but may be defeated if an attacker is able to access a different zone through browser vulnerabilities or if a user is coaxed into executing the content in a non-restricted zone (e.g. using an HTML file in an e-mail attachment).
Note to Reader: There may be instances where restricting a control is not feasible for the environment or the control is deemed a critical security risk (e.g. zero-day vulnerability). For such cases ActiveX controls can be completely disabled by “killing” the affected control through use of the kill bit.
Evading Protection
ActiveX vulnerabilities are an easy target for attackers and can be difficult to protect against. Generic protection is easily evaded by using encrypted channels or by obfuscating instantiation code. By using such evasion techniques, attackers can completely bypass generic and signature based protection.
Simple HTTPS can evade network based intrusion detection systems and is often permitted to pass through perimeter defenses and firewalls. If a vulnerable control exists that allows arbitrary downloads, an attacker can leverage a legitimate HTTPS connection to elude NIDS signatures.
Script obfuscation is another well-known avenue for hiding malicious code. Aside from encrypting a network channel, attackers will often obfuscate an ActiveX’s instantiation code (typically using JavaScript or VBScript) or the entire contents of a website. Obfuscation can be as simple as using a handful of preset keys to encode and decode the website upon being loaded. If the keys are easily found in the surrounding decryption code (i.e. keys under the doormat) then it isn’t difficult for one to figure out what is hidden.
To make it more difficult for analyzers to decode, attackers have started using randomly generated initialization vectors to obfuscate their payload. Browser Referrers, Cookies, Server-Variables, and other Session-based server-generated data are some of the vectors witnessed at eEye Research that would be nearly impossible to decrypt using generic HIPS or NIPS signatures.
Simply put, it’s impossible to analyze what you cannot programmatically decrypt.
eEye’s ActiveX Patent
VERSA is a vendor-agnostic newsletter, however eEye has recently filed for a patent (More Info) in a highly innovative technology designed to specifically combat ActiveX vulnerabilities.
Generic buffer overflow protection can prevent standard memory-based ActiveX vulnerabilities. Non-memory based ActiveX vulnerabilities on the other hand create issues since the vulnerability can be exploitable by abusing insecure features of the application. For instance, eEye Research discovered a vulnerability in the Husdawg ActiveX control that allowed file retrieval via HTTP, HTTPS, or FTP with immediate code execution upon download completion. This means that generic memory-based protection technologies will be useless in protecting these types of exploits and that signature-based detection will need to be enforced in order to identify threats. Unfortunately, as was previously mentioned, the use of encryption and/or obfuscation techniques are being employed to evade such detection and is advancing at a rate much faster than security software vendors are able to keep up.
eEye’s patent avoids the proverbial cat and mouse game of keeping pace with nimble malware and exploit writers. Rather than detecting threats at the network-level and developing complex signatures to counter evasion techniques, the ActiveX protection technology allows code to be processed by Internet Explorer until a call is made to call an ActiveX control. The protection mechanism hooks the ActiveX subsystem thus allowing calls to be identified prior to processing or execution in Internet Explorer. Any attempts to obfuscate data are impossible at this point since the control cannot be called without first using the subsystem defined by ActiveX standards.
By inserting our signature engine at this location, it eliminates the need to decode any obfuscation since the potentially-malicious data is in its native-decoded form; thus allowing for the accurate detection of vulnerabilities through use of signatures and heuristics. If the function call to the control is malicious in manner, then the vulnerable call is terminated. This means that any attempts to use an insecure method will be immediately blocked (e.g. methods to download malware via an encrypted channel, methods to download from an untrusted site, or even methods to write data to the file system or registry); case in point, the Husdawg ActiveX vulnerability.
An attacker could attempt to instantiate the vulnerable Husdawg ActiveX control with a legitimate-looking website. Upon visiting the website, the browser notifies the user with the “Gold Bar” and the user chooses to allow the blocked content. On a standard system (if the control was not kill bitted), the control would appear to behave normally—collecting system information then downloading an update—but unbeknownst to the user, the attacker is exploiting the control’s insecure method to download and install malware from a malicious site. On a system using our ActiveX protection, Internet Explorer would behave the same as it would on a standard system except that the ActiveX protection would engage as soon as Internet Explorer uses the instantiation code from the website to access the ActiveX subsystem. The protection engine, using the ActiveX signatures for the Husdawg vulnerability, would terminate the website’s call to use the insecure method.
During eEye Research testing, this technology was able to fight 100% of the known non-memory based ActiveX attacks revealed and witnessed in 2008. This functionality also enhances our existing generic memory-based protection by identifying attacks prior to execution—which translates into another layer of defense for one of the most commonly used attack vectors.
Click HERE for Article References
ActiveX is a Microsoft technology based on COM (Component Object Model) that allows developers to create distributed applications. The encapsulated functionality allows container applications such as Internet Explorer to re-use and link ActiveX files (much like Java Applets) but are limited in that the control is only compatible with Microsoft Windows environments. To use an ActiveX, the control needs to be programmatically instantiated with a language such as JavaScript or VBScript.
ActiveX Threats
ActiveX controls are susceptible to the same type of vulnerabilities as any other type of application (e.g. buffer overflows, memory corruption, insecure methods, etc.). The problem is that any website (unless the ActiveX control uses the rarely used SiteLock) can attempt to instantiate the control with a common scripting language. If a vulnerable ActiveX control is not installed on the system then it cannot be instantiated, however there is no limit on how many controls can be instantiated—more specifically—an attacker can attempt to load a list of vulnerable controls until one is found.
In a previous VERSA article, we detailed the threat of browser add-ons and plug-ins. eEye's ongoing focus has been to keep pace with the quickly moving threat trends and in doing so we've noticed a spectrum of vulnerabilities and issues with ActiveX controls that users should be aware of.
Non-Memory-Based Vulnerabilities
Not all applications are exploited via traditional memory based vulnerabilities, but are exploited through inherently insecure design flaws. These flaws are often seen in controls that access local or remote resources, such as an ActiveX control used for database maintenance (e.g. Microsoft Snapshot Viewer), an ActiveX control that benchmarks your system (e.g. Husdawg), or an ActiveX control that is preinstalled by a device manufacturer (e.g. Gateway WebLaunch).
Impacts of common insecure methods may include:
Many, if not all, of these non-memory based vulnerabilities could be leveraged to bypass traditional security protection and compromise a system directly, or perform reconnaissance for future attacks. For example, if an ActiveX control contains a vulnerability that allows arbitrary file downloads to arbitrary locations, then an attacker can use it to overwrite a system file or download a Trojan from another website into the Windows Startup folder.
Without due diligence, it is easy to overlook the obvious threats that can lay your system and network defenses to waste. Administrators however, have a variety of mechanisms at their disposal to restrict the use and behavior of ActiveX controls—the most common security mechanisms in Internet Explorer being:
Combined, each of the above settings are effective in protecting a user from malicious and untrusted code, but without proper configuration (e.g. allowing execution of controls marked safe for scripting without notification) could in fact make it easier for an attacker to exploit a vulnerability.
A more restrictive approach is to implement the policy based “Administrator Approved” setting which limits the execution of ActiveX controls to a particular Internet Explorer zone; thereby decreasing the likelihood of an ActiveX control being mistakenly executed by a user. An administrator approved list can be useful in restricting common attack vectors, but may be defeated if an attacker is able to access a different zone through browser vulnerabilities or if a user is coaxed into executing the content in a non-restricted zone (e.g. using an HTML file in an e-mail attachment).
Note to Reader: There may be instances where restricting a control is not feasible for the environment or the control is deemed a critical security risk (e.g. zero-day vulnerability). For such cases ActiveX controls can be completely disabled by “killing” the affected control through use of the kill bit.
Evading Protection
ActiveX vulnerabilities are an easy target for attackers and can be difficult to protect against. Generic protection is easily evaded by using encrypted channels or by obfuscating instantiation code. By using such evasion techniques, attackers can completely bypass generic and signature based protection.
Simple HTTPS can evade network based intrusion detection systems and is often permitted to pass through perimeter defenses and firewalls. If a vulnerable control exists that allows arbitrary downloads, an attacker can leverage a legitimate HTTPS connection to elude NIDS signatures.
Script obfuscation is another well-known avenue for hiding malicious code. Aside from encrypting a network channel, attackers will often obfuscate an ActiveX’s instantiation code (typically using JavaScript or VBScript) or the entire contents of a website. Obfuscation can be as simple as using a handful of preset keys to encode and decode the website upon being loaded. If the keys are easily found in the surrounding decryption code (i.e. keys under the doormat) then it isn’t difficult for one to figure out what is hidden.
To make it more difficult for analyzers to decode, attackers have started using randomly generated initialization vectors to obfuscate their payload. Browser Referrers, Cookies, Server-Variables, and other Session-based server-generated data are some of the vectors witnessed at eEye Research that would be nearly impossible to decrypt using generic HIPS or NIPS signatures.
Simply put, it’s impossible to analyze what you cannot programmatically decrypt.
eEye’s ActiveX Patent
VERSA is a vendor-agnostic newsletter, however eEye has recently filed for a patent (More Info) in a highly innovative technology designed to specifically combat ActiveX vulnerabilities.
Generic buffer overflow protection can prevent standard memory-based ActiveX vulnerabilities. Non-memory based ActiveX vulnerabilities on the other hand create issues since the vulnerability can be exploitable by abusing insecure features of the application. For instance, eEye Research discovered a vulnerability in the Husdawg ActiveX control that allowed file retrieval via HTTP, HTTPS, or FTP with immediate code execution upon download completion. This means that generic memory-based protection technologies will be useless in protecting these types of exploits and that signature-based detection will need to be enforced in order to identify threats. Unfortunately, as was previously mentioned, the use of encryption and/or obfuscation techniques are being employed to evade such detection and is advancing at a rate much faster than security software vendors are able to keep up.
eEye’s patent avoids the proverbial cat and mouse game of keeping pace with nimble malware and exploit writers. Rather than detecting threats at the network-level and developing complex signatures to counter evasion techniques, the ActiveX protection technology allows code to be processed by Internet Explorer until a call is made to call an ActiveX control. The protection mechanism hooks the ActiveX subsystem thus allowing calls to be identified prior to processing or execution in Internet Explorer. Any attempts to obfuscate data are impossible at this point since the control cannot be called without first using the subsystem defined by ActiveX standards.
By inserting our signature engine at this location, it eliminates the need to decode any obfuscation since the potentially-malicious data is in its native-decoded form; thus allowing for the accurate detection of vulnerabilities through use of signatures and heuristics. If the function call to the control is malicious in manner, then the vulnerable call is terminated. This means that any attempts to use an insecure method will be immediately blocked (e.g. methods to download malware via an encrypted channel, methods to download from an untrusted site, or even methods to write data to the file system or registry); case in point, the Husdawg ActiveX vulnerability.
An attacker could attempt to instantiate the vulnerable Husdawg ActiveX control with a legitimate-looking website. Upon visiting the website, the browser notifies the user with the “Gold Bar” and the user chooses to allow the blocked content. On a standard system (if the control was not kill bitted), the control would appear to behave normally—collecting system information then downloading an update—but unbeknownst to the user, the attacker is exploiting the control’s insecure method to download and install malware from a malicious site. On a system using our ActiveX protection, Internet Explorer would behave the same as it would on a standard system except that the ActiveX protection would engage as soon as Internet Explorer uses the instantiation code from the website to access the ActiveX subsystem. The protection engine, using the ActiveX signatures for the Husdawg vulnerability, would terminate the website’s call to use the insecure method.
During eEye Research testing, this technology was able to fight 100% of the known non-memory based ActiveX attacks revealed and witnessed in 2008. This functionality also enhances our existing generic memory-based protection by identifying attacks prior to execution—which translates into another layer of defense for one of the most commonly used attack vectors.
Click HERE for Article References
Source: Casey Rosini, Software Engineer
The following articles represent the opinions of their respective authors. They do not necessarily represent the opinions of eEye Digital Security.
These eight offerings including the eEye REM Security Management Appliance 1505 can boost your business by making your network more secure
Full Article
BlackBerry flaw discovered by researchers at eEye Digital Security can be exploited remotely
Full Article
Tighten your security and tighten your belt at the same time. Quick-payoff strategies can help you stay on top of evolving security threats without neglecting your network infrastructure
Full Article
eEye and its security solutions have been covered by numerous press and media associations
Full Article
Q: An application is crashing, how do I know if this is a vulnerability?
A: This is a common question, and typically our answer is that "it takes a lot of practice". Identifying a vulnerability will require at least novice disassemble and debugging skills with today's vulnerabilities (EIP=0x41414141 is not incredibly common these days).
However, there is one recent tool that is worth checking out from Microsoft that might be able to help: MSEC Debugger Extensions (http://msecdbg.codeplex.com/). Using WinDbg (free - http://www.microsoft.com/whdc/devtools/debugging/default.mspx), for a novice user, this tool will allow you to easily identify the basic crash information, and will likely give you some information regarding the "exploitability" of the issue.
We suggest you give it a spin. Of course, if this tool says something is NOT exploitable, that is not the final word - prove it for yourself.
A: This is a common question, and typically our answer is that "it takes a lot of practice". Identifying a vulnerability will require at least novice disassemble and debugging skills with today's vulnerabilities (EIP=0x41414141 is not incredibly common these days).
However, there is one recent tool that is worth checking out from Microsoft that might be able to help: MSEC Debugger Extensions (http://msecdbg.codeplex.com/). Using WinDbg (free - http://www.microsoft.com/whdc/devtools/debugging/default.mspx), for a novice user, this tool will allow you to easily identify the basic crash information, and will likely give you some information regarding the "exploitability" of the issue.
We suggest you give it a spin. Of course, if this tool says something is NOT exploitable, that is not the final word - prove it for yourself.
Have a question you would like answered? Send it to versa@eEye.com, and win an eEye t-shirt if we select your question for an upcoming newsletter.
eEye extends Research services to include elite penetration testing service that will be available for 25 percent off through April 30, 2009
Full Article
SecureIIS Web Server Protection was selected second runner-up in the Web Application Security category of the WindowSecurity.com Readers’ Choice Awards
Full Article
New product makes integrated security and threat management simple to help maximize organizations limited resources
Full Article
eEye and its security solutions have been covered by numerous press and media associations
Full Article
eEye Research has seen staggering results from the recent influx of Blink Personal/Neighborhood Watch users. These results in turn offer eEye Research distinct insight into host-based vulnerability and attack trends, and further enhance Blink's host-based intrusion prevention system. Keep a watchful eye on the eEye Research Portal http://research.eeye.com/ for future projects that have arisen because of the mass use of Blink Personal including Neighborhood Watch reports and attack trends.
More
The monthly Vulnerability Expert Forum focuses on recently announced critical vulnerabilities - from Microsoft and other software vendors. eEye's Internet security experts will describe the actions necessary to protect your systems from the threats that target these vulnerabilities.
More