A Mix of Active Technologies

Active content is a broad term and definition and can easily cause confusion as to what exactly fits the profile of this type of technology. In this section we will take a high level overview of the technologies included in the pantheon of active technologies and explore each one later in the chapter. In the following sections we will highlight the technologies considered as “active content” and then expand on each technology in more depth as we progress through the chapter and the book.

Microsoft Silverlight

Microsoft’s latest web development technology known as Silverlight is a web application tool that allows for the integration of multimedia, computer graphics, animation and interactivity into the web environment. The plug-in was first released as a video streaming plug-in with subsequent versions adding interactivity features and support. As of this writing the current version is 5. By most standards Silverlight is roughly equal to Adobe Flash in features and capabilities (not to mention security issues).

Silverlight is a free plug-in, powered by the .NET framework and compatible with multiple browsers, devices and operating systems. Silverlight is available for most browsers on the market, however it is limited to specific versions of the Windows Operations system like Windows Vista, 7 and 2008. It also relies on the .NET Framework. The .NET Framework is a software package developed by Microsoft that helps to supply much of the underlying technology needed to operate Silverlight such as the ability to do application development against it. It provides the class library used for Silverlight functionality.

Microsoft launched its Silverlight technology approximately three years ago as a platform for delivering rich media applications to web clients. This technology shares a lot in common with its competing technology Adobe Flash as it is designed to provide a means for presenting content and creating online applications. However, Silverlight should not be thought of as a mere clone of Adobe Flash, rather it does have enough differences to make it unique in some ways.

Microsoft has positioned Silverlight as part of a push of all its online services, but as a developer level service. The intention is to provide technologies that will allow developers to create dynamic applications and content, but like any tool the potential for abuse exists.

Silverlight based applications work by delivering a special text-based markup language to the client’s browser known as XAML. XAML, known as Extensible Application Markup Language, is used to describe the content and graphical elements that the user will interact with and present content. In other words, XAML is what makes the content possible, but it is not something that user themselves actually see or even are concerned about. The use of XAML makes Silverlight different than its competing technology Adobe Flash. Whereas Flash applications are an amalgam of code and markup compiled into a single unit Silverlight presents plain text in the code of a web page that can be crawled and indexed by web pages.

The following is a sample of Silverlight XAML code:

Silverlight is still fairly new in the marketplace so it is difficult to pin down any specific security problems, but it is reasonable to expect that the security problems on the client side will be similar to what is in Flash.

You can also install and use the Silverlight Toolkit as seen in Figure 5.2. With this toolkit, the Software Development Kit (SDK) and other Silverlight tools and examples, you can delve into the inner workings of Silverlight to see how flexible the technology is. It will also show you how attackers can easily use this technology against you.

As we have just covered, there are many types of technologies available to produce active content. There are also many others; however these are the ones that seem to be used most commonly. Others such as VBScript, Flash and Actionscript will be covered in more detail throughout this book.

All these active content types were never intended to be a security risk or be harmful to clients in any way, but each in some way has become a weapon in the hand of an attacker. While each browser on the market offers some capabilities that will block the use of such content most users are not willing to lose the functionality in favor of increased security. In light of the fact that users and companies are unlikely to shut off the use of such content it is up to us as security professionals to consider the risks of each technology accordingly, we will start with this process by taking a closer look at each of the technologies in turn. It should also be noted that in order to use specific sites and their added functionality, at times the end user may be required (or forced) to download and use specific technologies ultimately removing “choice” from the equation. It should also be noted that active content also exploits mobile devices just as easily as servers and desktop.

ActiveX

ActiveX controls are a technology that Microsoft introduced in the mid-1990’s as a new web development mechanism. However even though the technology was first introduced in the mid-1990s it has a long and storied history that we will briefly cover here in an effort to give some background to how the technology works.

