e e Prof. Lingyu Wang

Transcription

1 INSE 6130 Operating System Security Logging/Auditing g/ g and Vulnerability/Defense e e Prof. Lingyu Wang 1

2 Outline Logging and Auditing Vulnerability and Defense 2

3 Overview Motivation Normal users - trust, but verify (Доверяй, но проверяй) Attacker track down what has happened Logging Record events or statistics (summary) to logs Example: failed logins, failed su s, last logins, system calls, network traffic, etc. Auditing Analyze log records for meaningful results Example: manual inspection, intrusion detection (IDS), alert correlation, IP trace back, etc. 3

4 Overview (Cont d) Relationship Logging provides inputs to auditing Auditing makes sense out of logs Challenge Logging: Attackers will alter or delete logs of their activities Auditing: Heavily depend on human intervention Good research topic: How to automatically extract useful information from logs 4

5 Logging Example: Windows Three logs for different types of events System event log: system crashes, component failures, etc Application event log: as requested by applications Security event log: logging in and out, system file accesses, etc Log files are binary Use Event Viewer to read Default location: C:\WINNT\system32\config\ (AppEvent.Evt, Evt SecEvent.Evt, Evt SysEvent.Evt) Evt) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog Default size 512K Can set to overwrite events when exceeding a certain size 5

6 Logging Example: Windows (Cont d) 6

7 Logging Example: Windows (Cont d) Performance logs Performance data from local or remote computers In a comma-separated or tab-separated format, a binary log-file format, or SQL database format Because logging g runs as a service, data collection o occurs regardless of whether any user is logged on Three types Counter: e.g., cpu usage, memory, etc. Trace: begin logging only after an event occur, e.g., crash Alert: a message be sent, a program be run, an entry be made to the application event log, etc. 7

8 Auditing Example - Backtracker Question: When break-ins happen, how can we figure out which application was exploited? Backtracker solution: In operating systems, causal dependencies exist between processes and files/file names (e.g., read/write a common file) Use the causal dependency to track from detected event (e.g., using Tripwire) back to exploited applications Based on Sam King and Peter Chen s Slides here 8

9 BackTracker intrusion occurs intrusion detected BackTracker runs, shows source of intrusion Online component logs objects and events - Logging Offline component find entry point and sequences of events leading to the detecting point - Auditing 9

10 What Dependency To Track? Process / Process fork, clone, etc (creating, sharing memory, signaling) Process / File read, write, exec Process / Filename open, creat, link, unlink, mkdir, rmdir, chmod, etc 10

11 Process File Socket Detection point Fork event Read/write event 11

12 Outline Logging and Auditing Vulnerability and Defense 12

13 Top Vulnerabilities - Windows Top Vulnerabilities in Windows Systems Internet Explorer (buffer overflowed by examples) Microsoft Office (buffer overflowed by examples) Windows Libraries, for example:.wmf image causes remote execution (CVE ) Buffer overflow DOS in HTML help (.hhp) (CVE ) Windows Services, for example: Buffer overflow in Server Service (CVE ) Windows Configuration Weaknesses NTLM password hashes 13

14 Top Vulnerabilities - UNIX Top Vulnerabilities in UNIX Systems UNIX Configuration Weaknesses E.g., Brute-force attack on SSH passwords Mac OS X E.g., Safari, when rendering RTF files, can directly access URLs without performing the normal security checks (CVE ) Securing Mac OS X 10.4 Tiger ( com/white-papers/ securing-mac- securing mac os-x-tiger.pdf) Resources for vulnerability CVE, Bugtraq, Nessus plugin DB, NVD, etc. 14

15 Vulnerability Example PHP open_basedir race condition vulnerability Release Date: 2006/10/04 Author: Stefan Esser php.net] Application: PHP 4/5 Risk: Critical The successful exploitation of this vulnerability allows access to files normally not accessible due to the open_basedir restriction E.g., /etc/shadow 15

16 Background PHP open_basedir configuration directive It tells PHP only files within the specified directory trees can be opened by scripts Symbolic links are fully parsed, so no get around (well, let s see) Example If my web space s s root is /www/home/w/wang, then my php scripts cannot visit /etc You cannot even create a symbolic link to /etc using function symlink(), either But 16

