Security Testing

• Software quality assurance has often focused on identifying problems that are caused without intention.

– Does the application behave as expected in terms of functionality, performance, capacity, etc.?

– Does the application do what it should do?

• A secure application must be able to deal with someone who is intentionally trying to exploit a vulnerability.

– Does the application do what it shouldn’t do?

Objectives

• Focus on vulnerabilities to unauthorized access or manipulation

• Objective: identify any vulnerabilities and protect a system.

– Data

– Integrity

– Confidentiality

– Availability

– Network computing resources

Examples of security objectives

• Verify that errors are handled correctly so that the program safely recovers from erroneous input.

• Verify that cross-site browser scripting is not possible.

• Verify that user input provided through a web form will not allow direct execution of SQL statements on a database supporting the application.

• Verify that exceeding a nominal buffer size does not allow the installation of malicious code.

• Verify that private data is protected while in transit or being stored.

• Verify access controls

3

Strategy for security tests

• Ensure that “attack” use cases – malicious use of system resources – are part of the test campaign.

• Ensure that security is part of the development strategy.

• Model threat possibilities, and use the outcome of the analysis.

• Items identified as the greatest risk should be the focus of testing.

• When illegal input is permitted, attempt to create inputs that deliberately cause a program fault to see if the application can enter an unanticipated state.

4

A system’s “attack surface”

• The “attack surface” of a system are the interface points where a user may gain access to application resources:

– Application programming interfaces (APIs)

– Pipes, shared memory, sockets

– Network ports

– Files: permanent and temporary

– Other OS resources: registries, etc.

5

Common Vulnerabilities

• Poor use of cryptography

• Tracking of users and their permissions

• Flawed input validation

• Weak structural security

• Programming language implementation issues

• Platform implementation issues

• Generic application security issues

• Development process issues

• Weak deployment

Poor choice of cryptography

• Unless you are an expert in the field, do not attempt to implement encryption yourself. Use an approved library that has been tested thoroughly.

• Be sure you are familiar with the algorithms you are using, and on what basis their security rests.

• Do not rely on “security by obscurity” where a flaw is believed to be hidden.

• Hard-coded passwords, even if camouflaged by XORs, etc, are not secure.

• Sensitive information – including personal information – should not be put in a position where it could be read externally, and it should be present only when necessary:– temporary files– logs

Tracking of Users and their Permissions

• Authentication

– Clients must prove their validity before allowing access to sensitive information.

– Prevent password cracking via brute force or guessing.

• Session management

– For client access, ensure that a unique, non-guessable session identifier is used, and that it is encrypted.

• Authorization

– Ensure that clients can perform only the minimum functions needed for what they need to do.

Flawed Input Validation

• This is the most common cause of security issues.

• Any input provided by the user, or received from any external source, needs to be thoroughly validated.

• Validation in a secure context– While validation at the client (e.g. JavaScript in a browser) is

faster, it is not secure.

• Centralized validation– If validation is distributed throughout an application, it is

harder to check for correctness, and often easier to bypass.– Perform as close to user input as possible, without

compromising location (see previous point).

• Secure component boundaries– At any external component boundary – databases, sockets,

etc. – communication must either be authenticated, or input values checked.

– Often, internal input interfaces – even if there is external exposure – are assumed to produce correct input.

Weak Structural Security

• Large attack surface– More external connections decreases security

– Use of many communication ports, files, etc.– If input undergoes a large amount of processing before

authentication, authorization, and validation, a larger range of input could be flawed.

• Running a process at too high a privilege level– Daemon processes running at system/administrator

privilege level can be exploited to gain access to system resources.

• No defence in depth– Use multiple layers of security, so that if one fails, another

layer may prevent a security breach.

• Not failing securely– Error handling is often not as well designed or tested.– Error message could give away sensitive information.

Other design flaws

• Mixing code and data

– Sending a JavaScript input validation routine to a browser, which could be modified by a user.

– Writing SQL statements directly from user input.

• Misplaced trust in external systems

– Assumption is that if input is computer generated, it will be correct.

• Insecure default values

– Many systems get deployed with default values, so the default configuration should be especially secure.

