DO NOT Install * aCt!v3X

You must be wondering with the topic title that why it is so weird, “DO NOT” for actually DO NOT J and “Install” is strikeout means that not to install and “*” in SQL means ALL. “aCt!v3X” is nothing but ActiveX. So, in short title is “DO NOT Install all ActiveX”. Why? Let’s begin with history.

History

It was difficult for Microsoft to fight with Java when they came up with Java Applet for providing rich user interface functionalities at client side. Then to fight back Microsoft came up with ActiveX controls in 1990. ActiveX controls are basically COM objects that are used to interact with client’s system for special purposes like updating the system by applying latest patches, checking for installed software on the client machine. An ActiveX allows a program to self-register, make changes to registry/file system, and run itself automatically.

Like thousands of items downloaded via browser, ActiveX control also downloaded by browser and has access local operating system. With currently logged-in user privilege it (ActiveX control) has an access to local file system and some part of registry. Due to this reason it has potential power and poses risk when used in the internet.

ActiveX Control Structure

ActiveX control is used for many purposes, like one can be getting all necessary information of the local operating system and sending this information to web application which is invoking this ActiveX control. Mostly it is implemented in C++, but other programming languages can also implement this.

Following is the description for ActiveX control

  1. ActiveX interface – definition of methods and properties available.
  2. ActiveX object – COM component. Object contains interfaces, properties, methods
  3. ActiveX methods – function which has parameters
  4. ActiveX property – get/set conversations

As ActiveX has access to OS resources it can be written in a such fashion that it will be used to perform format string, buffer overflow and other attacks, creating security loop holes. If we compare the ActiveX with Java applet then ActiveX given access to OS via browser with currently logged-in user privileges and on the other hand applet works in sandbox mode. Whenever it needs the access to local operating system it uses virtualized wrapper which gives limited and necessary access.

How it works?

  1. A user visit the web site which invokes the ActiveX control
  2. If ActiveX control is not already installed then user is prompted to install the same. Depending on the behavior of ActiveX control there may be need of overall configuration changes that may need administrative rights.
  3. It will then request permission to execute instructions for the control.
  4. Depending on the browser’s security setting if OS will grants permission to ActiveX control then system will execute those instructions and will make necessary changes like installing programs, updating registry, or file system access as needed, looking for particular version of product. Installing basically needs downloading a dynamic link library (DLL) and registering this DLL under “HKLMSoftwareClasses” so that it can be used.
  5. Once the control is completely registered then COM object for this is stored at user’s operating system for future visits. So next time when user visits this website again, the ActiveX control will check that whether COM object has been installed or not.

ActiveX Pitfalls and Preventions

Due to its behavior once ActiveX control is downloaded it can access the user’s operating system and file system (if it is written in such a fashion). That is the reason it possible to accomplish an attack using ActiveX control.

1) Anyone is allowed to execute ActiveX control

ActiveX control does not maintain any listing of allowed or disallowed authorized servers and/or domains who can invoke something like *.allowedlist.com. For attacker this is like honeycomb with full of honey and there are to honey bees to protect it. So attacker get a very wide surface area for attacking any of the existing ActiveX control installed on user’s operating system for performing any malicious activity for own good.

Prevention: In order to deem this attack Microsoft has introduced the “SiteLock”, a mechanism (library) which developers can use to prevent ActiveX control access. Using this mechanism a developer can restrict the access to specific site such as *.allowedlist.com or to use Secure Socket Layer (SSL). But, XSS and DNS attacks still a problem!

2) Unsigned ActiveX

All the ActiveX controls should be signed; by this it confirmed that the binary which got installed in user’s machine is downloaded from certified source. Also it makes sure that it has not been modified, tampered or changed in transit or since the date it is released. On the other hand, Unsigned ActiveX controls do not guarantee that they are certified source or this binary is tamper free! This becomes more important for attacker who put their content on web site and in ads.

Prevention: All the ActiveX controls should be signed by company’s signing key. By this it makes sure that binary is coming from legitimate source. In order to this one just has to buy the singing key from VeriSign or any other vendor for that matter and can use Microsoft’s SignTool.exe program to sign the binaries.

Posted in ASP.NET, Programming Language, Secure .NET Coding, Security Tagged with: ,