Verizon data breach report

Interesting report by Verizon. Highlights:

  • External attacks are up 22% and are now responsible for 92% of losses.
  • Insider attack is down 31%. (Finally implementing internal security measures and not just focusing on the perimeter?)
  • Victims were not ‘chosen’ because they were large, important or had financial data. They were simply the easiest targets.
  • 92% of loss resulted from simple, known vulnerabilities

The conclusions sound a lot like the Gartner report:

“Every year that we study threat actions leading to data breaches, the story is the same; most victims aren’t overpowered by unknowable and unstoppable attacks. For the most part, we know them well enough and we also know how to stop them.”

And here’s the same thing in different wording:

“The latest round of evidence leads us to the same conclusion as before: your security woes are not caused by the lack of something new. They almost surely have more to do with not using, under using, or misusing something old.”

And of course, I like this one because it highlights Automated Vulnerability Assessment:

“SQL injection attacks, cross-site scripting, authentication bypass, and exploitation of session variables contributed to nearly half of breaches attributed to hacking or network intrusion. It is no secret that attackers are moving up the stack and targeting the application layer. Why don’t our defenses follow suit? As with everything else, put out the fires first: even lightweight web application scanning and testing would have found many of the problems that led to major breaches in the past year.”

Basically, your organization already has the security solution that it needs; you’re just not using it.

Gartner on Vulnerability Assessment

For years, Gartner has been recommending VA/VM as the effective way to prevent successful attacks, only they’ve been a bit too low key about it in my opinion. Of course as a VA vendor I’m not even going to pretend to be objective here, but I always wondered if the fact most leading vendors are relatively small made Gartner pay less attention to the field.

Whatever the reason was, Gartner just came out with Strategies for Dealing with the Increase in Advanced Targeted Threats.
Here are some nice quotes; I especially liked the one about 0-days. I’m in complete agreement with all of them:

Quotes from this article (emphasize is mine):

Enterprises need to focus on reducing vulnerabilities

” There are existing security technologies that can greatly reduce vulnerability to targeted attacks.”

” … the real issue [is] focusing on the vulnerabilities that the attackers are exploiting. “

The reality is that the most important issues are the vulnerabilities and the techniques used to exploit them, not the country that appears to be the source of the attack”

Own the vulnerability; don’t blame the threat: There are no unstoppable forces in cyber attacks” (this one should be printed on T-shirts).

“If IT leaders close the vulnerability, then they stop the curious teenager, the experimental hacker, the cybercriminal and the information warrior”

“Many attacks that include zero-day exploits often use well-known vulnerabilities as part of the overall attacks.”

Vodafone Hacked – Root Password published

Looks like a nice one:

The Hacker’s Choice announced a security problem
with Vodafone’s Mobile Phone Network today.

An attacker can listen to any UK Vodafone customer’s phone call.

An attacker can exploit a vulnerability in 3G/UMTS/WCDMA – the latest and most secure mobile phone standard in use today.

The technical details are available at http://wiki.thc.org/vodafone.

News article:
http://thcorg.blogspot.com/2011/07/vodafone-hacked-root-password-published.html

Simple passwords are the solution

ZDNet has a nice piece on why cheap GPU’s are making strong passwords useless. They are right, of course (though it’s pretty much been that way for 20 years, since the need for /etc/shadow) but they missing the obvious solution to the problem.

The solution is not to make passwords more complex. It’s making them less complex (so that users can actually remember them) and making sure brute force is impossible. We know how to do that, we just have to overcome a generation-old axiom about trivial passwords being easy to break (they are not, if you only get very few tries).

It’s not just cheap GPUs. Complex passwords are also the problem. Simple passwords are the solution.

The MSRC – now and then

It’s amazing to compare how the Microsoft Security Response Center handles vulnerability disclosures versus how things were just 10 or 12 short years ago.

Here’s a typical disclosure process 10 years ago (based on a very true story):

Us: (sending an email to secure@microsoft.com) we’ve discovered a vulnerability in an office product. Here are the technical details. Can you confirm the issue and let us know when it’s patched?
Microsoft: Thanks for reporting, bla bla, we’ll get back to you soon

[about a week passes]

Us: Hi MSRC, any news about our office vulnerability?
[no reply]
[Sending a personal email to an MSRC friend to speed things up]
Microsoft: Oh, thanks for reminding us. We’ll check with the office team

[another few days pass]

