Attacking ActiveX Controls
ActiveX controls are of particular interest to an attacker who is targeting other users. When an application installs a control in order to invoke it from its own pages, the control must be registered as “safe for scripting.” Once this has occurred, any other web site accessed by the user can make use of that control.
Browsers do not accept just any ActiveX control that a web site requests them to install. By default, when a web site seeks to install a control, the browser presents a security warning and asks the user for permission. The user can decide whether or not they trust the web site issuing the control, and allow it to be installed accordingly. However, if they do so, and the control contains any vulnerabilities, these can be exploited by any malicious web site visited by the user.
There are two main categories of vulnerability commonly found within ActiveX controls that are of interest to an attacker:
■ Because ActiveX controls are typically written in native languages such as C/C++, they are at risk from classic software vulnerabilities such as buffer overflows, integer bugs, and format string flaws . In recent years, a huge number of these vulnerabilities have been identified within the ActiveX controls issued by popular web applications, such as online gaming sites. These vulnerabilities can normally be exploited to cause arbitrary code execution on the computer of the victim user.
■ Many ActiveX controls contain methods that are inherently dangerous and vulnerable to misuse. For example:
- LaunchExe(BSTR ExeName)
- SaveFile(BSTR FileName, BSTR Url)
- LaunchExe(BSTR ExeName)
- SaveFile(BSTR FileName, BSTR Url)
Methods like these are usually implemented by developers in order to build some flexibility into their control, enabling them to extend its functionality in future without needing to deploy a fresh control altogether. However, once the control is installed, it can of course be “extended” in the same way by any malicious web site in order to carry out undesirable actions against the user.
Finding ActiveX Vulnerabilities
When an application installs an ActiveX control, in addition to the browser alert asking your permission to install it, you should see code similar to the following within the HTML source of an application page:
<object id=”oMyObject”
classid=”CLSID:A61BC839-5188-4AE9-76AF-109016FD8901”
codebase=”https://wahh-app.com/bin/myobject.cab”>
</object>
This code tells the browser to instantiate an ActiveX control with the specified name and classid , and to download the control from the specified URL. If a control is already installed, the codebase parameter is not required, and the
browser will locate the control from the local computer, based on its unique classid .
If a user gives permission to install the control, then the browser registers it as “safe for scripting.” This means that it can be instantiated, and its methods invoked, by any web site in the future. To verify for sure that this has been done, you can check the registry key HKEY_CLASSES_ROOT\CLSID\{classid of control taken from above HTML}\Implemented Categories . If the subkey 7DD95801-9882-11CF-9FA9-00AA006C42C4 is present, then the control has been registered as “safe for scripting,” as illustrated in Figure 1.
Figure -1: A control registered as safe for scripting
When an ActiveX control has been instantiated by the browser, individual methods can be invoked as follows:
<script>
document.oMyObject.LaunchExe(‘myAppDemo.exe’);
</script>
Preventing ActiveX Vulnerabilities
Defending compiled software components against attack is a large and complex area, and goes beyond the scope of this article. Basically, the designers and developers of an ActiveX control must ensure that the methods that it implements cannot be invoked by a malicious web site to carry out undesirable actions against a user who has installed it. For example:
Figure -2: COMRaider showing the methods of an ActiveX control
■ A security-focused source code review and penetration test should be carried out on the control to locate vulnerabilities such as buffer overflows.
■ The control should not expose any inherently dangerous methods that call out to the file system or operating system using user-controllable input. Safer alternatives are usually available with minimal extra effort. For example, if it is considered necessary to launch external processes, compile a list of all the external processes that may legitimately and safely be launched, and either create a separate method to call each one or use a single method that takes an index number into this list.
As an additional defense-in-depth precaution, some ActiveX controls validate the domain name that issued the HTML page from which they are being invoked. Some controls go even further than this, and require that all parameters passed to the control must be cryptographically signed. If an unauthorized domain attempts to invoke the control, or the signature passed is invalid, the control does not carry out the requested action. You should be aware that some defenses of this kind can be circumvented if the web site that is permitted to invoke the control contains any XSS vulnerabilities.
NEXT is..Local Privacy Attacks………………………………,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
