When we re-opened the browser, sure enough that item was now showing at -$9.95. What a deal! We bought five. And shipping was calculated in the same manner, so we got that for a real bargain, too.
So much for fun, here’s when the real trouble started. Since this was a live production site, the order was actually placed. Because our systems are so compartmentalized today, the accounting department only got a message saying, “debit this account $49.75.”
The people in shipping received a message saying to send five of these items to Security Innovation. There was no correlation or check between the processes. This order was never detected or blocked by the firewall or IDS because there was no abnormal behavior.
The only thing our “attack” did was select an item, place it in the basket and check out. Of course, we cancelled the order before it actually shipped, but it was difficult. We had to have conversations with several teams before they could stop that shipment.
This is a great example of why network security can give people a false sense of security and how we need to pay attention to the business processes we think we’re protecting.
These network defenses enable business logic attacks because the watchers are looking the other way; thinking they’re safe because they’ve got the latest and greatest deep-packet inspection firewall. Wrong.
Some buffer overflows can work the same way. Buffer overflows were the security bug of the 1990’s — cross-site scripting and SQL injection soon took over as the high-profile scares this decade. But buffer overflows still wreak havoc on many systems because our network defenses don’t have the context in which to understand well-crafted buffer overflow attacks.
Take for example a string of data that comes over the network pipe. It may be part of a picture, it may be text, we don’t know. But neither does the firewall watching the traffic. If this data happens to be part of a Flash, WMF, or PDF file, for example, the firewall has no way to determine if it is innocuous or evil.
Firewalls have no context in which to understand how a piece of network traffic is going to be used by an application. In this example, an input buffer on a piece of freeware, e.g., Flash Player, Adobe Acrobat Reader, etc. can be overflowed and the client machine compromised very easily.
Can’t happen you say? This exact vulnerability existed for years until early 2006 in a ubiquitous piece of Web software and no network defense in existence could stop it from being exploited.
Do you account for down-time and productivity losses when making your TCO (total cost of ownership) calculations on freeware like Acrobat Reader and Flash Player? Or do you just assume your network defenses protect you?
Network security defenses have a place in your security portfolio. They capture some malicious users and are affective and stopping known attacks and viruses. But beware of the shortcomings so you aren’t caught asleep at the wheel.
In the coming weeks look for more expanded articles from Ed Adams covering each of these themes: Over-relying on Network Defenses, Believing the Hype of Technology/Tools, Too Many People Assumptions, Assuming Secure Software is Costly, and Falling into the “Recency” Trap.
Ed Adams is CEO of Security Innovation, an independent provider of application security services that include security testing and training.