Transcript Security of Electronic Voting

Penetration Testing
James Walden
Northern Kentucky University
Topics
1.
2.
3.
4.
5.
Software Security Testing
Test Case Design
Tools
Attack Patterns
Web Application Testing Methodology
CSC 666: Secure Software Engineering
Types of Testing
White Box




Tester knows all information about system.
Including source code, design, requirements.
Most efficient technique.
Avoids security through obscurity.
Black Box
 Examines system as an outsider would.
 Tester builds understanding of attack surface and
system internals during test process.
 Can use to evaluate effort required to attack system.
 Helps test items that aren’t documented.
Grey Box
 Apply both white box and black box techniques.
CSC 666: Secure Software Engineering
Security Testing
Injection flaws,
buffer overflows,
XSS, etc.
Functional testing
will find missing
functionality.
Intendended
Functionality
Actual
Functionality
CSC 666: Secure Software Engineering
Penetration Testing
Test software in deployed environment by attacking it.
Allocate time at end of development to test.
 Time-boxed: test for n days.
 May be done by an external consultant.
Abuse
Cases
Requirements
Risk
Analysis
Design
Code Reviews +
Static Analysis
Security
Testing
Coding
CSC 666: Secure Software Engineering
Testing
Penetration
Testing
Security
Operations
Maintenance
Security Testing
Different from penetration testing
 White box (source code is available.)
 Use risk analysis to build tests.
 Measure security against risk model.
Abuse
Cases
Requirements
Risk
Analysis
Design
Code Reviews +
Static Analysis
Security
Testing
Coding
CSC 666: Secure Software Engineering
Testing
Penetration
Testing
Security
Operations
Maintenance
Equivalence Classes
A group of tests form an equivalence class if
 They all test the same thing.
 If one test discovers bug, others will too.
 If one test doesn’t find bug, others won’t either.
To form an equivalence class, tests typically




