Software Security Assessment

1. Software Security Assessment COEN 225

2. Code Auditing vs. Black Box Penetration Testing

3. Code Auditing vs. Black Box Penetration Testing • Security audits of software: • White box testing • Auditors work with source code • Manual code inspection • Automated tools such as • RATS, ITS4, Splint, Flawfinder, Jlint, Codespy • +: Complete code coverage is possible • -: Complexity: • Tools are imperfect and need to be supported by manual review • -: Occasional lack of availability of source code • Black box testing • Auditors provide input to program / service under audit. • +: Black box testing is always possible • +: Portability • Can test several applications with the same test suite • +: Simplicity • -: Coverage • -: Lack of intelligence

4. Code Auditing vs. Black Box Penetration Testing • Black Box Testing • Manual Testing • E.g.: Provide single quotes to various parameters in a form to find an sql or XSS attack possibility • Automated Testing or Fuzzing • Pros: • Availability: Fuzzing is always possible • Reproducibility: Fuzzing ports to similar applications to be tested • Simplicity: Fuzzing replaces analysis with extensive trials • Contras: • Coverage: Coverage usually implies code inspection • Intelligence: Fuzzing is unlikely to find complicated attack patterns

5. Code Auditing vs. Black Box Penetration Testing • Gray box testing • Combines black box testing with some Reverse Engineering (RE) • RE is used to identify possible vulnerabilities • Manual gray box testing • Use IDA PRO or similar disassembler tool to generate assembly code of binary • Identify possible vulnerabilities • Generate sample input • Automated gray box testing • Number of tools that automatize the process • BugScam • Inspector • Bin Audit • LogiScan • SecurityReview

6. Code Auditing vs. Black Box Penetration Testing • Gray box testing • Pro: • Availability: Can always be done • Coverage: Better than black box testing • Contra: • Complexity: Reverse Engineering is very difficult

7. Code Auditing vs. Black Box Penetration TestingExample struct keyval { char * key; char * value; } int handle_query_string(char * query_string) { struct keyval *qstring_values, *ent; char buf[1024]; if(!query_string) return 0; qstring_values = split_keyvalue_pairs(query_string); if(ent = find_entry(qstring_values, ″mode″))!= NULL) { sprintf(buf, ″MODE=%s″,ent->value); putenv(buf); } … } Vulnerability: Programmer assumes that ent->value fits into buffer ent->value is controlled by input

8. Code Auditing vs. Black Box Penetration TestingExample • Web server behaves differently if the query string contains • mode=xxx • Places string xxx into buffer • buffer can overflow • Black box testing will have difficulties finding this possible vulnerability • Gray box testing needs to find the if statement • Code inspection can find the faulty sprintf statement and check for existence of an actual vulnerability

9. Code Auditing and Development Life Cycle

10. System Development Life Cycle • Feasibility study • Requirements definition • Design • Implementation • Integration and Testing • Operation and Maintenance

11. Trust Relationships • Trust relationships: • Different components in a system place varying degrees of trust in each other. • Trust relationships need to be made explicit and investigated. • Transitive Nature of Trust

12. Trust Relationships:Misplaced Trust • Misplaced Trust = Making an unfounded assumption • Input: • Most vulnerabilities are triggered by malicious input • Developer assumes that no-one enters a 5000 character telephone number • Developer assumes that related software module sanitizes input to module under development

13. Trust Relationships:Misplaced Trust • Misplaced Trust = Making an unfounded assumption • Interfaces: • Mechanisms by which software components communicate with each other and the outside world. • Developers • chose method of exposing interface that does not provide enough protection from external attackers. • chose reliable method of exposing interface, but configure it incorrectly • assume that interface is too difficult for an attacker to access. • Example: • Custom network interface with custom encryption. • Attacker needs to reverse engineer a client

