VERT

Obsolete Software

Mon, 05 Oct 2009 19:29:40 -0800

Something came up recently that prompted some discussion around the office. What constitutes obsolete software? Does it mean a version of software that is no longer shipping or is it simpley software that is no longer maintained? That only prompted further discussion around the term "maintained" and how it is defined. Is software maintained if the vendor ships an update every 2-3 years and doesn't include patches in the interim?

It started to make me wonder and think about my own usage habits. I like to know the people I'm doing business with are secure, so if I could require every website to perform a full audit before I visit it, I would. Since that isn't possible, I like to know that they've taken reasonable steps to ensure security. The latest versions of software with proper security patches applied in a timely manner is usually a pretty good start.

Then I started thinking about the software that had started this conversation (Apache httpd). There are three main branches of Apache available right now: 1.3, 2.0, and 2.2. Apache 2.2 is the latest branch; with the greatest number of updates... in fact Apache 1.3 and 2.0 haven't been updated in 21 months. So does that mean 1.3 and 2.0 are obsolete? I guess that depends on how you define obsolete.

I suppose it's possible to see another release from either branch (after all 2.0.64-dev has a fix for a vulnerability, which must mean 2.0.64 stable is coming eventually). So technically, I suppose it isn't obsolete. Now let's look at this from a security stand point. 1.3 and 2.0 are old software, they haven't been updated in quite some time, and they have known security issues. Why would you want to continue to use them? Would I as your customer feel comfortable if you were using them? Probably not. I might be able to justify 2.0, but 1.3 there's no way I'm going to feel comfortable with a web server running that. So in my mind, from a security stand point, these are obsolete.

So which standpoint is correct, the technical one or the security one? That's an easy answer... it's the technical one... after all, it's technically correct. Yet which one is right (which is very different from being correct). My opinion is that the security definition of obsolete would be right. So let's cast away 1.3 and 2.0 as obsolete and move on to the newer, more secure software.

I started to browse the Apache website and noticed they use the word 'legacy' a lot... it doesn't mean obsolete but it kind of reminds me of it. I also noticed some lines in the changelogs of the most recent versions of 1.3 and 2.0 that really made me wonder:

"Apache 1.3.41 is the current stable release of the Apache 1.3 family. We strongly
recommend that users of all earlier versions, including 1.3 family release, upgrade
to the current 2.2 version as soon as possible." -- http://www.apache.org/dist/httpd/Announcement1.3.html

"We consider Apache 2.2 to be the best available version at the time of this release.
We offer Apache 2.0.63 as the best legacy version of Apache 2.0 available. Users
should first consider upgrading to the current release of Apache 2.2 instead." --
http://www.apache.org/dist/httpd/Announcement2.0.html

So, if the Apache Software Foundation is recommending you upgrade to 2.2, wouldn't you conclude that even they consider their software obsolete and that they are keeping it around for one-off situations? I sure would.

Anyways, back to my point. Much like my point in my last post... this is about user confidence. The more confident your users are in your service offering, the more likely they are to be ok with using your website. A lot of people are still afraid of the internet and even more are afraid of online transactions. We could ease a lot of their fears if websites would maintain their software and install the latest security fixes.

The Little Things

Wed, 30 Sep 2009 12:51:51 -0800

We seem to be so caught up these days in the "big things", things that are newsworthy, that will be talked about for weeks, months or, maybe even, years. We miss the little things. This is probably just a much a life lesson as it is a discussion on computer security but since this isn't a philosophy blog, I'm going to limit it to computer security.

When it comes to web application security, we primarily see mention of the "Big 3" - XSS, SQLi, CSRF. Sure, there are many other issues but those come up a lot. What we don't see is mention of the smaller issues, the little things that the media doesn't talk about and even security experts don't talk about. I don't know if they are overlooked, or, perhaps, no one really cares but I consider them to be issues, issues that need to be resolved. These are issues that consumers aren't aware of, and in all honestly shouldn't have to be concerned with.

I recently came across two of these issues while visiting a website. I know, by now I've built up the suspense and you're wondering what the issues were... so I'll tell you. The first was limit on password length and the second autocomplete wasn't disabled on the fields that wanted my credit card information. You're sitting there saying, "So what?", so let's discuss these a little more.