The ActiveX story begins with a technology known as OLE or Object Linking and Embedding. OLE was and is a technology that is designed to facilitate the creation of what is known as compound or hybrid document or content types. In layman’s terms this means that one could take an Excel spreadsheet and place it within a Word document allowing for the display of one piece of content with another. The advantage here is that new complex types of content can be made from different sources as well as allowing one to double-click on the content type to edit it in the original application that created it. While this was a beneficial feature, this foundation was built upon for what was known later as OLE2. OLE2 was introduced by Microsoft as a way to introduce a feature known as Component Object Model (COM). COM, in layman’s terms, is a technology designed to facilitate communication between applications and allow them to share data and services more effectively. COM, as a technology or process, was later used to much greater effect and degree in process and software that had nothing to do with compound documents such as ActiveX. In fact, ActiveX controls may even be viewed as the third version of OLE controls. Distributed Component Object Model (DCOM) was then created due to the distributed nature of applications to facilitate a better way to provide “middleware” between applications such as N-Tier designs where a front-end web server communicated with middleware installed via DCOM on application servers interacting with data on backend SQL database servers.

Implementation wise ActiveX is a technology that works by automatically downloading and executing on the client side (specifically in the web browser in most cases). Developers using their programming language of choice such as C, C++, Visual Basic or Java can develop their own controls to perform whatever task they see necessary. This also shows us something important about ActiveX, it is not a programming language itself, but rather a somewhat clearly defined set of rules that spell out how a control can be developed. This flexibility means that a developer is free to choose the language that they can author the control in, but also allows for a wide range of possibilities for both friend and foe alike. Figure 5.3 shows what an ActiveX Control is used for and the forcing of an installation for software that may or may not be malicious.

ActiveX has numerous potential security problems, some of which we will examine here to gain a better understanding of how a malicious party can exploit weaknesses in the technology.

ActiveX primarily relies on digital signatures to improve security from a trusted third party which usually is an entity such as Verisign. The goal of this signature is to give the client a clear idea of who created the control as well as assert that the control is trustworthy to a degree. Signatures are placed upon the control when it is created and stay with the control during its lifetime or until it expires.

Enhancing the security of ActiveX even further is something known as Authenticode which is built into Internet Explorer itself. This technology is designed to more thoroughly check a digital certificate and verify that it has not been altered prior to download. Authenticode, in the default configuration of Windows, will not even allow a control that is unsigned to be downloaded much less installed on a system. Of course users can make themselves victims of malicious controls if they choose to override the defaults and allow unsigned controls to be installed without prompting them about the danger as seen in Figure 5.4.

Microsoft has made many recommendations over the years telling users not to download controls that are not signed, but this has not stemmed the tide any and users still download questionable controls at their peril. You can see what ActiveX controls have been download and installed as well as delete them within your Internet Options within Internet Explorer as seen in Figure 5.5.

Probably the biggest security risk with ActiveX controls is the simple fact that they have almost unlimited access to the client system. Any Windows system that is running an ActiveX control is particularly vulnerable as this configuration gives full access to the operating system meaning that the risk is much higher. In fact due to the unique nature of ActiveX controls and the unlimited access they have to the host operating system the risk of running them is much higher than compared to any of the other technologies discussed here in this chapter. To help mitigate this risk and reduce the exposure to the client Microsoft did develop the system of registration designed to authenticate a control prior to download, but this is not total security for the client. You should also be aware that ActiveX technology now comes integrated into many other software packages such as Flash.

As briefly discussed earlier, a potential risk in Internet Explorer due to ActiveX is something known as the drive-by download. In this technique and attacker preys upon the fact that users do not typically read the license agreement or have reconfigured their browser to not display warnings. By using this technique with the user’s lack of interest in security or protecting the browser an ActiveX control can get installed quite easily taking control of a system or gathering information from the client. To prevent this from happening Microsoft introduced a feature known as ActiveX Opt-in in Internet Explorer 7. With this feature enabled the user will be prompted if they wish to install a new control or not potentially preventing controls from getting installed without the user’s knowledge. Figure 5.6 shows the ActiveX Opt-In prompt feature.

