Grumpy Security Guy

Here is a real world story about a customer of ours, this was a few years ago and was one of the key points in bringing the F5/Mod_security/WhiteHat integrated solution to market.

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.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Here is a scary story about a company, Nebuad (no link juice for you!) that performs a MITM attack all in the name of better ads. Now sniffing to get better data on your customers has been around for a while. In fact I worked at a company that did this as part of our offering. Where NebuAd goes over the line is they manipulate the traffic to get their ad code in the mix.

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

If you enjoyed this post, make sure you subscribe to my RSS feed!

As someone trying to get off the coffee train I find the recent reports of vulnerabilities in network connected coffee machines somewhat amusing. It seems some guy that has $2,900 to spend on a coffee maker(!!) also has the skillz to find a buffer overflow in it.

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

If you enjoyed this post, make sure you subscribe to my RSS feed!

I called this one the day after the first wave of mass SQL Injection attacks came out. I told Jeremiah that we would see botnets doing this attack shortly as it was much more efficient.  A few weeks later and boom, Botnets performing mass SQL Injection.

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.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Trey Ford has a good roundup of the new PCI 6.6 clarification in PCI 6.6 Information Supplement Released. All I have to say is well done to the PCI council! From my first pass it seems like it is pretty clear AND they understand the issues organizations are facing. I have a few nits, here and there but it is 1000% better than it was before.

If you enjoyed this post, make sure you subscribe to my RSS feed!

According to this story your ID (if you are a US citizen is now worth about $2. This is a pretty simple example of the laws of supply and demand hitting the ID market. The market appears to be flooded at the moment thus cost are going down. It is interesting that EU IDs are still high, in the $30 range. Scarcity or the value of the Euro coming into play here?

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?

If you enjoyed this post, make sure you subscribe to my RSS feed!

At the CanSec West conference Charlie Miller wins the PWN 2 OWN contest. I think these contest are kinda lame as they do not prove much, other than Charlie Miller was most likely sitting on a vulnerability waiting until the contest. I still think it is some what cool that there are people that are still interested in OS vulnerabilities.

 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

If you enjoyed this post, make sure you subscribe to my RSS feed!

This seems pretty scary. Apparently the FBI posted a link on some online forum that claimed to display kiddy porn. The story is here.

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…

If you enjoyed this post, make sure you subscribe to my RSS feed!

I’ve not been this pumped about something in a long time. Jeremiah actually has been pulling me into liking this idea for a very long time. I hated it at first. I mean WAFs, bleh. Plus I mean didn’t we already try scanners + WAFs before? Oh yeah the total trainwreck that was AVDL. So one thing I failed to realize was that Jeremiah’s approach is a bit different and when combined with WhiteHat Sentinel (aka NOT a scanner) it is a no brainer.

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.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Regardless of what you think about now former governor Spitzer and what he did, we can learn a lot from how he handled the public disclosure of his err “vulnerability” Here are 5 lessons you can use if you ever find yourself involved in a public disclosure of a vulnerability on your web site or a disclosure of a massive breach.

1. Understand that you have been caught.

Spitzer quickly understood that the cards where stacked against him and decided denials and platitudes where not going to work for him. Perhaps as a former prosecutor he knew how strong the case was against him. If you are dealing with an incident it is important to understand that excuses for poor security are not helpful right now and dealing with the task at hand has to take top priority. Also do not try to deflect by making up stories of honeypots, false alarms, or “really it is not a problem” statements.

2. Get out in front.

Maybe it is just because I am on the west coast, but it seemed like as soon as I heard the story I also heard that he had a press conference. This is a pretty quick response. In this case he probably knew it was coming since The New York Times probably gave him a courtesy call. You are not going to be that lucky so you will be playing catch up but it is important to respond quickly and decisively.

3. Don’t give up the ghost.

Spitzer’s first press conference was masterful. He admitted everything and nothing at the same time. This is when a good PR person can prove invaluable to the Incident Response Team. You want to acknowledge the problem, give concert steps you are taking, and buy time to get all your ducks in a row. If you are dealing with a large leak of credit cards for example you are going to need some time to figure out just what the heck is going on, who is effected, and what your response is going to be all while waiting for law enforcement to get out of the way.

4. Use the time you just bought.

Assuming you did #3 reasonably well you now have some time to figure out how you are going to respond. If you have law enforcement involved your hands are probably somewhat ties as they are going to want to control the flow of information. One area law enforcement is not going to get involved with is how you are going to respond to your customers. This template seems to have already been written, credit monitoring for a year and some gift cards. You can do better!

5. Cut your loses.

At some point you are going to need to get back to work and put this incident behind you. If the police are not involved this should probably be sooner rather than later. I have seen companies sink a lot of time and effort into trying to catch the person when there is little chance of getting anything out of it. I worked several cases where I tracked the attacker back to some non-US country that is practically impossible to get anything done and especially if it is just you and not the feds. There is some joy in finding out who did it but your time and money      is generally better spent finding out how it happened and correcting the the issue then finding out who. The who is most times irrelevant (unless it is an insider of course).

If you enjoyed this post, make sure you subscribe to my RSS feed!