There seems to be a lot of discussion regarding the 7 years it took for Microsoft to patch against SMBRelay (the name of a tool published in 2001.) There’s some speculation that Microsoft is only now addressing the issue because a Metasploit module was added in 2007 to exploit the vulnerability. Here’s our take.

Should Microsoft have patched SMB sooner? Why? Who has been adversely affected by the vulnerability? We’ve never had an Incident Response case that involved abuse of it. Given the fact that we now know there was a solution to the puzzle, chances are that solution was stumbled upon by accident in one of those “Eureka” moments. Once that idea was finally conceived, of course, it made sense for them to produce a patch, but do try to appreciate just what was at stake as they attempted to implement it and test it. Thousands, if not hundreds of thousands of 3rd party applications are based on SMB working just the way it does. Break it while patching the vulnerability and you’d have a lot of upset people.

(more…)

Today Microsoft released a patch for the “click-jacking” vulnerability announced by Robert Hanson in September. The issue, as you may remember, was that exploiting this vulnerability (in all versions of XMLHTTP but 3.0) allowed him to cause your click on a web page to be directed at anything he wanted. So you might have thought you were clicking a URL to http://securityblog.verizonbusiness.com, but you’d visit http://Ive_Got_You_Now_Sucker.com.

(more…)

From January to July 2008 Microsoft’s technologies disinfected just over 8 million more computers than it did in the previous six month period according to their just released 5th Security Intelligence Report.

Such a statement will make many jump to the conclusion that the state of crimeware is getting worse. But such a conclusion may not be accurate. For example, the increase in distinct computers cleansed in this latest period is just under 50%, whereas in the 2H07 report the increase was just over 79%. The increase in 1H07 was 95%. So the percentage increase this time around is smaller than it has been previously. The same can be said for the number of distinct infections cleansed. 1H08 was 47% higher than 2H07, but 2H07 was 219% higher than 1H07 and 1H07 was 80% higher than 2H06.

(more…)

Microsoft rarely releases these out of cycle patches, but when they do lots of people get excited. It should come as no surprise that we aren’t.

If you want to get an idea of what could happen as a result of this vulnerability, think MS06-040/Graweg/Mocbot/SDBot/August-September 2006. MS06-040 was a similar vulnerability which allowed criminals to gain control of systems they could reach via Server Message Block (SMB). Of course if you can get to someone’s machine via SMB, there’s a lot of harm that could possibly be done.

(more…)

How many times have you been asked about the Return On Investment (ROI) for some security product you were thinking of purchasing? For most of you, it’s probably a great deal. And determining ROI has likely not been easy either. How much productivity might be lost due to a breach? How do I count the time? Do I base it on wages, lost sales, reputation, or damage?

(more…)

By Mark Zimmerman

We all cringe when we see a member of the executive management heading in our direction clutching a trade magazine with the latest WIBHI (Wouldn’t it be Horrible If) article highlighted. In order to help address this situation, we’ll discuss a topic that is, unfortunately, still only largely written about or discussed more than actually understood and/or implemented within the Information Technology department—Risk Analysis.

I’m talking about Risk Analysis skills at the day-to-day, rubber-meets-the-road implementation level, versus that once a year frantic exercise done a half hour before the auditor arrives. You know, the guy (or gal) who freaks everyone out by setting himself up in the conference room and calling people in to ask them to describe their job functions.

(more…)

By Peter Tippett and Russ Cooper

There is a huge amount of angst, discussion, testing and endless worry about the “new DNS vulnerability” whose existence was published a few weeks ago concurrent with a coordinated patch release. Its dastardly “vulnerability” or “threat scenario” will be disclosed in full in early August. The worry is that, once fully disclosed, the unprepared world will be at risk—or at least large portions will be—and whole new categories of exploit will suddenly be possible…or something like that.

Let’s get out a few facts, and then discuss some hypothetical attacks. We’ll assume the extremes and see just how a very old and well-understood vulnerability might behave differently if, for example, a simple cache poisoning attack tool or technique were released. [For a primer on DNS look here. For a primer on DNS Cache Poisoning look here.]

(more…)

by Dave Kennedy

Implementations of the Domain Name Servers (DNS) protocol may leave systems vulnerable to DNS cache poisoning attacks. Last week many incident response teams, along with software and hardware vendors, issued security bulletins and patches to reduce this risk. Cache poisoning attacks are almost as old as the DNS system itself. Enterprises already protect and monitor their DNS systems to prevent and detect cache-poisoning attacks. There has been no increase in reports of cache poisoning attacks and no reports of attacks on this specific vulnerability. DNS is infrastructure. Infrastructure must be trusted, and it must be perceived as trustworthy. (more…)

By Peter Tippett and Wade Baker

Studies are useful to help us to learn what works and what does not. Studies of other’s experiences, such as The Verizon Business 2008 Data Breach Investigations Report, are especially instructive. But most of us crave to actually understand why events play out as they do, and to be able to accurately predict what the results of those studies will be. Risk models can be very useful in driving our understanding.

(more…)

One of the more commonly referenced findings from our “2008 Data Breach Investigations Report” is that 87% of breaches could have been avoided if “reasonable security controls” had been in place at the time of the incident. As this statistic filters through the press and blogs, some are suggesting our use of the term “reasonable” has legal implications, or refers to controls that are “extravagantly hard” to implement. Such interpretation is simply not justified, and we’d like to set the record straight.
(more…)