This feature simply prompts the end user that they may be installed an ActiveX control and that they now have an option to run (install) it or not to run (install) it. This then increases the security level of the end user system.

Starting with Internet Explorer 7 Microsoft introduced a new feature that provides some protection if a user installs a malicious control, this feature is known as Protected Mode. Protected Mode is only available on the Windows Vista and Windows 7 and Windows 2008. This mode is designed to limit the access malicious content may acquire within the browser and reduce security risks. When this mode is active, which it is by default, Internet Explorer is run as its own isolated process away from other applications immediately reducing the access that anything within the browser may acquire. In fact content within the browser will only be allowed to access two parts of the system a virtualized part of the registry and the Temporary Internet Files folder without further approval by the user.

As you can see ActiveX is a rich and deep technology that can enabled many types of features and abilities within a browser, but at the same time it can be a nasty security risk. We have outlined its basic functionality and how it can be secured at the basic level.

Java

Java is another popular programming language originally introduced by Sun Microsystems in 1995. Since its debut it has become a very popular choice for developing applets, applications, utilities, games, and enterprise applications. Currently Java is supported on a wide range of platforms and technologies including set top boxes, personal computers, handheld devices, and other devices.

Java works across multiple platforms by utilizing something known as a Java Virtual Machine (JVM). A Java Virtual Machine is an application or software appliance that is used to execute Java code or “applets” as provided, in this case, by websites. Java applets are installed on a system by a visitor accessing a web page and having the browser automatically downloading the applet and executing it via the Java Virtual Machine. During subsequent visits to the website the Java Applet is cached and starts running much quicker due to the lack of download time.

One of the big benefits of the Java development platform and language is the inclusion of a number of robust security features. Java was designed to include many features that make it one of the more secure development environments and much less prone to attacks that may introduce malicious code and unknown elements onto a system.

One of the biggest security benefits of the Java platform however has to be its sandboxing model. This feature in the Java environment effectively isolates applets and their code within a special software construct that limits their access to resources on the system. The main benefit here is that with unknown or risky applets a high degree of security is provided or ensured as untrusted code does not get any sensitive access where it is not advisable. In the Java environment code will continue to run in this isolated environment until it has been verified through means of a digital signature and through the user actually approving it as trusted.

Java along with ActiveX represents a large portion of the security vulnerabilities present in client-side environments and plug-ins. In fact over the last few years Java has come in second only to ActiveX in the amount of serious vulnerabilities that have been uncovered and exploited. In some cases exploit code exists in the form of proof-of-concept code which show how a particular exploit may be carried out by a properly motivated party.

Another area that makes Java particularly easy to target is the extreme proliferation of vulnerabilities and exploit code used to take advantage of these weaknesses. It has been found that numerous exploits that are not merely proof-of-concept, but full blown code and tools designed to leverage the weaknesses in Java applets. The sheer number of exploit code available to take advantage of Java’s failings makes it impossible to focus on any one piece of code, but it also underscores the importance of developers, site owners, and security professionals to be more vigilant in their countermeasures.

Some other potential security risks that can be problematic for security professionals and users of Java are as follows:

Next, one of the biggest issues that cause Java to be a very attractive target is the platform and browser independence that is part of the fabric of Java. Java is designed to be a technology that can be written once and run anywhere (on any supporting system), which is in fact a big reason why the technology has become popular with the academic and open-source communities alike. Attackers wishing to make the biggest “splash” need only exploit the large amount of systems out there that support and use Java to provide rich content and applications. Of course making these exploits even more dangerous and disconcerting is the fact that vulnerabilities can be platform independent meaning that an exploit can move across operating systems and environments easily. Attacks that leverage the power of Java can easily move across platforms due to the same reason that Java itself is popular, platform independence and the ability for developers to write once and run anywhere. All things considered exploits are relatively simple to implement and are able to run with little or no limitations. Consider the fact that most modern browsers supports Java without through bundled plug-ins or technologies and you have an incredibly dangerous situation.

