Monday, June 30, 2008

Top 5 Reasons WAF Will Not Die

I'd like to say that we've beaten the WAF (or as I call it a WaIDS) topic to an absolute bloody pulp... but I guess I'm wrong. A shining example is Marcin's TS/SCI security blog, which if you read their "Week of War on WAFs" is very technically accurate and packed with information - but doesn't address the real-world issue that continues to drive WAF adoption in the business world. Let's face it, there are a bunch of WAF companies out there and they're not all going belly-up - in fact, they're making a killing with the PCI DSS deadline today! By the way, this blog entry is a great read, if you are looking for some more analysis on the topic of PCI DSS and the June 30th deadline.

So as I thought about this (again) I decided to come up with the top 5 reasons why Web Application Firewalls are and will continue to be deployed in world of PCI DSS requirements. So, here it is... the list.

Top 5 Reasons why WAFs Won't Go Away
  1. The PCI DSS - [... and to be fair, other regulations] While it may not be accomplishing total security, as many people have already pointed out - WAFs do at least a minimalistic job of upping the security on a lot of credit-card processessing sites.
  2. IT Security Managers - Let's face it folks, if you're in charge of a large IT company's security team you've got a monumental job ahead of you. You can either try and turn the titanic and get developers to write better code (should only take 2-3 year or so) - or you can spend some cash and throw in a WAF optionally in block-mode... the PCI DSS says nothing about being in block mode! *(More on this in a future installment)
  3. Legacy Code - Legacy code sucks because it is hard to secure... primarily because you very rarely have the source. And even if you do have the source code, good luck figuring out what that code that was written 7 years ago and not commented on does.
  4. Clueless Management - If you don't believe WAFs will continue to exist because execs just don't get web application security - you should stop smoking crack, seriously. Executives are looking for quick ways to solve the "Are you PCI Compliant yet?" questions - and a "slap this box in, and you're done" approach that WAF vendors sell is irrisistible.
  5. Developers Still Suck - I'm sorry, but it's true. Whether they're off-shore, on-shore, in China, India, the US or the Moon developers are continuing to write bad code in alarming numbers. Pick up XSS Assistant for GreaseMonkey (FireFox plugin) and you can surf thousands of sites that are susceptible to parameter validation issues (XSS, SQLi, etc); this doesn't even account for the more complex logic issues that require some probing.
There you have it. WAFs will not be gone any time soon. Whether I agree with the assessments that they're best suited for doorstops and boat anchors or not - they're not going away and we need to figure out a way to move that technology forward and make it more intelligent and more "secure"... otherwise it'll be just another security failure that's blamed on the industry as a whole. And the reality is - if that happens, we've all failed.

Cheers.

Monday, June 23, 2008

Cell Phone as Boarding Pass

If you haven't caught this yet, the details are very scarce (let me know if you find anything worth posting, besides what's in this InformationWeek article already) and no one seems to be giving away more than the absolutely bare press-release... I can only imagine the ramifications of being able to not only use your cell phone for "boarding pass" purposes but other things now. Can you imagine the social engineering/hacking that'll go on?! I wish I knew more... like what the "encryption" will be used for? Will they simply just barcode-style scan your phone device?

Figures... spoke too soon. More info here.

As a commentary - I find it interesting that I've been "checking in" virtually on United Airlines and American Airlines for months now... and printing my own boarding pass. Is this any more convenient? To have a barcode on your phone rather than on a piece of paper? Maybe...

The Product Formerly Known as WAF

I've read too many blogs about how the Web Application Firewall (WAF) is a misnomer, and I've come up with a solution. I would like the entire micro-niche of current WAF vendors to change your name to ...
"Web Application Intrusion Defense System" or WaIDS for short

This makes far more sense than calling a product which is *not* a firewall exactly that - and it solves the issue of that managerial response "but we already have a firewall". Doesn't this make so much more sense? I'm serious. The new name would convey the idea of what a WAF actually *is* and give the technology actual meaning, and better sense of purpose.

