Nytro Posted September 5, 2014 Report Posted September 5, 2014 (edited) Dirty Browser Enumeration Tricks – Using chrome:// and about: to Detect Firefox & PluginsAfter 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 & Plugin Identification With a little bit of trickery we can use these local references to: 1. Identify Firefox with 100% accuracy 2. Identify any Firefox plugins 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!')" /> [TABLE=class: crayon-table][TR=class: crayon-row][TD=class: crayon-nums] 1 [/TD][TD=class: crayon-code]<img src="about:logo" onload="alert('Browser is Firefox!')" />[/TD][/TR][/TABLE] 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 plugins as well. For example if you are using the “Resurrect Pages” plugin, 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!')" /> [TABLE=class: crayon-table][TR=class: crayon-row][TD=class: crayon-nums] 1 [/TD][TD=class: crayon-code]<img src="chrome://resurrect/skin/cacheicons/google.png" onload="alert('Browser has Resurrect Pages installed!')" />[/TD][/TR][/TABLE] So, how do we know what plugins this works for? From the Mozilla Developer Network:“Chrome resources can no longer be referenced from within <img>, <script>, or other elements contained in, or added to, content that was loaded from an untrusted source. This restriction applies to both elements defined by the untrusted source and to elements added by trusted extensions. If such references need to be explicitly allowed, set the contentaccessible flag to yes to obtain the behavior found in older versions of Firefox.” https://developer.mozilla.org/en-US/docs/Chrome_Registration To put it short, if the plugin has a line like the following in it’s “chrome.manifest” file: content packagename chrome/path/ contentaccessible=yes [TABLE=class: crayon-table][TR=class: crayon-row][TD=class: crayon-nums] 1 [/TD][TD=class: crayon-code]content packagename chrome/path/ contentaccessible=yes[/TD][/TR][/TABLE] Then the plugin’s resources can be included just like any other web resource. Which means if the plugin 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: Firefox add-on detection with Javascript | WebDevWonders.comDetecting FireFox Extentions ha.ckers.org web application security lab 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:Firefox Plugin Detector 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,-mandatorySursa: Dirty Browser Enumeration Tricks - Using chrome:// and about: to Identify Firefox & Plugins | The Hacker Blog Edited September 5, 2014 by Nytro Quote