Finally, it is definitely worth noting that due to the way Java executes; detection of security problems can be difficult by client-side security mechanisms to mitigate. In the Java model code is downloaded to a system and run on a Java Virtual Machine as we mentioned earlier in this section. This code (known as bytecode) is only partially compiled and is only further compiled by the system’s own JVM into machine specific code which is then executed on the system. When this code is compiled or parsed the actual process itself is something that cannot be observed by most, if not all, security software meaning that the possibility for malicious code to thwart security is higher. Further compounding the problem is the fact that malicious Java applets need not display any abnormal behavior which makes detection difficult, in fact tasks running within Java may run with higher privileges in the event they are digitally signed. On this last point, if an applet is signed it does not mean that it comes from a legitimate source so the danger is high, not to mention hard to detect.

In addition to these problems is something else that makes vulnerability and exploitation worse is vendor update processes. Specifically software vendors are known to create their own Java Runtime Environment (JRE) and update and maintain them on their own on a less than rigorous schedule. In these situations vulnerabilities in the JRE may exist for a substantially long time and lead to weaknesses being present for a long while. Still not enough of a concern? Consider the fact that users are less than diligent about updating their systems with the latest patches and service packs meaning vulnerabilities may never be eliminated even though a fix exists.

JavaScript

JavaScript is one of the oldest types of dynamic or active content and is by far the most widely supported and recognized. JavaScript is used on just about every web site you may visit to perform various tasks of all types. This scripting language is so widely used mainly due to its simplicity (relative to other technologies) and its incredibly wide support among browsers and platforms. Furthermore this scripting language is popular because of its ability to be easily integrated with other types of content and applications making it useful to developers and web designers alike. The success of JavaScript however is also the reason why attackers have targeted and leveraged the technology as a means to compromise systems and cause untold grief for clients. JavaScript has been used to perform attacks that involve redirects, downloading of content, or even revealing details about a victim’s system.

JavaScript is a dynamic scripting language that was originally developed by Netscape to support richer client interaction in web browsers. The technology was originally implemented publically in the beta version Netscape Navigator 2 in 1995 under the name LiveScript, but renamed later to JavaScript.

When JavaScript was announced it was quick to gain attention and widespread use as a client-side language and quickly cropped up on webpages en masse. The scripting language which originally started on the Netscape Navigator platform has had some growing pains, but has since been adopted by every major browser and is now essentially ubiquitous. JavaScript today is used on most about every web site in some capacity and more than likely will remain a staple on web pages for a long time coming.

JavaScript, as originally intended, is a rich dynamic scripting language designed to enable site owners and web designers to create more attractive and rich web pages. While one can make a case that JavaScript is similar to Java in the sense that some structures look the same, however the similarities end there. Java is downloaded and run in a JVM, but JavaScript is downloaded, interpreted and run by the browser itself directly. This ability to run JavaScript code is inherent in most browsers and therefore the ability to write code once and have it run anywhere is in the system by design.

JavaScript as a technology is one of the older types of dynamic content available to site designers, but there’s something else about this age that is not readily apparent. JavaScript is 15 years old at the time of this writing and its security model has not been updated substantially since it was released. At the time the JavaScript language was released there were two security issues that were seen as being the biggest threats namely malicious code and scripts gaining access to the local computer’s file systems. As we’ll see it has somewhat, but not entirely accomplished these goals.

First, one of the biggest concerns with JavaScript when it debuted was the idea that it could allow access to content on the local computer. The idea was that a script running in a web browser could easily take the next step and grant access to the local file system on behalf of an attacker letting them view and alter local stored content such as the “My Documents” folder. To address this concern the creators of JavaScript specifically designed the language with the idea that local system access was prohibited by the technology. In fact JavaScript cannot get files from the hard disk unless the user or someone on the client side browses to and selects the files specifically.

