The Five Phases of Web Application AbuseSept 2010

Kyle Adams, Architect, MykonosAl Huizenga, Product Manager, Mykonos

The Problem

What is Web app abuse?

Manipulating your site (and it’s trust) in an attempt commit fraud, deface your

brand, and compromise your users’ privacy

The final attack (Injection, XSS, etc.) is just part of it

Examples

What does it look like?Hogging limited inventory via shopping cart abuse

Scraping competitive content

Phishing for credentials

Loading nasty 3rd-party content

Could be bad guys…

Could just be your users…

Characteristics

What’s common?

Often automated

Based on a deep understanding of application behavior

Hard to filter out effectively over time

How does it happen?

Over time…Not a one-time incident (it just gets reported that way)

The actual attack vector that works needs to be established first

The abuse needs to be tested and automated

It has it’s own dev lifecycle

Phase 1Silent Introspection

Phase 2Attack Vector Establishment

Phase 3Attack Implementation

Phase 4AttackAutomation

Phase 5Maintenance

Understanding

The 5 phases of Web app abuse

Phase 1

Silent Introspection

Footprint: Low

Run a debugger, surf the site, collect data, analyze offline

What Web server? Database? Network hardware and software? Programming languages and libraries?

Phase 2

Attack Vector Establishment

Footprint: Higher

Cloak yourself

For all dynamic URLs, test inputs for errors or blind injection to find vulnerabilities

For each vulnerability, start structuring your input to shape the error into an attack

Phase 3

ImplementationFootprint: Highest

Now that you know the vector(s), what can you do with them?

Extract/edit/delete DB records or tables?

Infect site with a worm that distributes malware?

Launch a complex phishing scam?

Phase 4

AutomationFootprint: Low

If the attack makes money, you want to do it discretely again and again

Write an attack program script

Buy a pre-fab “Command and Control” kit and raise your own BotNet to attack from

Phase 5

MaintenanceFootprint: Low

Let the money roll in, go do something else

Successful automated abuse can exist undetected in maintenance mode for years

If a patch disrupts the abuse, oh well. Either refine the vector again, or go hunting elsewhere

What can you do?

VM and filtering help, but…

Hard to pre-guess all possible vulnerabilities and vectors

Hard to filter intelligently and dynamically enough

Fix

Firewall

What else?

New approaches

Get closer to the app context (and more aware of the client environment)

Analyze app and user behavior to identify abuse early, esp. automated

Respond adaptively – beyond blocks and IP blacklists

Early Detection

What about all the requests before an attack is delivered?

Malicious activity detected

Attack vector established

Number of Requests

OSS Example

OWASP AppSensor Project

A conceptual framework for implementing intrusion detection capabilities into existing applications

http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project

Commercial Example

The Mykonos Security Appliance

A high speed HTTP gateway that injects code-level honeypots into application code at serve time, and provides automated adaptive responses

http://www.mykonossoftware.com

Questions