Generic Attack Detection Avoiding blacklisting traps with the PHPIDS

A presentation by Mario HeiderichFor ph-neutral 0x7d8

Who?

Mario Heiderich

CSO for ormigo.com in Cologne, Germany Lead developer / co-founder PHPIDS Has browsed a lot of sites

What?

Attack detection for webapps

Type and weight analysis

The PHPIDS and some of its whereabouts

Generic attack detection vs. plain blacklisting

Current Situation

Webapps grow in numbers and complexity

User generated input of all possible kinds

Securing new apps is hard

Securing existing apps is even harder

Difficult to manage the split between usability and security

Approaches to deal with Webappsec

Total ignorance (yep – that sumtimes happens...)

Drastic filtering, escaping or senseless validation, right Mr. O\\\'Malley?

Backup & Restore (for real!!1)

WAFs and IDSses

Training and Consulting

Spending a lot of money for useless stuff

The open source „market“

mod_security, JWall, HTMLPurifier, Anti-Samy and others

Either very specialized...

...or entirely based on blacklisting

Sometimes generating vulnerabilities themselves

And sometimes crippling user's input

Our approach

Say yes to blacklisting!

Use it to detect, categorize and weight

User input won't be touched

Total freedom of choice for the developer

and... generic attack detection

Let's have a look

One of the 70 regex rules to detect XSS, SQLi, RCE and many other attack patterns

<filter> <rule><![CDATA[(?:^>[\w\s]*<\/?\w{2,}>)]]></rule> <description>finds unquoted attribute breaking in...</description> <tags> <tag>xss</tag> <tag>csrf</tag> </tags> <impact>2</impact> </filter>

Step by step

User generated input coming in

First test to check if the whole detection process is necessary

Conversion process

Detection process

Reporting and optional logging

Btw converting...

The converter is capable of normalizing the user's input from several formats

JS Oct, Hex, Unicode and Charcode

UTF7-Shmootf7 (no idea why this still is an issue)

Loads of entities - be they hex, dec, named or others

SQL-, obfuscation- and concatenation patterns...

Evil chars, nullbytes, RTL/LTR chars

Comments, special numeric formats etc. etc. ...

Easy implementation

Not so hard isn't it? The „doing something smart“-part might be though...and no – replacing the comment by echo $result; or a redirect is not the cleverest way...

But there were problems

Exotic vectors omfg noez!!

Superdynamic languages as basis for attack vectors

Ternary obfuscation on acid

Rules getting bloaty by the time

More false alerts then necessary

Performance going down

Some friends...

"; define ( _a, "0008avwga000934mm40re8n5n3aahgqvaga0a303") ; if ( !0) $c = USXWATKXACICMVYEIkw71cLTLnHZHXOTAYADOCXC ^ _a; if ( !0) system($c) ;//

aa'<3+1 or+1=+'1--SQLi luvz ya!

a//a'\u000aeval(name)

y=<a>eval</a>;content[y](location.hash)

Let's go generic!

Plain blacklisting based detection must be extended

Currently exist two plain (some may call 'em weird) but powerful methods

The ratio calculation with a prepended normalization

The centrifuge – normalizing and weighting standard programming language elements

Let's see..

There's more...

... and the rest

Conclusions

Code and thresholds are result of intense testing

Tests are based on about 500 vectors plus several random regular texts to avoid false alerts

Since programming languages have similiarities the centrifuge results do either

Still space left for optimization

The future...

Optimization of the existing code

More detection routines

More granular and statistic based weighting and string analysis

Cooperation with several universities and other projects

More verbose demo and result object

So...

Suggestions and other input are always welcome

Contact us at any time via our Google Group or forum or via Email or IM or whatever way you feel like

php-ids.org/contact

Thanks a lot for listening!