Security Testing

1
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 shouldnt do?

2
Objectives

• Focus on vulnerabilities to unauthorized access
  or manipulation
• Objective identify any vulnerabilities and
  protect a system.
• Data
• Integrity
• Confidentiality
• Availability
• Network computing resources

3
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

4
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.

5
A systems 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.

6
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

7
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

8
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.

9
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.

10
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.

11
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.

12
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

13
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_at_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.

14
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.

15
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, c0af

16
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.

17
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
• Attackers 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.

18
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'

19
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

20
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.

21
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.

22
Phases of penetration testing

• Steps
• Information gathering
• Business logic testing
• Authentication testing
• Session management testing
• Data validation testing
• Denial of service testing
• Web service / AJAX testing

23
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

24
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 1710 49
  GMTServer Apache/1.3.23Last-Modified Thu, 27
  Feb 2003 0348 19 GMTETag 32417-c4-3e5d8a83Acc
  ept-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 0141 33 GMTDate Mon, 16
  Jun 2003 0141 33 GMTContent-Type
  text/HTMLAccept-Ranges bytesLast-Modified
  Wed, 28 May 2003 1532 21 GMTETag
  b0aac0542e25c31 89dContent-Length 7369

25
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' MicrosoftODBC Access 97 ODBC driver
  DriverGeneral error Unable to open registry key
  'DriverId'
• Database, vendor, database type, ODBC driver,
  name of a registry key, ...

26
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

27
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?authenticatedno
• change to
• http//www.site.com/page.asp?authenticatedyes

28
Authentication Testing (2)

• Directory traversal test that a user cannot
  travel outside of an applications 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

29
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// )

30
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

31
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.

32
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.

33
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

34
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

35
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.

36
Windows ProcessExplorer
37
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.

38
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.0135 0.0.0.00
  LISTENING
• TCP 0.0.0.0445 0.0.0.00
  LISTENING
• TCP 0.0.0.01027 0.0.0.00
  LISTENING
• TCP 0.0.0.01296 0.0.0.00
  LISTENING
• TCP 0.0.0.02401 0.0.0.00
  LISTENING
• TCP 0.0.0.02967 0.0.0.00
  LISTENING
• TCP 0.0.0.03306 0.0.0.00
  LISTENING
• TCP 0.0.0.010002 0.0.0.00
  LISTENING
• TCP 0.0.0.010006 0.0.0.00
  LISTENING
• TCP 127.0.0.11072 0.0.0.00
  LISTENING
• TCP 127.0.0.12402 0.0.0.00
  LISTENING
• TCP 137.122.91.188139 0.0.0.00
  LISTENING
• TCP 137.122.91.188427 0.0.0.00
  LISTENING
• TCP 137.122.91.1881032 137.122.94.30524
  ESTABLISHED
• TCP 137.122.91.1881033 137.122.94.30524
  ESTABLISHED
• TCP 137.122.91.1881107 137.122.93.39139
  TIME_WAIT

39
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

40
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.

41
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

42
Sample Wireshark session
43
Proxies
Client
Server
Proxy

• 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.

44
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.

45
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.

46
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.

47
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

48
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

49
WebScarab Message summary
50
WebScarab Message Details
51
WebScarab - Spider
52
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/gt"gtltscriptgtalert("XSS")lt/sc
  riptgt
• Format string errors
• Integer overflows
• -1, 0, 0x100, 0x1000, 0x3fffffff, 0x7ffffffe,
  0x7fffffff, 0x80000000, 0xfffffffe, 0xffffffff,
  0x10000, 0x100000

53
Fuzzers

• SQL injection
• ' OR 11
• OR 11
• ' 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
• lt!CDATAltscriptgtvar n0while(true)nlt/script
  gtgt
• lt?xml version"1.0" encoding"ISO-8859-1"?gtltfoogtlt!
  CDATAltgtSCRIPTlt!CDATAgtgtalert('gotcha')lt!C
  DATAltgt/SCRIPTlt!CDATAgtgtlt/foogt