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
“No. we are not writing another web scanner!!”
Agenda
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
User-session based approach Distributed Intelligent (or not?) Modular More than “application security scanner” coverage
This work background
STIF, STIF2 automation – agent-based cooperative automated hacking environment
http://o0o.nu/sec/STIF
So, why going for the web
They learnt to configure their firewalls They learnt to disable services they don’t
want They finally know how to use nmap (and
even nessus!!)
…. But they still want web And they can’t learn to code
So why web applications
Applications get complex Multilayered frameworks make it even more
fun Amount of web application based services
grow Number of web application programmers
increase (home brewed web applications)
but …
Web application remains a larger hole into one’s network 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..
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
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/N-Stalker/Watchfire Appscan – intelligent scanners. Session aware. Closed “blackbox” (some allow scripted plugins)
Why scanners ain’t enough
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
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
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 YAWATTmethod
User sessions
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
User session data can be obtained from: Proxy servers (burp, paros, ..) Web server logs Browser automation scripts (i.e. WATIR
framework) Spiders (burp)
Less code, more automation
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:
Semantic and functional classification of URL HTTP protocol classificators (server type, cookies ..) Session classificators Input data classification – type, semantics Output classification (application error detection, redirects,
“bogus’ responses etc) Test-case suites and executed in groups
Stateless tests Stateful tests Mixed
Classification process as new data arrives into the system
Go Intelligent
Main components: Web application components (URL) classification Semantic classification for web application input
data LSI based mapping and comparison of web content
In response analysers. Use of external search engines Limited “binary analysis” of downloaded files
(decoding pdf, doc, rtf (other formats later)
Knowledge Transfer to machine 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
Vulnerability scenario testing – uses ‘classificators’ subscribtion mechanism.
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
Other ideas to work on: 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 Cooperative Agents Infrastructure
Design cooperative agent system Multi-platform Portable
Distributed architecture
Distributed architecture (another look)
What distributed approach gives us: DDoS – EASY!!! Distributed brute-forcing. Bypassing IP based
restrictions, bandwidth limitations IDS – more tricks Bypass packet filtering restrictions
an agent behind the firewall!
Communication framework
Modified version of spread Robust Reliable message delivery Portable (windows/unix) Available in C/C++ and Java flavours. Bindings
exist for Python, Ruby!
In progress
Agents communicate with message Task distribution algorithms – in progress
More on intelligence
Aside from application vulnerabilities, other things of interest are: 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
Add your plugin code on the fly (attack automation plugins via subscription mechanism, classification plugins etc): Can’t be simpler:
Look mah, no hands!
No reload is needed, plugins executed next time the new data is processed
beyond normalities of average application scanner 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 hax0r tool – you still can use it (and feed the data to us!)
Other remainders:
Direct interaction with analyst (not fully implemented yet):
Other remainders:
Data lookup and data mining services for plugins (via mySQL database wrapping DataMiner).
Other ‘nice to have’ things in progress Propogation module: manual or automated
agent installation on vulnerable server (controlled worm spreading capability!)
Demo
Code is spaghetti (sorry about that) Will demonstrate functional bits
Questions and Answers
Sample questions, pick one: ;---------) Why another web hacking tool? Can you do X too..?
Thanks
Thanks for your patience The code, slides and docs will be available in
a while:
http://o0o.nu/sec
Xcon plug
XCon2006 the Fifth Information Security Conference will be held in Beijing, China, during August 22-24, 2006.
Speaking: abit late, but you can try: [email protected]
Attending: should be possible and interesting No politics! ;-) Thanks!