The Ashimmy Blog

Google Does Evil

Google seems to have violated its own prime directive with the premature disclosure and publishing of attack code by one of its researchers. According to this story in ComputerWorld, a Swiss Google researcher Tavis Ormandy gave Microsoft just 5 days before publishing the zero day vulnerability with attack code. This is just outrageous.

You can tell me that Ormandy did this without Google’s knowledge and consent. If that is so, they should fire him tomorrow. If it is not true, shame, shame, shame on Google.  Allowing their Microsoft-phobic psyche  make them violate their own prime directive to “do no evil”.

When two security researchers that I have a tremendous amount of respect for, Andrew Storms and Robert “R-Snake” Hansen are quoted saying things like:

"This stinks of retribution," said Hansen. "If Google really goes by responsible disclosure, they should fire Ormandy today." Hansen noted that Ormandy credited other Google security researchers for their help and linked to a Google blog on browser security in his message on Full Disclosure. "You shouldn't do that if you want to disassociate yourself from your employer."

That's impossible, argued Andrew Storms, director of security operations at nCircle Security. "[As a security researcher] you can't really separate your work from your employer. So you have to wonder if [Ormandy[] isn't intentionally feeding the feud between Google and Microsoft."

Like Hansen, Storms questioned Ormandy's decision to reveal his findings just five days after he reported the vulnerability to Microsoft. "You can't say in this case that the vendor was sitting on their hands, not being responsive, which is why researchers usually go public, to force [a vendor's] hand.

"This is no better than not reporting it to Microsoft," concluded Storms.

You know that what was done here was very bad and evil. Another example is that Google gives lip service to responsible disclosure while their employee had this to say about it:

He also slammed the concept of "responsible disclosure," a term that Microsoft and other vendors apply to bug reports that are submitted privately, giving developers time to craft a patch before the information is publicly released.

"This is another example of the problems with bug secrecy (or in PR speak, 'responsible disclosure')," Ormandy said. "Those of us who work hard to keep networks safe are forced to work in isolation without the open collaboration with our peers."

I am telling you, if Google does not fire this dude then their words about “doing no evil” don’t amount to a hill of beans. If I remember correctly violating the prime directive carries a death penalty even in Star Trek.

This weeks winner of the Captain Renault award

From the classic Casablanca:

Rick: How can you close me up? On what grounds?
Captain Renault: I'm shocked, shocked to find that gambling is going on in here!
[a croupier hands Renault a pile of money]
Croupier: Your winnings, sir.
Captain Renault: [sotto voce] Oh, thank you very much.
[aloud]
Captain Renault: Everybody out at once!

Last week I wrote about the "shocked to find gambling going on in here" revelation by Symantec, that the underground market for stolen data was in the hundreds of millions of dollars. This weeks winner of the "Captain Renault shocked to find there is gambling going on here" award goes to Secunia. They announced that their findings show 98% of Windows computers have at least one known vulnerability and nearly half have 11 or more programs at risk.

Bill Brenner has a good article on this as just Secunia spreading FUD and not many CIO's or security administrators are surprised by these findings. Bill points to a Verizon study that says 90% of all incidents involve a vulnerability that has a patch available for 6 months or more.  I think this is really important.

For all of the emphasis, time and money wasted on zero day attacks, the fact is 9 out 10 attacks take place against well known vulnerabilities.  Has the patch management process broken down?  Did it ever really exist?  Vulnerability management just isn't sexy anymore, but there are good products available.  In the face of such numbers, how can the security industry as a whole not get serious about patching, vulnerability testing and taking these low hanging fruit off the table before we get all hot and bothered about zero day stuff.

Related articles by Zemanta

• I'm shocked, shocked to find out that gambling is going on here
• Every Windows PC is at Risk if not Lucky- Confirms Recent Research
• Virtually every Windows PC at risk, says Secunia
• Windows patching abysmal, and getting worse

Less than zero strikes again

OK, I will admit it, I am a little bit giddy by all of the attention paid to the "less than zero" threats stuff.  Now, no less than Jaikumar Vijayan at ComputerWorld has written a top story entitled "Less than zero-day" threats to often overlooked.  This on top of all the other media outlets and blog articles on the subject, it amazes me how things can snowball from a simple blog post, WOW!  I will say that though I may have started this thread, Rich Mogull, Mike Rothman, Amrit Williams, Pete Lindstrom and many others have added the real value here. It really sort of  legitimizes and validates the whole reason we blog at some level.  Thanks guys for all of the help and thoughts on getting this problem into the spotlight.

Less than zero starting to add up to something

The "Less Than Zero" train continues to gather steam.  Today TechNewsWorld had a nice write up by John P Mello, Jr that does a nice job of summing it all up.  Couple of things that had me smiling was first of all he called me a White Hat (I always wanted to a white hat) and more importantly, other folks he interviewed from CA, Symantec, McAfee, Sophos and ESET were actually using the less than zero name to talk about this class of attacks.

The real cherry for me though was that none other than Mike Rothman actually gave me kudos on this one.  Mikey, you went easy on me, are you going soft?  Seriously, I realize there is marketing involved here, but I wanted to focus us on a job that needs to be done.  Also, Mike one of the culprits for this emphasis on zero day at the expense of less than zero is the fame and fortune we put on vulnerability research.  There is too much of a gold rush to announce to the market that you found the next vulnerability.  The real gold rush though is what the bad guys are doing with the unknown ones. White hats don't discover the bulk of these attacks.  You can buy less than zero attacks right now for 150k or less.  I realize that White Hats don't just bug test, but lets stop holding them out as the answer here.  We have to remain vigilant as you and I both say.  But I do appreciate the kind words and as usual, you have some good stuff on this one!  Thanks Mike.

More on Less Than Zero

So it seems some of the media have picked up on my Less Than Zero posts. Today the IT-observer, SecurityPro News and IT News Online all ran with the story.  I was also interviewed by a few other media outlets and will see if they run with anything.  It seems there is just a tremendous amount of confusion around this stuff still.  I don't think we have seen the last of it either.  Will keep you posted, but am interested in others thoughts on this as well.

Less Then Zero, Part 2

Less Then Zero, part 2

A StillSecure approach to vulnerabilities, exploits, patches, and security

In part 1, we introduced the idea of a Less-Than-Zero threat and defined it relative to a Zero-Day threat. Today, I'll go a little deeper on each and discuss ways to protect your organization from them.

The Less-Than-Zero threat

The first stage in the evolution of a threat is the "underground" stage. This is the Less-Than-Zero-Day attack.  In this stage, the vulnerability and a corresponding exploit are lose in the wild.  The Less-Than-Zero-Day vulnerability is only discovered when evidence of an unattributable attack is identified. Therefore you typically don’t see aLess-Than-Zero-Day vulnerability without an existing exploit.

The Less-Than-Zero attack is usually discovered using forensic tools that recreate an attack or incident after the fact.  There are no patches, IDS signatures, or other types of tools to prevent these attacks.  The only possible type of defense is a heuristic or behavior-based defense, if you believe in this class of technology (that is a subject for another day).  Your best defense is conforming to best practices within the layered security model. Whether layered security technologies are combined in single all-in-one integrated device or separate silos is up for debate.

Vigilant analysis to identify the attack vector is one of the best things to minimize the time period for this type of attack.  Other factors are whether the weakness is being used for attacks against a narrow range of targets or a mass-market type of attack. Obviously the quicker the attack becomes “known” the quicker it moves into the conventional Zero-Day stage. Therefore, mass-market Less-Than-Zero threats quickly become Zero-Day threats. 

Once the vulnerability and/or its exploit are known, the questions are: (1) Who knows about it? and (2) How is the vendor of the targeted system alerted to it?  The concept of responsible disclosure is has been hotly debated.  One camp believes that telling the vendor before releasing information to the general public gives the vendor time to get the fix out.  The other camp believes that vendors don’t react quickly enough. The bad guys already know about the vulnerability/exploit anyway, so what good does it do to withhold general disclosure?  Announcing the threat is the quickest way to enable organizations to protect themselves as best they can until a patch is available.

The Zero-Day Threat

A couple of things about Zero-Day attacks. Once publicly known, a whole new crop of Black Hats can try to use them. We do not subscribe to the vast hacker conspiracy theory that has all Black Hats sharing information. No doubt some sharing occurs, but there are exponentially more bad guys to worry about after the threat is made public.  That's the top of the curve in the graph from part 1 of this series. Let's be clear: the Less-Than-Zero risk is a significant one.  You should not let the Zero-Day threat defense come at the expense of Less-Than-Zero defenses. 

Another point about Zero-Day attacks:  If their genesis is from a Less-Than-Zero attack, then its exploit is already out there—so we're already in the period of peak threat.  This makes the "publicly-known exploit" argument discussed above a bit of a red herring. 

One more thing: Until the patch comes out there are things you can do to mitigate risk. You need to identify machines that are vulnerable to the attack. You can have a signature or some other behavior-based approach such as IDS/IPS that can detect and block it.  You can disable the services or port that serve as the attack vector and enforce this via NAC and vulnerability scanning. 3^rd party patches or other types of workarounds are also possible.

Patching

The final chapter of story deals with patching. 'Patching' typically mean the official patch put out by the vendor of the vulnerable software.  Just because a patch is available does not mean the threat goes away.  With the constant vulnerability/patch process, the time from when a patch is available until it is actually applied can range from hours to weeks, depending on size of company and patching process.  As a result the period of risk is extended.

Conclusion

Zero-Day, Less-Than-Zero, patching, exploits...the world is a dangerous place.  While our attention has been focused by some security vendors and the press on the Zero-Day attack, the Less-Then-Zero threat is also significant enough to warrant your attention and resources. The reason you don't hear a lot about this type of attack is because the majority of vendors don't have a silver bullet to sell you for solving the problem. There is still no substitute for good, old-fashioned, best practices in security. 

Less Then Zero, Part 1

                                   Less Then Zero, Part 1

                   A StillSecure approach to vulnerabilities, exploits, patches, and security

Introduction

The security industry and trade press have directed a lot of attention toward the "Zero-day attack," promoting it as THE threat to guard against. According to the marketing hype, the Zero-Day attack is the one that you should most fear, so you must put in place measures (i.e., buy stuff) to defend your organization from it.

The Zero-Day threat is born the moment a vulnerability is publicly announced or acknowledged. But what about the period of time that the threat existed before being announced. At StillSecure we call this class a "Less-Than-Zero" threat. In this two-part series I'll examine this Less-Than-Zero threat, compare it to the Zero-Day threat, and discuss ways to protect yourself from Less-Than-Zero attacks and vulnerabilities for which patches, signatures, etc. do not yet exist.

Zero-Day vs. Less-Than-Zero

Once a vulnerability is publicly announced, the zero-day clock starts ticking. The announcement is typically followed by some period of time before a patch is made available. This is the Zero-Day period. According to accepted wisdom, organizations face the greatest danger when an attack or exploit targeting the vulnerability is verified in the “wild.”

Some believe this is a flawed argument. As evidence, they point to “underground” vulnerabilities and exploits that are equally as dangerous and much more difficult to detect and protect against because they are “unknown. At StillSecure we call this class Less-Than-Zero Threats. The chart above shows the relationship between the Less-Than-Zero threat and the Zero-Day threat and the level of risk they pose to the organization. It also takes into account such factors as responsible disclosure, patch deployment, etc.

Typically Less-Than-Zero threats have a different genesis than Zero-Day threats. Most Zero-Day threats are discovered through the standard bug testing process, and the vulnerability is known prior to an exploit for it being seen in the wild. Less-Than-Zero attacks, on the other hand, are first detected through evidence of attacks that have exploited them.

Where many Zero-Day vulnerabilities are discovered by White Hats, most Less-Than-Zero attacks are true Black Hat attacks. It is, however, possible that an underground threat evolves into a zero day attack. This is a natural evolution of Less-Than-Zero vulnerabilities and threats. Often a Less-Than-Zero attack becomes widely known, and a patch issued. It becomes a Zero-Day type of attack at that point.

Hopefully you see my point: just because the Less-Than-Zero threat doesn't get a lot of media attention, it presents a real danger, and true security-conscious organizations will take steps to protect themselves from it.

In Part 2 of this series we'll look at each stage of a threat and determine what defenses are applicable and what can be done to shorten and reduce the time of highest risk

Undercover Exploits

Pete Lindstrom over at Spire has a good article up on Undercover Vulnerabilities and Exploits which he defines as:

Undercover Vulnerability: A vulnerability that was generally unknown (e.g. not published on any lists, not discussed by "above ground" security folks) until it was actively exploited in the wild. The vulnerability was discovered through evidence of tampering or other means, not through the usual bugfinding ritual.

Undercover Exploit: The event and/or code used to compromise a resource running the vulnerable software in the wild.

I think this gets to something I was trying to say in the zero day stuff prior.  Pete has a good list of up of real undercover examples and their dates.  I am going to put my thoughts together and put something out on how I view the whole zero day thing this week.

Another comment, another view on zero day

The Mogull seems to agree with me on the zero day stuff.  Have a look here, he says I nail it. What is interesting is now we have Amrit and Rich with two takes on this. Just goes to show that this is an issue that stirs up opinions on both sides of the table. I would be interested in other opinions on this one as well.

Comment on the zero day article

I usually don't call out comments to my blog, unless I am going to respond.  However, Amrit from over at http://techbuddha.wordpress.com has a well thought out response on zero day that I think deserves a read from you. He has further written on this here. Here is his comment on my article.

A zero-day exploit takes advantage of a vulnerability on the day that it is publically announced (sometimes before, but not as much as vendors with "we stop zero-day attacks" would lead the public to believe) When that happens it is difficult for organizations to respond quickly since they a. need to obtain updates for their security defenses (new sigs, reconfigurations, and what not) and b. need to obtain the patch (if one is available) and then distribute it to their environment. Even best of breed organizations with mature patch management programs can take weeks or even months to fully patch their environment - this is not due to technology but process and logistics.

I agree that there is a period prior to vulnerability identification or disclosure where malicious 3rd parties may find the vulnerable condition, write exploit code and then then use it as a vector for attack. The most common case is where a vuln is announced at the same time a patch is made available and within hours exploit code is in the wild and attempts are made to attack systems.

I am not sure what you and Patrick are calling BS? Are  you actually saying that there is no threat to an organization the day that a vulnerbility is released and there is exploit code available within hours? Are you suggesting that once a vuln is announced that a large enterprise just automagicallly patches its entire organization and is defended? What happens when   a vuln is announced and no patch exists (can you say wmf or createtextstring?) and then exploit code shows up in the wild. So you guys are off base on this one, there is a real danger facing organizations in that delicate period between vuln and/or patch announcement, with exploit code actively being used to attack orgtanizations and the scramble to defend themselves.

BTW - Rapid-patching as an initial response to a critical vulnerability, especially when exploit code is available in the wild, is a logistically difficult strategy for every organization I have ever spoken with. You absolutely must remove the root cause of a vuln, but the first step should be to shield the environment. That is use network and host-based security products (such as firewalls and IPS, perhaps update some NAC if you have that running) or other network infrastructure (such as routers) to prevent exploit of the vulnerability before you can patch everything. We have been advising organizations to do just that and will continue to do so...

To be clear, I recognize that most of us think of zero day attacks just as Amrit describes them.  I just think that the whole industry around them misses an obvious point and that is what about truly "unkown" vulnerabilities.  We need to concentrate on these just as much or even more so.