StillSecure, After All These Years

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.

Zero day attacks are bull according to Patchlink CEO

Patrick Clawson, CEO of Patchlink comes out swinging, "... calling bullshit on the whole zero day thing" according to this story in ITWeek. Here is the funny thing, I don't necessarily disagree with him.  Now before you go jumping to conclusions, hear me out.  First of all here is his complete quote:

“I’m calling bullshit on the whole zero day thing. These vulnerabilities are announced on that day, not released, it’s in the year running up to that date where they cause problems. By the time something like Slammer becomes well known, it is a nuisance, but [as an IT manager] what you have to worry about, is what you don’t know."

I think Patrick is right on. The issue is what is your definition of zero day. Today I think most people think of zero day as the time from when a vulnerability is announced through the time there is a patch for it.  This intervening period is known as the zero day period and a whole cottage industry has grown up around it.  From third party patches to responsible disclosure forums and lists and most of all the behavior based or heuristic products are milking this for all it is worth. This was not always the case and in fact is not really the case.  Patrick is right on, it is BS. Patrick's point, if I may be so bold, is that the real dangerous period is the one year or so before a vulnerability becomes known but not patched.  Really unknown vulnerabilities that fall in this area are the real threat.  The bad news is I don't think there is a great defense for these other than locking down as much as you can, training people to adhere to safe and secure policies and be ever vigilant.  Also, as long as this remains the case, the work of the security person will never be easy.  Good Luck!