nCircle.com >> 360 Security

Web Poll


Find us on Facebook

Twitter nCircletweets

January 29, 2010

BofA Website Outage - A Giant PR Mistake

For a lot of Americans, today is both a payday and the last business day to pay those bills online due this month. So it goes without saying that many people have noticed that Bank of America's website has been unavailable for most of the day.

A quick search on twitter shows many Americans complaining about the site being down. Yet, so far only a few news organizations are covering the outage. The only official word from the company has come from its twitter account ( http://twitter.com/BofA_help ). Apparently, they feel that the outage is only affecting a few people by issuing a statement, " We are aware some customers are experiencing access issues. Our tech team is working to resolve as soon as possible." Those news organizations covering the outage all report no word back from the company.

Meanwhile, speculation is on the rise that the company is in the midst of a cyber attack. This is turning into a giant PR mistake by Bank Of America. For a company that took billions of federal assistance, this would also seem like something our new Cyber Czar should be looking into. We must not forget that at the very least, one tenant of information security is availability.


January 16, 2010

Is Google to blame for the IE 0-Day Hype?

The sudden hypersensitivity regarding a new Microsoft IE 0-day, traces its roots to this weeks Google's overhyped breach. On Tuesday, Google went public with an admission of its own compromise. This was no ordinary breach, but one of global proportions that claimed they and 20+ other companies were all victims of state sponsored cyber thiefdom. Everyone suddenly became aware of China's cyber terror potential.

Queue the Beethoven.

While most everyone assumed the public Adobe PDF flaw was the attack vector, we should have more correctly assumed not one but many attack vectors were at play. Come Friday, in an unexpected turn of events, Microsoft was taking the brunt of the blame in a newly announced IE vulnerability. Microsoft is getting a bum deal here and has much of it to blame on Google's overhype.

What if we replayed this week's events with a different set of goggles?

Suppose that Google had not raised its own compromise to the level of state sponsored cyber terror, while threatening its own retaliation by ceasing censorship of search data. Furthermore, Google didn't need to announce that some 20+ other companies were also victims. At this point, the other companies have very little reason not to come forward. They can safely join the ranks of the others affected and cleanly play the victim role of being attacked by a state sponsored cyber terror. Yet, very few have come forward despite all having been notified.

It would seem to me this was an obvious calculated overhype. The event provided the perfect set of excuses for Google to combat Chinese censorship while giving them an alternative reason to pull out of China. It's a win-win for Google - fight Chinese censorship, support Chinese human rights activists and cleanly exit a failing business venture.

With any good attention diversionary plan an unexpected victim arises.


Take the facts of the IE vulnerability independent of all external events. What we have today is a bug in all versions of Internet Explorer, but so far only weaponized for IE version 6 on Windows XP. As usual, DEP and ASLR are providing significant mitigation with IE8, Vista and Windows7. The net of these findings is that today's attacks are only successful on Windows XP with IE6. Jonathan Ness of the MSRC engineering team spelled out these important facts in a blog post Friday evening. In an ordinary humdrum month, the vulnerability would be worrisome, but not epic.

Zero day attacks happen every day. Even the most secure organizations get compromised. Everyone is a target, everyone will be a victim. Take a few deep breaths.

December 9, 2009

Security Through Obscurity and the TSA

ABC news reports today that the TSA screening manual was accidentally posted online with formerly redacted information included.

"This is an appalling and astounding breach of security that terrorists could easily exploit," said Clark Kent Ervin, the former inspector general at the Department of Homeland Security.

It's not hard to conceive of why this is considered a breach, but it really should be. As [information] security professionals it should be extremely hard to understand why the TSA would create a screening process that relies on maintaining the secrecy of the process itself to be effective. First of all, it's very nature (a process that all screeners must follow) means that it's not a secret: all of the screeners know the process by definition. I'm willing to bet that this public disclosure isn't the first disclosure. Somewhere out there is a screener who made a tidy profit selling this very document. And the TSA should have expected that. All that this incident does is level the playing field between the bad guys (who already knew all of this) and Joe Businessman who doesn't want to miss his flight.

In fact, the TSA should have published the process in its entirety publicly to begin with.

One of the points in this article is that the data leaked included instructions for identifying CIA, ATF, and members of congress for alternate screening or no screening at all. First, if I'm a capable terrorist, you've got to assume I can reasonably (visually) replicate these credentials already. Until you have some cryptographically secure ID for these individuals, it's just a given. Secondly, a screening process that has a loophole better ensure that the identification to use that loophole is well secured. But let's give the TSA a little more credit than ABC news does. In fact, if you dig into the document, you'll find that armed Law Enforcement Officers (LEOs) are required to pre-authenticate via a secure network: "they will now obtain a unique identifier code from the TSA via a secure law enforcement network." You can't just walk up to the checkpoint, present an ID and board a flight while armed.

The article also points out that this manual contains a list of items that do not need to be screened, i.e. where to hide things from the TSA. This is a list that could be reasonably assembled by just about anyone who travels frequently. It's a list that can be obtained through observation, and as such it's already not a secret.

I think we all know that the existing airport screenings are minimally effective. Bruce Schneier has some nice pieces on how we might improve them. In the end, the only shocking thing about this breach is that it might have any effect on actual security whatsoever.

The TSA Screening Manual

Images of Credentials

October 5, 2009

Obsolete Software

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.

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.

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 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"

Authors