There is an impressive list of Firefox security add-ons that makes up the
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
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
firstname.lastname@example.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
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:
Having unreviewed add-ons exposed to the public, even with low visibility,
has been previously identified as an attack vector for hackers. For this
reason, we're already working on implementing a new security model for
addons.mozilla.org that will require all add-ons to be code-reviewed before
they are discoverable in the site.
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.
to post comments)