Browser extensions, sometimes called plug-ins or add-ons, provide all types of wondrous functionality on top of the web browser, some of which may be actually wanted by the user! These little gems, however, have also proved valuable to attackers. Volume 20 of Microsoft’s Security Intelligence Report demonstrates a year 2000-era marked increase in the rise of adware such as Win32/Diplugem. These types of threats register themselves as a browser extension to inject advertisements right into the rendered page of the user. It’s actually pretty clever.
Code Execution Too!
Browser extensions may also pose increased risk to users since some of them run native code in the context of the browser. For instance, Internet Explorer has long supported ActiveX modules (.ocx) which are treated by the browser as a DLL and loaded directly into memory. In this scenario, the browser plug-in is almost the same as an executable, inasmuch as it has the potential to execute malicious code or run any program as the current user.
While Internet Explorer allows you to define certain pre-approved websites for its add-ons to run and the most popular add-ons set this by default, most other add-ons run on all sites. By browsing to a specially-crafted website, an attacker can potentially enumerate installed add-ons and then invoke a vulnerability in them to gain control over the browser and ultimately over code execution.
Needless to say, it is important to figure out what browser extensions may be installed on your users’ systems. We’ll look at uncovering these extensions in Internet Explorer 11 and Chrome 51.0.2704.84 on Windows 8.1 and MacOSX. These techniques may work on older or newer versions as well.
Built-In Detection
Since browser extensions can also be active without any visual indication in the browser, a good start is to dig into the browser’s built-in manager. Internet Explorer 11’s Add-on Manager can be found under Tools-> Manage Add-ons. By default, Internet Explorer will only show currently-loaded add-ons, so be sure to expand the view to include all add-ons:
Extensions can be found in Chrome under the options menu, then More tools -> Extensions or just chrome://extensions/ in the URL bar.
Third-Party Tools
The de facto tool most responders use for this purpose in Windows is Autoruns. It has the built-in capability to look across components on the whole system for executables and modules which get loaded automatically. One tab is Internet Explorer:
Autoruns also has the ability to query these via the command line:
While this is great for responders, it is somewhat limited in that it only shows Internet Explorer add-ons, and doesn’t include all add-on types. As of Windows 8, Microsoft created a new registry location for add-ons that Autoruns doesn’t check.
Finding Chrome Extensions with Python
Every Chrome extension is given a unique identifier called an extensionid. This is just a 32-character long, base-16 encoding (using a-p instead of 0-9a-f) of the first 128-bits of the SHA256 hash of the RSA public key (that was a mouthful!). This ID is used locally and in the Chrome Web Store. For instance, feedly has an extensionid of hipbfijinpcgfogaopmgehiegacbhmob – to look it up in the Web Store, just go to:
On your local system, extensions are stored in directories named after their extensionids under the following location:
-
~/Library/Application Support/Google/Chrome/Default/Extensions/(MacOSX) %APPDATA%LocalGoogleChromeUser DataDefaultExtensions(Windows)
Each extension directory includes a manifest.json which holds content about the extension, including update URLs and the name. Sometimes these name values are not too useful. Chrome extensions support multiple languages, so an often more comprehendible name value can be found in the _locale/en/messages.json file under the keys appName, extName, or app_name.
Here’s a quick code snippet to demonstrate this:
Chrome also maintains a Preferences.json file which is also a great resource to query for extensions. It contains tons of information. Here’s an example of querying it for extension content:
Finding Internet Explorer Add-ons with PowerShell
Internet Explorer’s add-ons are spread across a few different registry entries, organized by a GUID, a unique identifier Windows calls a CLSID, that is assigned COM objects. Unfortunately, the exact structure of how these entries are organized varies between keys so there isn’t just one way to query them.
While you can also query these registry keys using Python, I wanted to highlight querying them with PowerShell because it can be easily adapted to run on a remote system or incorporated into a script. Querying the registry is just a matter of using Get-ItemProperty and recursing through the values. For instance, a subset of the registry keys that includes add-ons is structured such that a ClsidExtension key holds the CLSID of the browser add-on. To query these types we can do the following:
All CLSIDs are stored in single registry key HKLM:SOFTWAREClassesCLSID. You can get the registered name of the CLSID by looking under the InProcServer32 entry.
Here’s an example of looking up a CLSID via PowerShell:
Finding Chrome and IE Extensions in Windows and MacOSX
To help make this all much easier, I wrote a script to do it all for you 🙂
Running is easy, just run python extension_finder.py from your home directory to give it a whirl (you’ll need tabulate). If you’d rather just look for IE add-ons with PowerShell, run .FindIEExtensions.ps1 from a PS> command prompt.
Enjoy!
