Use of AI algorithms in design of Web

Use of AI algorithms in design of Web Application Security Testing Framework HITCON Taipei 2006

Or a “non-monkey” approach to hacking web applications By fyodor and meder fygrave@o 0 o. nu meder@o 0 o. nu

“No. we are not writing another web scanner!!”

Agenda n n Why hacking web applications What scanners do. Why they are useless (or not) What else could be done, but isn’t (yet) Introduction to YAWATT q q q User-session based approach Distributed Intelligent (or not? ) Modular More than “application security scanner” coverage

This work background STIF, STIF 2 automation – agent-based cooperative automated hacking environment http: //o 0 o. nu/sec/STIF n

So, why going for the web They learnt to configure their firewalls n They learnt to disable services they don’t want n They finally know how to use nmap (and even nessus!!) …. n But they still want web n And they can’t learn to code n

So why web applications Applications get complex n Multilayered frameworks make it even more fun n Amount of web application based services grow n Number of web application programmers increase (home brewed web applications) but … n

Web application remains a larger hole into one’s network n n Web application programmers skills aren’t usually the best Firewalls are there – just to let you in application firewalls can stop limited number of web application attacks, but are useless when it comes to detection of logical vulnerabilities IDS systems aren’t smart enough to pick up on Application attacks

Scanners. . use of. . n n n checking for enumeration. . . YES checking for exectution. . . YES checking if we can drop table YES checking if we can drop database. . YES. . CANNOT CONNECT TO APPLICATION

Scanners - summary n n Nessus et all – don’t see web applications beyond the underlying software configuration Libwhisker/nikto – signature based. Relatively primitive. Efficient for default bugs Wikto/e-Or – session aware, coding flaws scanner Kavado/Appscan/Webinspect/NStalker/Watchfire Appscan – intelligent scanners. Session aware. Closed “blackbox” (some allow scripted plugins)

Why scanners ain’t enough n n n Single-host based Commercial scanners are black-box (not extendable, non-correctable) Little or no control on “hacking” process Not easily extendable on the fly with new ‘automation” modules Often primitive, signature based logic

What would we like to have n n n n Maximum automation of web hacking process Minimum of code writing. Autonomous functionality Knowledge transfer Ability to add ‘hacks’ on the fly Deal with uncertainty in “intelligent way” Learn from valid user session data

Other good things to have n n Be able to test new class of bugs (i. e. session hijacking) Be able to attack web application from multiple-locations (bypass IP restrictions, improve brute-forcing process) Be able to automate testing of application logic bugs Be able to make intelligent guesses

Introducing YAWATT method

User sessions n n User sessions – collections of user request/response pairs (url, name/value pairs, session information and selective HTTP protocol data) Classified user session data include semantic classification of URL, parameters, responses and HTTP protocol data (server type, backend system(s) if visible, “unusual” HTTP headers content)

User sessions n User session data can be obtained from: q q Proxy servers (burp, paros, . . ) Web server logs Browser automation scripts (i. e. WATIR framework) Spiders (burp)

Less code, more automation n n Application content is learnt from user sessions (data feeders) Additional application information could be gathered by agent’s plugins (i. e. directory splitting tests) User session data is classified by: q Semantic and functional classification of URL q HTTP protocol classificators (server type, cookies. . ) q Session classificators q Input data classification – type, semantics q Output classification (application error detection, redirects, “bogus’ responses etc) Test-case suites and executed in groups q Stateless tests q Stateful tests q Mixed

Classification process as new data arrives into the system

Go Intelligent Main components: n Web application components (URL) classification n Semantic classification for web application input data n LSI based mapping and comparison of web content In response analysers. n Use of external search engines n Limited “binary analysis” of downloaded files (decoding pdf, doc, rtf (other formats later)

Knowledge Transfer to machine n n n Possibility to create new classification rules on the fly (and let the system re-learn from it) Possibility to ‘reclassify’ application responses Possibility to add new ‘testing’ plugins on the fly

How is URL classification used n Vulnerability scenario testing – uses ‘classificators’ subscribtion mechanism. n For example: login page tester will need ‘login’, ‘executable’ and ‘session’

How does input data semantics identification happen

How the classified user session data is used

Additional research directions n Other ideas to work on: q q q Detection of “hidden” parameters Identification of “hidden” urls Identification of “negative” and ‘positive” responses Detection of application failures, redirects Evaluation and priority based execution for plugins

A note on distributed architecture n Cooperative Agents Infrastructure q q q Design cooperative agent system Multi-platform Portable

Distributed architecture

Distributed architecture (another look)

What distributed approach gives us: DDo. S – EASY!!! n Distributed brute-forcing. Bypassing IP based restrictions, bandwidth limitations n IDS – more tricks n Bypass packet filtering restrictions an agent behind the firewall! n

Communication framework n Modified version of spread q q Robust Reliable message delivery Portable (windows/unix) Available in C/C++ and Java flavours. Bindings exist for Python, Ruby!

In progress n n Agents communicate with message Task distribution algorithms – in progress

More on intelligence n Aside from application vulnerabilities, other things of interest are: q q q Email addresses, user ids that could be seen within web content Domain names (within web pages, comments, binary files, etc) Building ‘target-oriented’ dictionary files (used by brute-force cracking modules)

Other good things n Add your plugin code on the fly (attack automation plugins via subscription mechanism, classification plugins etc): q Can’t be simpler:

Look mah, no hands! n No reload is needed, plugins executed next time the new data is processed

beyond normalities of average application scanner n n n Integration and use of other tools to collect and analyse data (search engine queries, . . ) Integration with other tools (script in python or ruby, or hack “plugin” in java or C) If you like your favourite application hax 0 r tool – you still can use it (and feed the data to us!)

Other remainders: n Direct interaction with analyst (not fully implemented yet):

Other remainders: n Data lookup and data mining services for plugins (via my. SQL database wrapping Data. Miner).

Other ‘nice to have’ things in progress n Propogation module: manual or automated agent installation on vulnerable server (controlled worm spreading capability!)

Demo n n Code is spaghetti (sorry about that) Will demonstrate functional bits

Questions and Answers Sample questions, pick one: ; -----) n Why another web hacking tool? n Can you do X too. . ?

Thanks for your patience n The code, slides and docs will be available in a while: http: //o 0 o. nu/sec n

Xcon plug n n n XCon 2006 the Fifth Information Security Conference will be held in Beijing, China, during August 22 -24, 2006. Speaking: abit late, but you can try: casper@xfocus. org Attending: should be possible and interesting No politics! ; -) Thanks!