Has the NSA Been Using the Heartbleed Bug?(wired.com)
wired.com
Has the NSA Been Using the Heartbleed Bug?
http://www.wired.com/2014/04/nsa-heartbleed/
22 comments
I mostly agree with this analysis - "this hole is too big for them to have sat on". Though it just occurred to me - it's possible to pick out exploit of this hole in captured encrypted traffic by examining sizes of inbound vs outbound heartbeat packets, right? In that case, with the NSA eavesdropping on everything they could possibly have been using it themselves while listening for examples of anyone else using it, which I still don't like (in terms of approval or likelihoods) but seems less flagrantly unacceptable than sitting on this and just leaving everyone's traffic and keys exposed to the world.
Uhm, as NSA and other agencies are responsible for "secure" internal comm, they have methods for that. Sometimes they get broken, probably, but thats their mission to find out, and sometimes let the enemy continue thinking their breakin is effective.
Its the same methods as in 1940, that is, classic intel methods.
Security does not just mean strong crypto algorithms.
If you find your enemy has found a flaw in openssl or some other methods which you are using to communicate - the best way forward is to continue using that - keep the enemy thinking its all good information when its in fact worthless, and move to another method for the real secure stuff, such as steganography or pidgeons.
Anyway, there probably isnt much "really highly, this kills the cat"-type of information goin on the internets, I guess one point of NSA would also be to keep highly classified information to a minimum. Think thats one reason why Navy and others have their own networks parallel to the internet. Where much secrets flow - isolate.
Its the same methods as in 1940, that is, classic intel methods.
Security does not just mean strong crypto algorithms.
If you find your enemy has found a flaw in openssl or some other methods which you are using to communicate - the best way forward is to continue using that - keep the enemy thinking its all good information when its in fact worthless, and move to another method for the real secure stuff, such as steganography or pidgeons.
Anyway, there probably isnt much "really highly, this kills the cat"-type of information goin on the internets, I guess one point of NSA would also be to keep highly classified information to a minimum. Think thats one reason why Navy and others have their own networks parallel to the internet. Where much secrets flow - isolate.
These are fair points, but I think the GP comment above was referring as much to political economy type espionage.
Say, for example, china wants to spy on a military contractor. Unless the NSA is sharing its secure pigeon network with every US defense contractor (and many of them, large and small) some pretty important US national security assets might be in play. So, perhaps not "state secrets" but things like technology inside of some tactical weapons guidance systems, or similar. The downside for the NSA of sharing any secret-pigeon networks would op-sec goes down as info dispersal goes up.
* Also for companies like a tesla or a space-x who may have purely industrial know how.
Say, for example, china wants to spy on a military contractor. Unless the NSA is sharing its secure pigeon network with every US defense contractor (and many of them, large and small) some pretty important US national security assets might be in play. So, perhaps not "state secrets" but things like technology inside of some tactical weapons guidance systems, or similar. The downside for the NSA of sharing any secret-pigeon networks would op-sec goes down as info dispersal goes up.
* Also for companies like a tesla or a space-x who may have purely industrial know how.
Tactical weapons guidance systems, tesla and space-x, I believe those are in the category of "NSA will secure this with a bit more tools than given to the public as recommendations".
It could be methods like increasing security for those companies gmail accounts - on the Google internal network and all, closing all normal backdoors on Tesla employee computers, installing NSAs own intrusion detection system on them and such.
And to top it off, feed any Chinese and Russian hackers misinformation through honeypots and "accidents".
In Sweden for example during cold war it was quite popular to install extra instrumentation on jets and provide "just for the soviets" technical documentation - seed confusion and such.
It could be methods like increasing security for those companies gmail accounts - on the Google internal network and all, closing all normal backdoors on Tesla employee computers, installing NSAs own intrusion detection system on them and such.
And to top it off, feed any Chinese and Russian hackers misinformation through honeypots and "accidents".
In Sweden for example during cold war it was quite popular to install extra instrumentation on jets and provide "just for the soviets" technical documentation - seed confusion and such.
The NSA has been squirreling away tons of intercepted https traffic. A week ago it would have seemed as if they were doing so in the hopes of future changes. Either cryptographic advacements, or private keys revealed due to intrusion or court order or what-have-you. Even so it seemed a remarkably weird thing to do. Today, in the light of heartbleed it makes perfect sense, and I think the idea that the NSA has been ubiquitously making use of the vulnerability has to be on at least even footing with the alternative.
For the sake of argument, swap out 'NSA' for any large state actor - it's silly to ask this specifically of the NSA and most of the attention is around them because of the Snowden leaks.
Now, would a large state actor involved in offensive black hat hacking have known of heartbleed? I think the answer is likely yes.
Any decently funded team with a dozen good auditors to commit to the project would be watching popular open source projects like openssl, linux, chromium, firefox, apache, nginx, gnupg, openssh, boost, gmp, berkeley db, qt, gtk, etc.
For this part of the project, you only have to grep for low hanging fruit in each new patch that is released for each project, that is usage of: gets, scanf, strncpy, strncat, memcpy etc (or the equivalents for each project that has wrappers or handling functions).
Any large state actor with any decent team running such a project would have discovered heartbleed within days of it being committed. They also would have discovered a lot of other bugs that we either don't know about yet or have fixed.
With heartbleed the state actors are kicking themselves either way: either because they didn't know about the bug and missed it, or they did know about the bug and now can no longer use it as effectively.
"They" (and you can include black hat groups that don't disclose in this as well) combined likely have more resources dedicated to uncovering these bugs than what the open community does, and it might be an order of magnitude larger.
When you think about this further, you realize that the state actors having discovered heartbleed or not doesn't matter - what does matter is that they do have a lot of exploits that we don't know about and it has been confirmed that they are not only looking for these bugs and have a lot of people working on it, but are actively discovering them, using them and purchasing them on the market.
The response to this shouldn't be heartbleed specific - it should be what do "we" do to stop "them" from discovering and using exploits from open source and projects. There needs to be a heck of a lot more effort or a whole new approach to defeat the level resources that are out there dedicated to uncovering and not disclosing these exploits.
The best thing that could have happen did happen: heartbleed was discovered and it was disclosed, and a hell of a lot of people are now more aware of just how frail some of this infrastructure is and what the risks are.
Now, would a large state actor involved in offensive black hat hacking have known of heartbleed? I think the answer is likely yes.
Any decently funded team with a dozen good auditors to commit to the project would be watching popular open source projects like openssl, linux, chromium, firefox, apache, nginx, gnupg, openssh, boost, gmp, berkeley db, qt, gtk, etc.
For this part of the project, you only have to grep for low hanging fruit in each new patch that is released for each project, that is usage of: gets, scanf, strncpy, strncat, memcpy etc (or the equivalents for each project that has wrappers or handling functions).
Any large state actor with any decent team running such a project would have discovered heartbleed within days of it being committed. They also would have discovered a lot of other bugs that we either don't know about yet or have fixed.
With heartbleed the state actors are kicking themselves either way: either because they didn't know about the bug and missed it, or they did know about the bug and now can no longer use it as effectively.
"They" (and you can include black hat groups that don't disclose in this as well) combined likely have more resources dedicated to uncovering these bugs than what the open community does, and it might be an order of magnitude larger.
When you think about this further, you realize that the state actors having discovered heartbleed or not doesn't matter - what does matter is that they do have a lot of exploits that we don't know about and it has been confirmed that they are not only looking for these bugs and have a lot of people working on it, but are actively discovering them, using them and purchasing them on the market.
The response to this shouldn't be heartbleed specific - it should be what do "we" do to stop "them" from discovering and using exploits from open source and projects. There needs to be a heck of a lot more effort or a whole new approach to defeat the level resources that are out there dedicated to uncovering and not disclosing these exploits.
The best thing that could have happen did happen: heartbleed was discovered and it was disclosed, and a hell of a lot of people are now more aware of just how frail some of this infrastructure is and what the risks are.
Excellent response Nik. I write from Laos, where one of the TPB guys apparently lives in exile, next door to where another was extradited, and next door to where lots of exploits apparently get sold (according to certain media reports and personal interactions). This whole thing is invisible to normal people. The bigger question is how can we educate the masses without reliance upon government. I think a global network of free wifi with knowledge libraries people can access on their cellphones would be a good start. Off the internet.
I would take anyone for a fool who thought the NSA hasn't been using heartbleed.
I take anyone as a fool who thinks the NSA is the only spy agency that does such things.
It's not an exclusive statement. The safe bet is that both the NSA and other spy agencies around the world have been using the openSSL hole.
If the NSA has not, they're incompetent.
If the NSA has not, they're incompetent.
Would the NSA be interested in knowing the security flaws of popular opensource programs that could be used for attacks?
Has the NSA ever used a 0day to access a machine they were interested in?
Are the people that work for the NSA likely to be smart enough to realise the NSA's upside in finding security flaws and not telling people about them?
Will the NSA have ever done a security review of popular opensource libraries?
I'm not begging the question. What we know is incomplete. However, answer those questions yourself and then imagine how you might answer those questions if you were rich, liked playing dirty, full of smart people, and in a position of power. That's as good a bet as any on what might have been going on.
My two cents: all that is needed is a small crack in security. I wouldn't bet on the internet being secure, because men and women are fallible and security is complex.
Has the NSA ever used a 0day to access a machine they were interested in?
Are the people that work for the NSA likely to be smart enough to realise the NSA's upside in finding security flaws and not telling people about them?
Will the NSA have ever done a security review of popular opensource libraries?
I'm not begging the question. What we know is incomplete. However, answer those questions yourself and then imagine how you might answer those questions if you were rich, liked playing dirty, full of smart people, and in a position of power. That's as good a bet as any on what might have been going on.
My two cents: all that is needed is a small crack in security. I wouldn't bet on the internet being secure, because men and women are fallible and security is complex.
> And even on sites that were vulnerable, using the Heartbleed bug to find and grab the private keys stored on a server’s memory isn’t without problems.
Yeah, having to collect and process all that random data... I'm sure they gave up after a couple weeks.
Yeah, having to collect and process all that random data... I'm sure they gave up after a couple weeks.
No, I'm pretty sure they would do the only good thing and stored all that lost encrypted, traffic to return to the sender.
Can you imagine those guys doing anything remotely evil, like extracting metadata and data of anything they could get their hands on?
Can you imagine those guys doing anything remotely evil, like extracting metadata and data of anything they could get their hands on?
A rare example of Betteridge being wrong because in this case - Almost certainly yes.
They're usually a few years ahead of what gets published, so I'd assume yes.
I would think that the NSA would be opening themselves up to quite a firestorm if they were found to be exploiting this bug without saying a word about it. I very much doubt they were making use of this for the simple fact that, by not disclosing, they'd be allowing this gaping hole to potentially be used by "enemy" governments, which is the exact opposite of what they want.
If they knew about this, they used it, and they told or by other means deactivated heartbeat for sensitive systems of USA, and using honeypots to see if the Russians and Chinese have figured it out too.
Then when their honeypots attract alot of bees, is time to tell Google to seal the hole, to protect all the medium sensitivity networks and info.
Then when their honeypots attract alot of bees, is time to tell Google to seal the hole, to protect all the medium sensitivity networks and info.
Good thought, though I would think that the reason behind a ton of government offices suddenly dropping SSL would've been leaked by one of the many hands involved.
Why bother? There are a million different ways to own servers available to the security services that require little to no expertise, from compromising the engineers, the physical servers, the CAs, or plain legal intimidation. Even if the NSA had heartbleed they wouldn't have needed to use it.
What we need to know is when a given system was patched, that would tell you who knew what when. Is the Google fork of OpenSSL publicly maintained? Has anyone identified the commit that introduced the "bug"?
The answer is, they are still using it. The spoil is not over. Even old keys are good. They can be used with the data they have already there in the basement.
Disclaimer: All characters and events appearing in my comment are fictitious. Any resemblance to real events or persons, living or dead, is purely coincidental.
Disclaimer: All characters and events appearing in my comment are fictitious. Any resemblance to real events or persons, living or dead, is purely coincidental.
This is a fundamentally different situation than a backdoor in a parameterized encryption standard, such as ECDSA (which is often referenced in these discussions): there, only the people who built the backdoor can use the backdoor. Here, the backdoor exists in a shared resource, waiting for others--including your enemies--to take advantage of; that's quite a risk, and unless you've been seeing some weird behavior--such as the NSA distributing heartbeat-disabled builds of OpenSSL for any potential government usage--I think it is a horrible stretch to believe that they've been sitting on this bug (or even having themselves planted the bug), using it as the long-term surveillance means that some people seem to be want to believe.
Frankly, the fact that they've been logging SSL traffic is enough: for systems without perfect forward security, if they don't already have the keys through other means, they just wait for an opportunity like yesterday and then attempt to quickly get the keys they want. I would almost go so far as to claim the NSA was being negligent in their strategy (not that I like this strategy, mind you) if they didn't follow through to that point. But I just don't see it as being rational to believe the NSA is willing to make our own country's secrets less secure if they are seeing benefits using the bug against others; if anything, I could see them trying to secretly (so as not to tip their hand as having had any advanced notice) fix the bug (after using it for a short time period to pull a bunch of keys, of course ;P).