• No audit logs

– Provide capability to locate and trace security breaches.

Compiled language issues

• Buffer/array overflows

– No checking of string or array lengths in C/C++.

– Buffer overruns can put return addresses on program stack.

– Mismatch of format codes (e.g. %d) and variables in printf type statements

• Integer type overflows

• Heap overflows

• Function pointer overwriting

Interpreted/Script language issues

• Metacharacters (e.g. ; | ) with special meanings

– User inputs may include metacharacters that affect script operations.

• Script command injection

– Creation of user input that will get executed as a script.

– Perl example, Unix system:– Command: [user input to variable $to]/usr/lib/sendmail $to

– User enters:nobody@nobody.org; rm –rf /;

• Automatically created variables

– Variables are created as needed, but often variables can also be entered via command line arguments or URLs.

Virtual Machine Languages

• Poor exception handling

– Exception in secure part of code may transfer control to insecure part of code.

• Native code

– Virtual machine cannot check native code.

Platform Issues

• Directory traversal from URLs

– The last part of a URL is interpreted by web servers as a directory traversal from a root directory for the web application.

– Enter a URL that ends with something like www.server.com/../../../windows/boot.ini

• Symbolic links

– If an application accesses a file, a symbolic link may allow an attacker to redirect to a file of their choice.

– If an application is known to delete a file with a specific name, a symbolic link may allow an attacker to delete files arbitrarily.

• Character encoding conversions

– You might check for the character / in the above input to prevent directory traversal, but with URLs, the following are also interpreted as a /: %2f, %255c, %c0%af

Generic application security issues

• Cross-site scripting

– Using user input to get script code from another site to be executed on a site which already has a valid session id / cookie.

– Retrieving session identifiers or cookies from a valid session, and using them to hijack the session.

Generic application security issues

• SQL Injection

• Security attack consisting of:– Entering unexpected SQL code in a form in

order to manipulate a database in unanticipated ways

– Attacker’s expectation: back processing is supported by SQL database

• Caused by:– The ability to string multiple SQL statements

together and to execute them in a batch– Using text obtained from user interface

directly in SQL statements.

SQL injection example

• Designer intends to complete this SQL statement with values obtained from two user interface fields.SELECT * FROM bank

WHERE LOGIN = '$id' AND PASSWORD = '$password'

• Malicious user enters:Login = ADMIN

And

Password = anything' OR 'x'='x

• Result: SELECT * FROM bank

WHERE LOGIN = 'ADMIN' AND PASSWORD = 'anything' OR 'x'='x'

Development Process Issues

• Poor communication and documentation

– Developer of one code section does not document all assumptions made by the code, which is needed for other developers to use the code.

– Lack of security standards

– Reactive security: patches are made only when problems found in field

Weak deployment

• Assumption that internal files and registry entries will not be tampered with.

• Assumption that configuration file is always created by the system, and that it is well-formed.

• Running software at unnecessarily high privilege level

• Default settings are insecure

– Example: well known root password is default at installation, and user is not forced to change it.

Web Application Security

• Source: OWASP Testing Guide, version 2.0, available from www.owasp.org.

– OWASP: Open Web Application Security Project

• Advocates combination of automated and manual approaches: use tools but know their strengths and limitations.

• Four elements:

– Manual inspection and reviews

– Threat modelling

– Code review

– Penetration testing– Most of what follows is for this element.

Phases of penetration testing

• Steps:

1. Information gathering

2. Business logic testing

3. Authentication testing

4. Session management testing

5. Data validation testing

6. Denial of service testing

7. Web service / AJAX testing

Information gathering

• Fingerprinting: is it possible to identify the type of web server?

• Spidering (Googling): attempt to find direct entry pages via URLs.

• Error messages: do they give away information such as...

– server, operating system, etc.

– presence of a database, specific DB used

– when something is “not found”, what was being searched

• File extensions in URLs: indicating technology used

– Example: .jsp Java server pages

Fingerprinting

• The HTTP reply contents and format yield enough information to identify the system and software:

• Example: request to various servers is HEAD / HTTP/1.0

