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

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.

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.

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.

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"

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.

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.

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/'

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'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.

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.

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.

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).