CIT 380: Securing Computer Systems. Software Security

Transcription

1 CIT 380: Securing Computer Systems Software Security

2 Topics 1. The problem of software security 2. System security standards 3. Secure lifecycle 4. Buffer overflows 5. Integer overflows 6. Format string attacks

3 Traditional Security is Reactive Perimeter defense (firewalls) Intrusion detection Over-reliance on cryptography Penetrate and patch Penetration testing

4 The Problem is Software 75% of hacks happen at the application. - Theresa Lanowitz, Gartner Inc. 92% of reported vulnerabilities are in apps, not networks. - NIST 64% of developers are not confident in their ability to write secure code. - Bill Gates

5 Connectivity Trinity of Trouble Ubquitious Internet; wireless & mobile computing. Complexity Networked, distributed code that can interact with intermediate caches, ad proxies, etc. Extensibility Systems evolve in unexpected ways, e.g. web browsers, which support many formats, add-ons, plugins, programming languages, etc.

6 SSE Objectives 1. Dependability: software functions only as intended; 2. Trustworthiness: No exploitable vulnerabilities or malicious logic exist in the software; 3. Resilience: If compromised, damage will be minimized, and it will recover quickly to an acceptable level of operating capacity; 4. Conformance: to requirements and applicable standards and procedures.

7 System Security Certifications Software system security certifications Orange Book ISO Common Criteria PCI Data Security Standard (PCI DSS) Many standards indirectly impact SSE FISMA (supersedes CSA of 1987) HIPAA (health information privacy) Gramm Leach Bliley Act (GLB) SOX (Sarbanes-Oxley)

8 Orange Book Trusted Computer System Eval Criteria Issue in 1983 by NSA. Replaced by Common Criteria in System classification levels D: failed evaluation for higher level classification C: discretionary protection Authentication, DAC, basic auditing B: mandatory protection MAC, security policy requirements, auditing incl covert channels A: verified protection Formal specification and design techniques with proofs

9 Common Criteria ISO standard International standard, used by US and others. Protection Profile (PP) Description of system, e.g. anti-virus, firewall, smartcard Evaluation Assurance Level (EAL)

10 PCI DSS PCI Data Security Standard (PCI DSS) Proprietary security standard for organizations that handle card payment information for major credit and debit card companies. Requirements Network security Cardholder data security Access control and auditing Security policy Vulnerability management, and Develop and maintain secure systems and applications

11 Secure Development Processes CLASP (Comprehensive, Lightweight Application Security Process) Correctness-by-Construction (formal methods based process from Praxis Critical Systems) MS SDL (Microsoft Secure Development Lifecycle) SSE CMM (Secure Software Engineering Capability Maturity Model) TSP-Secure (Team Software Process for Secure Software Development) Touchpoints

12 Security Lifecycle 1. Code Reviews 2. Risk Analysis 3. Penetration Testing 4. Security Testing 5. Abuse Cases 6. Security Operations Abuse Cases Risk Analysis Code Reviews + Static Analysis Security Testing Penetration Testing Security Operations Requirements Design Coding Testing Maintenance

13 Code Reviews Fix implementation bugs, not design flaws. Benefits of code reviews 1. Find defects sooner in the lifecycle. 2. Find defects with less effort than testing. 3. Find different defects than testing. 4. Educate developers about security flaws.

14 Architectural Risk Analysis Fix design flaws, not implementation bugs. Risk analysis steps 1. Develop an architecture model. 2. Identify threats and possible vulnerabilities. 3. Develop attack scenarios. 4. Rank risks based on probability and impact. 5. Develop mitigation strategy. 6. Report findings

15 Black Box Testing Advantages of Black Box Testing 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. Test Input System Test Output

16 White and Grey Box Testing White Box Tester knows all information about system. Including source code, design, requirements. Most efficient technique. Avoids security through obscurity. Grey Box Apply both white box and black box techniques. Test Input Test Output

17 Penetration Testing Black box test of deployed system. Allocate time at end of development to test. Often time-boxed: test for n days. Schedule slips often reduce testing time. Fixing flaws is expensive late in lifecycle. Penetration testing tools Test common vulnerability types against inputs. Fuzzing: send random data to inputs. Don t understand application structure or purpose.