Us: Hello? Anybody there?
Microsoft: Oh, yes. That vulnerability thing. Here’s what we decided: (a) It’s not a vulnerability. (b) it’s not a problem with the office product but with the world (or the RFC) (c) The office team can’t recreate it (d) even if the vulnerability was real, it wouldn’t be exploited in real world scenarios
Us: are you kidding us? Did you actually look at the sample code we gave you?
[a few days pass. We are pondering if to go complete full disclosure or give them time to digest]

Microsoft: Ok, this time we actually read your advisory and yes, it seems to work. But it’s just a denial of service. Nobody will ever exploit it because of … [something that heap spraying/DEP bypass/code mutation made look ridiculous about a year later]
Us: [starting the get mad] look guys. We sent you PoC code. You actually want us to write an exploit code for you?
Microsoft: yes, that would help convince our developers

[Us, spending time writing code so that Microsoft is convinced to fix their own products based on free information while wasting our precious time]

Us: here it is
Microsoft: oh, wow, it really does run code. Ok, we’ll fix it in the next release cycle which should be right after the democratic primaries of 2012.

Us: Ok, forget it. We’re going full disclosure

Microsoft: no, wait wait wait. We found your name on the world wide web and now realize you’re legit. Ok, we’ll fix it. Happy now? We might even mention your name in our advisory if/when that happens.

If it sounds familiar, that means you were disclosing vulnerabilities to vendors in the early 2000’s or late 1990’s. If you think I’m exaggerating, it’s only because you didn’t.

But here’s the amazing thing. Just a few years later, some radical changes started to happen. The big dysfunctional dinosaur that was MSRC became an efficient, friendly and if I didn’t know it, I would think it’s a different company altogether. Here’s a real recent discussion:

Us: Hello MSRC, here’s information about an office vulnerability
Microsoft: Hi, thanks for reporting. I checked the information, went over the sample code and have some technical questions [some intelligent questions here, basically they are doubting the findings but being really careful to check all the angles first]

[technical discussion continues for a couple of days with questions and answers going back and forth]

Microsoft: Ok, we get the picture now. Thanks for reporting. Here’s the guy that is going to be responsible for your case.
[a few days pass]
Microsoft: Ok, we now know it’s a […] vulnerability and not a […] one. We’ll pass it to the relevant team, just wanted to keep you posted
[further proactive updates and niceties continue until disclosure time. Credits, the end.]

What could have possibly caused this radical change that made MSRC focus on the technical side instead of the PR, not to mention being so research-friendly? New team? New procedures? Full disclosure forced them to see the truth? Too many beers at defcon finally showed them the light? Whatever they are taking, I wish they could spread some around. Most of the other vendors could use that. Yes, I’m looking at you Google.

Codegate 2011

Korean is a tricky language. It is probably the easiest language on the planet to read and write in, especially for geeks.

It takes literally hours to learn: if you have any background in breaking codes as a hobby, you will be able to learn to read and write Korean fully, within the day. Now you can read signs, read most of the newspaper and decipher the airplane safety card on Korean Airlines.

But reading is not understanding, and this is where the trap springs. While its writing is possibly the easiest of all languages, the vocabulary/grammar part is one of the hardest that exist. Forget hash functions: identical Korean sentences can look totally different just because you’re speaking to your father instead of your son; Ask a few native Koreans how to say “the Apple is red”. I have 3 different answers so far (with no resemblance whatsoever to one another). The real code here is the semantics. It’s like doing a simple XOR cypher to a book cipher. What a clever trick.

But by the time I hit the brick wall with the honorifics, Subject-Object-Verb and impossible pronunciation I was already too deep in to stop. Plus, I never let security by obscurity stop me. Though in this case, I have to mention they’ve perfected their obscurity to impressive levels.

So I was very excited when I was asked to speak at Codegate 2011 in Seoul. It looks like a really fun conference. If you are in Seoul or the area, I recommend it.
I will be speaking on April 5th, and don’t expect too much: the Korean part of my lecture won’t go beyond Annyeong haseyo and je ireum eun Abiram imnida. And even that will be with incomprehensible pronunciation so bad they might have to subtitle that part.

In any case, if you are in the conference, come say hello and test my Korean. Just don’t be offended if I get my honorifics completely wrong.

Update: The correct date is April 5th and not as I originally wrote.

Shut off switches and unicorns

Commentators are now agreeing with what I wrote two weeks ago. It’s now clear there is simply no way to effectively shut down the Internet.

Typically, this is where the skynet references come in, except that this version of skynet is not a computer brain, it’s the sum of you and me and the other human users. The People’s republic of the Internet, if you will.