Slashdot Mirror
Hackers Steal Opera-Signed Certificate Through Infrastructure Attack
wiredmikey writes "Norwegian browser maker Opera Software has confirmed that a targeted internal network infrastructure attack led to the theft of a code signing certificate that was used to sign malware. 'The current evidence suggests a limited impact. The attackers were able to obtain at least one old and expired Opera code signing certificate, which they have used to sign some malware. This has allowed them to distribute malicious software which incorrectly appears to have been published by Opera Software, or appears to be the Opera browser,' Opera warned in a brief advisory. The Opera breach signals a growing shift by organized hacking groups to target the internal infrastructure network at big companies that provide client side software to millions of end users."
Does this really signal a growing shift? Or are we just saying that whatever happens in a news story must signal a "growing shift" toward that thing to induce widespread panic?
Microsoft Update?
Operation Guillotine is in effect.
Whenever the topic of security comes up, there are always a bunch of people who go on and on and on about how certificates are always the answer to security problems.
How do we fix security problems with email? "Certificates!", they say.
How do we fix security problems with HTTP? "Certificates!", they blurt out.
How do we fix security problems with DNS? "Certificates!", they scream.
How do we fix security problems with passwords? "Certificates!", they yell.
How do we fix security problems with application executables? "Certificates!", they exclaim.
Yet we see so many stories about certificates getting compromised in one way or another. And then the infrastructure surrounding them is always so goddamn awful. They cause just as many, if not more, problems than they actually manage to partially solve.
It's time for the certificate advocates to stop and think. They need to look at the big picture. They need to realize that while certificates may have their place in some very specialized situations, they are not the ultimate solution that we so desperately need.
Alls they have to do is search for the intercept with the headline: "The fat lady has sung."
The problem is that implementations that are checking the certificate are not requiring third party authenticated signing timestamps.
If the implementations checking certificates required a trusted root signed timestamp with the digital signature in any of those implementations, then expired certificates would be useless.
Certificates can be compromised, but they are far better than passwords people use.
There has yet to be an actual problem with certificates, just bad implementations.
I would love for you to point me at some software that has never had any implementation faults.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
A workers soviet America will give them the honors they deserve!
Nobody sane wants that. It would kill too many workers.
There will always be people who want to commit crimes of theft.
However, we can thin their ranks a bit. Support the death penalty for cyberthieves (at least in Texas).
Futurist Traditionalism
Well of course, this only affects people that would run software signed by Opera and they have already taken steps to notify both of them of the situation.
and doing it in ASL was never a real improvement
I don't know much about intrusion detection but how would someone go about detecting what was taken? How do you detect someone copying data from somewhere? It seems like data is only being read which would be more difficult to detect than data being written over or being deleted which could be detected. Does anyone have any insight how you would detect an intrusion?
if bad guys are doing it, the governments are doing it.
the whole idea of SSL is based around the trust of the certificate and signing infrastructure. it is a growing shift away from the assumption that SSL=safe+secure when shit like this keeps happening over and over.
We have Snowden cyber attack leak and his claims NSA was behind thousands of cyber attacks including the Chinese University.
http://www.guardian.co.uk/world/2013/jun/13/snowden-revelations-nsa-china-relations
We also have the leaked memo from the President authorizing it:
http://www.guardian.co.uk/world/interactive/2013/jun/07/obama-cyber-directive-full-text
The NSA *are* the 800lb gorilla in cyber attacks, a few script kiddies don't have a $4 billion cyber budget the NSA has. So the question comes back to, a simple one. "Are we sure this wasn't the NSA operation to sign malware?". Like Stuxnet was some super clever worm, only later it turned out to be targetted at Iran reactors and probably made by the NSA. If they did Stuxnet, it's likely they did many others and breaking into to database is one of the possibles listed in the Presidents authorization.
Perhaps if people took better care of private keys, this wouldn't bloody happen at all.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Reading the advisory from Opera, the only information on the possible consequences of the breach is that :-
Are users of other OSes similarly exposed to malicious software, such as those using Mac, Lunix, Android or iOS?
For a company that just laid off most of its developers and resigned itself to being a rebranded Google Chrome, this cannot be coincidental.
The only vestige of any use from the former Opera Software is Fastmail.fm, and the developers struggle mightily to keep that branch as separate as possible from the Mother Ship.
Now this cert-signing issue, which on the surface seems petty, but signals a larger problem of a lack of focus on security and a neglected infrastructure. Layoffs will do that. I'm curious if Opera discovered the stolen Cert on their own or if it was reported to them, and how long it was compromised before revoked.
This is not the first sign that Opera is dead, but the bad news keeps piling on for this company. First the loss of mobile space due to actual smart phones, then the dropping of support for non-Windows PCs and non-Android smartphones, rumors rampant of a Facebook/someone else takeover, throwing away fifteen years of incremental browser improvement to become a Chrome skin (and thus breaking services like Opera Link), etc. Opera is DOOMED.
Did you recently ...
- copy any html codes from someone else's website?
- save any pictures or files from the web?
- cut and paste an article or link it to a friend?
- take any screenshots of any interesting pages you found?
- download any movies, music or porn?
Congrats, you may be a cyberthief. This way please, for your appointment with Mr. Noose.
Whenever the topic of security comes up, there are always a bunch of people who go on and on and on about how certificates are always the answer to security problems.
How do we fix security problems with email? "Certificates!", they say.
How do we fix security problems with HTTP? "Certificates!", they blurt out.
How do we fix security problems with DNS? "Certificates!", they scream.
How do we fix security problems with passwords? "Certificates!", they yell.
How do we fix security problems with application executables? "Certificates!", they exclaim.
Yet we see so many stories about certificates getting compromised in one way or another. And then the infrastructure surrounding them is always so goddamn awful. They cause just as many, if not more, problems than they actually manage to partially solve.
It's time for the certificate advocates to stop and think. They need to look at the big picture. They need to realize that while certificates may have their place in some very specialized situations, they are not the ultimate solution that we so desperately need.
Are you saying "certificate" when you mean "PKI"?
This might be taken as evidence that you know very little about security...
Opera is not the first nor the last victim of certificate theft. There is evidence that the use of digitally signed malware is increasing since the Stuxnet incident gave this attack vector worldwide exposure.
Also, unless I'm mistaken, revoking stolen certificates do not prevent malware signed with it from running. Most casual users I think tend to trust certificates (that is what it's for, after all, to certify that its from a trusted source). Not many will bother to check the authenticity of the certificate.
It might be premature to talk about its impact being limited until the full scope of the intrusion and loss of data is made known, and the number of users affected by the intrusion (not disclosed so far).
We could have encrypted email tomorrow if it didn't require a signing authority to issue a certificate!
Nothing stops a computer generating a public/private key pair, an email client like Thunderbird could do it tomorrow. Nothing stops it sending the public key in the header of sent messages, and collecting those public keys as it goes along.
First time you get a public key from an email that you trust, the key is accepted, and tracked. If you have a public key... send it encrypted using the public key to that email address. If you get a different key from that email address, warn user of possible man in middle attack (either with new key or previous key).
Certificates are not secure, any spying agency with access to a certificate authority can issue themselves fake certs and perform man in the middle attacks. Since many signing authorities are in the USA, they are subject to the secret FISA court and thus cannot be trusted anymore than the FISA court can (i.e. demonstrably not at all).
SSH currently will do a key exchange using the first-time approach without a certification authority and we should use the same system for end to end email encryption.
> It's time for the certificate advocates to stop and think. They need to look at the big picture. They need to realize that while certificates may have their place
> in some very specialized situations, they are not the ultimate solution that we so desperately need.
If you're really convinced that the certificate people don't have a clue, then why are you asking *them* to fix the problem?
Most casual users I think tend to trust certificates (that is what it's for, after all, to certify that its from a trusted source). Not many will bother to check the authenticity of the certificate.
This is why God created CRLs. That's actually what happened to the dinosaurs: they got revoked.
He probably had a hand in it.
That's right, cyber criminals must be made to eschew all technology post-1800 and be consigned to an Amish paradise for life and have sex with real women. No more computers, microwave ovens and clothes with buttons and zippers. Oh, and they have to go to Church too.
"SO we bide our time, waiting for a purer kick to bloom and the future is still bleak, uncertain and beautiful" -GSYBE
Witness the "HACKURS DID IT" headline, which is quite at odds with the careful press release.
This is one case where I'd rather read the press release --notoriously full of CYA mealy-mouthed unreadable word salad-- than even the headline some ham-fisted hack came up with. On a self-described so-called "tech savvy" site, no less.
There are three things that I don't believe you:
(1) Dancing (2) Girl (3) Club
I was using opera at that time and haven't received anything... I feel cheated now.
My SSH client warns me when the fingerprint changes. It TRACKS the PRIOR fingerprints. It's happened once, SSH Client warned me. I suspect local hackers trying to gain a server, but never did resolve where the line had been intercepted and the problem went away the next day, the key was back and I could connect. [Silly me, I was looking at *my* end, I never thought that the basic infrastructure of American telecoms had been hacked by criminals in uniforms.]
Anyway the point being that the change of key IS NOTIFIED, the user IS aware of man in the middle attacks, and the NSA would have had to do a MITM attack on the FIRST key exchange to do their illegal interception of email unnoticed.
The current CA system does not work, IS NOT USED, IS NOT USABLE, emails are sent unencrypted and EVERY email you assume its from the person who sent it, but it is totally vulnerable to spoofing. So your decision that the email from fred@blogs.com is really fred@blogs.com is your choice, you can choose to accept that first key exchange or reject it. But this is the same decision you are always making anyway with the content.
With the key, you know this is the same fred@blogs.com you've been talking to since years, not creep@nsa.dictator.mil undermining America.
This works for SSH, it protected my connection from malicious actors. It can work for mail too, even politicians, even press, even ordinary people.
"What would also need to be added to your proposal is to supplement with SRP or other secure password system that allows two users to easily exchange relatively insecure passwords out of band to verify the exchanged verifier. This also applies to SSH, especially when remotely connected to a box under your direct control."
No, not at all. You trust the message content is from Bob, ergo so must the key be from Bob.
You could for example publish your email address in a format that includes the public key. So users clicking on an email link on a webpage automatically get the secure key. For example a bank might publish the email address on its https website, it contains a mailto tag
[a href="mailo:no-one@test.com+publickey:fwefiuwhefiuwheiuhw3o3joid9323dsijfoioijqwif.."]example[/A]
If the website is secure then so is the public key exchange.
If you are a journalist, politician or law enforcement and need more secure email, you can always pass the first key via a more secure route. But even if its passed via a https website link, its as good as a certificate exchange is now.
But that brings up back to the main point. Email IS NOT encrypted because the certificates system does not work, is cumbersome, and is subject to NSA man in the middle attacks at any time anyway!
A key revoke is an unencrypted email negotiation the same as the first one. Only now you're suspicious, and can ring them to check, or contact them some other way... as it is, you have to check each and every discussion. You don't hand any 'trusted' third party the key exchange because 'third parties' are inherently subject to a secret court order from a secret court.
Yes, but its more like PGP that automatically upgrades to encryption on the first key exchange.
A few of us will use Thunderbird and recommend it to our friends, as they in turn use Thunderbird, so that link will be encrypted and as it spreads so the encryption network spreads with it. Constitutional protection is restored, right to privacy back, democracy protected... all good stuff without any issues.
Webmail is inherently unsafe, you have to trust Hotmail or Gmail or Yahoomail , those accounts could also publish keys, but the link would only be secure up to their accounts. Because they'd hold the private portion of the key. Even then, that's better than the current situation.
All they do now is recompile Chromium with their branding.
Who logs in to gdm? Not I, said the duck.
Are you saying "trees" when you mean "forest"?
The problem is that implementations that are checking the certificate are not requiring third party authenticated signing timestamps.
There you go again, "if only the technology...". The rest of your comment is mostly tu quoque arguments and other fallacies. That is, you're talking bullshit.
NO. Just NO. The problem with certificates is much deeper than that, and starts with the premise of the certificate issuers: They'll protect you from anyone they won't take money from. This being commercial entities. It goes downhill from there.
The problem isn't with the two guys that run Opera, it's with the other two guys that thought what they downloaded and installed was Opera. Opera has no idea who those other two guys are, so they need Slashdot's help in getting the word out fast.
i'm wondering about "The only effect of the revoke process is that the bad guys will not be able to sign any further malware with it." in the cited article. how would revocation prevent further signing ?
using crl would (should ?) prevent signed software from working, but signing with a key already in somebody's possession wouldn't be impacted
Rich
The problem with code signing certificates though is what should the validate rule actually be? Should an executable no longer be considered trusted when the cert expires?
I bet certain segments of the software industry would love that. Talk about planed obsolesce.
Maybe the binary should be trusted as long as the create or modify dates are prior to the certificates expiry?
This wont do anything because anyone sophisticated enough to create malware can just manipulate the date stamps before signing.
I know OCSP! We will just do revocation checks every time.
Again certain segments of the software industry would love this. It would empower them to decide when your software no longer works. No you can't just check once, malware authors would just have stuff sleep for awhile, and the CA or signer may not know they have had a breach. After all something like 60% of commercial breaches we reported by 3rd parties last year.
Then there are the privacy implications of doing a revocation check everytime you run some code.
The certificate trust model just does not work for software
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
You forgot one:
How do we fix security problem with certificates? "Certificates!", they squeal with the heads exploding.
They need to realize that while certificates may have their place in some very specialized situations, they are not the ultimate solution that we so desperately need.
Certificates!
Clearly the solution is to sign these old certificates with new certificates so that they become more secure.
In this instance it is critical to differentiate, certificates have not been broken/compromised at all, underlying implementations of the infrastructure and the people handling that infrastructure have been compromised or broken. Certificates in general are an excellent solution to many security issues, however it does require good PKI infrastructure and management otherwise they are pointless. For many of their uses you don't even need to trust or rely on any external authority, you can run your own which no fukker has access to except those you specifically grant access and trust, for instance we run a PKI infrastructure where I work, not exposed to the internet and the CA itself is segregated off and heavily secured. We rely on no external party.
What are you blabbering about? If I have a policy on my domain to allow executables signed with certificates where the software publisher is Adobe, Oracle, Microsoft, Apple, etc., no one is going to be able to get pass that barrier without stealing private keys from Adobe, Oracle, Microsoft, etc. (which is the same "weakness" for every single security protocol in existence or has ever existed anywhere at anytime or will exist anytime in the near future)
Why are you disproving claims of idiots? Nobody sane has ever held a position that certificates are the silver bullet for security or anything else. Like every single thing in life, protecting something of value is a never ending arms race..
Want to cheat at a sport? Arms race between people making designer drugs and people making testing protocols to detect them.
Want to kill someone? Arms race between people designing security protocols and people with high tech weaponry/low tech bribing, etc.
How do we fix security problems with Certitficates? "Certificates!", they drunkenly mumble..
Some people, such as a PlayStation fan on Slashdot who will remain nameless, would argue that a barrier to entry is a good thing. It ensures that anybody who wants to distribute software to the public is serious about creating quality software. It's a fallacy, but like other fallacies, appeal to accomplishment springs from a heuristic: companies that have successfully published quality works in the past are more likely to publish quality works in the future. The example he likes to trot out is the North American video game recession of 1983, when there was so much shovelware crap on store shelves that neither players nor retailers could find which 2600 games were worthwhile. The North American market pretty much abandoned video games until the fourth quarter of 1985 when Nintendo added a lockout chip to its new Nintendo Entertainment System to assure retailers that only games that Nintendo had evaluated for a certain baseline quality level would be allowed to run.
That's just great! Now all of those snooty Opera users will be able to brag about having another feature before all of the other browsers.
no one is going to be able to get pass that barrier without stealing private keys from Adobe, Oracle, Microsoft, etc.
So how should a legitimate software developer get its publisher certificate into your domain's "etc." list?
First time you get a public key from an email that you trust
How should one decide to trust a particular e-mail? The sender can spoof the From address.
SSH currently will do a key exchange using the first-time approach without a certification authority
Your SSH connection could be MITM'd from day one and you might not notice it.
Apart from platforms that use OpenPGP, such as .deb-based GNU/Linux platforms, each platform has a separate signing certificate. OS X has its own, Android has its own, iOS has its own, and Windows has two: Authenticode for desktop applications and the Windows Store developer license for immersive applications. For small developers, it's a hassle to keep all of them renewed, but for companies big enough to draw targeted attacks like this, it's a benefit.
They have signed third-party timestamps. We use them for email so that way people claim that the email was faked as easily. Just have one generated when you sign the executable and as long as the all four combinations of timestamp and certificates are valid the stamp is good. Likewise, you have to look for any revocation through OCSP or a CRL.
The problem is that implementations that are checking the certificate are not requiring third party authenticated signing timestamps.
Actually, one of the most prominent implementations does exactly that. It's Windows Kernel Code signing.
you could communicate a key id over another channel, (in person, via phone, mail, etc)
But what providers of shared hosting or a virtual private server are willing to do this for a customer? I've asked the tech support departments of a few such hosts, and the answer was "Just say yes to whatever key fingerprint your SSH client shows."
They paid so much for the certificate would it really be that costly to them to keep the private key on a machine not connected to a network?
That's not true at all. They have made their own user interface on top of Chromium.
Clever signature text goes here.
So they are UI company now. Still not a browser company,
Who logs in to gdm? Not I, said the duck.
No, they are still a browser company. They are even contributing to Webkit (now Blink). Anyway, you should at least admit that the claim you made turned out to be false.
Clever signature text goes here.
Its not false and it wont be false until I can right click in Opera >=15 and see "edit site preferences"
Who logs in to gdm? Not I, said the duck.
So if they removed that option from Opera 12, they would no longer be a browser company? That setting is what defines a browser company? Come on... you are making a fool of yourself
Admit it, you messed up. You claimed that all they do is to recompile Chromium, which is wrong since they've made their own UI. You then admitted that you were wrong but now insisted that they were just a UI company. I then pointed out that they are contributing to Webkit/Blink, and now you're just trying to change the subject.
Clever signature text goes here.
But they didnt remove anything. They STOPPED MAKING browsers. Now they take Chromium codebase, add their skin and call it a day.
As a user I dont care about them contributing to some rendering engine if the end product is no longer a browser I was using.
Who logs in to gdm? Not I, said the duck.
You are extremely confused. That it's not the same browser you were using still doesn't mean they stopped making browsers. Are you trolling?
Again: You claimed that all they do is to recompile Chromium, which is wrong since they've made their own UI. You then admitted that you were wrong but now insisted that they were just a UI company. I then pointed out that they are contributing to Webkit/Blink, and now you're just trying to change the subject.
Now you repeat a claim you know is false (that they just add a skin). That's called a lie. Consciously posting a false claim is called lying. You are a liar.
You also didn't answer the question about removing that option from Opera 12.
Clever signature text goes here.
You are boring and arguing for the sake of arguing.
Opera made innovative fully customizable browser. Now they are just google's bitch making clone of Chrome.
Who logs in to gdm? Not I, said the duck.
You keep changing your claims.
You first claimed that all they do is to recompile Chromium, which is wrong since they've made their own UI. You then admitted that you were wrong but now insisted that they were just a UI company. I then pointed out that they are contributing to Webkit/Blink, and you changed your claim to Opera only making a skin, which is obviously wrong again since they coded their own UI.
Now you've moved the goalpost again. This is getting pathetic.
Of course, your latest claim is demonstrably false as well, since they made their own UI and are adding all sorts of features that don't exist in Chrome.
Now, since your claims are mutually exclusive you have really revealed yourself as a liar and a troll.
You also didn't answer the question about removing that option from Opera 12.
Clever signature text goes here.