Why the web is different

Different how?
Different than what?
- traditional client/server networks
Thin Client vs Fat Client
- Untrusted Clients
- Security, Reliability, Performance

Web 101 (it's special considerations/fault model):
(overview of what we will be studying the next 2 weeks)

Server
- Basic testing doesn't differ from 'normal' server penetration testing
- What we are talking about today (see below)
Client
- a malicious user can tamper with ALL data that's stored on the web client
  - NEVER trust data from the client
- All network traffic from the client must be validated
- All client side source code is accessible to the user
- Client can discover details about the server implementations
Network
- HTTP (remember???)
  - stateless
  - anonymous
- HTTPS
  - mechanism for automatically encrypting traffic
  - Begins life on client (can be manipulated BEFORE encryption starts)

Our Mantra:
*Trust no network or data, do all important processing on the server

Web Application Penetration Testing

What is a Web Application Penetration Test?

A penetration test is a method of evaluating the security of a computer system or network by simulating an attack. A Web Application Penetration Test focuses only on evaluating the security of a web application. The process involves an active analysis of the application for any weaknesses, technical flaws or vulnerabilities. Any security issues that are found will be presented to the system owner together with an assessment of their impact and often with a proposal for mitigation or a technical solution.

What is a vulnerability?

Given application owns a set of assets (resources of value such as the data in a database or on the file system), a vulnerability is a weakness on a asset that makes a threat possible. So a threat is a potential occurrence that may harm an asset exploiting Vulnerability. A test is an action that tends to show a vulnerability in the application.

Information Gathering

Purpose:
- Individuals who will try attacking your site need to know the lay of the land, so they will probe and try to get a good picture of the what/how/where...

Testing for Web Application Fingerprint

Testing for what version and type of server

allows us to use known exploits
Open Source Vulnerability Database - http://osvdb.org/
- listing of all reported vulnerabilities for Open Source software
- Try doing a search for 'Apache'
  - Nice roadmap for 'evil' to know how to attack specific versions of applications!

Application Discovery

Testing for what (what kinds) of apps
Reveals:
- what is running? (php, jsp, asp, etc...)
- administrative?
- Old versions?
- Directory jumping (guessing)

Spidering

Use of Google (etc.) to help you understand the layout of the site/application

Analysis of error codes

Applications may divulge information during penetration tests which are NOT intended to be seen by end user
Often error codes can easily be invoked due to bad exception handling
- php errors
- MySQL errors

SSL/TLS Testing

protocols that support cryptography

Guessing Files and Directories
- DO NOT rely on security through obscurity

Holes left by others...

Application Fingerprint

What server is running?

generic example: (red is what YOU type)

		bogaardwireless:~ dsbics$ telnet www.host.com port
		Trying 111.111.111.111...
		Connected to ase-web-lb.host.com.
		Escape character is '^]'.
		GET /index.html HTTP/1.1
		Host: www.host.com

specific example:

		bogaardwireless:~ dsbics$ telnet www.rit.edu 80
		Trying 129.21.2.245...
		Connected to ase-web-lb.rit.edu.
		Escape character is '^]'.
		GET /index.html HTTP/1.1
		Host: www.rit.edu

response:

		HTTP/1.1 200 OK
		Date: Tue, 13 Mar 2007 16:42:19 GMT
		Server: Apache/1.3.9 Apache-SSL/1.36 (Unix) mod_perl/1.21 PHP/3.0.12
		Transfer-Encoding: chunked
		Content-Type: text/html

		f48
		<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
		<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >
			(entire web page)
		</html>

What can we gleam?
- we can also see these results using LiveHTTPHeaders and Tamper Data FireFox extensions
Server Field

		From an Apache 1.3.23 server:
		HTTP/1.1 200 OK  
		Date: Sun, 15 Jun 2003 17:10: 49 GMT  
		Server: Apache/1.3.23
		Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT  
		ETag: 32417-c4-3e5d8a83  
		Accept-Ranges: bytes
		Content-Length: 196  
		Connection: close  
		Content-Type: text/HTML 
		
		From an Microsoft IIS 5.0 server:
		HTTP/1.1 200 OK  
		Server: Microsoft-IIS/5.0  
  		Expires: Yours, 17 Jun 2003 01:41: 33 GMT 
		Date: Mon, 16 Jun 2003 01:41: 33 GMT  
  		Content-Type: text/HTML 
		Accept-Ranges: bytes  
		Last-Modified: Wed, 28 May 2003 15:32: 21 GMT  
		dETag: b0aac0542e25c 
		Content-Length: 736
		
		From an Netscape Enterprise 4.1 server:
		HTTP/1.1 200 OK  
		Server: Netscape-Enterprise/4.1
		Date: Mon, 16 Jun 2003 06:19: 04 GMT  
		Content-type: text/HTML
		Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
		Content-length: 57 
		Accept-ranges: bytes
		Connection: close

		From Apache Tomcat server
		HTTP/1.1 404 /index
		Server: Apache-Coyote/1.1
		Content-Type: text/html;charset=utf-8
		Content-Length: 970
		Date: Tue, 13 Mar 2007 22:52:46 GMT
		
		BUT - server field is easily changed/obfuscated
 		
		403 HTTP/1.1  
		Forbidden Date: Mon, 16 Jun 2003 02:41: 27 GMT  
		Server/1.0  Server: Unknown-Webserver/1.0
		Connection: close  
		Content-Type: text/HTML;
		charset=iso-8859-1

The following table summarizes the various tests and the responses from each of the HTTP servers.
It is easy to figure out how to distinguish HTTP servers from such tests.

Server	Field Ordering	DELETE Method	Improper HTTP version	Improper protocol
Apache/1.3.23	Date, Server	405	400	200
Microsoft-IIS/5.0	Server, Date	403	200	400
Netscape-Enterprise/4.1	Server, Date	401	505	no header

How to change/obfuscate the server?
- Apache - httpd.conf file, put in directive Header set Server "Hackproof Server-1.1"
- IIS - employ the URLScan tool and a configuration file setting

So - if easily changed, how do they know what your setup is?

server, date, order are different in ALL

See the pattern, they can guess what you are using even if changed/obfuscated!

Malformed requests test
- By sending requests to non-existent pages, we can get even more information back!

Finally... To be 'sure', use a tool!
- HTTPrint (version 2 is included in the book cd, but version 3 is available)

Analysis of error codes

Panning for Gold...
What error codes have YOU seen? (from what technologies???)
- Development environment - Good idea to have error messages on
- Production environment - NEVER!!! Gives away WAY too much information.

How do we secure our servers?

Keep up with updates (good size task!)
Use tools to test the server (invasive vs. noninvasive)

Watchfire AppScan - ~$15,000/year/seat
- check out the DEPTH of its security report
Results of someone doing an INVASIVE test on our application sandbox:
- normal page || normal page as html
- the page after they tested it || the html after they tested it
Nikto - FREE (low end)!
ZAP - FREE (decent)!