Happy New Year. It’s now 2008 and what do we have to show for it? Seriously, it’s not a rhetorical question—it’s one that every information security person and organization should be asking, and the beginning of a new year is as good a time as any. Really.
So, rather than rattle off a list of accomplishments or predictions, I’m going to use this space this month to provide some food for thought, just as I’ve done in past Januaries.
• Profit. We’ve all witnessed how attackers have increasingly adopted for-profit motivations over the past 5 or so years. That whipped cream is out of the can now, and we shouldn’t expect it to change…ever. Behind all those spam emails, all those malware attacks, all those zero-day exploits, all those phishing schemes, all those botnets, all of it—lies a living breathing criminal intent on making boatloads of money. They’re just as happy to get their money from you, your customers, or the next guy. And they’re not going to give up.
That said, the attackers are running businesses. It is our job to present them with a target that is cost-prohibitive for them to go after. If it costs them too much to attack you, they’ll find less expensive targets.
That is the state of the world we live in. Accept it and get on with business.
• CSRF. I know not many IT security folks watch the Open Web Application Security Project (OWASP) top-10 list, but there’s one hidden in their 2007 list that should be getting a lot more attention—Cross Site Request Forgery, or CSRF. OWASP defines CSRF as, “A CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim’s browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.”
Sure enough, that sounds bad, but if anything, the badness is understated. You see, CSRF attacks generally hide in image requests on web pages or in HTML emails. (I’ll bet your email client is configured to render HTML content by default, and to load requested images, right?) The problem that comes in is because in HTML, image requests can contain any valid HTML including parameters. What’s the big deal, you say? Well, an example cited in the OWASP details describes how a miscreant could reprogram a home router/firewall to allow incoming packets on any arbitrary TCP/UDP port—all it takes is a router with a default password (“admin,” anyone?).
Since the browser, by way of the image request, sends a packet along with any active cookies to the third party site, the third party site believes the request is legitimate.
The vast majority of today’s web sites are affected by this issue. As OWASP puts it, “Unfortunately, today, most web applications rely solely on automatically submitted credentials such as session cookies, basic authentication credentials, source IP addresses, SSL certificates, or Windows domain credentials.”
Having said all that, the sky is surely not going to fall any time soon (so far as I know). CSRF vulnerabilities can be avoided in our web applications, but in most cases, the solution involves some fairly significant recoding of every page of every web app. Time consuming and costly.
Now, I’m not a FUD guy, really. But I do know software well enough to recognize a major problem when I see one. I expect we’ll be hearing a lot more of CSRF over the next year or so.
• Multics. Why would a 1960’s era operating system be on a 2008 New Year’s column list, you ask? It turns out that a lot of seminal work in information security was done in and around the Multics system over several years. It also turns out that many of us in today’s Web 2.0, hyper-connected, supercomputer-in-a-smart-phone world have failed to learn much, if anything, from what those visionaries tried to teach us in the ‘60’s and ‘70’s. I, for one, would sure like to see some of those lessons dusted off and re-introduced to our software developers today. That is why I put it here on this list. (I plan to elaborate on this here over the year.)
Welcome 2008. I hope it’s a good one for all of us. But in our rush to make our systems PCI compliant and such, let’s take a moment to make sure we’re addressing what’s really important.