Software Security - Just Over the Horizon

Thursday, March 31, 2011

Rafal Los


Everyone wants to have a crystal ball so they can look into the future and see what tomorrow's attacks and trends will be. 

I don't have one of those, but I've been in the industry for a long time so between history and experience I think I have a pretty good chance at telling you what's just over the horizon. 

Coincidentally, this has a lot to do with what I've been working on in conjunction with some folks from our lab [WSRG].

Looking Back

Software is everywhere.  There is no denying that software powers cars, space shuttles, smart mobile devices we used to call phones and even your refrigerator.  Some of these pieces of software are built to 'secure' standards but most are not and are simply content to 'work right'. 

I doubt there was much security testing done on the code that runs your refrigerator or microwave - but I'm willing to bet a virtual ton of testing went into the code that powers the Automated Teller Machine (ATM) you took out money from yesterday. 

The amount of testing a piece of software undergoes, from a security perspective or otherwise, is directly proportional to the amount of risk it undertakes -which is both logical and obvious. 

This makes total sense when you think about how much we test the software that works from within your browser and allows you to access your bank and pay your bills online.  There is serious money at stake, so lots of testing gets done to make sure hackers can't easily break the system and take your (or the bank's) money.

The type of testing done about 90%+ of the time (this is purely an anecdotal number based on my experience) when we talk about security testing is looking for issues which can be exploited by subverting the system's controls to exhaust resources, directly access systems, impersonate users, or reflect attacks against the user of the system. 

Things like Cross Site Scripting (XSS), SQL Injection, buffer overflow, access violation, race conditions and other interesting variations are tested for using static analysis, dynamic analysis and some of the forthcoming hybrid technology.

As an industry we're getting much better at pattern-based security testing.  Finding defects that we can write patterns for has become a thriving, competitive and maturing industry... but that only covers things we can find patterns for.

Peering Over the Horizon

So as I look out over the horizon at the types of issues I feel we're going to see in the coming years - I think of the types of attacks and defects we can't easily pattern-match.  What does that mean, you ask?

Think about it this way, we can find SQL Injection in a web application from within your IDE if you're a developer, from within your testing framework if you're a QA analyst, or from within a penetration testing platform if you're a security tester... but what about the type of attack that AT&T's website suffered to expose iPad owners' email addresses? 

Well unfortunately, there is no way to test for this type of security defect, because it's in the application logic and not in the way that it sanitizes input variables or manages system memory.  Make sense?

Enter application logic defects. What I see as I look out over the horizon is more exploitation of application logic. I see more attacks going after the logic that is derived from business processes that are designed into applications (for the web or otherwise).  Since we can't adequately test for these types of defects (today), and more often than not no one is really looking for them they're getting by and making it into production systems where they can be exploited. 

Exploitation of logic defects in applications is rarely reported as hacking and more likely reported as variants of fraud against a system.  Hackers generally have a singular goal in mind when 'hacking' systems, that goal is financial gain.  Sure there is hacktivism and 'hacking for fun' still out there but the real cases of serious intrusions come from financially-motivated attacks.

Why Attack Business Logic?

The reasoning behind attacking business logic, I think, is simple.  It's a combination of vanishing opportunity in existing exploitation, risk of being caught, and payout that is going to drive criminals (not just hacker punks) to attack business logic.

  • vanishing opportunity - Whether you think security has made headway in software development in the last decade or not - you have to admit there are far less critically vulnerable, critical sites out there than there were a few years ago.  This means that critical sites like banking and commerce-related sites which are the highest value targets when it comes to financial gain have gotten better at protecting the assets that house their most important business data.  I didn't say they were great or perfect, just better.  You have to admit that at this rate, in the next 5 or so years there is a very real chance that SQL Injection and Cross Site Scripting may actually be in serious decline or close to eradication on business-critical sites.
  • risk of capture - As applications get the ability to self-defend, and network-based technologies to detect web-based application attack get better security teams will be able to catch hackers in the act a lot more.  At RSA this year there were some cool technologies demonstrated for identifying and catching web-based hackers ... so as these technologies mature and are adopted on the network catching hackers will be easier, and punnishing them will be more prevalent.
  • payout - the payout from hacking web apps is getting smaller as the black market for personally identifiable information, credit cards data, and other critical information is being flooded by more and more successful attackers every day.  We've witnessed the cost of a verifiable identity go from several hundred dollars just a few years ago to just a few dollar today... that's a staggering testament to the over-abundance of stolen information.

Business logic defects give hackers new ground because while we the security community have been busy little beavers getting developers to stop allowing SQL Injection, we've been largely ignoring anything else that we can't easily 'test for' as I mentioned earlier. 

While pattern-matching cross-site scripting attacks is becoming much better with data normalization and string reconstruction techniques there is still no technology that can detect a business process being subverted -heck, when a colleague subverted a specific website's ordering process to exploit free 'loyalty points' no one even noticed... and didn't believe him when he called them to tell them about it. 

There are simply no trails or forensic fingerprints that business logic attackers leave behind -this is dangerous!  Let's end on payout, because if an attacker can subvert a business process odds are they're going after a mechanism that handles cash somehow. 

Whether it's loyalty points or more directly the cost of an item, by the time you notice that you're being 'attacked' you've already chalked it up to a half-million dollar fraud and you can't figure out where or how the attack happened - everything seems to be functioning find and there aren't any attacks registered in the WAF or IPS, after all.

So let me sum this up by saying, what we're working on, and what I see just over the horizon is defects in the application business logic designed into applications themselves.  I see smart attackers moving to an attack methodology that's abundant to exploit, next to impossible to detect and has huge payouts.  If I was an attacker, that's what I'd be targetting... once all the low-hanging SQLi holes are gone off the critical sites.

So with that in mind, watch this space for more announcements and the results of the Black Hat Europe talk I'm giving on 17 March in Barcelona. I strongly urge you to start thinking about these types of defects and attacks now, before you have to start racking up the fraud count in a few years.

Good luck!

Cross-posted from Following the White Rabbit

Possibly Related Articles:
Viruses & Malware
XSS SQl Injection Testing Vulnerabilities Development Software Security Assurance
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.

Most Liked