nCircle.com >> 360 Security >> VERT

« July 2009 | Main | October 2009 »

September 2009 Archives

September 7, 2009

Vista/Windows 7 SMB Blue Screen of Death

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"

September 8, 2009

SMB2 Vulnerability -- Affected Platforms

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.

September 30, 2009

The Little Things

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.

About September 2009

This page contains all entries posted to VERT in September 2009. They are listed from oldest to newest.

July 2009 is the previous archive.

October 2009 is the next archive.

Many more can be found on the main index page or by looking through the archives.