I've never been one to shy away from praising Microsoft when I think that praise is due. My colleagues can tell you that I still insist Windows ME was a decent operating system and I've loved my Vista install since the first day I used it. I've also been quick to commend Microsoft when something is patched quickly and an issue is resolved. But, I'm not just another "Yes-Man".

Last night Jabulani Leffall referred to me as a 'security gadfly'. I had to look it up, discovered that it meant a pest, and was a little shocked. However, it was quickly pointed out by several people that gadfly also refers to someone not afraid to ask the difficult questions. I thought about that and really liked the term. I like to think that I'm not afraid to ask the difficult questions, and when I think about it, sometimes the responses I get to emails to secure@microsoft.com make me feel like they consider me a pest.

Why all this back story? Because I want to ask the difficult question with regards to MS09-032. It's a question I asked with MS09-008, and should have asked with MS08-032 (and I'm sure a few others).

That question is, when did it become acceptable for a mitigation to be issued as a patch? Forget the root issue, or the results and potential outcome... why does Microsoft continue to get away with this and why aren't we questioning them repeatedly? The CVE for MS09-032 as many people have discussed recently is CVE-2008-0015, it was assigned Dec. 13, 2007. That's 20 months ago... aka a very long time. Yet in all this time, the best they could do was a mitigation? Why not a patch to the affected DLL? The advisory contained the mitigation in FixIt package a few weeks ago, why rerelease that detection as a security bulletin? And a security bulletin that was simply a cumulative update to ActiveX killbits, something that is released every month as a "Security Advisory" suddenly became a "Security Bulletin" this month and I want to know why.

The (seemingly) obvious answer, at least in my eyes, is that this was entirely a marketing ploy. I've noticed that the Security Bulletins (the so-called "For IT Professionals" version) have become more marketing speak and less technical description with every Patch Tuesday. In this case the entire bulletin stinks of marketing speak. So why does Microsoft continue to get away with this? Why can't we put our collective foot down and put a stop to this?

It's actually quite simple to determine the difference between a patch and a mitigation. It becomes even easier if we think of the patch as the solution to the problem. The patch makes the problem go away, end of story. A mitigation doesn't solve the problem... it simple silences it temporarily, it is possible (under the right circumstances) for that problem to come back. A mitigation is not a silver bullet for the problem, and releasing Security Bulletins that contain mitigations is misleading to the every day user.

Let's take this to a completely different place. Imagine you're driving down the road and suddenly get a flat. You pull over and pull off the tire and head to the trunk to pull out your spare... a doughnut. The doughnut will keep you driving, but at a reduced speed and probably not as smoothly. It's probably not ideal but it's a stop-gap solution to your flat tire and will serve you well until you can buy a patch kit or replace the tire (depending on the situation).

In the above scenario, the doughnut is your mitigation and the patch kit/new tire is your patch. Imagine if you were told that getting a flat tire required you to permanently drive around with that doughnut... I doubt you'd be very happy, especially if you're a highway driver. So why should we be happy accepting mitigations as patches, especially if we're in a multi-user environment?

I think it's time that we put a call out to Microsoft, and any other vendor utilizing this practice, and insist that when they call something a patch, it actually be a patch.

Today is an exciting day for the security community... a very exciting today. Today we see the release of Nmap 5.0. Nmap has come a long way since I first used it and it's growing to be more powerful each and every day. With such powerful addons as NSE, Ncat, Ndiff and Zenmap, Nmap is a must-have for your toolbox.

With today's post I wanted to make sure that everyone saw that Nmap 5.0 had been released and I wanted to share a few tips. Before that though, I want to say congratulations to Fyodor. I've had the opportunity to talk to him on a few occasions... while helping out with some of the technical editing on Nmap Network Scanning and over drinks at BH/DC last year. Not only is he brilliant and the obvious reason for the success of Nmap, but he's a great guy to share a beer with. So Congrats Fyodor, today's an exciting day.

When you think about it, Nmap has always been a real "game-changing" piece of software. It was one of the first tools that I can think of that the security industry really standardized on. Everyone who was port scanning anything, was doing it with Nmap. Not much has changed really... sure there are other port scanners but when you talk to others, Nmap is still the most frequently used. Nmap 5.0 may be a another game-changing release, where Nmap goes from port scanner to tool kit... a necessary piece of software for anyone in security.

Now on to some of cool things!

Something that came up during the discussion for this release was the mention that Nmap was no longer just a port scanner. Those days are definitely long gone, the features and extras are numerous and extremely helpful. That being said there are still times when a basic port scanner with minimal dependencies is what you really need. I mentioned that I'd spoken to some people that had run into this issue and the response was to use "--without-ndiff --without-zenmap --without-liblua --without-ncat --without-openssl" during your configure stage. The diffence is astounding (8.5M vs 4.3M on my Ubuntu system) and you're left with only the nmap binary and some files for fingerprinting and service detection.

