How Browser Add-On Vulnerabilities Are Becoming an Attackers Best Friend
Browser add-ons are typically deployed by a software vendor in order to enhance the user experience of web-based applications. In the world of emerging web technologies, browser add-ons are being used more and more by developers to deliver enhanced content over web-sites that would normally not be possible via simple HTML and JavaScript. Unfortunately, these add-ons are binaries that are downloaded and run on a user’s machine, allowing attackers to leverage potential vulnerabilities within the add-ons to potentially compromise a workstation, similar to any other application running on a user’s system. Exploits for browser add-ons have increased quickly over recent years, and that trend is expected to continue for some time. Furthermore, for a variety of reasons, browser add-ons have become one of the main tools for attackers to exploit remote systems.
Background
When discussing browsers that support add-ins, two main technologies come to mind: Microsoft’s Internet Explorer and Mozilla’s Firefox. The battle has raged on for quite some time now over which browser is safer than the other, but that is not the point of this article. The point here is that both browsers do support some sort of mechanism for downloading and installing add-ons, and then allowing those add-ons to be interacted within a remote nature, such as HTML over HTTP.
Internet Explorer ActiveX Controls:
Internet Explorer is considered the most potent threat when it comes to browser add-ons in the form of ActiveX controls. ActiveX controls are binary files that are downloaded from a remote site (hopefully legitimate) and then installed within Windows. These binaries are later instantiated typically via some sort of scripting language (commonly JavaScript within HTML) and passed parameters or values to offer some sort of end-user-tailored experience. Unfortunately, many of those parameters allow an attacker to reach exploitable conditions such as buffer overflows or command execution vulnerabilities, therefore allowing an attacker to execute code on a remote system under the context of the logged in user.
Mozilla Firefox Browser Plugins:
Firefox has a similar framework as ActiveX (COM) within Internet Explorer in the form of Firefox plugins. These plugins can be used to fulfill many different types of end-user requirements ranging from video viewing to anonymity plugins. Unfortunately, some vulnerabilities can exist within these plugins which could be exploited in a manner similar to ActiveX controls.
Complications for IT Security Teams
Easy To Install:
Browser add-ons are typically exceptionally easy for a user to install without ever realizing the consequences for introducing new code on their system. Most of the time a user encounters an add-on by viewing a random website with some enhanced content that requires an ActiveX or plugin in order to be seen on the client. The user, of course wanting to see what the content is meant to show them, will install the binary on the system in order to get the content as quickly as possible. It’s a standard scenario of users automatically “clicking-through” security warnings in order to get the content they want, without even a thought of the security implications of doing so. However, from the network view, potentially vulnerable code is easily introduced in the network. Furthermore, many applications will install ActiveX controls without the user even knowing that this functionality exists within their browser. For instance, the three referenced vulnerabilities at the end of this article were all browser add-on vulnerabilities included with other software. Most users would never have known that the applications had code accessible via the web browser, but attackers sure did, and were able to leverage this vulnerability for in-the-wild attacks.
Hard To Identify/Patch:
Browser add-ons tend to be very difficult to identify via the entire enterprise network; no listening ports are opened up, the binary will only be loaded in memory whenever it’s being used, auditing of systems for add-ons will always require credentials, as well as many other challenges faced by IT security teams. Furthermore, add-ons tend to not identify themselves in most of the ways that larger applications do by being listed within the “Start” menu or within “Add or Remote Programs”. Therefore, if a normal Tier 1 administrator were to log into a workstation to verify that non-compliant software was not installed on the system, he or she would most likely never notice the many browser add-ons that could be installed on the system. Furthermore, this lack of identification makes developing a patch process nearly impossible for an IT team since they are usually in the dark as to what add-ons are even installed within their network beyond what comes with the standard Windows and Office applications.
Attacks Are Difficult To Catch At A Network Layer:
At a network layer, ActiveX control exploitation attempts can be difficult to identify. JavaScript is used as the primary attack mechanism since it supports many programming features that attackers need to leverage in order to execute code within an exploit. Because of this, JavaScript also has many of the programming features that attackers can utilize to hide their attacks. JavaScript obfuscation makes processing ActiveX or plugin exploits at the network layer impossible because of the latency implemented by having to decompile the JavaScript. Therefore, it is incredibly difficult for gateways of a network to be used in any fashion for stopping these types of attacks.
Advantages for an Attacker
Exploitation Anonymity:
Attackers are able to leverage browser add-in vulnerabilities for a very anonymous exploitation technique, commonly referred to as “drive-by” exploitation. This technique methodology is simple: an attacker uploads a malicious HTML page and a malicious binary to a remote server. This server could be owned by them, owned by another party that allows web page hosting, or maybe even owned by a 3rd party that has been compromised by the attacker. Once the exploit is uploaded to that site, all the attacker has to do is direct the victim to view that page. Typically this is done by posting links to the malicious URL in forums, but a sophisticated attacker can leverage iFrames to embed the malicious HTML within a seemingly benign website if he or she somehow has access to the HTML code. All the while, the web server is the one launching the attacks against the victim, not the attacker themselves; this is quite a bit different than the classic network-based exploits and proves very difficult when tracking down the actual attacker.
Widespread Installation Base:
In modern times on the Internet, it is all about quantity and not quality. The attacker wants as much widespread infection as possible, most likely somehow related to botnet control. Attackers are seldom using these types of attacks for surgical exploitation, but more of a “spray and pray” methodology where their goal is to gain and add as many zombie computers to their botnet as possible, to be used for some other type of exploitation or money-making opportunity. Since these browser add-ins are going to be found on a large percentage of workstations both at home and within corporate networks, this is a great attack vector for malicious attackers looking to increase the size of their botnets.
Reliable Exploitation:
Exploitation is quite simple for add-on vulnerabilities since they are so rarely updated. It’s quite different than when trying to exploit a Windows-based vulnerabilities where there are many different operating systems, service packs, and patch levels; add-ons will commonly remain the same version regardless of the operating system their installed upon. Therefore, the attacker can generate one exploit, and that exploit can be utilized to infect a Windows 2000, Windows XP, Windows 2003, and Windows Vista workstation as long as the same add-on is installed across all platforms. Furthermore, exploitation is simpler since there is minimal network-based protection. Rather than network-based exploits where an attacker must verify that certain ports are accessible from beyond the firewall, outbound TCP/80 connections will nearly never be filtered, and the attacker will nearly always be able to leverage this type of exploit.
“Easy” To Discover:
Perhaps the biggest advantage for attackers to leverage add-on vulnerabilities is how easily they can be discovered. Numerous discovery tools have been released publicly, and there is ample documentation on how add-on exploitation works available from many sources. If an attacker is looking to infect a large quantity of victims with an exploit that will go undetected for at least a short amount of time, there are plenty of tools available for that attacker to identify a zero-day vulnerability and develop an exploit for it.
How Networks Can Be Protected
Add-on vulnerabilities are a great example of how the attackers focus has shifted from network-based to client-side attacks. Resistance is not futile however; technologies and processes do exist to help networks secure themselves from these vulnerabilities.
Vulnerability Assessment:
Perhaps the most important part of combating add-on vulnerabilities is the need to be able to identify which add-ons are installed within the network. Since this cannot be done at the network layer without credentials, the best location for this is to utilize a host-based vulnerability assessment tool. By correlating this data for the entire network, IT security teams will have a good understanding of their posture against browser add-on attacks.
Generic Host-Based Protection:
Protection against vulnerabilities is critical to the security posture of a network. Unfortunately, there is only one layer to offer comprehensive protection of add-on vulnerabilities and that exists on the host itself. Network IDS systems are simply unable to perform the processing necessary to de-obfuscate in-the-wild exploits and still deliver the traffic quickly in the case that it is non-malicious. Therefore, the only truly effective protection comes from a non-signature host-based IPS system with an integrated anti-virus system to effectively stop the downloaded malware as well.
Drastic Measure - Disable Add-Ons:
Browser add-ons can potentially be disabled from a network-wide level for all affected platforms. This is definitely a drastic security step and would raise a lot of usability and experience issues for users, but is something that should at least be considered when developing corporate IT security policies. This conversation can be easily boosted with stats from the vulnerability assessment reports described above.
Some Recent Browser Add-On Vulnerabilities:
RealPlayer: http://research.eeye.com/html/alerts/zeroday/20071019.html
Yahoo!: http://research.eeye.com/html/alerts/zeroday/20070606.html
QuickTime: http://research.eeye.com/html/alerts/zeroday/20060920.html
Source: Andre Derek Protas, Director of Research and Preview Services |
Q: What programming languages do eEye Researchers normally use in everyday research?
A: eEye Research has a wide-variety of skill sets within our Researchers, and this is greatly reflected with our programming. It is not uncommon for some of our internal tools to be written in one language, and then translated multiple times so other Researchers can modify them for their own use. However, there is usually one paradigm that most Researchers standby: know one scripting language and one compiled language really well.
Scripting languages (primarily Python and Ruby) are very useful for doing quick tool development or doing some quick-and-dirty vulnerability testing. However, for tools that will have a longer shelf-life than the current project they’re being used for, eEye Research will tend to use a more robust compiled language (typically C/C++/C#).
Of course, the rule-of-thumb is to stick with what you’re good at. If you’re an absolutely stupendous Lisp or Cobol programmer, stick to it. That’s not the destiny most people would choose on their own, but if you can perform every task related to research that you’d come across, god speed.
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. |
News & Articles
Announcements
Tech Talk
Reader Q&A
Etcetera