Let's look at the limited password length first. The password limitation? 20 characters. To me, that's way too few. Whenever people ask me about creating secure passwords, I always recommend the following style: + - + (keyword is generally capitalized, contains numbers for letters or ends in a number -- and you end up meeting most password complexity requirements). This works fine if your keyword is dog and your visiting www.ncircle.com (password = Dog-www.ncircle.com) as your password is 19 characters long. What if my keyword was purple (Purple-www.ncircle.com) is greater than 20 characters. This is a nice simple memory trick to create long, complex passwords that are easy to remember but a password character length of 20 ruins the possibility of that. Since you're storing the password and storage space is so cheap, why not 64, 128, 256 or even 1024 characters? I see this as a security issue as it decreases the security of the user’s password.
The second issue came on my second use of the website. I entered in my credit card information and was surprised to see that when I typed the first digit, the remainder of the credit card number was completed by my browser's autocomplete functionality. That's right, the form field didn't have autocomplete=off set. To me this is web security 101 if you're accepting credit card numbers or asking for passwords. There have been attacks and malware in the past that have stolen this autocomplete information.

I know what you're thinking, "Why don't you just turn off autocomplete and shut-up?" Sure, that works for me but what about your average user? I doubt they know how to turn off autocomplete and I doubt they want to, I even find it useful in some situations. That's why I rely on websites that are collecting personal information to develop their forms properly.

At the end of the day, my confidence in this website was greatly decreased by these two issues. Sure, the average user won't notice the decreased confidence and will go on happily using the website but that shouldn't be how it works. Companies shouldn't fix issues because they've adversely affected someone, they should fix them on discovery and address even minor security concerns as if they were mission critical problems.

SMB2 Vulnerability -- Affected Platforms

Tue, 08 Sep 2009 15:23:04 -0800

Hey All, just a brief blog post here to outline what we're seeing with regards to the SMB2 vulnerability.

We've tested the these platforms with the following results:

Vista SP1 - Crash
Server 2008 SP2 - Crash
Windows 7 RC - Crash
Windows 7 RTM - No Crash
Server 2008 R2 RC - Crash
Server 2008 R2 RTM - No Crash

We've also had reports that others are seeing the same with Win7/2K8R2. It looks like it's only the RC that is affected.

Vista/Windows 7 SMB Blue Screen of Death

Mon, 07 Sep 2009 23:11:56 -0800

It would appear as though this has been a bad month for Microsoft. We started the month with the IIS FTP DoS and now, less than 24 hours before Patch Tuesday officially kicks off, we have a SMB BSD (reportedly affecting Vista, Windows 7 and possibly 2008). I have confirmed that it works against Windows Vista. The report, along with source code, was released on the vulnerability discoverer's blog

Microsoft's !exploitable Crash Analyzer reports the following:

1: kd> !exploitable
Warning: Unable to read from the TEB in the current thread.
Warning: Unable to read from the TEB in the current thread.
Exploitability Classification: UNKNOWN
Recommended Bug Title: Data from Faulting Address controls Branch Selection starting at srv2!Smb2ValidateProviderCallback+0x00000000000004ec (Hash=0x4f46440f.0x7c4b5e55)

The data from the faulting address is later used to determine whether or not a branch is taken.

The standard advice of blocking ports 139 and 445 is pretty solid here, and another option for people (a standard step I take before attending any conferences) is to disable the server service.

nCircle customers can use the following Focus query to find vulnerable systems:
(os:"Windows Vista" or os:"Windows Server 2008" or os:"Windows 7") AND app:"Direct SMB"

The Browser Landscape is a Scary Place These Days

Wed, 22 Jul 2009 10:05:09 -0800

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.

Nmap 5.0 Released!

Thu, 16 Jul 2009 09:12:22 -0800

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

Enough is Enough

Wed, 15 Jul 2009 10:27:26 -0800

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.

Microsoft Enables Drive-By Downloads in Firefox

Fri, 22 May 2009 14:50:28 -0800

