Penetration Testing

1. Penetration Testing James Walden Northern Kentucky University

2. Topics • Software Security Testing • Test Case Design • Tools • Attack Patterns • Web Application Testing Methodology CSC 666: Secure Software Engineering

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

4. Security Testing Injection flaws, buffer overflows, XSS, etc. Functional testing will find missing functionality. Intendended Functionality Actual Functionality CSC 666: Secure Software Engineering

5. 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. AbuseCases Risk Analysis Code Reviews + Static Analysis Security Testing Penetration Testing Security Operations Requirements Design Coding Testing Maintenance CSC 666: Secure Software Engineering

6. Security Testing Different from penetration testing • White box (source code is available.) • Use risk analysis to build tests. • Measure security against risk model. AbuseCases Risk Analysis Code Reviews + Static Analysis Security Testing Penetration Testing Security Operations Requirements Design Coding Testing Maintenance CSC 666: Secure Software Engineering

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

8. Equivalence Class Examples CSC 666: Secure Software Engineering

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

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

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

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

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

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

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

16. Edit Web Data • URL • Cookies • Form Data Web Proxy Web Server Web Browser Proxies • Tamper Data extension • Burp Suite • Paros Proxy • WebScarab CSC 666: Secure Software Engineering

17. Tamper Data CSC 666: Secure Software Engineering

18. Tamper Data CSC 666: Secure Software Engineering

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

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

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

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

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

24. WAHH Testing Methodology CSC 666: Secure Software Engineering

25. Map Application’s Content • Explore Visible Content • Browsing (cookies/JS enabled/disabled.) • Manual spidering • Consult Public Resources • Search Google / Internet Archive. • Discover Hidden Content • Check robots.txt and guess file/directory names. • Check HTML code for references to hidden content. • Discover Default Content • Use Nikto to find default server/frmwrk content. • Enumerate Identifier-Specified Functions • Identify where pages accessed via URL parameters. • Check for debug/admin URL parameters. CSC 666: Secure Software Engineering

26. Analyze Application • Identify Functionality • Core functionality of application. • Security mechanisms. • Peripheral functions like errors, redirects, logs. • Identify Data Entry Points • URLs, query strings, POST, cookies, headers. • Identify Technologies • Client-side code, server/frmwrk, svr code, etc. • Map the Attack Surface • Develop model of application’s inner structure. • Identify common vulnerabilities for each function. CSC 666: Secure Software Engineering

27. Test Client-Side Controls • Transmission of Data Via Client • Hidden fields • Cookies • Preset parameters • ASP.NET ViewState • Client-side Input Controls • Length limits • Javascript validation • Disabled elements • Thick Client Components • Java • ActiveX • Flash CSC 666: Secure Software Engineering

28. Test Authentication Mechanism CSC 666: Secure Software Engineering

29. Test Session Management • Understand Mechanism • Identify which data used to identify users. • Modify token one-byte at a time to find user part. • Test Tokens for Meaning • Compare tokens from multiple users. • Check for detectable encoding (Base64, etc.) • Test Tokens for Predictability • Use WebScarab to analyze stats of many tokens. • Check for Insecure Transmission of Tokens • Check if tokens transmitted via HTTPS only. • Check Mapping of Tokens to Sessions • Can you login twice as same user? • Test Session Termination • How long does it take for token to expire? Is there a logout? CSC 666: Secure Software Engineering

30. Test Access Controls • Understand Access Control Requirements • Different access levels of users. • Data accessible to users at same level. • Test with Multiple Accounts • Use high level acct to identify functionality. • Attempt to access with lower level account. • Test with Limited Access • Find high level functionality w/o account. • Test for Insecure Access Control Methods • Check for simple URL parameters, acl=read. • Check for Referer header dependencies. CSC 666: Secure Software Engineering

31. Test for Input-Based Vulnerabilities • SQL Injection • Cross-Site Scripting • Command Injection • Path Traversal • Script Injection • File Inclusion CSC 666: Secure Software Engineering

32. Function-Specified Input Vulns • SMTP Injection • Native code flaws (buffer overflows &c) • SOAP Injection • LDAP Injection • XPath Injection CSC 666: Secure Software Engineering

33. Test for Logic Flaws • Identify Key Attack Surface • Multistage processes • Security functions such as login. • Trust boundary transitions. • Checks/changes to prices/quantities. • Multistage processes. • Can the steps be accessed out of sequence? • Submit params from one stage to another. • Test Handling of Incomplete Input • Remove parameters one by one. • Transaction logic. • Submit negative values (integer overflow.) • Can multiple small transactions bypass limit? CSC 666: Secure Software Engineering

34. Test for Server Vulnerabilities • Test Segregation of Shared Infrastructure • Can customers gain shell access? • Can injection attacks access others’ data? • Submit requests with incorrect Host headers. • Test for dangerous HTTP methods • Use OPTIONS to list methods. • Look for WebDAV and TRACE methods. • Test for proxy functionality • Try to use GET/CONNECT to proxy requests. • Test for web server bugs • Scab OS + web server software. CSC 666: Secure Software Engineering

35. Miscellaneous Checks • Test for DOM-based Attacks. • DOM-based XSS. • Test for frame injection. • Check for <frame> tags with name attribute. • Verify names are securely random. • Check for Local Privacy Vulnerabilities. • Check cookies for sensitive data, expiration dates. • Verify autocomplete=off set for sensitive form fields. • Follow Up Any Information Leakage. • Use Google code search for error messages. • Check for Weak SSL Ciphers. • Use THCSSLCheck to list ciphers/protocols. CSC 666: Secure Software Engineering

36. Key Points • Test Types • Black Box • White Box • Grey Box • Testing Techniques • Equivalence classes • Boundary values • Fuzz testing • Security Testing Differences • Tools: Spiders, Proxies, Scanners • WAHH Methodology CSC 666: Secure Software Engineering

37. References • 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, Addison-Wesley, 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