Involve the same input variables.
Result in similar operations.
Affect the same output variables.
None require error handling or all of them do.
CSC 666: Secure Software Engineering
Equivalence Class Examples
Input
Valid Equivalence Classes Invalid Equivalence Classes
Enter a
number.
Integers between 1 and 99.
Negative numbers.
0
>99
Arithmetic strings, e.g. 9-9.
Non-numeric strings.
Enter a
username.
8-character lowercase
alphanumeric strings
beginning with an alphabetic
character.
Strings longer than 8 chars.
Uppercase strings.
Strings beginning with a number.
Strings with special chars: ‘ ; &
Non-alphanumeric strings.
Enter a VISA 16-digit numbers beginning
credit card
with a 4, with a valid LUHN
number.
checksum.
Numbers not beginning with 4.
Numbers shorter than 16 digits.
Numbers longer than 16 digits.
Numbers with invalid LUHNs.
Non-numeric strings.
CSC 666: Secure Software Engineering
Boundary Values
Boundary values exist on both sides of each edge
of an equivalence class.
Numerical Range Example
Equivalence class = [1,99]
Boundary values = { 0, 1, 99, 100 }
Character Range Example
Equivalence class = [A, Z]
Boundary values = { @, A, Z, [ }
Limit Example
Equivalence class = { x, y, z | x + y + z = 180 }
Boundary values = { x, y, z | x + y + z = 179, 180 or 181 }
CSC 666: Secure Software Engineering
Fuzz Testing
 A testing methodology in which well-formed
inputs are randomly changed and used for
testing.
 Example: file fuzzing
 Create set of valid files.
 Choose parts of file to fuzz
- Metadata: data format, size, etc.
- Content: bytes, HTML/XML tags, etc.
 Randomly modify parts of file.
- May need to recompute checksums.
 Submit fuzzed files to application.
 Monitor application for crashes and errors.
CSC 666: Secure Software Engineering
Fuzz Testing
Fuzz testing is useful when
 There is no obvious way to divide the input
into equivalence classes.
 You want to check that your equivalence
classes actually cover all possibilities.
CSC 666: Secure Software Engineering
Tools
Spiders
 Follows links to identify all URLs of web app.
Proxies
 Intercept HTTP transaction between client
and server and permits modification.
Vulnerability Scanners
 Scan for single vulnerability
 Spider + scan for all vulnerabilities
CSC 666: Secure Software Engineering
Spiders
Crawl application
 Start at specified URLs.
 Follow each link.
 Records URLs.
Caveats
 May need help with
authentication.
 Often cannot follow
embedded links in
Javascript, Flash, etc.
 Will click on all links,
including deletions,
large downloads, etc.
CSC 666: Secure Software Engineering
User-Directed Spidering
User-Directed Spidering Process
 User configures browser to use proxy.
 User walks through application.
- Proxy passes traffic to spider,
- Spider builds map of application.
 Optionally, spider will crawl application, using
identified URLs as starting points.
Advantages
 Handles authentication.
 Handles Javascript and Flash links.
 Avoids dangerous content.
Caveats
 Time-consuming.
 User may miss some links.
CSC 666: Secure Software Engineering
Brute-Force Spidering
Access URLs in robots.txt.
 Lists URLs spiders are supposed to avoid.
 Robots exclusion protocol purely advisory.
 Some devs use for security via obscurity.
Attempt to guess URLs.
 Based on widely used directory/file names.
 Based on web server and framework used.
 Based on previous spider results.
CSC 666: Secure Software Engineering
Proxies




Tamper Data extension
Burp Suite
Paros Proxy
WebScarab
Edit Web Data
• URL
• Cookies
• Form Data
Web Browser
Web Proxy
CSC 666: Secure Software Engineering
Web Server
Tamper Data
CSC 666: Secure Software Engineering
Tamper Data
CSC 666: Secure Software Engineering
Auto Scan Tools
Automatically check app for vulnerabilities.
 Spiders application to identify inputs.
 Supplies set of malicious data to each input.
Caveats
 Same dangers as any spider tool plus
 Malicious data may crash app or modify db.
 Does not verify absence of vulnerabilities.
Uses
 Fix common vulnerabilities anyone can find.
 Prioritize applications for security review.
CSC 666: Secure Software Engineering
Attack Patterns
Attack Pattern: framework for carrying out
a particular type of attack.
 Similar to design patterns, but with a
 Focus on testing and risk assessment.
Exploit: A technique or software that takes
advantage of a vulnerability in a specific
piece of target software.
Attack: The act of carrying out an exploit.
CSC 666: Secure Software Engineering
Attack Pattern Description
Pattern Name and Classification: A unique, descriptive identifier for pattern.
Attack Prerequisites: What conditions must exist or what functionality and
what characteristics must the target software have, or what behavior must it
exhibit, for this attack to succeed?
Description: A description of the attack including the chain of actions taken.
Related Vulnerabilities or Weaknesses: What specific vulnerabilities or
weaknesses (see the glossary for definitions) does this attack leverage?
Method of Attack: What is the vector of attack used (e.g., malicious data
entry)?
Attack Motivation-Consequences: What is the attacker trying to achieve by
using this attack?
Attacker Skill or Knowledge Required: Low, medium, high. Contextual
information.
Resources Required: What resources (e.g., CPU cycles, IP addresses, tools,
time) are required to execute the attack?
Solutions and Mitigations: What approaches are recommended to mitigate
attack?
Context Description: In what technical contexts (e.g., platform, OS, language,
architectural paradigm) is this pattern relevant?
References: What further sources of information are available on this attack?
CSC 666: Secure Software Engineering
Example Attack Pattern
Pattern name and classification: Make the Client Invisible
Attack Prerequisites: App must have a multi-tiered architecture with division btw client
and server.
Description: This attack pattern exploits client-side trust issues. The attacker removes
the client from the communication loop by communicating directly with the server.
This could be done by bypassing the client or by creating a malicious impersonation
of the client.
Related Vulnerabilities or Weaknesses: CWE–Man-in-the-Middle (MITM), CWE-Origin
Validation Error, CWE- Authentication Bypass by Spoofing
Method of Attack: Direct protocol communication with the server.
Attack Motivation-Consequences: Potentially information leak, data modification,
arbitrary code execution, etc. These can all be achieved by bypassing authentication
and filtering.
Attacker Skill or Knowledge Required: Moderate skill to find. Low skill after
automation.
Resources Required: None, though protocol analysis tools and client impersonation
tools help.
Solutions and Mitigations: Increase Resistance to Attack: Utilize strong two-way
authentication for all communication between client and server. Increase Resilience
to Attack: Minimize the amount of logic and filtering present on the client; place it on
the server instead. Use white lists on server to filter and validate client input.
Context Description: Any client can be attacked in this manner.
References: Exploiting Software: How to Break Code, p.150 [Hoglund 04].
CSC 666: Secure Software Engineering
Attack Pattern Catalogs
CAPEC
 Common Attack Pattern Enumeration and Classification
 http://capec.mitre.org/
Exploiting Software book
 http://www.exploitingsoftware.com/attackpatterns/
CSC 666: Secure Software Engineering
WAHH Testing Methodology
CSC 666: Secure Software Engineering
Map Application’s Content
1. Explore Visible Content


Browsing (cookies/JS enabled/disabled.)
Manual spidering
2. Consult Public Resources

Search Google / Internet Archive.
3. Discover Hidden Content


Check robots.txt and guess file/directory names.
Check HTML code for references to hidden content.
4. Discover Default Content

Use Nikto to find default server/frmwrk content.
5. Enumerate Identifier-Specified Functions


Identify where pages accessed via URL parameters.
Check for debug/admin URL parameters.
CSC 666: Secure Software Engineering
Analyze Application
1. Identify Functionality



Core functionality of application.
Security mechanisms.
Peripheral functions like errors, redirects, logs.
2. Identify Data Entry Points

URLs, query strings, POST, cookies, headers.
3. Identify Technologies

Client-side code, server/frmwrk, svr code, etc.
4. Map the Attack Surface


Develop model of application’s inner structure.
Identify common vulnerabilities for each function.
CSC 666: Secure Software Engineering
Test Client-Side Controls
1. Transmission of Data Via Client




Hidden fields
Cookies
Preset parameters
ASP.NET ViewState
2. Client-side Input Controls



Length limits
Javascript validation
Disabled elements
3. Thick Client Components



Java
ActiveX
Flash
CSC 666: Secure Software Engineering
Test Authentication Mechanism
CSC 666: Secure Software Engineering
Test Session Management
1. Understand Mechanism


Identify which data used to identify users.
Modify token one-byte at a time to find user part.
2. Test Tokens for Meaning


Compare tokens from multiple users.
Check for detectable encoding (Base64, etc.)
3. Test Tokens for Predictability

Use WebScarab to analyze stats of many tokens.
4. Check for Insecure Transmission of Tokens

Check if tokens transmitted via HTTPS only.
5. Check Mapping of Tokens to Sessions

Can you login twice as same user?
6. Test Session Termination

How long does it take for token to expire? Is there a logout?
CSC 666: Secure Software Engineering
Test Access Controls
1. Understand Access Control Requirements


Different access levels of users.
Data accessible to users at same level.
2. Test with Multiple Accounts


Use high level acct to identify functionality.
Attempt to access with lower level account.
3. Test with Limited Access

Find high level functionality w/o account.
4. Test for Insecure Access Control Methods


Check for simple URL parameters, acl=read.
Check for Referer header dependencies.
CSC 666: Secure Software Engineering
Test for Input-Based Vulnerabilities
1.
2.
3.
4.
5.
6.
SQL Injection
Cross-Site Scripting
Command Injection
Path Traversal
Script Injection
File Inclusion
CSC 666: Secure Software Engineering
Function-Specified Input Vulns
1.
2.
3.
4.
5.
SMTP Injection
Native code flaws (buffer overflows &c)
SOAP Injection
LDAP Injection
XPath Injection
CSC 666: Secure Software Engineering
Test for Logic Flaws
1. Identify Key Attack Surface




Multistage processes
Security functions such as login.
Trust boundary transitions.
Checks/changes to prices/quantities.
2. Multistage processes.


Can the steps be accessed out of sequence?
Submit params from one stage to another.
3. Test Handling of Incomplete Input

Remove parameters one by one.
4. Transaction logic.


Submit negative values (integer overflow.)
Can multiple small transactions bypass limit?
CSC 666: Secure Software Engineering
Test for Server Vulnerabilities
1. Test Segregation of Shared Infrastructure



Can customers gain shell access?
Can injection attacks access others’ data?
Submit requests with incorrect Host headers.
2. Test for dangerous HTTP methods


Use OPTIONS to list methods.
Look for WebDAV and TRACE methods.
3. Test for proxy functionality

Try to use GET/CONNECT to proxy requests.
4. Test for web server bugs

Scab OS + web server software.
CSC 666: Secure Software Engineering
Miscellaneous Checks
1. Test for DOM-based Attacks.

DOM-based XSS.
2. Test for frame injection.


Check for <frame> tags with name attribute.
Verify names are securely random.
3. Check for Local Privacy Vulnerabilities.


Check cookies for sensitive data, expiration dates.
Verify autocomplete=off set for sensitive form fields.
4. Follow Up Any Information Leakage.

Use Google code search for error messages.
5. Check for Weak SSL Ciphers.

Use THCSSLCheck to list ciphers/protocols.
CSC 666: Secure Software Engineering
Key Points
1. Test Types
1. Black Box
2. White Box
3. Grey Box
2. Testing Techniques
1. Equivalence classes
2. Boundary values
3. Fuzz testing
3. Security Testing Differences
4. Tools: Spiders, Proxies, Scanners
5. WAHH Methodology
CSC 666: Secure Software Engineering
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
Andres Andreu, Professional Pen Testing for Web Applications,
Wrox, 2006.
Brian Chess and Jacob West, Secure Programming with Static
Analysis, Addison-Wesley, 2007.
Gary McGraw, Software Security, Addison-Wesley, 2006.
Greg Hoglund and Gary McGraw, Exploiting Software, AddisonWesley, 2004.
Paco Hope and Ben Walther, Web Security Testing Cookbook,
O’Reilly, 2009.
Cem Kaner et. al., Testing Computer Software, Wiley, 1999.
Joel Scambray, Mike Shema, and Caleb Sima, Hacking Exposed:
Web Applications, 2nd edition, Addison-Wesley, 2006.
Daffyd Stuttard and Marcus Pinto, The Web Application Hacker’s
Handbook, Wiley, 2008.
Chris Wysopal, et. al., The Art of Software Security Testing,
Addison-Wesley, 2007.
CSC 666: Secure Software Engineering