The second security issue with JavaScript? Attacks initiated by malicious websites via JavaScript which has become an all too common occurrence unfortunately. By using JavaScript it is more than possible for an attacker to steal information from a client system within the limitations placed upon the scripting language.

A third type of attack exists that is closely related to the malicious code attacks mentioned previously in this section, these are cross-domain attacks. Cross-domain attacks occur when scripts are run from a location different than the web page or content being accessed, just like some forms of XSS. An example would be a website where several embedded advertisements or other similar types of content exist. In this scenario the content is embedded in the page, but does not exist in the same domain as the web page itself meaning they are being called from another site. Such is the case in the following example:

In this example a web page with the embedded tags would actually be obtaining script from a third-party website and running it in the client’s browser. The danger here becomes one of trust and accessibility. First, because the user is more than likely accessing a website they already know and trust they will not think twice about the danger of running scripts from a third party as, after all, it did come from a site they trusted. In fact in this example the user will more than likely not even be prompted as to there even being a security concern. Second, when multiple scripts are called by one page an executed together they have access to each other’s global functions, objects, and variables. The effect of such access is that scripts can interact in unknown and unexpected ways potentially revealing information about the client and their environment.

What can happen if scripts can access each other? Well take a look at the following list:

Another danger with JavaScript is the fact that it is widely used and supported by other technologies to make them work properly. JavaScript is in fact used by other technologies such as Adobe Flash and others to make them work as designed. Accentuating this situation even further is the reality that JavaScript is used in other technologies such as the AJAX suite of web development technologies which themselves are gaining more traction in the marketplace.

VBScript

VBScript or VBS is a programming language originally launched in 1996 by Microsoft as part of their Windows Script Technologies suite. This technology is specifically designed for the Microsoft platform and was originally designed to automate commands and as such replace the older batch languages that were in use by network administrators and developers up to that point.

While VBScript can be used to do simple batch processing and such on the client it can also be used as a web scripting and development tool like JavaScript. Using VBScript it is possible to access what is known as the Object Model in Internet Explorer and manipulate the application in ways not possible in other browsers or languages.

Web Application Obfuscation is one client-side method of attack that should be covered, especially when discussing scripting languages. Obfuscation of code has allowed hackers to take one attack and create hundreds-if not millions-of variants that can evade your security measures. Web Application Obfuscation takes a look at common Web infrastructure and security controls from an attacker’s perspective, allowing the reader to understand the shortcomings of their security systems. An attacker could bypass different types of security controls, as well, these same security controls can introduce new types of vulnerabilities.

Security tools such as IDS/IPS are often the only defense in protecting sensitive data and assets besides for being educated when it comes to mitigating attack.

Your best method of defense aside from trying to avoid attack is to secure your data, make sure its backed up and highly available. More of these protection methods will be covered in Chapter 10.

VBScript has been responsible for a number of security threats over the years, but some of the more well-known ones are discussed here in this section.

One of the most common issues with VBScript is its power to access different parts of the client system (usually if the client is Windows). Some well-known attacks include the accessing of objects such as address books in email, history in the browser, and other items. In fact worms such as Melissa were successful because the two main users of VBScript, Outlook and Internet Explorer were right in the crosshairs of the attack.

VBScript also is known to have a number of security holes that are periodically patched as the situation merits. The problem, as was seen with other technologies, is that users may and generally do fail to install the required patches and fixes to their systems and leave themselves vulnerable to attack. Even though VBScript has been folded into the .NET technology suite and doesn’t exist in the same form it used to enough older environments exist that are not being patched or maintained properly and they become targets.

HTML 5

This is the “new kid” on the block for websites and designs. HTML5 published as a Working Draft by the W3C, is designed to enhance and eventually replace what is currently known as HTML4 which first debuted in 1999. The new version is designed to introduce new features such as dynamic content, flexibility and security features. While HTML5 is not a standard yet, but rather a work in progress at this point, it is not widely used as of this writing however, is something you should be aware of due to its active content nature.