Chris Sullo has a post out over on the HP Security Labs blog on his experience downloading Google Chrome. He clicked and it was installed... no download prompt, no installer, nothing. I actually experienced it this morning before I left my apartment but in my haste said I'd wait until tonight to explore further. I really thought I was going crazy... I'm glad to know that I'm not, or at least not in this case.

I don't know if horrified is a strong enough word to express how this makes me feel. Shocked, disgusted, sorry I've ever defended Microsoft in the past... these are a few things that come to mind. Not only did they undermine the security of Firefox... they've destroyed my trust in them. How will I ever feel comfortable accepting another Microsoft update (after all, that's how .NET came to be installed on my computer). Had I went and downloaded it... sure, but I didn't I did what we in the security industry tell every individual to do... I installed my available updates. I even reviewed them but there was no note that read "CAUTION: This will decrease the security of your computer".

Microsoft has managed to successfully allow drive-by downloads in Firefox. My skin is crawling... and unfortunately if my wife is at home browsing right now my computer probably is to.

Some Thoughts on the OWASP Top Ten

Tue, 19 May 2009 09:47:40 -0800

Over the past few weeks, I've been looking at the OWASP Top 10 and thinking back to my time spent as the Sys Admin for a SMB. As the technical resource at the company... web app development also fell on my shoulders. This wasn't simply building the company website, as I worked for a marketing company this included full blown web applications for clients. Now prior to joining nCircle, I lived and breathed security... it was (and still is) my passion. This isn't the case for Sys Admins and developers at other SMBs and even larger enterprises. Security is often an afterthought.... sometimes a "way-afterthought". For these people, the ultimate resource to turn to is the OWASP Top 10, the ten most pressing concerns in web application security decided on by experts in the industry. The OWASP Top 10 "represents a broad consensus about what the most critical web application security flaws are" and the people at OWASP "urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws." I don't disagree with this, if everyone takes the steps to prevent these flaws, we'll have a safer online world.

That being said, given the OWASP stated purpose of the Top 10, I don't feel that it is written to best represent everyone who uses it. The Top 10 often feels as though it is written by industry experts for the rest of the industry. This isn't, in my mind, what the document was intended to do. The Top 10 may be referred to by pen testers or web application researchers to reference, but it's primary goal is to raise awareness and provide assistance to developers. Many of these developers aren't security oriented and simply write code... look at the colleges and universities, they have programs pumping out plenty of web developer grads who have never seen a course on secure coding. Usability is number one is many of their projects. It is these people that I feel the Top 10 fails... it doesn't give them something they can easily work off and to me that should be the primary goal of a project such as this.

Let's take a look at two scenarios.

Scenario #1

Imagine you work for a small marketing company with less than 30 employees. You are the sys admin with all the regular sys admin duties, however you are also tasked with the responsibility of building web applications and/or web sites for customers and for use within the company. You have limited time and take the OWASP Top 10 as your guide to securing the application you are building. You aren't security oriented and someone pointed you toward the document. If you first tackle A1 (XSS) you'll read the following: "Cross-site scripting, better known as XSS, is in fact a subset of HTML injection. XSS is the most prevalent and pernicious web application security issue. XSS flaws occur whenever an application takes data that originated from a user and sends it to a web browser without first validating or encoding that content." You follow the advice of "Ensure output is passed through htmlentities() or htmlspecialchars()" and continue on to the next line item A2 (Injection Flaws).

Here you read this description, "Injection flaws, particularly SQL injection, are unfortunately very common in web applications. There are many types of injections: SQL, Hibernate Query Language (HQL), LDAP, XPath, XQuery, XSLT, HTML, XML, OS command injection and many more." As stated you aren't a security person, this is a job that you ended up in but one of the things you notice is the mention of HTML Injection. Why does that sound familiar? Oh yeah, A1 was a subset of HTML Injection... well I've protected against A1, that must mean I'm good here and you move on to A3. STOP! How about we look at the other types of injection (perhaps SQL Injection) and protect against those as well. Right now, reading this, you are thinking that no one would ever do that... but it happens. Now why does it happen?