In addition to the brilliant new name, here are the Top 5 things that WaIDS should advertise itself to solve:
  1. Short-term detection of known web application security defects
  2. Security support for legacy web-based applications (those not likely to change)
  3. Layered (defense in-depth) security for well-established application security programs
  4. Auditing, auditing, auditing of web-application attacks
  5. [I can't think of a 5th one]
There you have it. I've solved the problem. Next?

Friday, June 20, 2008

Application Security - Logic Flaws

Web Application Security Scanners are great tools, in my opinion, and they are getting better and better at finding a wealth of flaws with the applications - but one perfect example of what humans are required for is the following. This is a real-world example - obviously I can't reveal the client but if you know me then you've heard this story and you know exactly who I'm talking about... my point though is the company this happened at is irrelevant. The real issue is the problem, and how it was detected. The example shows how a human being using a black-box scanning tool was able to find a logic flaw within an application that would have been catastrophic if exploited in production... a combination of technology and people with a sprinkle of process saved the day - sort of.

Imagine the following scene... A web-based application, heavily relying on database connectivity, is built in J2EE and about to be released to production. The security team, as typically happens, has to "certify" the application code as 'secure' before production. Let's take into account that the application was just load-tested with 10,000 concurrent users and it breezed through testing.
Security now gets this application and runs a black-box scanner (doesn't matter who the vendor is) against it. The application "halts" after just 10 requests. By halts I mean becomes non-responsive, and effectively dead. Obviously this test is repeated 2 or 3 times, once the app server has been restarted and the same exact result comes back. 10 requests sent, app stops responding... effectively it's dead.

At this point the project manager starts to panic, and the blame-game ensues. Clearly it's the security team's "fault" for breaking the application. Once this idiotic argument gets slapped down, rationalization begins - "well, it worked perfect with 10,000 users, what are you doing different (besides launching attacks?))?" A few days go by, the tests are repeated a few times but the result is always the same. The app server is restarted, and it sings perfectly until the black-box scanner sends 10 bad-data requests, at which point it falls over.

After a week of this, the security analyst asks to step in and analyze the logs to try and help. By now the project is behind schedule for release and people are starting to get very upset. A look through the logs around the time the scan was run produces very strange "Connection pooling" errors from the app server. Basically, there is a connection pool that is being exhausted, and the app just stops working, waiting... indefinitely.

The moral of the story was - after a week of developers trying to figure it out, it took the security analyst looking at it for 5 minutes to isolate the validator function and laugh as the solution was painfully obvious.

Here's the pseudo-code... enjoy figuring this one out - feel free to post replies...

MainDataValidatorFunction ()
{
open DBConn
if dataIsValid
process request
close DBConn
return (1)
else
return (0)
}
OOPS?

Las Vegas Hotel Security

Las Vegas hotel security is apparently taking pointers from the TSA. You've all heard (or read) me rant about how the TSA is trying very hard to give the "perception" that commercial flight is more secure but the reality is much different... apparently the hotels here in Las Vegas are following suit.

On a recent business trip (still here as I write this) to Vegas I had occasion to stay at the Palazzo hotel, gorgeous in every way including their preception of security. As you walk towards the guest suites you're greeted and interrogated by "security guards" who ask you to show your room key - presumably to keep the hookers out, haha... The odd thing is just holding up a room key, or walking with someone who is, will get you in.

The other interesting thing is what happened to me as I walked out of my room to go down to the pool, realizing that I forgot my key in the room as it slammed behind me. In what I think is a rather disturbing story, here's what happened. I walked down to the registration desk, only to be asked for my photo ID (sound familiar yet?). Obviously I didn't have a wallet so I had no ID on me. The agent asked me for my room number, and my last name - then once I gave her that he told me to go up to my room and wait for security to come up. After about 2 minutes of waiting, security shows up, asks me my last name, which I give them, and lets me into my room. No need to watch me go in, no need for me to produce an ID from my room... nothing.

I am now offiicially worried as crap. I have a laptop, work stuff, and some rather expensive clothes in here, and if all it takes is to get security up to let you in - this is a problem. There is this illusion that there is high security in the hotel - but when it comes to practice, it's just all for show and the reality is security doesn't exist.

What a disappointment in the Palazzo, and what a scarry situation to have to be in... yikes.

Saturday, June 14, 2008

Cross-Site Scirpting (XSS) - A Real-World Example

Cross-Site Scripting (XSS).

Cross-Site Scripting (XSS) si an attack that's pretty basic to detect, pretty basic in execution, and you'd think that it would be rather simple to understand. Unfortunately this is apparently not the case. I won't go into the details of Cross-Site Scripting because others have beat that to death - but rather I'm going to go through a little real-world exercise for you. I'm hiding the actual URL until the site owner either does something about it, or ignores this issue long-enough for me to disclose it on this blog.

First, I've been looking around and just doing non-invasive, non-malicious checks to see how wide-spread XSS is on some of the sites I use regularly. I came across one that made me think, and so I got a little creative and came up with a real-world use-case for this vulnerability, and how it can be executed and cause real damage.

Looking at the URL and I though - gee, I bet I can make it look like the user has to click to get results and send them somewhere malicious. Here's how this works:

  1. Standard email goes out to people (pet owners are particularly susceptible), telling them of a great new offer at this site which will get them something for free for, say, their dog.
  2. The link looks like this: http://www.________.com/search/noResults.jsp?kw=%3Ca%20href=
    http://www.malicious.com%3EClick%20Here%20for%20Results%3C/a%3E; the malicious attacker simply stands up a site that looks relatively close to this site, either in an iframe, or who knows... think creatively.
  3. The site result looks like this in the user's browser...
  4. The user unknowingly clicks the link, and gets sent to the malicious user's site and after that... it's game over.
All this because of a simple Cross-Site Scripting (XSS) flaw. It is a rather complex attack, I know... inserting an html-encoded link into a URL... (I'm joking of course).

Look - it's simple. Cross-Site Scripting causes major Pwnag3... and all you have to do is write better code, or at the very freakin' least... use a black-box testing tool and it'll find stuff like this!

/rant

Friday, June 13, 2008

McAfee, ScanAlert - More Proof it's a Sham

How much more proof do we really need before someone takes action on this? This is officially the last straw, I've proven to folks over and over again this program by McAfee is nothing more than a sham, and if the public media doesn't want to listen - then so be it. I'm washing my hands of this whole mess... I'm done with it.

Ladies and Gentlemen,
I've been increasingly upset that companies are still not seeing the light - namely, that McAfee's "HackerSafe" (now re-branded McAfee Secured) program is a complete joke. I can't believe that there are so many companies that are still associating themselves with these people, who are obviously deceiving the public.
Here's an interesting customer list from McAfee's site...


With all that in mind, and all those high-powered customers, you'd figure this was one heck of a service - but alas.. it's just as stupid as any previous versions. Apparently, they still fail to check for Cross-Site Scripting (XSS)... a basic web-application vulnerability that's as old as dirt.

Here's an example... Ironically... You'll see PetSmart prominently displayed as a customer , but PetSmart's website does not have the McAfee or ScanAlert log anywhere to be found. Good for PetSmart, but they still have XSS issues...

So I ask you - which is worse? Is PetSmart the more guilty party for relying on a 3rd party to throw up a false sense of security to their online buyers? Or is McAfee worse in this because they're providing PetSmart and their customers with a false sense of security?

I guess this is what you get for not creating a secure software lifecycle program... and looking for a band-aid approach to security.

Tuesday, June 10, 2008

TSA Security Logic (follow-up)

I've had several responses, both public and private to my previous post - all of which indicate that lighters are "ok" now to carry onto planes. Some folks (presumably from the TSA) have posted links (I'll help by posting them below). Interestingly enough, there is a blog posting on the TSA Blog on the logic behind the 3-1-1 rule for airports.

For the record, I still fail to see some of the logic here... maybe I'm not intelligent enough to comprehend but the power-trips the TSA folks go on is absolutely incomprehensible at best, malicious at worst... follow me on my logic here-
  • Flammables such as lighters are an immediate threat (if you disagree, tell me why)
  • Some of the other banned substances are significantly less threatening (water?)
  • The "detectors" should be able to detect explosives (even in liquid form, right?)
  • The UK liquid bombs were to be set off by camera flash!
  • Hand-mixed liquid bombs have been deadly in small quantities before

After all that... I can only surmise that any "real" threat will not be thwarted by these existing counter-measures (with the exception of advanced intelligence). So - much like many other things that are currently being done (reference this news story about ID requirements... http://news.cnet.com/8301-13739_3-9962760-46.html?tag=nefd.top) to secure us... it's a "feel-good" measure. It's meant to give us a sense of security - and like the rest of these measures, has very little actual anti-terrorism value.

Oh, and I couldn't resist... Breast Milk is now allowed to be brought onto planes again - because... you know, we all know that Johnny Jihad likes to use breast milk as an explosive. I'm sure there's some scientific reasoning for this that I don't understand, it's just funny...

Links to TSA blog/site etc...

A final analysis - I am starting to understand why the torch lighters are not permitted (higher temp, truer burn, etc) but regular lighters can STILL be used to start a fire on board a plane! Seriously. This particular piece is concerning...

Q. Are lighters not a threat anymore?A. Lighters are not a serious threat.
Lifting the ban is a common sense, risk-based security decision. This change
allows officers to focus on finding explosives and IED components. TSA collects
22,000 lighters a day.

So - who made this determination that lighters are not a serious threat? Was it because so many were comfiscated? Does this mean if we bring in some other thing thats on the banned list in massive quantities the TSA will simply allow it? I'm not being argumentative for no reason - I'm just trying to comprehend the logic. It's one thing to say "that's just the way it is" but when logic appears to be taking a back seat... it would be good to understand why we're being hassled and annoyed while we fly.

Sorry TSA, I'm not going to simply be pacified by the "just trust us" answer...I simply don't feel ANY safer.

Monday, June 9, 2008

TSA Has Failed Us

I am still in shock, and absolutely horrified by what I saw today. First, let me explain the situation and then I will paste the letter which I sent to the TSA directly... maybe they'll respond.

1:05 PM Central Daylight Time: I arrive at O'Hare Int'l Airport, and go through security check (I only have my 2 carry-ons so no need to check anything). I am hassled in the security checkpoint because I have a 1 oz. bottle of hand sanitizer, and they immediately throw it away, without asking if I would like to put it in the quart-sized bag that is in the other bin I have, with my suitcase... no matter, it was cheap. I am reprimanded by someone from TSA (I will keep the name out of it, as it's of no relevance) who impolitely reminds me that these "safety measures" have been in effect for quite some time and that they are for my safety (more on this in a minute). I then watch a very old wheelchair-bound woman being made to walk through the security screen, then patted down, searched, as if she was spouting Jihad... unreal.

... my flight takes off 40 minutes late (weather delays, you know) and we land in Lexington, KY airport and everyone starts to deplane. It is then that I discover, much to my horror - a lighter sitting on the floor under row 6, seat C. My eyes about popped out of my head, and my heart sank to my stomach. I can't believe that in this day of ultra paranoid TSA personnel (poorly trained as they are) I'm still able to find this lighter, a combustible object unlike my hand sanitizer... on the plane. UNREAL you say? I mean, it must have been that 90+ year old lady who wasn't throughly cavity-searched enough, right? I'm absolutely befuddled, baffled and dumbfounded.

Now - ask yourself... do you feel any safer today than before 911? I certainly don't.

Here is the email I sent directly from the TSA website (http://contact.tsa.dhs.gov/default.aspx), with a
Security Issues (Choose One)*
Urgent/Time Sensitive

designation... Let's see what the TSA folks have to say for themselves. Who wants to bet that I get some standard answer about "no one being perfect" and some crap about how "they're always improving"... waste of my taxpayers money, if you ask me...

To the TSA
This afternoon I was on United Flight 5802 from Chicago, IL [ORD] to Lexington, Kentucky [LEX] at 2:19pm CDT. As we were de-planing in Lexington, and in utter horror I passed seat 6C I saw a green BIC lighter on the floor. If I can't bring a hand sanitizer on board, how is it that someone walks onto this plane with a (potentially) EXPLOSIVE device? We are being told that our privacy is being violated in the name of safety - I demandto know how this could possibly happen, and who will be held accountable.
Thank You.

__________________________________________
Date and Time of message: 6/9/2008 8:54:57 PM

Monday, June 2, 2008

Security vs Functionality on the Banking platform

I find it very interesting how some of the larger banking sites (I'm using Bank of Antarctica as the example, but I'm sure they're not the only ones like this) go to extensive lengths to keep their online customers' data secured, yet... there are some very interesting ways to get around all the extra security.

Let's take a real-world use-case and work it through. Say you're Joe User, and you've just opened an account at Bank of Antarctica. You're excited and can't wait to get home and use all the great features that Bank of Antarctica gives you online. You're also very security-aware (which is rare, I know, but go with me on this one) so you're looking to use as many security features as are available to you. When you login the first time, you set up your "secret questions/answers" and pick your picture for the site verification feature (you don't want to be a phishing victim, after all). You also enable the terriffic feature which requires you to set up your cell phone for SMS, so that when you want to login, or do any kind of transactions such as transfer money, Bank of Antarctica sends your phone a 6-digit SMS to use as a one-time password. So far you're psyched! Everything is working great, and you're feeling like you have a great chance of being secured.

Your feeling of being secured is unfortunately short-lived. As you discover that Bank of Antarctica has enabled their site for your cell phone's browser (a handy little feature I think is neat!) but since the mobile-code-applet which accepts your one-time password obviously won't load well on a cell phone, that doesn't exist. So you're now down to a username and password again... you can't transfer money *outside* your own accounts though - so that helps with the nagging feeling a little. Hrmm...

So. That fancy one-time password feature is only valid if I don't send a header that says I'm a cell phone, huh? And we all know that it's rediculously simple to fake browser headers, right?

So - I'm not necessarily saying this is the fault of Bank of Antarctica, but... maybe an overall flaw in the system. Since we have incompatible devices all over the place we often have to resort to the lower-denominator and that, sadly, is typically devoid of features which enable security. So what do you do as the system architect? Do you disable features since you can't secure them properly, or do you just hope they're not exploited? These are some very tough choices, and often they are not driven from the security office, but rather from the business. I've said it before, we as security professionals have to understand the business lest we become background noise.

I will pose this question for thought to the audience - What do you do if you're the systems architect? Use this use-case example of Bank of Antarctica. Do you disable mobile banking? Or do you take the risk? Are there other ways to mitigate?

(intelligent) Thoughts are always welcome.
Google+