18 Security Testing Functional testing will find missing functionality. Injection flaws, buffer overflows, XSS, etc. Intendended Functionality Actual Functionality

19 Security Testing Two types of testing Functional: verify security mechanisms. Adversarial: verify resistance to attacks generated during risk analysis. Different from traditional penetration testing White box. Use risk analysis to build tests. Measure security against risk model.

20 Anti-requirements Abuse Cases Think about what software should not do. A use case from an adversary s point of view. Obtain Another User s CC Data. Alter Item Price. Deny Service to Application. Developing abuse cases Informed brainstorming: attack patterns, risks.

21 Security Operations User security notes Software should be secure by default. Enabling certain features may have risks. User needs to be informed of security risks. Incident response What happens when a vulnerability is reported? How do you communicate with users? How do you send updates to users?

22 Buffer Overflows A program accepts too much input and stores it in a fixed length buffer that s too small. char A[8]; short B=3; A A A A A A A A B B gets(a); A A A A A A A A B B o v e r f l o w s 0

23 Buffer Overflow domain.c Main(int argc, char *argv[ ]) /* get user_input */ { char var1[15]; char command[20]; strcpy(command, whois "); strcat(command, argv[1]); strcpy(var1, argv[1]); printf(var1); system(command); } Retrieves domain registration info: $ domain nku.edu Top of Memory 0xFFFFFFFF var1 (15 char) command (20 char). Bottom of Memory 0x Stack Fill Direction

24 strcpy() Vulnerability domain.c Main(int argc, char *argv[]) /*get user_input*/ { char var1[15]; char command[20]; strcpy(command, whois "); strcat(command, argv[1]); strcpy(var1, argv[1]); printf(var1); system(command); } argv[1] is the first command line argument strcpy(dest, src) does not check buffer size strcat(d, s) concatenates strings Top of Memory 0xFFFFFFFF argv[1] var1 argv[1] (15 char) (15 (20 char) char) Overflow command exploit (20 char). Bottom of Memory 0x Stack Fill Direction

25 Stack Smashing void fingerd ( ) { char buf[80]; get(buf); } previous frames current frame f() arguments return address local variables f() arguments return address buffer EIP EIP attacker s input malicious code next location padding The fingerd service, which was once ran as root was vulnerable to buffer overflow attacks in 1988, the year of the Morris worm, which exploited fingerd by: Writing malicious code to stack buffer. Overwroting return address w/ address of malicious code. Function returns to malicious code, not to calling function. program code program code

26 Shellcode Shellcode in C. int main() { char *name[2]; name[0] = "/bin/sh"; name[1] = 0x0; execve(name[0], name, 0x0); } Running the program. > gcc static o shell shellcode.c >./shell sh-3.00$ exit

27 Buffer Overflow Mitigations 1. Use a language with bounds checking. Examples: Ruby, Python, Java 2. Do your own bounds checking. Or use secure libraries to do it for you. 3. Page protection (no-exec stack). 4. Address space randomization. 5. Canaries inserted by compiler.

28 Canaries on the Stack Buffer Normal (safe) stack configuration: Other local variables Canary (random) Return address Other data Buffer Buffer overflow attack attempt: Overflow data Corrupt return address Attack code x The canary is placed in the stack prior to the return address, so that any attempt to overwrite the return address also overwrites the canary.

29 Key Points 1. System security certifications 1. Orange book, Common criteria, PCI DSS 2. Security lifecycle 1. Abuse cases 2. Architectural risk analysis 3. Code reviews 4. Penetration and security testing 5. Operations 3. Buffer overflow vulnerabilities 1. Allow overwriting of process memory. 2. Can inject machine code into process from across network. 3. Can overwrite instruction pointers, like the return address. 4. When instruction pointer is used, injected code is executed.

30 References 1. Aleph Null, Smashing the Stack for Fun and Profit, Phrack 49, Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, Goodrich and Tammasia, Introduction to Computer Security, Pearson, Koziol, et. al, The Shellcoder s Handbook: Discovering and Exploiting Security Holes, Wiley, Robert C. Seacord, Secure Coding in C and C++, Addison- Wesley, John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, David Wheeler, Secure Programming for UNIX and Linux HOWTO,