Generic Attack Detection
Avoiding blacklisting traps with the PHPIDS
A presentation by Mario Heiderich
For 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!