If they are taking the 'drastic' step of bringing everything offline, how about banning future internet explorer use in all sensitive areas. Chrome would provide much better security thanks to its update mechanism. Any workplace still using this abomination is just begging to be hacked.
Is Chrome be subject to being used as a malware delivery vector if you could MITM the DNS? Or does its SSL pinning prevent that (presuming that the updates happen over SSL)?
Interesting.. theoretically SSL should prevent MITM of this kind. But if you are able to redirect at DNS level, probably you can deliver your own certificate and its authority.
I don't see how DNS MiTM is going to subvert the basic math of public key crypto. Even if the browser is implementing its own SSL stack, it would have access to validate those keys against those that ship with the OS. This SSL pinning seems to be something outside the crypto mechanism. It's flair.
Creating a phony certificate is much harder -- or at least by design it's supposed to be much harder -- than DNS redirection/spoofing. So there's not a "if you can do one you can probably do the other" kind of threat-equality.
However, given how many Certificate Authorities have been flaky, compromised, or deferential to certain unsavory authorities, there probably are some actors who could launch both kinds of attacks.
I expect both Google and Microsoft use some private mechanism for authenticating their updates, perhaps SSL but not dependent on any Certificate Authorities or secrets other than those they manage themselves. Pressure from some state authorities, or catastrophic failures in these companies' own security, could give some other malicious actor the power to hijack these updates. But that should be again harder than either DNS subversion or finding/compromising the weakest browser-trusted CA.
(When Google suddenly became so mad at China a while back, my favorite theory -- wholly unsupported by any confirmed info, however -- was that Google had observed China's incursions trying to win control of the various Google auto-update mechanisms. Third-party malware injection via those avenues might threaten Google's very existence, which would justify the strongest possible reaction, in the name of self-preservation.)
Here's the thing, network security needs to be balanced against organizational operations. Internet Explorer has been sold to organizations as a platform where thin client applications can be deployed cheaply. Internet Explorer doesn't update automatically because the last thing Microsoft wants to do to their clients is break all of their web apps through an untested update. Security updates also need to have backwards compatibility, or large firms won't upgrade, since their web apps might break.
Security and usability are at odds. Large organizations (thus far) tend to favor usability. It's a cost-benefit analysis, and the benefit of not redeveloping their web apps outweighs the cost of increasing security.
Considering the type of work that goes on at Oak Ridge, I'm not so sure they correctly calculated the true cost of using Windows and Internet Explorer....
I'm not sure they (or any other really high-risk security company) calculated the true cost of connecting their network to the internet at all. A really simple, effective way of protecting sensitive data is to say that the network that hosts it will have absolutely no path outside. Then give your employee another machine on the same desk which connects to the internet but is on a completely network.
It's annoying at first, but it works pretty damned well.
If their applications break because of an upgrade of IE (or even if the apps doesn't work with a different browser/operating system), I'm not sure their problem is with security.
It's true that after the attackers got the entry point, there are several thing wrong according to article (ie. "Four days after the e-mails arrived, administrators spotted suspicious traffic leaving a server." -- so they got a mail that used an IE vulnerability, and then a server got affected?).
Sure, once the attacker gains a foothold, targeting servers from inside the network is certainly possible, especially if the infected user has significant permissions on the network.
I've had chrome updates that broke working standards-compliant code. There's some truth to IE stability between minor releases. The problem is that every major release of IE so far has required big changes (usually to take out IE-specific code). What they win on minor updates, they squander on the major ones. Chrome and firefox haven't had that much of migration pain in years.
Not only that, but also active directory,which requires a window server, which requires a special dns thing, which almost requires a dns serviced by windows. An endless chain of turds...
> On Apr. 7, 2011, five days before Microsoft patched a critical zero-day vulnerability in Internet Explorer that had been publicly disclosed three months earlier on a security mailing list
I don't think "zero-day" means what you think it means.
"zero-day" doesn't mean what it means any more. Today it means only "unpached security hole", full stop. Sadly, a lot of security terminology use has tended more towards the desire to provide a titillating story than to accurately portray facts.
Zero-day was coined to describe malware being found in the wild that exploits a previously unknown vulnerability. The terminology is literally referring to there being zero days between discovery of a vulnerability and discovery of malware in the wild that exploits it.
They are prized in the black hat community specifically because they've never been disclosed and thus no-one has had any chance to patch the vulnerability.
In this case the vulnerability was known and unpatched for three months. It was more like a 90-day exploit than a 0-day exploit.
That's not correct. We found and traded 0day exploits (referring to them as 0day at the time) on irc long before malware was exploiting it. Malware using 0day is a very new thing, and the advent of that certainly isn't when the term was coined. The term actually originates in the warez scene, referring to the days prior to RTM of some software. It was adopted in the hacker scene in the early 90s.
And that doesn't make sense anyway. It was obviously known to someone if malware was written. These aren't found and written by skynet. I've been around since about as long as the term was used, and long before the media used it, and it was universally understood to mean something that wasn't patched. Over time, more and more people would know about the 0day. So what number are you using for "unknown"? 1 person knows about it? A hacker group? 2 hacker groups, because one of them stole it from the other? Or is that semi-0day?
The zero days is between when it exists and when it is patched, even if it ends up on full disclosure or bugtraq. When it did hit a list, its status goes from "private" to "public", but this is orthogonal to its 0day status.
Ask tptacek, he was around back then ;) According to that nytimes article, comex is 20 +/- 1 year, so I forgive him ;)
> "The term actually originates in the warez scene"
A full etymology would certainly be interesting, but I was trying to stick to the subject matter at hand.
> "It was obviously known to someone if malware was written."
Again, in the context of security, 'known' -- at least as far as I've ever heard it used -- is shorthand for known to the security-minded public and/or to the vendor. It could be known to a million black-hats writing a million exploits and that still counts as 'unknown' until the day someone discloses it to the wider public and/or the vendor.
"A full etymology would certainly be interesting, but I was trying to stick to the subject matter at hand."
The point is that you said it was "coined" to describe malware usage. In fact that was neither the first use of the term in this context, nor where the term originated at all.
28 comments
[ 0.32 ms ] story [ 79.2 ms ] threadHowever, given how many Certificate Authorities have been flaky, compromised, or deferential to certain unsavory authorities, there probably are some actors who could launch both kinds of attacks.
I expect both Google and Microsoft use some private mechanism for authenticating their updates, perhaps SSL but not dependent on any Certificate Authorities or secrets other than those they manage themselves. Pressure from some state authorities, or catastrophic failures in these companies' own security, could give some other malicious actor the power to hijack these updates. But that should be again harder than either DNS subversion or finding/compromising the weakest browser-trusted CA.
(When Google suddenly became so mad at China a while back, my favorite theory -- wholly unsupported by any confirmed info, however -- was that Google had observed China's incursions trying to win control of the various Google auto-update mechanisms. Third-party malware injection via those avenues might threaten Google's very existence, which would justify the strongest possible reaction, in the name of self-preservation.)
SSL pinning just prevents a rogue trusted CA from MITMing you. SSL certificates specify a domain, no matter what the DNS says.
Security and usability are at odds. Large organizations (thus far) tend to favor usability. It's a cost-benefit analysis, and the benefit of not redeveloping their web apps outweighs the cost of increasing security.
It's annoying at first, but it works pretty damned well.
It's true that after the attackers got the entry point, there are several thing wrong according to article (ie. "Four days after the e-mails arrived, administrators spotted suspicious traffic leaving a server." -- so they got a mail that used an IE vulnerability, and then a server got affected?).
How much information does a commercial company selling a product or service have to keep secret?
* User details
* Future plans that might affect customers or employees
* 'Secret Sauce' stuff like code if it is closed source or plans &c
What else?
I think companies should put more effort into looking for ways how to provide service without gathering and storing user details.
Examples being lastpass and various storage services that can't access filess you keep at their machines.
I don't think "zero-day" means what you think it means.
They are prized in the black hat community specifically because they've never been disclosed and thus no-one has had any chance to patch the vulnerability.
In this case the vulnerability was known and unpatched for three months. It was more like a 90-day exploit than a 0-day exploit.
And that doesn't make sense anyway. It was obviously known to someone if malware was written. These aren't found and written by skynet. I've been around since about as long as the term was used, and long before the media used it, and it was universally understood to mean something that wasn't patched. Over time, more and more people would know about the 0day. So what number are you using for "unknown"? 1 person knows about it? A hacker group? 2 hacker groups, because one of them stole it from the other? Or is that semi-0day?
The zero days is between when it exists and when it is patched, even if it ends up on full disclosure or bugtraq. When it did hit a list, its status goes from "private" to "public", but this is orthogonal to its 0day status.
Ask tptacek, he was around back then ;) According to that nytimes article, comex is 20 +/- 1 year, so I forgive him ;)
A full etymology would certainly be interesting, but I was trying to stick to the subject matter at hand.
> "It was obviously known to someone if malware was written."
Again, in the context of security, 'known' -- at least as far as I've ever heard it used -- is shorthand for known to the security-minded public and/or to the vendor. It could be known to a million black-hats writing a million exploits and that still counts as 'unknown' until the day someone discloses it to the wider public and/or the vendor.
The point is that you said it was "coined" to describe malware usage. In fact that was neither the first use of the term in this context, nor where the term originated at all.