Another nmap favourite of mine is actually a modification I did to a command posted to the nmap mailing list. I'd previously posted about this, but I think it's worth bringing up again.
You create a shell script with the following:

nmap -sL $1 2>/dev/null |
perl -ne 'print unless /^Host [\d.]+ /' |
grep 'not scanned' |
cut -d ' ' -f 2,3 |
sed -e 's/\(.*\) (\(.*\))/\2 resolves to \1/'

and end up with output that looks like this

198.133.219.9 resolves to test-garbage.cisco.com
198.133.219.10 resolves to fed.cisco.com
198.133.219.11 resolves to asp-web-sj-1.cisco.com
198.133.219.12 resolves to asp-web-sj-2.cisco.com
198.133.219.13 resolves to fedtst.cisco.com
198.133.219.14 resolves to www.netimpactstudy.com
198.133.219.15 resolves to deployx-sj.cisco.com
198.133.219.16 resolves to contact-sj1.cisco.com
198.133.219.17 resolves to scc-sj-1.cisco.com
198.133.219.18 resolves to scc-sj-2.cisco.com
198.133.219.19 resolves to scc-sj-3.cisco.com
198.133.219.20 resolves to jmckerna-test.cisco.com
198.133.219.21 resolves to events.cisco.com
198.133.219.22 resolves to bam-prod-1.cisco.com
198.133.219.23 resolves to redirect.cisco.com
198.133.219.25 resolves to origin-www.cisco.com
198.133.219.26 resolves to partners.cisco.com

Something I've only recently noticed and started playing with is the --reason option. I've never seen anyone use it, but I think that it could be quite useful in some scanning situations.

treguly@ns:~/bin$ nmap --reason

Starting Nmap 5.00 ( http://nmap.org ) at 2009-07-15 04:21 EDT
Interesting ports on ():
Not shown: 904 filtered ports, 92 closed ports
Reason: 904 no-responses and 92 conn-refused
PORT STATE SERVICE REASON
25/tcp open smtp syn-ack
80/tcp open http syn-ack
443/tcp open https syn-ack
32771/tcp open sometimes-rpc5 syn-ack

Nmap done: 1 IP address (1 host up) scanned in 9.49 seconds

All in all, today is an exciting day. Everyone go and download Nmap 5.0

I decided to take one last look at the computer before heading to bed the other night... check the email, see if there are any interesting blogs in the RSS Reader and glance at Twitter. It was the last one that caused me to start writing this. One of the trending topics on Twitter was 'IE6 Must Die'. It took me a little bit to scroll through the tweets before I found a link to this article on mashable.com.

I was intrigued because it was just a few hours earlier that I had been cursing Firefox for making a small web page edit I was doing more difficult, so I read through the article.
I had to laugh when I got to this point as a reason for getting rid of IE6:

- General Security: Just like not updating your virus software can get you riddled with spyware, not updating your browser can be a gateway to attacks. There are even code snippets that will shut down IE6. I won't tell you what they are, but you can find them on Wikipedia. It's unstable.

I'm sure that this will draw some mixed opinions, but I think this is a prime example of why security is a specialized field and why we have so many security issues plaguing us. I'm sure that AV enthusiasts are noting that AV software doesn't have to protect you from spyware (even though most of it does these days)... but for me it was the second half of that comment that caught my attention.

The browser landscape is a scary place these days. There doesn't seem to be a period of time when at least one browser isn't the target of an unpatched 0-day. I actually think that this blog post highlights why we have so many computers that are members of botnets, and so many browser-based attacks. This opinion that an up-to-date browser makes you more secure is wrong, and given that IE6 still receives regular updates, it's also completely invalid. If you want to discuss additional security measures, then sure... IE6 has some issues, but it is still "up-to-date". To say that this is an IE6 issue is misleading and irresponsible.

If we move on, we get this "code snippets that will shut down IE6". There are plenty of ways to crash pretty much any browser; this is primarily because certain companies (*cough*Microsoft*cough*) don't feel that a denial of service attack is worthy of a patch. This means that DoS affecting IE7 and IE8 also aren't patched. You can also find conditions that affect other popular browsers. Which means that saying "It's unstable" is also completely moot -- no browser is stable.

Am I saying that everyone should continue to run IE6? Definitely not. What I'm saying is that uninformed comments, like these, can't lead to anything good. Readers of the mashable.com blog will be under the impression that these are issue plaguing only IE6, and this is incorrect. Making these claims is no different than if I claimed that you shouldn't buy a Ford simply because they can run out of gas and get in accidents. The same is true for all cars, but someone unaware of these facts could make poor choices because of misinformation.

In the end, users need to remember that their browser is *ALWAYS* at risk, and that, regardless of the browser and the protections that it offers, you need to be aware of that risk. It's really that simple.