A1 is XSS and A2 is Injection Flaws. XSS is a subset of HTML injection which is a child of Injection Flaws, yet it's also been made a peer of Injection Flaws. There is a logic flaw that exists here and it is enough to cause confusion for many people.

Scenario #2

Now let's imagine that you are an enterprise with separate teams for Development, System Management and Security Auditing. Company policy states that audits must be done before Web Applications go into production and again immediately after going into production. The criteria for the audit is defined by the OWASP Top 10. Development and QA have done their part and the application is audited internally. The application passes audit (no vulnerabilities according to the Top 10) and sent off to System Management for deployment. The system is deployed and a follow-up audit is performed. Again no issues are found and the web app is live. Two months later a report comes in that your web app has been blacklist for serving malware. An investigation ensues and sure enough, live malware is being distributed... the website is pulled down and forensic investigation reveals that a flaw in the server software was used to upload malware to the server. If the auditing team had been using the 2004 edition of the Top 10, they would have discovered this flaw, however Insecure Server Configuration was removed from the 2007 edition of the list.

Now as I said, I've been considering the Top 10 for quite some time, and both of these potential situations have caused me some concern. Last week I started to consider this write-up on the subject and instead decided to contact the Top 10 mailing list to discuss these issues. While the readdition of Insecure Server Configuration seems to have been well received the problem that I see in XSS and Injection Flaws has not. I understand that the people responsible for this list are considered industry experts and I don't meant to slight anyone by making the suggestion that the current list is flawed. That being said, since a new version of the list is planned, that means the current iteration isn't perfect and that there is room for improvement. I believe that this area is one of the areas where improvement can be achieved, but I'm not so full of myself to think that because I believe it, it must be true.

I fully understand that in the past, it made sense to distinguish between XSS and SQL Injection, they were two major issues that needed recognition. I'm not sure though that the categories XSS and Injection Flaws properly represent the issues at hand. With more and more people referencing the Top 10 and the PCI Security Council leaning heavily on it to define web related portions of the PCI-DSS, I feel we need to make it as clear and concise as possible.

That being said, there are three ideas that I feel more properly describe this situation:

1) Drop Injection Flaws from the list, if the important items are XSS and SQL Injection and we don't want to combine them for fear of a loss of importance, then why lump SQL Injection in with anything. XSS and HTML Injection are closer than SQL Injection and HTML Injection yet they are not defined in that way. So A1 would be XSS and A2 would become SQL Injection.

2) Merge XSS into Injection Flaws. Make Injection Flaws A1, leaving A2 open for the current "risk de jour" and lump them together in a way that makes them technically accurate and easier to understand.

3) Create the OWASP Top 20, or two separate Top 10 lists. One that identifies the buckets of larger groupings (Injection Flaws) and the other identifies the specific vulnerability classes (XSS, SQL Injection, etc).

As I said, this didn't receive the warmest welcome on the OWASP Top 10 list, but I can't help but wonder if it's a matter of the experts not being able to place themselves in the shoes of the people using the list. This is a common and easily made mistake in our industry, we become so comfortable and familiar with the material that while it makes sense within our own grouping, we forget that the material needs to be referenced and acknowledged by people that don't live with our mindset.

Off to CanSecWest

Tue, 17 Mar 2009 09:25:52 -0800

Just wanted to let everyone know that I'm off to CanSecWest for the remainder of the week. If you're going to be there and want to talk security, nCircle, VERT or anything really... Feel free to track me down. You can also ping me on twitter (@treguly).

Patchigation: How much do you want to know?

Sun, 15 Mar 2009 19:20:34 -0800

Recently Microsoft released a blog post addressing MS09-008, after I raised an issue with it. I think it's clear where my colleagues and I stand on the issue, but here's a quick summary for those who haven't been following ...

The MS09-008 "patch" provides the functionality to apply a mitigation (Global Query Block List) and the application of the mitigation. One of my colleagues even coined the term "patchigation", since the issue is never actually patched. To patch the issue Microsoft would have had to block the ability to set wpad and isatap entries dynamically and they chose not to do this. Instead they have mitigated the risk of a malicious entry by providing a method of blocking the valid response from being sent.

