ActiveX Data Leaks: Making Bad (Non-)Browsers Worse

Outdated browser plugins like ActiveX are a perfect target for compromise, yet they still lack regular updates

Outdated browsers and browser plugins. People use them, forget about them, they become outdated, and their machine gets compromised. It’s a story almost as old as the web browser. The problem is, people never learn and never update - or, in this case, get rid of the problematic plugin.

Source: sploit.io

ActiveX, a framework native to Internet Explorer, was introduced in 1996. Still supported in Windows 10, it allows an attacker to steal data and fully take over the victim’s machine when that person visits a page that contains a particular set of scripts.

How relevant is this exploit in 2019? In an unscientific survey among software engineers about ActiveX and if it still played a role, we got answers like this, from Zachary S. in San Francisco: "I think it’s dead. I hope it’s dead. It should be killed if it’s not dead."

Unfortunately, it’s not. According to NetMarketShare ("Market share statistics for Internet technologies”), Internet Explorer as of May 2019 still holds 7.70% of the entire browser market share, ranking higher than Microsoft Edge (5.36%). Never mind that Microsoft by now has disavowed IE and doesn’t even want to call it a “browser” anymore. People are still using it, including in large organizations.

Even though IE’s market share has slumped way below 10%, what’s important to keep in mind here are the commercial and government entities that still use Internet Explorer on their internal networks, to evade compatibility issues within their enterprise environment. Microsoft’s warnings and PR noise notwithstanding, IE is here to stay for a long time.

So let’s explore the numerous ways in which a specific module, ActiveX, can be used to attack unsuspecting users who visit a web page with a regular browser (or "compatibility solution," as Microsoft calls IE now) susceptible to such exploits.

Source: sploit.io

What you’re looking at is a web page that contains a list of a site visitor’s attached network adapter device names and corresponding MAC addresses.

Question: Can you inadvertently disclose this unique identifier by just visiting a website with a locally installed traditional browser?

Answer: You better believe it. And yes - there’s absolutely no (good) reason for any website to have access to your MAC address, let alone all MAC addresses.

Yet here we are - courtesy of an ActiveX object. The underlying script is pretty basic and relies on using JavaScript and an ActiveX object to retrieve all network adapters attached to the computer. It works on all versions of Internet Explorer, as long as ActiveX is enabled.

Here’s how this script works. It starts by creating a new ActiveX object, followed by executing a local query "SELECT * FROM Win32_NetworkAdapterConfiguration", which retrieves all network adapters and corresponding MAC addresses.

It then runs a loop that prints out every entry from that query. Quite simple. Since this is a "try and catch" method, if that doesn’t work or if it runs into a problem, it simply prints N/A. Because of its "wait and prey" nature, this script can easily be used by an attacker to passively collect network device information that can later be used for fingerprinting purposes, to keep track of visitors that fall victim to it.

Once they have obtained all the network adapter names and MAC addresses, what can attackers do with them?

The MAC address and device name both give us vital information about the make and model of the network card - enough information, to be sure, to find a corresponding hardware exploit on a site like exploit-db.com and to use that against our visitor. It’s that simple.

From the looks of it, this script also gives us user-defined network adapters. So if, say, a user needed to make a loopback (non-existing/virtual) network card for something like Wireshark or for redirecting VPN traffic, that information can still be obtained even if it’s not a physical network card. That’s why in the above screenshot, some entries are not assigned a MAC address; they are just null.

Imagine the (bad) possibilities. This script can be used for de-anonymization or de-cloaking and singling out visitors based on how unique their setup is. Moreover, it can be modified further to have all this data sent and stored in a remote database through basic POST or GET requests.

Now let’s take a look at some more revealing ActiveX object scripts.

Source: exploit-db.com

The above script is part of an exploit that breaks out of Internet Explorer using ActiveX and executes an arbitrary binary, in this case, calc.exe. User visits web page, calculator applet opens. Why would this feature be useful for a potential attacker?

If you’re up to no good and you’re getting site visitors to download a malicious executable, you’d want them to run it, wouldn’t you? Instead of pointing at calc.exe, an attacker can point it to C:\Users\%username%\Downloads\evil.exe and it would auto-execute it instantly once the download has finished.

Depending on how big the binary is, the bad guys can infect and pivot off a site visitor’s machine, probe the internal network that person is connected to, and by the time the web page is done loading, everyone within the target organization is infected with ransomware.

That’s why attackers who’ve set their eyes on particular organizations with a large legacy browser base just love ActiveX. How does this specific exploit work?

The object tag is used in HTML for ActiveX, Flash, PDF, et al. Here the object tag also has an attribute called "classid" and within it is a registry key "2C24DD5-D70A-438B-8A42-98424B88AFB8" which correlates to a CLSID that’s used to load ActiveX objects.

The CLSID for ActiveX can be found in the registry. The next line in the script evokes a script tag with VBScript embedded. The VBScript contains the path to the binary in question. Quite simple and easy to use for remote code execution.

Source: exploit-db.com

This script shown here contains only two lines, but don’t let its simplicity fool you. In the wrong hands, it has much evil potential. Below the two lines, I’ve broken it down, so it’s easier to read. In a nutshell, this script allows you to read any file on the target computer, using nothing but JavaScript and an ActiveX object.

Internet Explorer had a feature (as "useful" as Clippy) that was called “ShowHelp”. It was well intended, displaying help content in web pages. Problem is, this function also helps attackers. For example, here are two lines of code for stealing cookies off any site the victim has visited:

showHelp("file:");showHelp("http://www.google.com/");
showHelp("javascript:alert(document.cookie)");

Just two lines like before. This example takes the cookies stored from Google.com and shows them to the user using a popup. They could have been silently sent to a remote server instead, and then used to steal the user’s login session.

Two lines. This code can easily be sneaked into various sites for remote session hijacking.

This particular exploit takes advantage of the showHelp function along with ActiveX to read any file stored on the visitor’s computer. Now, obviously, an attacker would have to know what the file is called and where it’s located. Not too difficult for someone with a probing mind, you say?

I agree. With this trick, an IE or ActiveX plugin user’s most sensitive files are up for grabs.

Here’s an attack strategy for any Red Teams out there doing offensive and reconnaissance work for organizations that still use Internet Explorer and ActiveX.

• Create keylogger binary and upload it to a remote server.
• Create a webpage that initiates a download of this keylogger once the page finishes loading, then redirects the user to an exploit page described in the next step.
• Use the ActiveX exploit from above that breaks out of IE to execute any binary, and point it directly to C:\Users\%username%\Downloads\keylogger.exe
• Use the first ActiveX object to store the MAC Address of the user so you can uniquely identify each infected victim.
• Use the showHelp ActiveX exploit to periodically read and retrieve the keylogger log file (since the filename and path is known) containing all the keystrokes recorded from the user every time the site has been revisited, and pair the obtained log file with the visitors MAC Address obtained from Step 4 to distinguishably know what keystrokes belong to which victim.

That’s all there is to it. You can find a way to inject the showHelp exploit into the user’s browser homepage. That way, every time IE is opened, the Red Team gets the log file sent to the remote server: full system compromise, the user wouldn’t suspect a thing, and the resulting report to the CISO will hopefully be the death knell for any ActiveX-supporting browsers and plugins still used within that company.

It’s one thing to know the basics of how ActiveX and Internet Explorer are helping the bad guys out, and quite another to see it up close in practice. That’s why I compiled these illustrated examples.

If your company or public sector entity (example) still has either of the two installed somewhere on its network, you may want to share these examples with your higher-ups. Let them know where you found it, and that Silo Cloud Browser prevents all web-borne and browser-targeting exploits - ancient or contemporary - from ever reaching the user’s machine or local network.