Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Generic Attack Detection - ph-Neutral 0x7d8

2.840 Aufrufe

Veröffentlicht am

Veröffentlicht in: Business, Technologie
  • Login to see the comments

Generic Attack Detection - ph-Neutral 0x7d8

  1. 1. Generic Attack Detection Avoiding blacklisting traps with the PHPIDS A presentation by Mario Heiderich For ph-neutral 0x7d8
  2. 2. Who? Mario Heiderich  CSO for ormigo.com in Cologne, Germany  Lead developer / co-founder PHPIDS  Has browsed a lot of sites
  3. 3. What?  Attack detection for webapps  Type and weight analysis  The PHPIDS and some of its whereabouts  Generic attack detection vs. plain blacklisting
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Let's have a look One of the 70 regex rules to detect XSS, SQLi, RCE and many other attack patterns <filter> <rule><![CDATA[(?:^>[ws]*</?w{2,}>)]]></rule> <description>finds unquoted attribute breaking in...</description> <tags> <tag>xss</tag> <tag>csrf</tag> </tags> <impact>2</impact> </filter>
  9. 9. 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
  10. 10. 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. ...
  11. 11. 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...
  12. 12. 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
  13. 13. Some friends...  quot;; define ( _a, quot;0008avwga000934mm40re8n5n3aahgqvaga0a303quot;) ; 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)
  14. 14. 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
  15. 15. Let's see..
  16. 16. There's more...
  17. 17. ... and the rest
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. Thanks a lot for listening!