• Reply from an Apache server:HTTP/1.1 200 OKDate: Sun, 15 Jun 2003 17:10: 49 GMTServer: Apache/1.3.23Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMTETag: 32417-c4-3e5d8a83Accept-Ranges: bytesContent-Length: 196Connection: closeContent-Type: text/HTML

• Reply from a Microsoft server:HTTP/1.1 200 OKServer: Microsoft-IIS/5.0Expires: Tue, 17 Jun 2003 01:41: 33 GMTDate: Mon, 16 Jun 2003 01:41: 33 GMTContent-Type: text/HTMLAccept-Ranges: bytesLast-Modified: Wed, 28 May 2003 15:32: 21 GMTETag: b0aac0542e25c31: 89dContent-Length: 7369

Error message analysis

• Send badly formed messages and see what can be learned from the responses

• From an HTTP “404 not found” response:Not FoundThe requested URL /page.html was not found on this server.Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7gDAV/2 PHP/5.1.2Server at localhost Port 80

– Server type, operating system, software versions, PHP scripting,...

• From a malformed database connect command:

Microsoft OLE DB Provider for ODBC Drivers error '80004005' [Microsoft][ODBC Access 97 ODBC driver Driver]

General error Unable to open registry key 'DriverId'

– Database, vendor, database type, ODBC driver, name of a registry key, ...

Business Logic Testing

• This type of testing has to be specific for an application.

• Some general elements

– Use cases

– Abuse cases

– Business scenarios: browsing, searching, ordering, checkout

– Workflow scenarios: order creation and processing

– Differing user roles: customer, administrator– Access rights and privileges

Authentication Testing (1)

• Test for default or guessable userid-password combinations– default administrator account– password dictionary

• Test for scenarios that may bypass authentication entirely:– Direct page requests– Guessing session identifiers– URL parameter modification:

http://www.site.com/page.asp?authenticated=no

change to:http://www.site.com/page.asp?authenticated=yes

Authentication Testing (2)

• Directory traversal: test that a user cannot travel outside of an application’s folder structure.– Example:

www.site.com/file1.html – Goes to the application root folder and then

returns the file file1.html in that folder.– Try (if it is known that the server is Unix/Linux based) to

obtain password file :www.site.com/../../../../../etc/passwd

• Test password reset functions:– Can the secret question answer be guessed?

– Example: make of first car: there are only so many car models...

• Test for post-logout session access:– Use of a previously valid cookie– Back button on browser

Session management testing

• How is a session identified?

– Possibilities: cookie, session ID, hidden field

– Are the identifiers...

– decodable? (i.e. they were encrypted insecurely from something like a user name)

– reusable?

– predictable?

• Can valid cookies be generated by a user?

• Are session variables exposed?

