Dirty Browser Enumeration Tricks – Using chrome:// and about: to Detect Firefox & Addons
After playing around with some of the cool Firefox Easter eggs I had an interesting thought about the internal chrome:// resources in the Firefox web browser.
In a previous post I found that I could access local Firefox resources such as style-sheets, images, and other local content in any public web page. For example, if you’re using the Firefox web browser, you know what the following image is:
For everyone else, the above image is broken.
This is because the image is actually a link to “about:logo”. It’s a reference to a local resource only found in Firefox flavored web browsers. When the image is viewed in Chrome, Internet Explorer, or Safari, the reference doesn’t exist and the image link is broken.
Alright, how about a consolation prize – what about this image?
That may be cool, but it does beg the question – can we abuse this?
Of course we can!
Subverting Same Origin for Browser & Addon Identification
With a little bit of trickery we can use these local references to:
-
Identify Firefox with 100% accuracy
-
Identify any Firefox addons with special “chrome.manifest” settings (to be covered below)
This can be done by doing something like the following:
<img src="about:logo" onload="alert('Browser is Firefox!')" />
Simply enough, if you get a JavaScript alert – you’re using Firefox!
(Interestingly enough, this doesn’t work on the Tor browser. Perhaps due to the NoScript addon?)
The same trick can be used to identify some addons as well. For example if you are using the “Resurrect Pages” addon, you can see the following image:
Using the same tactic as above, we can enumerate the install of “Resurrect Pages” via the following:
<img src="chrome://resurrect/skin/cacheicons/google.png" onload="alert('Browser has Resurrect Pages installed!')" />
So, how do we know what addons this works for?
From the Mozilla Developer Network:
“Chrome resources can no longer be referenced from within
,
https://developer.mozilla.org/en-US/docs/Chrome_Registration
To put it short, if the addon has a line like the following in it’s “chrome.manifest” file:
content packagename chrome/path/ contentaccessible=yes
Then the addon’s resources can be included just like any other web resource. Which means if the addon has any style-sheets, images, or JavaScript – it can be enumerated!
When I was first investigating this behavior I thought I was original, but of course others have attempted this as well:
http://webdevwonders.com/detecting-firefox-add-ons/
http://ha.ckers.org/blog/20060823/detecting-firefox-extentions/
Oh well, let’s do it on a bigger scale!
Gathering Firefox Addon Analytics
In order to get a comprehensive list of which addons had set this “contentaccessible” flag to “yes”, I scraped ~12K addons from the Firefox Addons website. Each addon XPI was parsed for it’s “chrome.manifest” file for the “contentaccessible=yes” flag. If the flag existed, the proper chrome URI was generated for each file in the content path. These path’s were then used to construct a JavaScript scanner that works by making references to these chrome URIs and checking if they are valid via the “onload” event.
The completed scanner:
After taking analytics on all of these addons it was found that only a mere ~400 had the proper contentaccessible flag combined with detectable resources. By detectable resources I mean resources such as JavaScript, CSS, or images that could be embedded and detected. This means that out of all the addons, only about ~3.3% could be detected in this manor. Although there are other methods of detecting the presence of Firefox addons. For example, despite the Adblock Plus addon not having a contentaccessible flag, it can be detected by attempting to make a script or image reference to a blocked domain. If the reference fails to load on a file that is perfectly valid, we know it is being blocked by Adblock Plus or some other anti advertisement addon. In the same manor we could fingerprint which Adblock Plus list is being used.
The detection of addons is quite quick and only takes a few seconds to complete. This is due to the fact that the references are local, so they aren’t being grabbed off a webserver but directly from the browser itself. To try the scanner out in your Firefox browser, see the following link:
//thehackerblog.com/addon_scanner/
For other hackers or web developers, a full JSON dump of the data collected is available here (warning, big file!). This contains data on publicly accessible chrome:// URIs as well as basic information on every addon collected. I’d link to the dump of all the Firefox addon XPIs downloaded but it goes well over a gigabyte in size and I’m not sure if re-hosting addons is allowed.
As a final point, being able to access this data has another advantage. If any information is leaked in the JavaScript resources such as local filesystem references, OS information, etc, this could be included and potentially could leak sensitive information. After checking many of the chrome:// resources inside Firefox itself I found that most references to the browser’s version or other information have been crudely commented out. I assume because someone else has attempted this style of enumeration before. Not to mention if the content is vulnerable to XSS, you have remote code execution due to the JavaScript running at the same level as a Firefox addon.
Until next time,
-mandatory
