There is an impressive list of Firefox security add-ons that makes up the Web Application Security Penetration Testing collection. It contains many of the most well-known addons (Firebug, Greasemonkey, etc.) along with a whole raft of lesser-known, but still useful add-ons—83 add-ons in all. Folks who install from the collection probably weren't expecting that it might also contain a trojan horse in the form of a password logger, but that's just what the "Mozilla Sniffer" add-on did, as Netcraft recently reported.

The add-on in question was marked as "experimental", which means that it had not undergone the code review that add-ons get before turning off the experimental flag. That flag should make users more wary about installing those add-ons, but since it came from the Mozilla web site, and was listed in the collection, it's not hard to see how users, even seemingly security-conscious ones, might get fooled into installing it. The malware author did try to misdirect users by stating that "the addon was validated by MOZILLA validation", but the download page clearly indicated that it had not been reviewed. In any case, some 1800 users downloaded it, and it was in daily use by 334 at the time it was discovered to be a trojan.

So, what did Mozilla Sniffer do? It didn't only "view and modify HTTP/HTTPS headers" as it claimed, but also checked each form that was submitted to see if there were password fields in the form. If so, it sent the form data, which would include the username and password, and the form destination URL off to a server that was presumably under the malware author's control. Essentially all credentials that were used while the add-on was installed were logged for whatever, undoubtedly nefarious, plan the attacker had.

Mozilla Sniffer was uploaded to addons.mozilla.org on June 6, but its trojan nature was not discovered until July 12. Johann-Peter Hartmann had installed some add-ons from the collection to do some security testing of an online game when he noticed a strange HTTP request being made when he logged into the game. Noticing that it sent the credentials and URL to some IP address he didn't recognize, he started to dig deeper.

Hartmann realized that one of the recently installed add-ons was likely to blame, so he started poking around in the source code for those, looking for the destination URL for the unexpected HTTP request. He found it in the popular (and reviewed by Mozilla) Tamper Data add-on, which was rather surprising. It turns out that Mozilla Sniffer had used Tamper Data's universally unique identifier (UUID) so it was able to overwrite the data in the Tamper Data directory—in effect masquerading as that add-on.

The add-on was quickly removed once Hartmann reported it to security@mozilla.org. Mozilla also put out a security announcement on the add-ons blog, but for a substantial number of users, the damage was already done. Mozilla Sniffer was added to Mozilla's add-on blocklist, which will cause users to be prompted to uninstall the add-on. That should remove the problem going forward, but it is likely that some credentials were sent off to the author's site so affected users should probably change any passwords they used after installing Mozilla Sniffer.

Mozilla is currently working on a proposal to change the add-on review process so that unreviewed add-ons are not available from addons.mozilla.org:

The new review process would essentially require all add-ons to get at least a preliminary, cursory code review for malicious code before it could appear on the site. Add-ons that had not passed that initial review would not appear when users searched or browsed add-ons. That would remove the implicit—though clearly disclaimed—Mozilla "stamp of approval" for unreviewed add-ons. Even those that pass the preliminary review will still be marked as "unverified" and be subject to a number of limitations (lowered search ranking, click-through warning on install, etc.).

The preliminary review is meant to get the add-on out in front of users fairly quickly so that developers can get feedback before requesting a full review. The full review will take longer, but passing it will give the add-on full privileges at the Mozilla add-on site.

While it is rather ugly for the users affected, the effects of the attack were not all bad. It should help lead to better procedures for reviewing add-ons as well as making it clearer what the limitations of the current review process are. The attack itself wasn't terribly sophisticated, so it would presumably have been detected immediately if a review had been requested. A more subtle attack, that might remain undetected even with a full review, would be much more dangerous.

In the end, installing an add-on requires some level of trust in the author. Reviewers can make mistakes, as can automated review tools. Since Mozilla does not do any vetting of the add-on authors, it would seem possible, likely even, that some day a determined attacker will slip something through Mozilla's review process. That will be a really bad day.