360 Security

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"

A Collection of Computing Laws

Sun, 23 Aug 2009 12:37:59 -0800

My kids were asking me about laws and I told them there were laws in computing. As always they did not believe me so I had to gather my evidence. Here are a few I took the liberty of summarizing.

Cargill's 90/90 Law: The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time --Tom Cargill

Page's Law: Software get twice as slow every 18 months -- Larry Page

Brooks' Law: Adding manpower to a late software project makes it later -- Fred Brooks "The Mythical Man-Month

Metcalfe's Law: The value of a network grows proportional to its number users squared. -- Robert Metcalfe

Amdahl's Law: Multiple CPU cores are only as fast as the slowest serialized code -- Gene Amdahl

Moore's Second Law: As CPU transistor counts grow geometrically, so does the cost of manufacturing. -- Gordon Moore

Asimov's Three Laws of Robotics: Protect, Obey, and do not Injure Us -- Isaac Asimov

I said that if they could prove any of these wrong, I'd give them 5 bucks. :-)
--tk