Vulnerability Analysis CSSE 490 Computer Security Mark Ardis

Vulnerability Analysis CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute April 26, 2004 1

Acknowledgements Many of these slides came from Chris Clifton and Matt Bishop, author of Computer Security: Art and Science 2

Vulnerability Analysis l Vulnerability or security flaw: specific failures of security controls (procedures, technology or management) l l l Errors in code Human violators Mismatch between assumptions Exploit: Use of vulnerability to violate policy Attacker: Attempts to exploit the vulnerability 3

Techniques for Detecting Vulnerabilities l System Verification Determine preconditions, post-conditions l Validate that system ensures post-conditions given preconditions Can prove the absence of vulnerabilities l l Penetration testing Start with system/environment characteristics l Try to find vulnerabilities Cannot prove the absence of vulnerabilities l 4

System Verification l What are the problems? l l l Invalid assumptions Limited view of system Still an inexact science External environmental factors Incorrect configuration, maintenance and operation of the program or system 5

Penetration Testing l Test strength of security controls of the complete system l l l Attempt to violate stated policy Works on in-place system Framework for evaluating results Examines procedural, operational and technological controls Typical approach: Red Team, Blue Team, White Team l l l Red team attempts to discover vulnerabilities Blue team simulates normal administration l Detect attack, respond White team injects workload, captures results 6

Types/layers of Penetration Testing l l Black Box (External Attacker) l External attacker has no knowledge of target system l Attacks often build on human element – Social Engineering System access provided (External Attacker) l Red team provided with limited access to system l l Goal is to gain normal or elevated access l l Models external attack Then violate policy Internal attacker l Red team provided with authorized user access l Goal is to elevate privilege / violate policy 7

Red Team Approach Flaw Hypothesis Methodology: l Information gathering l l Flaw hypothesis l l Flaw does Not exist Determine where vulnerabilities exist Flaw generalization l l Predict likely vulnerabilities Flaw testing l l Examine design, environment, system functionality Refine with new understanding Attempt to broaden discovered flaws Flaw elimination (often not included) l Suggest means to eliminate flaw 8

Problems with Penetration Testing l Nonrigorous l l l How do we make it systematic? l l l Dependent on insight (and whim) of testers No good way of evaluating when “complete” Try all classes of likely flaws But what are these? Vulnerability Classification! 9

Vulnerability Classification l Goal: describe spectrum of possible flaws l l Enables design to avoid flaws Improves coverage of penetration testing Helps design/develop intrusion detection How do we classify? l l l By how they are exploited? By where they are found? By the nature of the vulnerability? 10

Example flaw: xterm log l xterm runs as root l l Generates a log file Appends to log file if file exists Problem: ln /etc/passwd log_file Solution if (access(“log_file”, W_OK) == 0) fd = open(“log_file”, O_WRONLY|O_APPEND) l What can go wrong? 11

Example: Finger Daemon (exploited by Morris worm) l finger sends name to fingerd l l l fingerd allocates 512 byte buffer on stack Places name in buffer Retrieves information (local finger) and returns Problem: If name > 512 bytes, overwrites return address Exploit: Put code in “name”, pointer to code in bytes 513+ l Overwrites return address 12

Vulnerability Classification: Generalize l l l xterm: race condition between validation and use fingerd: buffer overflow on the stack Can we generalize to cover all possible vulnerabilities? 13

RISOS: Research Into Secure Operating Systems 1. Incomplete parameter validation – – 2. Inconsistent parameter validation – 3. Trojan horse; accounts without passwords Violable prohibition / limit – 7. Race conditions and Time-of-Check-to-Time-of-Use flaws Inadequate identification /authentication / authorization – 6. OS fails to isolate processes and users Asynchronous validation / inadequate serialization – 5. Different routines with different formats for same data Implicit sharing of privileged / confidential data – 4. Check parameter before use E. g. , buffer overflow – Improper handling of bounds conditions (e. g. , in memory allocation) Exploitable logic error – Incorrect error handling, incorrect resource allocations etc. 14

Protection Analysis Model Classes l Pattern-directed protection evaluation l l Applied to several operating systems l l Methodology for finding vulnerabilities Discovered previously unknown vulnerabilities Resulted in two-level hierarchy of vulnerability classes 15

PA flaw classes 1. 2. 3. 4. Improper protection domain initialization and enforcement a. domain: Improper choice of initial protection domain b. exposed representations: Improper isolation of implementation detail (Covert channels) c. consistency of data over time: Improper change d. naming: Improper naming (two objects with same name) e. residuals: Improper deallocation or deletion Improper validation (validation of operands, queue management dependencies) Improper synchronization a. interrupted atomic operations: Improper indivisibility b. serialization: Improper sequencing critical operator selection errors: Improper choice of operand or operation 16

Aslam’s Model l Attempts to classify faults unambiguously l l l Emergent Faults l Decision procedure to classify faults Configuration errors l l Coding Faults l Synchronization errors l l l Timing window Improper serialization l l Wrong install location Wrong configuration information Wrong permissions Environment Faults Condition validation errors l l Bounds not checked Access rights ignored Input not validated Authentication / Identification failure 18

Common Vulnerabilities and Exposures (cve. mitre. org) l Captures specific vulnerabilities l l l Standard name Cross-reference to CERT, etc. Name CVE-1999 -0965 Description Race condition in xterm allows local users to modify arbitrary files via the logging option. Entry has three parts l l l Unique ID Description References • CERT: CA-93. 17 • XF: xterm 19