Greg Hoglund

Cory Feldman

a

Greg Hoglund = Cory Feldman

This customer had a massive application written in ASP classic. Since it was in ASP classic it had massive numbers of SQLi vulnerabilities. Everything from Blind SQLi to the always fun SQL statements in the URL. The customer said this application was roughly 250,000 lines of code with SQL hardcoded throughout. The reason the customer had called WhiteHat is because they where working on a big deal with a potential client and this client was asking for a security report on the application. They where also in the early phases of rewriting the application in .NET (yeah) with an estimated completion date 1.5 years out.

After seeing our report (100+ SQLi and 300+ XSS) and after a protracted developer battle(yes XSS is not good) they where left with two not good options.

1. Lose the customer.
2. Stop the rewrite and spend a few months digging through old code to fix these issues

Now from a business point of view neither of those makes sense. At the time we where in the WAF hater camp but we saw that in this case it made total sense. The customer deployed a WAF, configured it using our vulnerability data, and was able to mitigate the risk in about 3 weeks.

Bottom line and what people continually fail it understand is that every current solution on the market today has its short comings. In security everything does. Is there one magic network solution that will prevent all network attacks? No. You have spent a ton of money protecting your network infrastructure. Let’s take a quick look at the list of things you probably have spent money on today:

1. Firewalls
2. IDS/IPS
3. Network Vulnerability Scanning
4. AntiVirus
5. Configuration and Patch Management
6. Database Scanning
7. Database Encryption

Guess what, none of that protects you from the rush of SQLi, XSS, and other web based attacks. All that money and you still have big gaping holes.

To properly attack the Web Application Security problem you should be doing all of these things:

1. Secure coding practices
2. Source code review
3. Black box testing
4. Web Application Firewalls
5. Developer Training
6. Configuration and change management

The reality today is that people underestimate the size of the problem and therefore do not have the budget to do all these things. You can stretch those budget dollars pretty far with an open source scanner and mod_security (software cost $0). WhiteHat is not that cheap but we are very cost effective, combined with mod_security you can go a long way. Need a more robust solution, WhiteHat + F5 can scale to 1000 of web sites in a very cost effective manner. WhiteHat and our WAF partners can knock items 3-5 off your list while you go work on getting your coding practices in place. Even after you get those practices in place you are still going to find vulnerabilities and having that “instant” mitigation ability is very comforting.

Robert over at cgisec sees the light as well. He has managed and is currently managing web site security for some of the largest most frequently attacked web sites on the planet.

Post from: Grumpy Security Guy

The Business Case for WAFs + Testing

But Free Press and Public Knowledge found that sometimes when a WOW subscriber visited Yahoo or Google, NebuAd faked an additional packet of data that appears to be the last part of the downloaded Google webpage. The extra packet included NebuAd-written JavaScript that directs users’ browsers to a NebuAd-owned domain named faireagle.com, where the company drops tracking cookies from other domains and companies on the user’s computer. These can be used later to deliver customized ads based off analysis of where people have gone on the web or what search terms they have used.

Cool so not only are they sniffing traffic they are now inject JavaScript and making it appear to originate from Google. This technique is the same one used by the ever popular and super fun Airpwn. Now what would happen if NebuAds servers where compromised? The ultimate JS malware distrubution platform would be born!

Link

Post from: Grumpy Security Guy

When ISPs Attack!

This type of thing is only going to increase as people slap more stuff onto the network with little to no care about security. These things generally all have web UIs which makes the vulns that much more interesting. It is somewhat easy to detect the spread of a mass SQLi attack on public facing web sites but what happens when we get this attack on internally facing systems? They are much harder to track and even detect. What if my coffee maker now does drive by malware attacks? What if my wireless router does? Our jobs are only geting harder people.

Link

Post from: Grumpy Security Guy

Dude Don’t Hack My Coffee

The interesting things about these attacks so far is what they are actually doing. They are not attempting to steal data out of these databases directly, they are populating the pages with links that attempt to do drive by malware installs by exploiting browser vulnerabilities. It was pretty successful but SQL Injection is a  vulnerability  that is on the decline (and will decline even more after this attack). I begin thinking about vulnerabilities that would do the same thing but have a much broader reach.

