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."
BlueHost (Score:5, Interesting)
Looks like the stolen data was being sent to a hacked BlueHost account. Figures.
Advertised purpose? (Score:2, Interesting)
What was the addon supposed to do?
Re:Native features in browser (Score:5, Interesting)
In this case, for instance, the malice was flagged by somebody watching network traffic, which is pretty trivial on any platform that doesn't have a bad case of being a console/iProduct. A purely binary, closed source, application could have been caught in exactly the same way.
Re:Native features in browser (Score:3, Interesting)
There's no way to be sure of anything, but as far as risk goes, you have to admit that trusting one vendor with a financial stake in not having a privacy loss scandal is a lot easier than trusting any random person in the world who can submit a plugin to the mozilla site.
I'm a software developer, but I'm not going to go over every line of source code for the applications or plugins that I install on my computer. Seriously, even if you did, have you ever read along with or participated in code obfuscation contests? Many developers with malicious intent can make evil code look totally innocuous.
seeing the recent fraud commited (Score:3, Interesting)
on Apple's store your suggesting we avoid Apple products? I figure you were going to imply Android as being less safe, but the only recent story about market safety I have seen is someone exploiting iTunes accounts to the benefit of a single developer.
though it would be interesting to have two bad apps released simultaneously into both markets and see which one gets caught first
Re:wait, add-ons don't have a permissions model? (Score:5, Interesting)
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.
Re:Native features in browser (Score:3, Interesting)
>>>And since Opera is not open source, there is no way to be sure of that.
I think we can trust the Opera developers. They've been around long enough (15 years), and they are the #1 browser in eastern Europe and Russia* so someone would have caught them by now, if they were thieves. ----- My main complaint about Opera's built-in features is it creates a memory hog. I don't need AdBlock or Bittorrent or Mail in my web browser. Using Firefox allows me to have a leaner program that is stripped of those features.
*
* Or so I've heard. I've never seen any proof.
Re:Native features in browser (Score:3, Interesting)
This is why I love that Opera comes build-in with all the features you need and a lot more.
Except that it doesn't. I heavily rely on Firefox extensions to, for example, manage my tabs. It's entirely possible for me to work on three projects, each with ten to thirty tabs associated with them, while simultaneously using the same browser for personal stuff, which incurs further tabs. Having fifty or more tabs open at the same time is not unusual for me. Does Opera have an easy way of organizing a huge amount of tabs without having to use additional windows (which break the way I partition my screen)? Firefox has an extension for that. I can even suspend tab groups and open them again later if I know I won't need them for a while.
Likewise, is Dragonfly as powerful as Firebug? Can Opera give me the sent and received HTTP headers in realtime? User styles and plugins not distributed with the browser don't count; you're positing that Opera already comes with anything I need. Plus, what about ARM?
Don't get me wrong. Opera probably does come with anything a casual desktop/notebook user needs. Some people have requirements that don't mesh well with what the Opera devs thnk the average user wants, however, and in that case Opera becomes rather unattractive. Given that this is Slashdot, the assumption that the people here are average users may not be sound.
Re:Native features in browser (Score:3, Interesting)
Seriously, even if you did, have you ever read along with or participated in code obfuscation contests?
Any obfuscated code, especially if it's FOSS, should be suspect. Either they have something to hide, or they're a shitty programmer. Either way, I don't want their code on my hardware.
Re:Native features in browser (Score:5, Interesting)
Reminds me of a line in Doctor Who's last season:
Amy: You don't always tell me the truth.
The Doctor: If I always told you the truth, I wouldn't have to ask you to trust me.
Trust is not a state of absolute certainty or God-like understanding. In the end, it's a process of establishing your own comfort. You have to decide which risks matter to you personally, and which assurances are sufficient.
Trying to guarantee that every component and piece of software in a computer is "benign" to everyone is a fruitless, endless process.
But I certainly appreciate the complications you bring up. In the final analysis, all trust must be conditional, and revocable.
--
Toro
Re:Native features in browser (Score:3, Interesting)
I like most people as well!
The only issue with Opera is that they keep adding retarded things like BitTorrent downloading and built in web servers. It also doesn't help that they try to change the entire UI with every milestone.
I still don't see myself switching away any time soon.
To perfect this hack... (Score:5, Interesting)
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.
Re:Native features in browser (Score:5, Interesting)
LOL
Extension of trust works as follows:
If you trust Bob, and Bob trusts Alice, you trust Alice.
However, no one ever fully trusts Bob.
So, more explicitly, extension of trust is as follows:
If you trust Bob to a degree, and Bob trusts Alice, you trust Alice to the same degree that you trust Bob.
But this is incorrect as well. Because Bob's trust relationship with Alice is also "to a degree". Let's try this again:
If you trust Bob to a degree, and Bob trusts Alice, you trust Alice only to the product of the two degrees.
Trust does degrade with each step in the relationship chain.
One of the most common "degrees" of trust is a restriction on forwarding that trust. We never actually "trust" Bob, we simply authorize him (as a supplier of code, a maintainer of data, etc.) to access our shit because we need to get shit done. The "trust" relationship is not freely given - privacy and access are sold in exchange for access to various services.
Thus, the degree of trust in an actual relationship is not a measure of actual trust, but a measure of what you are willing to risk.
The claim against the "you can only trust yourself" argument is that if you trust Bob, you must trust Alice in the same manner, because you are trusting Bob's integrity (who he chooses to trust). The claim is bullshit, because we never "trust" Bob - we simply accept a certain level of risk, and built into our threshold of acceptable risk is the restrictions on who Bob can extend that trust to.
The bottom line is that we can indeed choose to trust Bob completely and choose to not trust Alice at all. This is because the "trust" relationship is never actually based on trust - it is based on risk.
Re:wait, add-ons don't have a permissions model? (Score:3, Interesting)
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 meaningful permissions scheme to extensions that modify web pages is difficult or impossible in practice(unless you are willing to accept amounts of permission confirmation windows that would make a hardened noscript user cry).
Control over local program execution, local filesystem access, and local GUI are all quite doable; because those all consist of easily knowable, and known, sets of objects.
The trouble, is with web pages:
"Permission to modify headers- which headers" Ok, this wouldn't be too bad for some site-specific anti-nuisance plugin(assuming the site's design doesn't change unexpectedly, and break the plugin, or change frequently and habituate the user to accepting any demand for changes a plugin makes); but it doesn't help you too much for site-generic plugins(like the security testing tool in TFA, whose features pretty much include "modify any header on any site, at the user's direction" and secretly included a silent added header.)
Worse, since a fair few pages, in our Web 2.0 age, do a lot of sending and receiving on their own behalf, much of it script driven. This would mean that, in effect, on many domains, permission to modify scripts would imply permission to communicate more or less arbitrarily, just by making the web page communicate for you.
The other problem, with something like a web page, is that the line between "content"(HTML) "style"(CSS), and "scripts"(JS) might be fairly bright programmatically, in terms of the visual result that the user ends up interacting with, it gets pretty fuzzy. Even assuming freedom from sanitization failures and injection attacks, a malicious program that can "just" manipulate the CSS can pull some pretty crazy stunts with a fair few web pages. Now, there is nothing stopping you from having privilege granularity going all the way down to individual CSS elements(or even relationships between elements, say to keep a malicious extension from hiding foreground text by making it the same color as the background); but that would mean that any user would have to be a reasonably serious web developer just to comprehend the permissions list, much less know what is dangerous and what isn't.
Re:Native features in browser (Score:2, Interesting)
Having a History function is retarded. If you don't know which sites you've been to then you have some serious mental issues that you should have investigated. If Opera took those functions out and added them to their site under a plug-ins section then people who don't have Alzheimer's could have a nice lightweight browser.
Despite your retarded attitude, most people do, in fact, only visit a few sites with short, easy to remember, URLs. If someone wants some bookmarks, because he is mildly advanced compared to the rest of the public, he can go to the Opera site and click on the link which will load the small code into the browser.
Re:Native features in browser (Score:3, Interesting)
Re:Native features in browser (Score:3, Interesting)