14. Trust Relationships:Misplaced Trust • Misplaced Trust = Making an unfounded assumption • Environment • Software does not run in a vacuum • Developer trusts environment, but attacker manipulates it • Classic example – teaser: /tmp – race • Application creates file in /tmp or /var/tmp • Attacker creates symbolic link while app is running • Application writes to the symbolic link instead Teaser Teaser TEASER

15. Trust Relationships:Misplaced Trust • Misplaced Trust = Making an unfounded assumption • Exceptions • Attacker causes unexpected change in application’s program flow by external measures • Example: • App writes to a (attacker-controlled) pipe • Attacker causes pipe to close just before write • Results in a SIGPIPE exception (in *nix) • App aborts, possibly leaving data incoherent Teaser Teaser TEASER

16. Design Review • Algorithms • E.g.: Sorted list poses a DoS risk if attacker can cause it to increase beyond reasonable bounds • Problem Domain Logic – Business Logic • Banking Example: • Person can make one monthly transaction with their money market account to or from checking. • Can make unlimited transfers to checking account. • If checking account is below limit, money is transferred from money market account to checking

17. Design Review • Trust Relationships • Trust boundary • Reflects limitation of trust between modules • Trust Domains • Regions of shared trust, limited by trust boundaries • Trust Model • Abstraction that presents these relationships

18. Design Review: Trust Relationship • Win98 Trust Model • Users are not protected from each other • If not networked, need to get physical access to machine Administrator Rest of World Administrative Privilege Boundary Physical Access Boundary User 1 User 2

19. Design ReviewExamples for Design Flaws • Exploiting Strong Coupling • Application is not decomposed along trust boundaries • Example: Windows Shatter • Windows WM_TIMER Message Handling can enable privilege elevation (12/2002) • Interactive processes need to react to user events • One mechanism is WM_TIMER, sent at expiration of timer • Causes process to execute a timer callback function • One process can cause another process to execute a timer callback function (of its choosing), even if the second process did not set a timer. • Several processes run with LocalSystem privileges • Attacker logs onto system interactively, executes program, that levies a WM_TIMER request upon a LocalSystem privilege process, causing it to take any action the attacker specifies. • Fixed by MS 2003

20. Design ReviewExamples for Design Flaws • Exploiting transitive trusts • Solaris Example: • Solaris contains automountd • Runs as root • Allows root to specify a command as part of a mounting operation • Does not listen on an IP network • Available only through three protected loopback transports • Solaris contains rpc.statd • Runs as root • Listens on TCP and UDP interfaces • Monitors NFS servers to send out notification if they go down • Clients tell rpc.statd which host to contact and what RPC program number to call on host

21. Design ReviewExamples for Design Flaws • Exploiting transitive trusts • Solaris Example continued: • Attacker registers local automountd with rpc.statd • Attacker tells rpc.statd that NFS server has crashed • rpc.statd contacts automountd daemon through loopback device • automountd trusts message since it comes from root through loopback device and carries out a command of the attacker’s choice. • Some work needed to make request a valid automountd request.

22. Design ReviewExamples for Design Flaws • Failure Handling • User friendly: • Recovers from problem • Generates assistance in solving problems • Security conscious: • Assumes that failure conditions are result of an attack • Close down app without explanation

23. Design ReviewExamples for Design Flaws • Authentication • Lack of authentication • Attacker can get access to a (presumably) private interface between modules in an app • Example: Web site does authentication in a main page, but then does not check it when using links from main site. • Untrustworthy credentials • Versions of sadmind were shipped without a default of “no authentication required” (1999) • Use of source IP address as a credential

24. Design ReviewExamples for Design Flaws • Authorization • Omitting authorization checks • Allowing users to set up authorization themselves • …

25. Design ReviewExamples for Design Flaws 200801091536 Logon Failure: Bob 200801091539 Logon Success: Alice 200801091547 Logout: Alice • Accountability • Logging Failure • Example: Log of Login Attempts • User name allows newlines • Accountability • Logging Failure • Example: Log of Login Attempts • User name allows newlines username: Alice\n 200801091559 Logon Success: Alice 200801091536 Logon Failure: Bob 200801091539 Logon Success: Alice 200801091559 Logon Failure: Alice 200801091559 Logon Success: Alice