17 Create the Link to / Symbolic links are fully parsed So no easy get around Suppose we are in /www/home/w/wang / / / and we want to take a look at / through php scripts <?php mkdir("a/a/a/a"); symlink("a/a/a/a", "dummy"); symlink("dummy/../../../../", mylnk"); unlink("dummy"); symlink(".", "dummy");?> Now mylnk points to / 17

18 Let s Race Run two scripts simultaneously a.php: keeps alternating a symbolic link newlnk between mylnk y and /www/home/w/wang / / / / g in a loop b.php: keeps listing directory newlnk in a loop Sooner or later b.php gives you the content in / 18

19 Race Condition There is a small time span between php checks permissions and it actually opens a file When php check for permission, newlnk points to /www/home/w/wang, which is allowed When php p opens the directory, newlnk points to mylnk, which in turn points to / bphp b.php a.php open_basedir p okay /www/hom / e/w/wang /www/hom e/w/wang / 19

20 Defense - Objectives Detect intrusions Previously known attacks Zero-day attacks In a timely fashion Real-time Present accurate results False positives, false negatives In an easy-to-understand format Alerts versus attack scenarios 20

21 Classification of Intrusion Detection (We are considering Host-Based IDS) Anomaly detection Assumption: attacks vary from normal behaviors Method: statistics, data mining, Machine learning, etc. Advantage: potentially detect zero-day attacks Disadvantage: (theoretically) less accurate Misuse detection ti Assumption: attacks can be identified with a signature Method: state transition, colored Petri net, etc. Advantage: more accurate Disadvantage: can only detect modeled attacks 21

22 Example of Anomaly Detection Sequence of system calls (Forrest 1996) Training Training data: open read write open mmap write fchmod close Sliding window of size 1+3 (1 followed by 3) open read write open open mmap write fchmod read write open mmap write open mmap write write fchmod close mmap write fchmod close fchmod close close This is the normal behavior 22

23 Example of Anomaly Detection Detection open read write open open mmap write fchmod read write open mmap write open mmap write write fchmod close mmap write fchmod close fchmod close close open read read open mmap write fchmod close Differs in 5 places: Second read should be write (1st line) Second read should be write (3rd line) Second open should be write (3rd line) mmap should be open (3rd line) write should be mmap (3rd line) 18 possible places of difference 18=5*3+2+1 Mismatch rate 5/18 28%? A pre-defined threshold 23

24 Difficulty w/ Anomaly Detection Question: Is an 99% accurate IDS any good? Intuitively Answer: maybe? Counter-intuitively Answer: not necessarily! If attack rate is one attack per 1,000,000 calls Which h is reasonable The base rate fallacy says the IDS will generate about 10, false positives for every real attack it detects Why? Which is absolutely not acceptable 24

25 Base Rate Fallacy What does the attack rate mean? In 100,000,000 calls, there are 100 real attacks What does 99% accuracy mean? False positives: (100,000, )*1/100= 1,000,000 False negatives: 100*1/100= 1 100,000, normal and not detected 1,000,000 normal but detected attack but not detected t d 1 99 attack and detected 1,000,000 false positives per 99 detected attacks! false negative false positive 25

26 Example of Misuse Detection t1 %cp p/ /bin/csh/ /usr/spool/mail/root/ / / t2 %chmod4755 /usr/spool/mail/root t3 %touch x t4 %mail root<x t5 %/usr/spool/mail/root t6 $ t1,t2 create a SUID shell /usr/spool/mail/root t3,t4 t4 let mail to change the shell ss owner to be root Then you have an executable root s shell Cool, but how do we create a signature for this attack? 26

27 Colored Petri Net The attack steps are partially ordered t1<t2, t3<t4, t1<t5,? Modeled with a colored Petri net 27

28 Colored Petri Net (Cont d) Will these be detected? t3, t1, t2, t4 t1, t3, t2, t4 t2, t1, t3, t4 t1, t2, t4 28

29 Difficulty of Misuse Detection Zero day exploit Exploit is on the same day or before the vulnerability is publicized It has no signature Other defense methods, for example, Buffer overflow overwrite memory from the buffer to the return address So put a canary word before return address If it s been changed, the function won t return The canary word must be random, why? 29

30 Other OS Defense Methods NX bit No execute bit (last bit of the paging table entry) Can be used to mark stack as non-executable to prevent buffer overflow attacks Pentium tu 4 or later, AMD64 Many OS support this or emulate it via software Linux, Solaris 10, WinXP SP2, Win2003 SP1, etc. Vulnerable to return-to-libc attack No need to return to shell code on stack, but return to existing function 30

31 Other OS Defense Methods Memory randomization Make buffer overflow, including return-to-libc, more difficult Basic idea: Buffer overflow and return-to-libc exploits need to know the address of attack code in the buffer, or address of a standard kernel library routine Same address is used on many machines Slammer infected 75,000 MS-SQL servers using same code So introduce artificial diversity Make stack addresses, addresses of library routines, random Supported by OpenBSD, Windows vista, PaX, Hardened d Gentoo, etc. 31

32 w/o Randomization Stack Frame c o d e b u f Exploit! r e t a dd d r 3 GB 32

33 w/ Randomization Stack Frame c o d e b u f r e t a d d r b u f crash 3 GB 33

34 De-Randomization The amount of randomness is limited PaX only uses 16 bit of random shift Subject to de-randomization attacks Repetitively guess randomized address Spraying injected attack code 34

35 De-Randomization 1 Stack Frame c o d e b u f r e t a d d r Pad crash Step 1 35

36 De-Randomization 2 Stack Frame c o d e b u f r e t a d d r Pad crash Step 2 36

37 De-Randomization 3 Stack Frame r c o d e b u f e t a d d r Pad Exploit! 216 seconds (avg.) to derandomize! Step

38 Spraying Attacks Exploit a buggy application and spray p y attack code in write-able user-level memory areas c o d e b u f Exploit! 38