The purpose of this whitepaper is to provide administrators and engineers with an overview of ActiveX controls, and information on understanding and preventing the malicious use of ActiveX controls with Cisco’s firewall Application Layer Protocol Inspection feature.
What is ActiveX?
ActiveX is a technology developed by Microsoft. This technology was introduced in 1996 and is based on the Component Object Model (COM) and Object Linking and Embedding (OLE) technologies. Multiple applications, including Microsoft Windows applications Internet Explorer, Microsoft Office, Microsoft Visual Studio, and Windows Media Player, enhance their feature sets and encapsulate their functionality as ActiveX controls to embed the functionality into other applications.
ActiveX controls are small building blocks of programs (active content) that are used to create distributed applications that interoperate over the Internet through the use of web browsers (n.a. 1996, 1). The original intent of ActiveX, as defined initially with the advent of COM and OLE, was to provide easily reusable pieces of code. This reusability is achieved by creating objects that offer interfaces that can be called by other COM objects or programs, for example, Internet Explorer and its integration with COM. This integration provides the ability to seamlessly interface with Windows and third-party applications through the Internet Explorer browser. In addition, this allows the functionality of Internet Explorer to be easily extended by software developers who create complex applications that interface with websites through the browser.
ActiveX controls are often compared to Java applets because both enable end users to download small programs into their web browsers, resulting in more dynamic and interactive web pages (Felten 1997, 1). A major difference between ActiveX controls and Java applets is that ActiveX controls are granted higher levels of control over applications than Java applets. The additional privileges granted to ActiveX controls makes them a more attractive target for those looking to perform malicious activities.
Understanding ActiveX Attacks
Over the past few years, there has been a rapid increase in the use and subsequent exploitation of ActiveX controls. Many technologies and tools such as social networking websites Facebook and Myspace, applications such as Yahoo’s Music Jukebox, Real Network’s RealPlayer, and Apple’s QuickTime, have succumbed to ActiveX exploitation. The wide use of ActiveX attests to its position as a security target for vulnerability research, leading to the identification of security holes and exploits.
Although ActiveX controls are built into the Microsoft operating system and Internet Explorer, it is important to note that applications may install their own ActiveX controls to provide unique functionality through Internet Explorer. In addition, web sites install ActiveX controls. An example of this is often seen in Shockwave Flash, where a pop-up window prompts the user to install the Shockwave ActiveX control.
ActiveX controls are typically identified by their class identifier (CLSID). The CLISID is a unique value associated with each control to differentiate it from other controls. A CLSID key also exists. This key contains information used by the default COM handler to return information about a class when it is in the running state. Within the CLSID key, there are thousands of class identifiers, each specifying ActiveX controls. The unique string used for each CLSID is referred to as the globally unique identifier (GUID), which programmers often use a utility called Guidgen.exe to generate. There are websites available that list CLSIDs and what they refer to, two of which are listed below:
On devices running the Windows operating system, a list of all existing CLSIDs can be found at the following registry location:
Only a specific subset of these class identifiers can be instantiated by a website, because the CLSIDs must be marked as safe and categorized as such. An example of this is evident with controls that are marked as safe for scripting. A list of CLSIDs that contain this ability can be found at the following registry location:
HKEY_CLASSES_ROOT\CLSID\<control clsid>\Implemented Categories
The other manner in which ActiveX controls are identified is by the ActiveX control’s program identifier (ProgID). The ProgID and CLSID relationship can be compared to the relationship of an IP (Internet Protocol) address as it interacts with DNS (domain name system). Essentially, the ProgIDs can be looked up to determine the correlating CLSID. This interaction is seamless to Internet Explorer, thus it proceeds as if the CLSID had been initially provided (Warlord 2008, 4).
There are many forms of ActiveX attacks. Many of these attacks consist of a wide range of exploits. One such form is the ability to capitalize on remote code execution. Using remote code execution, an attacker can build a specially crafted web page, which would use the vulnerable ActiveX control in a user’s browser to perform remote code execution, potentially resulting in the complete control of the affected system.
Detecting and Preventing ActiveX Exploitation
To detect attempts to exploit vulnerable ActiveX controls, employ the proper use of detection tools such as the following:
See the Additional Information section of this document for links and details regarding the aforementioned tools.
In addition, the OleView tool can be run to determine if an ActiveX control is marked as safe or not.
In regards to testing potential vulnerabilities, the use of fuzzers can be employed. Fuzzers provide a technique to send random data to the inputs of a program. The results of the fuzzer testing can then be noted and implemented for future use in mitigation actions. ActiveX fuzzers such as H.D. Moore’s Axman and iDefense’s ComRaider are two fuzzers that have the ability to provide a database of controls that Internet Explorer can recognize (Warlord 2008, 4).
To reduce the likelihood that vulnerable ActiveX controls will be exploited, the proper safeguards must be implemented. The following Cisco firewall devices can implement mitigation techniques to prevent exploitation of vulnerable ActiveX controls:
A regular expression matches text strings either literally as an exact string or by using metacharacters. Using metacharacters with a regular expression allows a single regex to match multiple variants of a text string. You can use a regular expression to match the content of certain application traffic; for example, you can match a URL string inside an HTTP packet.
Use Ctrl+V to escape characters that have special meaning to the CLI, such as question mark (?) or a tab. For example, type d[Ctrl+V]?g to enter d?g in the configuration. The following table describes the metacharacters often used with application layer protocol inspection. For a more extensive table, refer to the regex Metacharaters table in the Cisco Security Appliance Command Reference.
Table 1. Common Application Layer Protocol Inspection Regex Metacharacters
Many regex options exist that aid in preventing ActiveX controls. A scale of samples exemplifying example progressions of basic regular expressions to some of the more advanced options follows:
Regex example 1: “My favorite color is (green|blue)”
Example 1 shows an exact match (including case and spaces) for the words “My favorite color is ”. The “( )” metacharacter indicates a subexpression that segregates characters and phrases from other characters so that specific actions can be taken on these characters or phrases in isolation. In this case, it isolates the words green and blue. The “|” metacharacter is an alternation indicating the regex will match either expression separated by it. In this case, the “|” separates the words “ green” and “blue”, thus, the regex will match on either of the following statements:
Regex example 2: “[Mm]y favorite color is ([a-zA-Z]+)\.”
In example 2, the word “my” can be uppercase or lowercase as indicated by the [Mm], which indicates a match on either “M”or “m”. Example 2 reflects an exact match (including case and spaces) for the phrase “ favorite color is ”. The “( )” isolate a subexpression. The “[a-zA-Z]” metacharacter represents a character range class that means match any character in the range stated in the brackets. In this example, it means match any uppercase characters “A-Z” or lowercase characters “a-z”. The “+” metacharacter indicates that there is at least one of the previous expression. In example 2, there is at least one of the expression “[a-zA-Z]”. The “\” represents an escape character; in example 2, it escapes the period (.) indicating that the text to be matched must end with a period (.). The regex example 2 will match a statement specifying any color specified in upper or lowercase and using an upper or lowercase “my” as follows:
It is important to note the possibility of unintended matches, as shown in the last statement above.
Regex example 3: “[Mm][Yy](\x20|\x2b)[Ff][Aa][Vv][Oo][Rr][Ii][Tt][Ee](\x20|\x2b)[Cc][Oo][Ll][Oo][Rr](\x20|\x2b)[Ii][Ss](\x20|\x2b)([^\s]+?)[.!]”
In example 3, the “[Mm][Yy]” allows the use of the word “my” in upper and lowercase. The string “(\x20|\x2b)” matches the ASCII hexadecimal integer “20” or “2b” as the metacharacter “\xNN” represents an escaped two-digit hexadecimal number. The “|” is the alternation metacharacter indicating a match of either said option. The string “[Ff][Aa][Vv][Oo][Rr][Ii][Tt][Ee]” specifies a match on the word “favorite” in upper or lowercase. The string “(\x20|\x2b)” again matches either ASCII hexadecimal integer “20 or 2b”. The string “[Cc][Oo][Ll][Oo][Rr]” matches the upper or lowercase syntax of the word “color”. Again, either integer “20 or 2b” is matched. The string “[Ii][Ss]” indicates a match of the word “is” in uppercase or lowercase followed by a match on either “20 or 2b”. In the string “([^\s]+?)”, the expression “[^\s]” indicates a match on a negated character class, meaning a match on a character NOT contained in the brackets. In example 3, the “[^\s]” matches any character other than whitespace such as a space or tab. The “+” is a quantifier indicating that there is at least one of the previous expression. In example 3, the “+” indicates that there is at least one iteration of the expression “[^\s]”. In this context, the “?” indicates that the previous quantifier should match as few characters as possible. This action is called non-greedy matching. Lastly, the expression “[.!]” simply indicates a match on any single character in the “[ ]”, thus either a “.” or “!” in example 3. The use of a “.” in a character class is a special-case; when used in this manner, the “.” does not act as a metacharacter and will only match a period. With this being the case, the regex for example 3 matches any of the following options:
It should be noted that a regular expression must consider any possible permutation of the data to be matched.
Caution: Application layer protocol inspection will decrease firewall performance. Performance impact should be tested in a lab environment before deployment in production environments.
The invocation of ActiveX controls can also be filtered using application layer protocol inspection and regular expressions on Cisco ASA, FWSM, and PIX firewalls. Regular expressions within application layer protocol inspection are supported on the PIX and ASA firewalls beginning with software version 7.2.1 and on the FWSM with software version 4.0.1 and later.
When vulnerabilities are found in ActiveX controls, the vendor typically discloses the specific vulnerable ActiveX CLSID or ProgID values. If these details are provided, the use of regular expressions can be employed within the application layer protocol inspection engine to identify specific strings in a packet and perform specific actions on this traffic as defined by the inspection policy.
Application layer protocol inspection is used for services that embed IP addressing information in the data packet, open secondary channels on dynamically assigned ports, and that require a deep packet inspection. The firewall must analyze each session of the protocol to properly identify the dynamic ports and permit the data exchange accordingly. There are numerous applications that use the application layer protocol inspection engine, including HTTP.
For a listing of the applications supported by application layer protocol inspection, and their supporting details, refer to “Supported Application Inspection Engines” under the Default Inspection Policy section of the Cisco Security Appliance Command Line Configuration Guide.
The inspection policy will leverage two regular expressions to identify packets containing the CLSID or ProgID of the CA BrightStor ActiveX control. The HTTP application layer protocol inspection will drop connections where the HTTP response body contains either the CLSID or ProgID of the Brightstor ActiveX control.
Caution: The configured regular expressions may match on any text strings within the body of a HTTP response. Care should be taken to ensure that business legitimate applications that use matching text strings without calling the ActiveX control are not impacted.
The following configuration example may be applied to PIX, ASA, or FWSM firewalls.
Cisco's Applied Intelligence team has incorporated a tool below which will aid with the building of regular expressions and the subsequent ASA regex configuration.
The following configuration example blocks the vulnerable CA Brightstor ActiveX control using a CLSID of BF6EFFF3-4558-4C4C-ADAF-A87891C5F3A3 and a ProgId of LISTCTRL.ListCtrlCtrl.1.
Please use the following two fields to generate a configuration example specific to the ActiveX control you want to block. This information is available in the IntelliShield alert or vendor response.
To verify the application layer protocol inspection and regex configuration, use the test regex and show service-policy commands as seen below:
! firewall(config)# test regex yahOO yahoo INFO: Regular expression match failed. firewall(config)# test regex brightstor brightstor INFO: Regular expression match succeeded. firewall(config)# test regex Cisco Cisco INFO: Regular expression match succeeded. firewall# ! Note: For additional information about the test regex command, refer to the Cisco Security Appliance Command Reference. ! !-- To verify the statistics of the application layer protocol !-- inspection use the “show service-policy” command which is !-- applied globally by default. ! firewall# show service-policy Global policy: Service-policy: global_policy Class-map: inspection_default Inspect: dns preset_dns_map, packet 0, drop 0, reset-drop 0 Inspect: ftp, packet 0, drop 0, reset-drop 0 Inspect: h323 h225 _default_h323_map, packet 0, drop 0, reset-drop 0 Inspect: h323 ras _default_h323_map, packet 0, drop 0, reset-drop 0 Inspect: netbios, packet 0, drop 0, reset-drop 0 Inspect: rsh, packet 0, drop 0, reset-drop 0 Inspect: rtsp, packet 0, drop 0, reset-drop 0 Inspect: skinny , packet 0, drop 0, reset-drop 0 Inspect: esmtp _default_esmtp_map, packet 0, drop 0, reset-drop 0 Inspect: sqlnet, packet 0, drop 0, reset-drop 0 Inspect: sunrpc, packet 0, drop 0, reset-drop 0 Inspect: tftp, packet 0, drop 0, reset-drop 0 Inspect: sip , packet 0, drop 0, reset-drop 0 Inspect: xdmcp, packet 0, drop 0, reset-drop 0 Class-map: MATCHING-WEBPORTS Inspect: http http-policy, packet 612, drop 203, reset-drop 0 protocol violations packet 210 class vulnerable-activex-class drop-connection log, packet 203 firewall# ! !-- For more granularity specify the specific inspection !-- (HTTP) policy as follows: ! firewall# show service-policy inspect http Global policy: Service-policy: global_policy Class-map: inspection_default Class-map: MATCHING-WEBPORTS Inspect: http http-policy, packet 612, drop 203, reset-drop 0 protocol violations packet 210 class vulnerable-activex-class drop-connection log, packet 203 firewall# ! !-- Syslogs can also be used to verify the activex control is !-- matched and thus discarded. System log message 415007 is !-- generated when the message body matches the regular !-- expression that has been configured. ! firewall#show logging | grep 415007 May 28 2008 15:26:43: %ASA-5-415007: HTTP - matched Class 26: MATCHING-WEBPORTS in policy-map http-policy, Body matched - Dropping connection from outside: 192.168.240.97/6618 to inside:192.168.60.65/80 May 28 2008 15:28:04: %ASA-5-415007: HTTP - matched Class 26: MATCHING-WEBPORTS in policy-map http-policy, Body matched - Dropping connection from outside:192.168.240.97/6685 to inside: 192.168.60.65/8080 !
For further information regarding the system log message 415007, refer to the log message in the Cisco Security Appliance System Log Messages documentation.
The ability to understand protocols is essential for administrators and engineers to properly detect and prevent attacks. Application developers have increased their reliance on protocols, technological concepts, and tools such as ActiveX. It is imperative that administrators and engineers understand the numerous aspects and implications of ActiveX controls and the technology, including the configuration solutions required to prevent these attacks.
Andrae Middleton (email@example.com)
Andrae Middleton is a member of the Security Intelligence Engineering organization at Cisco. Additional content produced by Security Intelligence Engineering is located in the Security Intelligence Best Practices section of Cisco Security Intelligence Operations.
Microsoft OLE/COM Object Viewer
Microsoft Windows Debugger
Felten, Edward W. “Security Tradeoffs: Java vs. ActiveX.” April 28, 1997.
n.a. “Microsoft Announces ActiveX Technologies.” March, 12, 1996.
Warlord. “ActiveX Active Exploitation.” January, 2008.
This document is part of Cisco Security Intelligence Operations.
This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.