NSA Director Says Agency Shares Vast Majority of Bugs It Finds
threatpost.com
threatpost.com
Interesting to compare with timeline: http://www.smh.com.au/it-pro/security-it/heartbleed-disclosu...
Hm. I didn't know that MS would be involved in this as well since they're not really affected by this.
Patching for customers in Azure can be done through normal OS channels, though patches can be forced and base images an be modified to close holes (this was done).
I'm just depressed because I suspect many people will start claiming the NSA solved Heartbleed. :/
I guess all their good talent and money was tied up in domestic call metadata social graph analysis. But at least they had someone smart enough to do the trivial patch once the vulnerability was known![0]
P.S. I also notice they didn't mention "Shellshock". Why not?
So while not every - at least a lot.
No, it doesn't really prove incompetence, but on the other hand "we released a trivial patch for an issue the private sector already found and fixed"* doesn't prove competence either, or inspire any sympathy from me. These are the types of people who trot out imagery like "cyber Pearl Harbor" when they're telling us why they need to be granted more power to protect us, yet their go-to public example of fixing a critical vulnerability in the national digital infrastructure is laughably irrelevant.
* Depending on what time of day it was, the official fix may or may not have been publicly released when NSA did whatever they're claiming they did.
If they are to exist on the taxpayer dime, they should serve the taxpayer first and foremost. They like to brag about this kind of thing, because it makes them look good (and maybe allows them to believe they are "good people", as I often see folks who defend the NSA say of them) but it isn't actually their priority, and it is not something they have a history of doing.
For example, this is the kind of thing the NSA actually spends significant money on: https://en.wikipedia.org/wiki/Utah_Data_Center
That same money would have employed a number of excellent security researchers, and the tools they need to help make the Internet a safer, more secure place, for all Americans.
In short, this kind of article is misdirection, and people in our industry should not be snowed by those tactics. We should know better, based on their historical behavior.
I assume this is why Stuxnet had so many zero-day exploits in it. The agencies behind it had security firms feeding them.
The market for 0days has been cooling off in recent years, but for a good decade there you could sell 0days, even mediocre ones for six digits. Nowdays you'll need a pretty good vuln for six digits, and something pretty stellar for seven (this isn't unheard of). ZDI, frsirt and others got into the game as middlemen. They allow(ed) you to not know who the final purchaser is and would allow you to sell 0days that may or may not be interesting to a government entity - in this case ZDI, etc would swallow the cost.
Sorry for the questions, no contact info in your profile. Answers from anyone would also be appreciated.
Have you personally ever sold a vulnerability?
(And obviously, I don't have such a 0day to sell, so I can't prove that they would actually pay up.)
Disappointed that 'mediocre' vulns got interpreted in this thread as 'trivial'.
Mediocre doesn't mean trivial, extremely scoped or useless. Mediocre means that it is for sensitive but not widely deployed software, for widely deployed software on default config but is post-auth or is not reliable, or it is reliable and yiels high auth but requires pairing with another vulns (i.e. memory disclosure) or extended recon (revision number, etc).
A MySQL bug affecting recent revisions that causes arbitrary file overwrites with semi-controlled content but that requires unprivileged (guest) auth would meet this criteria.
Apologies for the confusion with the word 'mediocre' - I figured people here would know.
In general organizations in the offensive world will pay more than those in the defensive world. This is not a hard and fast rule, but mostly it is the case that offensive network operations stand to gain more from the use of 0days than vendors stand to lose by not paying for the disclosure to patch them. It's not really a good calculus to use data from vendors sales to calculate the other.
Not speculating about nation states here but 'groups': making good money from post-Auth MySql RCE not totally absurd - Amazon, Rackspace, HP, Heroku and Jelastic all offer MySql-as-a-service, where you are given low privilege (maintained, geo-redundant, etc) account access to shared MySql instance. If there's more than five digits of business value stored in that database then a five digit exploit makes sense.
Or think about any of the (poorly written) bitcoin services out there that use some default phpAdmin creds for a database that also hosts their vault.
As for the "market assessment" I find it implausible. It seems to be based on the assumption that the demand for capabilities has decreased over time while the availability of good bugs has increased. This is at odds with reality.
I have no firsthand knowledge of how these connections work (the gossip I hear tends to involve firms proffering vulnerabilities to middleman "commercial" firms --- not ZDI, by the way --- but who knows?). But I'm skeptical of the idea that security research firms are a real feeder for vulnerability intel to NSA, because based on the people NSA spits back out into commercial industry, they appear to have a very, very capable internal research staff.
The claim makes me think either that they're lying about sharing what they find (either intentionally or via institutional stupidity); or they're really inept and not finding much at all compared to much less well funded OSS developers and participants in industry.
It would be interesting for someone to setup a scorecard site to document NSA's infosec contributions.
So I'm not sure this is a valid critique.
The answer is a lot.
Crypto software implementation vulnerabilities are very common, but the kinds of things you're talking about are most often found in obscure and/or serverside software. Look at the tempo at which bugs like the NSS e=3 bug are released; it's like once or twice a year.
The sorts of bugs I'm talking about exist in client and popular software. As far as tempo is concerned this year alone has given us BERserk, gotofail, Android Master Key, OpenSSL fork(), Bitcoin's use of P256, GNUTLS X.509 parsing bug, the OpenSSL compiler optimization+processor family randomness bug, and others.
If we were to entertain OP's point maybe there would be a faster tempo if the NSA were helping out. :)
But I did also mean that more broader than just construct attacks..., implementations of cryptosystems are often flawed in low level ways which people without special expertise are unlikely to notice... both from a design perspective (any of the great many protocol design flaws in TLS that have turned around an bitten us), or straight forward coding (e.g. it wasn't the NSA that reported reference implementations of Curve25519 had broken carry propagation).
The other 98% of zero days that are easy enough to stumble upon by foreign cyber units might be better to disclose and get fixed.
If the NSA can find a bug relatively easy, then we can assume China(example) might be able to as well. Getting those bugs fixed is a big gain for national security. Although, it will boost security of all nations.
It's the New New Great Game.
So when they say they share, with whom? And what priority? Ooh, you found a documentation bug; is that the one you chose to share? The more severe a bug is, the more useful to them.
There's a million ways to parse this bullshit that come down to mean they're doing what they did all along but better at lying in public.
There are two uses of "sharing" in the response. One was sharing of vulnerabilities. It was never clear who it was shared with. It could be with the DoD, with GCHQ, with private contractors under contract with the NSA, etc. and still be counted as "sharing."
The other is an example of sharing one patch, for the Bash vulnerability, with the private sector.
I think we are supposed to connect those two pieces of data, but there's no reason to do so.