26. Design ReviewExamples for Design Flaws • Confidentiality & Integrity • Obfuscation instead of encryption • Insecure Use of Encryption • Example: XOR-encryption • Storing Sensitive Data Unnecessarily • Example: Storing a password • Instead store (1-way) salted hash of password • Without salt, can use rainbow tables to crack password • Bait & Switch Attacks • Example: Using an insecure hash (MD5, SHA1) to validate • Application signs hash of request • If hash is insecure, can generate request with the same hash

27. Design ReviewThreat Modeling • Michael Howard and David LeBlanc: Writing Secure Code, Microsoft Press, 2002 • Frank Swiderski and Window Snyder: Threat Modeling, Microsoft Press 2004

28. Design ReviewThreat Modeling • Process during design phase, updated in later development phases • Information Collection • Application Architecture Modeling • Threat Identification • Documentation of Findings • Prioritizing of Implementation Review

29. Design ReviewThreat Modeling: Information Collection • Goal: Get understanding of application • Assets: • What has value for an attacker? • Entry points: • Path through which an attacker can access the system. • External entities: • Those that communicate with process through the entry points • External trust levels • Major components • Use scenarios

30. Design ReviewThreat Modeling: Information Collection • Developer Interviews • Keep in Mind • Developers have put lots of efforts into work. • Avoid any judgmental or condescending overtones • Developer Documentation • Often incomplete • Often no longer representative of implementation • Standards Documentation • Source Profiling (Not Source Inspection)

31. Design ReviewThreat Modeling: Information Collection • System Profiling • Requires access to a functioning installation • Approaches: • File system layout • Code reuse • Imports and Exports • Sandboxing • Determine all objects touched and all activities performed • Use sniffer and application proxies to record any network activity • Use tools such as FileMon, RegMon, WinObj, Process Explorer • Scanning

32. Database Web Application User Design ReviewThreat Modeling: Application Architecture Modeling • Create Data Flow Diagrams http request database query https request database response http answer https answer

33. Database Login process User Authenticated Operations Design ReviewThreat Modeling: Application Architecture Modeling • DFD level-0 diagram of login process login database query login status database response operational request database query operational response Authenticated user boundary database response

34. Check for HTTPS Look-up user Database Access denied Check password User Design ReviewThreat Modeling: Application Architecture Modeling Submit login request https connection accepted Redirect to https Query password salt for user Return salt Salt is valid Login accepted Query for username with salted password Invalid password Return user record Login failed Invalid salt value

35. Check for HTTPS Look-up user Database Check password User Design ReviewThreat Modeling: Application Architecture Modeling Submit login request Query password salt for user https connection accepted Redirect to https Return salt Invalid user name Salt is valid Query for username with salted password Invalid password Return user record Login accepted

36. Design ReviewThreat Identification • Process of determining an application’s security exposure • Uses attack trees

37. Design ReviewThreat Identification • Process of determining an application’s security exposure • Uses attack trees

38. Design ReviewThreat Identification 1. Adversary gains access to a user’s personal information 1.1. Gain direct access to the database 1.2. Login as target user 1.3. Hijack user session 1.4. Passively intercept personal data 1.1.1. Exploit a hole in system application or kernel 1.2.1. Brute force login 1.2.2. Steal user credentials 1.3.1. Steal user session cookie 1.4.1. Identify user connection initiation 1.4.2. Sniff network traffic for personal data 1.2.1.1. Identify user name 1.2.1.2. Identify user password