So where does that leave us?

Before Patchigation

Attacker sends Dynamic Update to set the wpad entry to a malicious target
DNS Stores wpad entry
Victim queries DNS and is provided the malicious wpad entry

After Patchigation

Attacker sends Dynamic Update to set the wpad entry to a malicious target
DNS Stores wpad entry
Victim queries DNS and is told the address doesn't exist

After a proper Patch (which isn't available)

Attacker sends Dynamic Update to set the wpad entry to a malicious target
DNS Rejects wpad entry

The reason I originally brought this issue to light was because Microsoft chose function over security and decided that if a wpad entry already existed, the mitigation should not be applied. So we can actually break out 'After Patchigation' into "wpad" and "no wpad" .

After Patchigation - no wpad

Attacker sends Dynamic Update to set the wpad entry to a malicious target
DNS Stores wpad entry
Victim queries DNS and is told the address doesn't exist

After Patchigation - wpad (valid or malicious)

Attacker sends Dynamic Update to set the wpad entry to a malicious target
DNS Stores wpad entry
Victim queries DNS and is provided the malicious wpad entry

But I thought I was patched? Why didn't Microsoft inform me about this?

To be fair, Microsoft did provide information about this (strictly speaking) - the advisory contains a Known Issues link that points to a knowledge base and that knowledge base contains a single line, halfway down the page to inform you that wpad and isatap entries won't be created if they existed prior to the host being patchigated. It's not directly referenced in the advisory, and the Known Issues" link wasn't added until after I contacted Microsoft and wrote my initial blog post, but I digress ...

Microsoft has since commented that it is not the goal of an update to undo an attack that has already taken place and that customers are encouraged to apply the update. I do not believe they should aim to undo previous attacks and I firmly believe that customers should apply the update. The update addresses more than the WPAD issue and we have encouraged our customers to apply the update from the time it was released.

I do, however, believe that this practice of patchigation is a dangerous practice. By burying a packaged mitigation within the monthly patches, Microsoft leaves customers who have already been compromised with a false sense of security that there is no problem. As I've said many times in the past, I'm a big fan of Microsoft's Security Program in general. As a Security Researcher however, my appreciation has to take a back seat to exposing risks as I find them. This one is risky, I found it, and I exposed it.

Microsoft has also stated that no previous patch has ever undone an attack. This is not the first time I've heard the argument that patches are not aimed at undoing an attack, and I feel the need to be clear - I do not expect a Microsoft patch to undo an attack, I expect a Microsoft patch to effectively prevent future attacks. This patchigation does not do that.

If a wpad entry exists, the mitigation is not applied. Since the patch and mitigation are one and the same, that means that the issue is not actually remediated. It's not a matter of undoing the single attack that's taken place already, it's an issue of not preventing future attacks. This same issue holds true for organizations with valid wpad entries, the mitigation isn't applied (as Microsoft has indicated, there's no way of knowing if an entry is valid or not) and therefore future attacks can occur. So this isn't about undoing a single attack, this is about preventing future attacks. I suspect customers' expectations are the same as mine: once I'm patched, I'm immune to future attacks.

So I put the question to you: Is patchigation good enough? Whether you think it is or think it isn't, how much do you want to know?

Functionality Versus Security - Who Wins?

Wed, 11 Mar 2009 21:11:49 -0800

I wanted to share the response that I received from Microsoft and provide some of my own feedback. I must admit that I was initially floored by their response, which was:

"Thanks for bringing this to our attention. While I understand your concern, this is in fact expected functionality of the security update."

[removed discussion of issue]

There are important reasons why this path was chosen: it is not possible to tell legitimate WPAD entries from illegitimate ones that were loaded by attackers. Hence our need to accept an already "existent" entry as being valid.

They also pointed me to a KB that references this issue. What's interesting is that this KB wasn't referenced in the advisory release; it was added today as a 'Minor Update'

V1.1 (March 11, 2009): Clarified that CVE-2009-0093 does not apply to supported editions of Windows Server 2008. Added a link to Microsoft Knowledge Base Article 962238 under Known Issues in the Executive Summary. Clarified what systems are primarily at risk for CVE-2009-2033. Finally, updated a finder acknowledgment for CVE-2009-0233 and CVE-2009-0234.

I was then asked in future to wait for a response from them before having such discussions publicly. Anyone who knows me knows that I fully support contacting the vendor when you have a newly discovered vulnerability and I've always reported my findings to Microsoft first. In this case, however:

This was not a newly discovered vulnerability. How to exploit the vulnerability was already public knowledge.
This public discussion did not benefit malicious individuals. It did, however, raise some awareness with Microsoft's customers who may believe they are adequately protected when they are not.

So why was I floored by Microsoft's response? They didn't actually patch this vulnerability; instead they introduced a means of mitigation and deployed that mitigation in the update. That alone would be fine. The issue I have is that they have punted security altogether in the interest of functionality. The responsible thing to do would be to find a balance between the two.

There are a number of approaches that Microsoft could have taken here, that they chose not to take:

Provide a simple message during installation of the patch, notifying the user of existing wpad or isatap entries in the DNS server zones and informing them that the intended mitigation would not be applied.
Modify the way that dynamic updates work to provide a dynamic update block list, restricting wpad or isatap from being updated dynamically. As it stands right now you can still submit updates for these, they just wont be resolved if they exist in the global query block list.
Add both entries to the global query block list and allow users to go back and remove them if the functionality was required.
Bring this case to the public as part of the original Advisory if they already knew about it.

These are quick examples from a long list of alternative approaches that could have been taken - each of which would have provided more responsible guidance to their customers than the "don't ask; don't tell" method that they chose.

I'm probably the the biggest Microsoft supporter within VERT. I'm a huge fan of the work they've done to improve security across the board. That being said, I can't help but see this as a step backwards. I understand the need to preserve functionality, but not at the cost of sweeping security issues under the rug. Simply providing a comment within the original advisory would have been a step forward. Instead, no notification was provided to their customers until after I had brought the issue to their attention. Even then, the response was a single line linking to a KB. That KB contains a list of other KBs and one of those contains a single line indicating that this may occur. This suggests that Microsoft was aware of this issue and released their update with minimal concern for security. I believe their customers deserve more.

Earlier today, Larry Seltzer commented that "Microsoft updates don't undo exploits". This is 100% true; however undoing the exploit in this case would be reverting a configured wpad/isatap entry. I'm not asking Microsoft to undo exploits; I'm simply asking that they provide the mitigation that their advisory claims it will provide or proactively advise customers that a particular risk has been accepted on their behalf.

In this case, they provided neither guidance nor remediation.

Winner: functionality by technical knock out.

Successful Exploit Renders Microsoft Patch Ineffective

Tue, 10 Mar 2009 23:45:27 -0800

Patch Tuesday can be a long night for a VERT Engineer. With nCircle's 24-hour Patch Tuesday SLA, we work long hours to ensure our customers get the best detection available. These nights are usually filled with coffee, bad jokes and really bad music. Tonight was a little different... as it included a cool yet disturbing discovery. The discovery was that the patch for MS09-008 is highly flawed in it's patching of CVE-2009-0093.

This vulnerability allows users to set a WPAD entry in DNS when dynamic updates are enabled. Internet Explorer, configured to "Automatically Detect Settings", will query for this WPAD value and attempt to download proxy settings from the associated server. This could allow an attacker to Man-in-the-Middle the connection.

The flaw that I discovered is with servers that have already been exploited – in that compromised servers will already contain a WPAD entry. I initially thought, "No Problem! The block list will keep me from getting a response," but I’m a researcher, so I had to be sure.

It turns out that this isn't the case. Instead, the patch checks to see which entries have been created in the DNS server and *only adds block list entries for values not already being served*. In other words, if your DNS server contains an entry for WPAD and you apply MS09-008, the block list will not have WPAD added to it. Subsequent queries for WPAD will continue to be answered and if the WPAD entry is from a previous attack, your users will continue to be Man-in-the-Middled - even after you are patched.

This has serious consequences, as enterprises may mistakenly believe that this vulnerability has been remediated on compromised servers. After all, the patch appears in the 'Remove Programs' dialog and the patch registry keys are created. As a result patch management solutions and Microsoft’s Automatic Update service will likely report incorrectly that the patch has been successfully applied.

To verify that you are indeed effectively patched:
Check that HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList contains both 'wpad' and 'isatap'

Note: Although WINS also makes use of a query block list (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WINS\Parameters\QueryBlockList) WINS is not affected by this issue.

We have contacted Microsoft to notify them of this issue and are awaiting a response. VERT’s checks confirm that the vulnerability has been effectively remediated. If you’re not an nCircle customer, follow up with your vendor to ensure that they are checking for more than just the presence of the patch.

Where PCI Fails

Fri, 30 Jan 2009 13:08:15 -0800

Anton Chuvakin has an interesting post up on how PCI could have possibly failed in the Heartland issue. I had initially planned to avoid talking about Heartland has it has been blogged to death, resurrected and blogged to death again.

Anton gives 5 possibilities as to what could have happened and they are (summarized):

1. Bad QSA
2. Compliant but a password was set to something simple following the tests
3. Non-Compliant but begged for a card brand to say they were OK
4. Compliant but hit with malware that bypassed PCI-Mandated Controls
5. Compliant but an employee walked out with the data.

After laying out 5 possible options, Anton asks (rhetorically) for comments on "which of these cases indicates that "PCI failed"". I almost commented on his blog but decided instead to write a blog post. I disagree with his opinion that none of these are PCI failures.

I don't know that PCI can (realistically) do much about #2, #4 and #5, but I do believe that PCI has failed if #1 or #3 is the case. I should preface this by saying that I'm a huge supporter of PCI-DSS. While the program may not be enough on its own, it's a start and a start is what we need right now.

The fact that card brands are ultimately responsible for certification is a problem, and ultimately this is a failure on the program ... period. No exceptions, No Mulligans ... do not pass Go, do not collect $200. What good is a certification if the certification group is off to the side and doesn't preside over the final decisions. It reminds me of the various IT/IS certifications and how there are two camps with nearly a 50/50 split on their usefulness, and worse yet, it creates too many "not my jurisdiction" cracks for things to fall through. The SSC creates the DSS and trains/certifies Assessors to audit against a supposedly objective standard that is subjectively governed by 5 different Card brands.

Now the bigger issue (in my mind) ... the "Bad QSA". The existence of "easy grader", "we just look at the docs", "pay per compliance" QSAs is definitely evidence of a PCI failure. QSA FAIL. PCI SSC FAIL. PCI PROGRAM FAIL. This is one of the reasons why "PCI" struggles to be taken seriously by the Security community. nCircle is a certified ASV (I don't think that's a secret (if it is... well now you know :) )). I'm actively involved in the preparation, completion, and ongoing maintenance of our certification. We invest a lot of time and energy to ensure we're as good as we can possibly be ... because we feel that it's important. Subpar audits are not acceptable. If you are barely hitting your mark as an ASV or QSA, you should be gone.

So in the end, yes... there are scenarios proposed by Anton where PCI fails, but that doesn't mean we should disregard PCI or throw it away. It means we should work to solve these problems and evolve the standard to something that works. As long as we in the community give the PCI Security Program a free pass when it falls down, we become a part of the reason for its failures. Criminal and Civil Codes exist so citizens, law-makers, police, judges and lawyers have a common understanding. The PCI Security Program has not yet evolved to provide this common understanding and until it does, there will continue to be instances of PCI FAIL.

The IE Vuln & A Monthly Patch Release Process

Tue, 16 Dec 2008 10:40:05 -0800

As I'm sure everyone has heard by now that there's an IE 0-day floating around. The result of this 0day is that some people are questioning if the monthly MS Tuesday is really a good idea these days. The alternative is that patches could be released as soon as they are available.

I'm still of the opinion that MS Tuesday is the right way to approach the issue. We've seen other large enterprise vendors follow in Microsoft's footsteps. I'd say there are two main reasons to keep a monthly patch cycle. The first is for system administrators and their already hectic lives. Imagine if patches were released randomly as they were ready. This year saw 77 bulletins for Microsoft products. If they were "released as ready" that would have resulted in more than a bulletin a week... and we're talking about the bulletins, what if each patch was "released as ready". For example, what if every IE vuln was patched individually, or each Office vuln? This month's advisories patched 28 unique CVEs... that's almost one a day over the course of the month. It would be unreasonable to ask admins to maintain a respectable level of patch status.

My second reason is related to consumers. We constantly see reports of unpatched boxes and users who dislike the patching process. If Windows Update starts offering daily or weekly patches, end users are going to give up on patching. It will become a chore for them.

Yet many people want patches as quickly as possible, so how do we solve this problem? Why couldn't the solution be a public beta patch program? I know Microsoft has a patch beta program that enterprises with large deployments can get involved with, people who have the labs to provide feedback on a larger scale. This would be more consumer / small business focused, since they don't qualify for Microsoft's current beta patch program. Although, that's not to say that enterprises couldn't choose to go this route instead. Interested parties can sign up to download the patches themselves. These patches would be available after development and before Microsoft begins QA (or perhaps after initial QA, this point could be decided on in the future).

Admins who want to test serious issues in their labs to ensure a faster rollout once the official patch is released could choose to do so. End users who have been calling out Microsoft for not releasing patches more quickly and for sticking to their monthly schedule, could download these beta patches and make use of them.

Now... I can hear the argument already. Malicious individuals will download the beta patches and reverse them to find the vulnerability. This is true, I'm not going to argue it but they're finding the vulnerabilities right now and making use of them. Perhaps this public beta program is only used for already public vulnerabilities or perhaps we look at the alternatives. To flesh this out a little further... the bad guys will always find the vulnerabilities. Whether they find them today or tomorrow is of little difference, they will find them and somebody will be unpatched. The best we can do is hope to protect as many people as possible. With actively exploited vulnerabilities, I propose that the answer is a beta patch program such as this one.

As I said, maybe that isn't the case with private vulnerabilities. Since they sit quietly without being discovered, sometimes for months on end. However, if it's a choice between a beta program and "release as ready", I would prefer the beta program. It gives users a choice without making the end user feel pressured to patch. If there's valid reason for an out of band advisory (MS08-067 for example) then by all means release it, however we have to weigh the security of the end user with the capability of the end user.

If we make the move to 'release as ready' administrators will have major backlogs and consumers will ignore patches. So the malicious individual will reverse the patch and still have plenty of viable targets. I believe that 'release as ready' is no less dangerous than a public beta program and there's more benefit to the public beta program.

I'm sure that someone somewhere is saying "release as ready" is the same as the beta program, in that people can get the patches earlier than with a scheduled monthly release. This is true... and when I think 'people', I'm thinking hackers. If the "hackers" reverse the beta patch and produce an exploit, then we have an active exploited vulnerability without an official patch and this is a problem. Then again, it's not unlike having a ZERT patch... in fact I consider ZERT to be evidence that a public beta patch program is a good idea. But let's look go back and look at the "release as ready" idea through the eyes of the consumer though.

I come home from work, sit down to use my computer and that little yellow icon is telling me I have updates waiting to be installed. I click install, start typing emails and 5 minutes later I'm told I have to reboot. I save my work, reboot, wait for my computer to come back on, log in, wait for my software to load (I know... you're getting impatient reading this sentence but imagine if you're this end user) and finally I'm back to work typing that same email. Now imagine that this happens more than once a week. What is that end user going to do? They're going to get fed up and disable automatic updates. Now we have a user that is less secure than they were on the monthly update cycle... because once a month they could handle, but this weekly (or even daily) process is unbearable. At this point we have a worse situation then we did with a monthly patch release and a beta patch program.

So in the end, the Pros and Cons of a Public Beta Patch Program are:

Pros:
Monthly Update Cycle is maintained.
Patches are available to those that desire them.
We don't inundate the end user with patch releases.

Cons:
Malicious Individuals could determine the vulnerable condition

As I said though, I believe this con exists with the 'release as ready' program as well, yet it doesn't have the potential pros. That being said, I'm definitely for the idea. Thoughts, Opinions and Comments from others?