– Example: generating a new session ID for a secure transaction (via https:// ) that is then sent over an insecure channel (via http:// )

Data validation testing - Injection

• Using the following as entered data in an attempt to inject into code:

– Script language (e.g. JavaScript, PHP) commands

– Operating system commands

– Programming language code

– SQL statements

– Object-relational mapping tool (e.g. Hibernate, Toplink) commands

– Directory access protocol (e.g. LDAP) commands

– XML data / XPath queries

– E-mail protocol (e.g. IMAP, SMTP) commands

Data Validation Testing - Overflow

• Attempt to overflow and/or corrupt (usually with large input)

– Input buffers

– Stack

– can overwrite instruction pointers

– Heap

– creation of too many objects

– Format strings

– mismatch of format codes and parameters in printf() type statements.

Denial of service testing

• Denial of service: arranging that legitimate customers are not able to perform transactions.

• Example:

– A host is supposed to respond to an internet control management protocol (ICMP) “echo” message by sending an “echo reply”.

– Messages are intended for use as network diagnostics to confirm connectivity.

– Overwhelming a server with “echo” messages so that incoming message queues are too full to accept regular connection requests effectively puts the system out of service.

Denial of service scenarios

• Locking customers out of their accounts– repeated incorrect login attempts on a valid userid– being able to reset passwords (e.g. from the secret

questions)

• Incoming message buffer overflow:– connection requests, echo messages

• User can indirectly cause the following to happen an arbitrary number of times:– object creation– loop execution– write to disk (e.g. log files)

• Failure to release resources (e.g. database connections)

• Too much session data

Web services testing

• XML parsing

– malformed XML may throw exceptions

– long XML may cause parsing delays or (if DOM parsing is used) memory issues

• URL parameters written into XML

• String content can include system commands, SQL statements, ...

• SOAP with attachments: malicious code in the attachment

• Replay attacks: capture a legitimate session and replay it.

• AJAX:

– service endpoint discovery

– modification of JavaScript sent to browser

Tool resources

• Debuggers

• File handler locators: show OS resources used

– Example: “Process Explorer” for Windows identifies resources such as registry keys, sockets, named pipes, shared memory, etc. used by an application.

• Fingerprinters: determine software used from response formats.

• Sniffers: observe network protocol messages

• Fuzzers: generate malformed inputs

• Proxies: intercept messages between client and server (or vice versa), and possibly modify them.

• Password cracking tools:

– Identify potentially insecure passwords before they can be exploited.

35

Windows ProcessExplorer

Setting up a test lab

• Arrange for an isolated network

– Need to be able to control all aspects of an attack.

– Arrange to instrument software on both client and server machines with tools such as Process Explorer.

– Security failures cannot be propagated to public network.

• Need to be able to generate arbitrary network traffic.

• Use default, or most popular, installation of software.

• Install proxies to be able to modify network traffic generated by client or server.

• Custom client can generate malicious traffic to server.

Port discovery

• Identify ports used by an application.

• Example: use netstat command on Windows or Unix. Proto Local Address Foreign Address State TCP 0.0.0.0:135 0.0.0.0:0 LISTENING TCP 0.0.0.0:445 0.0.0.0:0 LISTENING TCP 0.0.0.0:1027 0.0.0.0:0 LISTENING TCP 0.0.0.0:1296 0.0.0.0:0 LISTENING TCP 0.0.0.0:2401 0.0.0.0:0 LISTENING TCP 0.0.0.0:2967 0.0.0.0:0 LISTENING TCP 0.0.0.0:3306 0.0.0.0:0 LISTENING TCP 0.0.0.0:10002 0.0.0.0:0 LISTENING TCP 0.0.0.0:10006 0.0.0.0:0 LISTENING TCP 127.0.0.1:1072 0.0.0.0:0 LISTENING TCP 127.0.0.1:2402 0.0.0.0:0 LISTENING TCP 137.122.91.188:139 0.0.0.0:0 LISTENING TCP 137.122.91.188:427 0.0.0.0:0 LISTENING TCP 137.122.91.188:1032 137.122.94.30:524 ESTABLISHED TCP 137.122.91.188:1033 137.122.94.30:524 ESTABLISHED TCP 137.122.91.188:1107 137.122.93.39:139 TIME_WAIT TCP 137.122.91.188:3017 0.0.0.0:0 LISTENING TCP 137.122.91.188:4643 72.5.124.55:80 CLOSE_WAIT TCP 137.122.91.188:4645 132.246.2.8:80 CLOSE_WAIT UDP 0.0.0.0:445 *:* UDP 0.0.0.0:1044 *:* UDP 0.0.0.0:1434 *:* UDP 0.0.0.0:5353 *:* UDP 137.122.91.188:137 *:* UDP 137.122.91.188:138 *:* UDP 137.122.91.188:427 *:* UDP 137.122.91.188:500 *:* UDP 137.122.91.188:1028 *:* UDP 137.122.91.188:4500 *:*

Port scanning

• Port scanners are available that will attempt to discover open ports on a system.

• When an open port is discovered, various test messages can be sent to the port, and the exact format and content of the reply can be used to identify the exact version of an operating system on the machine.

• Example of this type of tool:

– nmap, available at www.insecure.org

Sniffers

• Tools that can observe network protocol messages.

• Typically, a sniffer tool turns sets the Ethernet interface card in “promiscuous” mode, where frames broadcast on the network are not filtered by the interface.– Result: all frames on a local area network can be

captured and analyzed.

• If the tool is aware of protocol message format, it can also interpret the field values.

• Useful for diagnosing network problems.– Example: configuration where two hosts use same

address.

• For security testing, they can be used for:– Capturing field values of authenticated sessions.– Observing the effects of attack messages.

Sniffer tools

• Example: Wireshark (ex. Ethereal)

– Open source protocol analyzer available from www.wireshark.org.

– Version 1.0.0 available Mar. 31/08

– Features

– Capture live packet data from a network interface.

– Display packets with detailed protocol information.

– Packet filter and search

Sample Wireshark session

Proxies

• A proxy passes messages between a client and a server, or vice versa.

– Proxy can intercept, or modify, messages that pass by.

• Malicious proxy could use client credentials to create its own session on a server.

Client ServerProxy

Proxy example: WebScarab

• Available from OWASP: www.owasp.org

• Use:

– Proxy runs on a selected port (8008 by default)

– Set browser to use this port as a proxy on the local host.

– WebScarab will then record (and potentially modify) traffic that passes through in both directions.

WebScarab features

• Proxy - observes traffic between the browser and the web server.– Able to observe both HTTP and encrypted HTTPS

traffic, by negotiating an SSL connection between WebScarab and the browser instead of simply connecting the browser to the server and allowing an encrypted stream to pass through it.

• Manual intercept– Allows the user to modify HTTP and HTTPS requests

and responses on the fly, before they reach the server or browser.

• Beanshell– Allows for the execution of arbitrarily complex

operations on requests and responses. Anything that can be expressed in Java can be executed.

WebScarab features

• Reveal hidden fields.

• Bandwidth simulator

– Allows the user to emulate a slower network, in order to observe how their website would perform when accessed over, say, a modem.

• Spider

– Identifies new URLs on the target site, and fetches them on command.

• Manual request

– Allows editing and replay of previous requests, or creation of entirely new requests.

Proxy example: WebScarab

• SessionID analysis

– Collects and analyses a number of cookies (and eventually URL-based parameters too) to visually determine the degree of randomness and unpredictability.

• Parameter fuzzer

– Performs automated substitution of parameter values that are likely to expose incomplete parameter validation, leading to vulnerabilities like Cross Site Scripting (XSS) and SQL Injection.

• Search for items in responses, and compare with previous reponses

Proxy example: WebScarab

• SOAP – Plugin that parses WSDL, and presents the various

functions and the required parameters, allowing them to be edited before being sent to the server.

• Extensions – Automates checks for files that were mistakenly left

in web server's root directory (e.g. .bak, ~, etc). – Checks are performed for both, files and directories

(e.g. /app/login.jsp will be checked for /app/login.jsp.bak, /app/login.jsp~, /app.zip, /app.tar.gz, etc).

– Extensions for files and directories can be edited by user.

• Passive analysis plugin that searches for user-controlled data in HTTP response headers and body

WebScarab: Message summary

WebScarab: Message Details

WebScarab - Spider

Fuzzers

• Tool objective: take correct input and perform various modifications to generate incorrect input.

• Original correct request: http://www.example.com/8302fa3b

• Enumeration:

http://www.example.com/00000000

http://www.example.com/00000001

http://www.example.com/00000002

• Replacive fuzzing– Cross-site scripting:

http://www.example.com/>"><script>alert("XSS")</script>&

• Format string errors

• Integer overflows

-1, 0, 0x100, 0x1000, 0x3fffffff, 0x7ffffffe, 0x7fffffff, 0x80000000, 0xfffffffe, 0xffffffff, 0x10000, 0x100000

Fuzzers

• SQL injection' OR 1=1—

OR 1=1

' OR '1'='1

; OR '1'='1‘

INSERT INTO mysql.user (user, host, password) VALUES ('name', 'localhost', PASSWORD('pass123'))

GRANT CONNECT TO name; GRANT RESOURCE TO name;

• XML injection<![CDATA[<script>var n=0;while(true){n++;}</script>]]>

<?xml version="1.0" encoding="ISO-8859-1"?><foo><![CDATA[<]]>SCRIPT<![CDATA[>]]>alert('gotcha');<![CDATA[<]]>/SCRIPT<![CDATA[>]]></foo>