39. Design ReviewThreat Identification 1. Adversary gains access to a user’s personal information OR 1.1 Gain direct access to the database 1.1.1 Exploit a hole in system application or kernel 1.2 Log in as target user OR 1.2.1 Brute-force login AND 1.2.1.1 Identify user name 1.2.1.2 Identify user password 1.2.2 Steal user credentials 1.3 Hijack user session 1.3.1 Steal user session cookie 1.4 Passively intercept personal data AND 1.4.1 Identify user connection initiation 1.4.2 Sniff network traffic for personal data • Textual representation

40. Design ReviewThreat Mitigation • Adorn attack tree with threat mitigation measures • Dashed lines indicate improbable attack vectors

41. https required System patches up to date https required Design ReviewThreat Mitigation 1. Adversary gains access to a user’s personal information 1.1. Gain direct access to the database 1.2. Login as target user 1.3. Hijack user session 1.4. Passively intercept personal data 1.1.1. Exploit a hole in system application or kernel 1.2.1. Brute force login 1.2.2. Steal user credentials 1.3.1. Steal user session cookie 1.4.1. Identify user connection initiation 1.4.2. Sniff network traffic for personal data 1.2.1.1. Identify user name 1.2.1.2. Identify user password

42. Design ReviewDocumentation of Findings • Threat summary structure: • Threat:Bruce force login • Affected component:Web application login • Description:Clients can brute force attack usernames and passwords by repeatedly connecting and attempting to log in. This thread is increased because the application returns different error messages for invalid usernames and passwords making usernames easier to guess. • Result:Untrusted clients can gain access to a user account and therefore read or modify sensitive information • Mitigation Strategies: Make error messages ambiguous so that an attacker does not know whether the username or password is invalid. Lock the account after repeated failed login attempts

43. Design ReviewDREAD Risk Ratings Brute force login • Damage potential: 6 • Reproducibility 8 • Exploitability 4 • Affected users 5 • Discoverability 8 • Overall 6.2

44. Operational Review • Operational vulnerabilities • result from application’s configuration • result from deployment environment • Operational vulnerabilities can result from • configuration options • failure to use platform security mechanisms properly • insecure deployment • insecure base platform • Hence, responsibility falls between developer and administrative personnel

45. Operational Review • Attack surface reductions • Minimizing attack surface = Hardening platform • Get rid of unnecessary services • Use virtualization • Example: • IIS HTR vulnerabilities • Scripting technology not widely used because supplanted by ASP • Default IIS enabled HTR service • 1999 – 2002: Number of HTR vulnerabilities • Insecure Defaults • In order to make installation simple • Pay attention to • Application’s default settings • Platform’s default settings

46. Operational Review • Access Control • Externally, application depends completely on access control of host OS or platform • Example: • Python on Windows installed on C:\Python25 • Default write permissions on Windows to any direct subdirectory of c: drive • python uses mscvr71.dll • Attacker can provide mscvr71.dll in the Python25 directory • python.exe will pick mscvr71.dll in its own directory by preference

47. Operational Review • Secure Channel Vulnerabilities: • Simply not using a secure channel • Example: Web site sends session cookie in the clear • Acceptable for web-based email • Not acceptable for banking • Spoofing and Identification • Trusting TCP or UDP source addresses • Network profiles • NFS or Server Message Block (SMB) are acceptable within a firewall, but not without

48. Operational Review • HTTP request methods: • Question honoring TRACE, OPTIONS, and CONNECT requests • OPTIONS – Lists all services server accepts • TRACE – echoes request body to client • Worry about cross-scripting attacks • CONNECT – provides way for proxies to establish SSL connections • Directory Indexing

49. Operational Review • Protective Measures • Stack protection • Non-executable stack • Canaries • Address space layout randomization • Registered function pointers • Long-lived function pointer calls are wrapped by protective checks • Virtual machines

50. Operational Review • Host-based measures • Object and file system permissions • Restricted accounts • Chroot jails • System virtualization • One virtual system per service • Enhanced kernel protection • SELinux, Core Force • Host-based firewalls • Antimalware applications • File and object change monitors • Host-based intrusion detection systems