Our good friends XSS and CSRF.

So here is the attack.

1. Find a few permanent XSS vulnerabilities in some high traffic sites.
2. Find some CRSF vulns in popular blog and forum software.
3. Craft your payload.
4. Profit!

So the bot software basically sits back and waits until the computer it is on visits a vulnerable site and then places it payload in the vulnerable spot. It could of course do this without you visiting a site with a little more coding to check if you are permanently logged in.

Considering the number of sites with XSS and CSRF this attack would dwarf the current SQL Injection attack happening today.

Post from: Grumpy Security Guy

Bots + Web Vulnerabilites - An Approaching Storm

Post from: Grumpy Security Guy

PCI 6.6 clarified

Then the quote that really hit home:

Also popular with attackers are Web site-specific vulnerabilities because few are fixed quickly. Of 11,253 so-called “cross-site scripting” vulnerabilities found on specific sites during the second half of 2007, only 473 were patched.

Yeah virtual patching is really going to be a bad thing huh?

Post from: Grumpy Security Guy

Your ID is worth $2

 Link 

In other news some swiss guys (P.S. I LOVE your pancakes!) did a pretty good analysis of the time it takes for Apple and Microsoft to patch there disclosed vulnerabilities.  Apple sadly has a ways to go. I think they are still at the Microsoft in 1999 phase. Hopefully they wake up.

 Link

Post from: Grumpy Security Guy

Mac Hacked in 2 Minutes, Apple is a lame patcher

Upon reading this the first thing that popped into my mind was CSRF(Cross Site Request Forgery) Now this is not classic CSRF since CSRF generally implies I am exercising some functionality on the target site. I am using CSRF as a handy term for “if you visit a page I control content on I can make you request any other link I want”. Now remeber this is not only pages like this blog where I clearly control the content, but any other place I can provide links, usually to images. Social networking sites, forums, image hosting sites and even in email signatures.

This is an even better scam than the now famous 911 swatting scams. Now instead of SWAT busting in to rescue you the FBI bust in to arrest you. What great fun! It will be interesting to see how many of these stick. It seems to be based on some pretty flimsy evidenc. The article above points out that open wireless networks are just one way someone could fool the system. CSRF is better because your browser will actually go to the page and a forensics examination of your machine will show that you went there. Not a good position to be in in court with a jury and often times judge with no technical background at all.

Update from my buddy Zeno: The file that keeps track of places IE has been, index.dat, does not log refers and apparently that file and it’s contents have held up in court…

Post from: Grumpy Security Guy

FBI CSRF and Jail How to Get Someone Raided

WAFs generally struggle in a few different areas, the people running them are not web app. security experts and trying to apply a default deny policy, while a great idea in theory, is pretty hard in the real world . There is just way to much movement in most applications to pin it down. Even if the app does not change frequently, WAF admins are very hesitant to even come close to blocking legitimate traffic. What really sold me though is when I saw it in action for the first time. From the Sentinel UI we clicked a button that updated the F5 with a rule to block a vulnerability. The rule is automatically generated based on the vulnerability. We then clicked the retest button and the vulnerability was no longer exploitable . Note my careful choice of words, exploitable VS. “not there anymore”. The vulnerability certainly still exist in the code but now that the attack is blocked the business can decide if this is a good enough solution or they need to go fix the actual flaw.

The geek in me is screaming that it still needs to be fixed, the business side is saying that the rule is good enough and I am not going to commit resources to fixing it until that code is worked on again. From the PCI Section 6.6 perspective this gives the business some great options. As our customers are becoming aware of the PCI requirements and the PCI auditors are becoming tougher on web application vulnerabilities we run into a difficult situation. PCI audit is coming up and the app. is riddled with vulnerabilities.  I now have to dedicate precious development resources to fix these vulnerabilities ASAP. With this solution I can apply this rules and effectively mitigate the issue.

I am pretty excited to be part of this. I think we have moved the industry forward today, even if it was just a small step. People now have some more options to mitigate risk besides running to the development team with yet another fire.

Post from: Grumpy Security Guy

The Big Announcement