1 / 96

Computer Forensics Use of Malicious Input

This article discusses the use of malicious input buffer and heap overflow attacks in computer forensics, including their role in system access escalation and their common occurrence. It also highlights some real-world examples and offers lessons learned in dealing with these attacks.

lavin
Télécharger la présentation

Computer Forensics Use of Malicious Input

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Computer Forensics Use of Malicious Input

  2. Buffer and Heap Overflow Attacks • Standard Tool to Break Into Systems. • Used for Access Escalation. • Very Common. • Prototype of an Attack Mode.

  3. Beware of User Input • Anonymous FTP should allow access to files selectively. • One implementation parsed the file name. • Assume /pub/acc is an allowed directory. • Request: get /pub/acc/../../../etc/passwd

  4. Beware of User Input • This implementation only parsed the first part of the string. • Decided access is OK • get /pub/acc/../../../etc/passwd • Allowed access to any file. • Took several versions before the security breach was firmly patched.

  5. Morale: • Don’t reinvent the wheel. • Other implementations used a sandbox. • Community had learned how to get it right. • Parsing input is difficult. • Users have an incentive to be inventive. • ALL INPUT IS EVIL

  6. ALL INPUT IS EVIL • Canonical Representation Issues • Canonicalization: Translates name to standard representation. • Canonical Filenames • Napster Name Filtering. • Ordered to restrict access to certain songs. • Access was denied based on name of the song. • Users bypassed it with uncanonical song names • Deepest Chill  Deepest Chi11 • Candyman  AndymanCay (in pig latin)

  7. ALL INPUT IS EVIL • Mac OS X and Apache Vulnerability • HFS+ is case insensitive. • Apache uses text-based configuration files, that are case sensitive, to determine • Disallow access to directory scripts: <Location /scripts> order deny, allow deny from all </Location

  8. ALL INPUT IS EVIL • Denies user request • Allows user request http://www.mysite.org/scripts/index.html http://www.mysite.org/SCRIPTS/index.html

  9. ALL INPUT IS EVIL • Sun StarOffice /tmp directory symbolic link vulnerability • Symbolic link: file that points to another file. • Symbolic links do not share access rights with the file they point to.

  10. ALL INPUT IS EVIL • Sun StarOffice creates file /tmp/soffice.tmp with 0777 access mask. • Attacker links /tmp/soffice.tmp to /etc/passwd. • Root runs StarOffice • Permissions on /etc/passwd would get changed to 0777.

  11. Canonicalization Issues • Subsystems cooperate. • First subsystem does not canonicalize input in the way the second one does.

  12. Canonicalization Issues • Common when software make decisions on file names • 8.3 representation of file names • IIS looks at extensions. • Request to ***.asp::$DATA is routed to asp.dll. But this is a NTFS stream, that sends the ASP source code to the user. • Trailing dots or slashes • “secretFile.doc.” is same as “secretFile.doc” for windows.

  13. Canonicalization Issues • \\?\temp\myfile is the same as \temp\myfile • Directory traversal ../ • AOL 5.0 parental controls: • Bypass restriction on URL by adding period to file name. • Secure IIS verifies incoming and outgoing data • Use hexcode: %64elete instead of delete for key words. • Use “%2e%2e/” for “../” • Two canonalization issues in Security Software!

  14. Canonicalization Issues • Lines with carriage returns: • Assume logging of file access: • Attacker accesses file: • Log entry: 111.11.11.11 Mike 2004-02-19 13:02:12 file.txt file.txt\r\n127.0.0.1\tTom2004-02-19\t13:02:12\tsecret.doc 111.11.11.11 Mike 2004-02-19 13:02:12 file.txt 127.0.0. 1 Tom 2004-02-19 13:02:12 secret.doc

  15. Canonicalization Issues • Escaping: Many ways to represent a character • US-ASCII • Hexadecimal escape codes • UTF-8 variable width encoding • UCS-2 Unicode encoding • HTML escape codes • Double Escaping

  16. Canonicalization Issues • Homograph Attacks • Characters look the same, but are not • Latin letter “o” • Cyrillic character “o” (U+043E)

  17. Morale • Software should not make decisions based on names. • If it has do, enforce name restrictions • Don’t trust relative paths.

  18. Data Base Inputs • Don’t trust the user. • Data base access over the web lead to execution of sql code. • string sql = “select * from client where name = ‘” + name + “’” • Variable name provided by user • If name is Schwarz, this executes • string sql = “select * from client where name = ‘schwarz’”

  19. Data Base Inputs • User enters: • Schwarz’ or 1=1 - - • The sql statement becomes • string sql = “select * from client where name = ‘schwarz’ or 1=1 - -” • Selects all clients • - - SQL comment, comments out everything behind.

  20. Buffer Overflow Exploits and Much More • How do you break in? • In the following: • Overview of Buffer Overflow Exploits • Detailed Explanation of Buffer Overflow Exploits • Writing Shell-code • Heap exploits

  21. Buffer Overflow Attacks • Stack: push and pop

  22. Buffer Overflow Attacks • Memory used by a program is split into segments. • Data segment – global program variables • BSS segment – static program variables • Heap – dynamic program variables • Stack – procedure call data and local variables

  23. Buffer Overflow Attack int main(int argc, char* argv[]) { foo(argv[1]); return 0; } void foo(const char* input) { char buf[10]; printf("Hello World\n"); }

  24. Buffer Overflow Attack int main(int argc, char* argv[]) { foo(argv[1]); return 0;} void foo(const char* input) { char buf[10]; printf("Hello World\n"); }

  25. Buffer Overflow Attack • Works by overwriting the return address to jump somewhere else.

  26. Buffer Overflow Attack #pragma check_stack(off) #include <string.h> #include <stdio.h> void foo(const char* input) { char buf[10]; printf("My stack looks like:\n%p\n%p\n%p\n%p\n%p\n%p\n\n"); strcpy(buf, input); printf("%s\n", buf); printf("Now the stack looks like:\n%p\n%p\n%p\n%p\n%p\n%p\n\n"); }

  27. Buffer Overflow Attack void bar(void) { printf("Augh! I've been hacked!\n"); }

  28. Buffer Overflow Attack int main(int argc, char* argv[]) { printf("Address of foo = %p\n", foo); printf("Address of bar = %p\n", bar); if (argc != 2) { printf("Please supply a string as an argument!\n"); return -1; } foo(argv[1]); return 0; }

  29. Buffer Overflow Attack Chapter05>stackoverrun.exe Hello Address of foo = 00401000 Address of bar = 00401050 My stack looks like: 00000000 00000A28 7FFDF000 0012FEE4 004010BB 0032154D Hello Now the stack looks like: 6C6C6548 0000006F 7FFDF000 0012FEE4 004010BB 0032154D

  30. Buffer Overflow Attack Chapter05>stackoverrun.exe Hello Address of foo = 00401000 Address of bar = 00401050 My stack looks like: 00000000 00000A28 7FFDF000 0012FEE4 004010BB 0032154D Hello Now the stack looks like: 6C6C6548 0000006F 7FFDF000 0012FEE4 004010BB 0032154D

  31. Buffer Overflow Attack

  32. Buffer Overflow Attack • If we overflow the buffer, then we overwrite the return address. • If we overwrite the return address, then (mostly), the memory location executed after the return does not belong to the program. • Segmentation Fault. • O.K., now we know how to write programs that crash!!!!!!!!

  33. Buffer Overflow Attack • By looking at the program and its output, we can write the address of bar into the return address. • This will cause the execution to go to bar.

  34. Buffer Overflow Attack Address of Bar

  35. Buffer Overflow Attack

  36. Buffer Overflow Attack • This is fun, but useless. • Real attack: overwrite return address so that code execution jumps into the input given by attacker.

  37. Buffer Overflow Attack • To protect against signatures, structure input • Varying stuff such as NOP sled • execve(/bin/sh) (gives new shell with program privileges in UNIX) • Pointer to execve statement. • This pointer overwrites the return address.

  38. Buffer Overflow Attack • Finding vulnerabilities • Script-kiddies scan target with automated tool. • Tool creator has detailed analysis of vulnerabilities. • Look for strcpy, gets, getws, memcpy memmove, scanf, … • Alternatively, just cram the application until it crashes. • Crash used to give you locations of registers.

  39. Buffer Overflow Attack • Example: Cram in lots of input of As. • Program crashes, EIP has value 41414141. • Sign of buffer overflow. • Now try to feed more specific input.

  40. Buffer Overflow Attack

  41. Buffer Overflow Attack • Attack signature can be used by IDS. • Vary the NOP commands. • Many alternatives.

  42. Buffer Overflow Attack • Protection • Make stack non-executable. • Use canary birds.

  43. Buffer Overflow Attack • Stack Guard • MS Visual Studio use canaries.

  44. Buffer Overflow Attack • Happen a lot: • Most frequent vulnerability according to CERT • MS Outlook Vcard: Virtual business card buffer overflow vulnerability. • IIS 5 • Internet Printing Protocol

  45. Heap Overflow Attack • These protections do not apply to heaps, where dynamically allocated memory resides. • Some of this memory contains the addresses of functions that are going to be called. • Harder to find, harder to protect against.

  46. Remember: People attack computer systems because they can.

  47. Final Question • You find evidence of a crime on a system that you are administering. However, in finding and collecting the evidence, you violated the law. You feel strongly about the case and hence you send the evidence anonymously to the police who use this to investigate the perpetrator. Is the collected evidence admissible in a court of law? • No, you obtained the material without proper authorization and therefore violated constitutional protection. • No, it needed to be collected in a forensically sound manner, which you did not do since you did not pay attention in class. • Yes, you were not acting as an agent of the government and the constitutional amendments protect only against actions by government. • Yes, since the evidence came from a system that the perpetrator did not own.

  48. Buffer Overflow Details • This function just mismanages the stack: int main ( int argc, char* argv[]) { char buffer[500]; strcpy(buffer, argv[1]); return 0; }

  49. Buffer Overflow Attack Details • Assume that this program is a suid root program: $ sudo chown root vuln $ sudo chmod +s vuln $ ls –l vuln -rwsr-sr-x 1 root linuxUser 4934 May

  50. Buffer Overflow Attack Details • We need three ingredients to break this code: • NOP sled • Shell-code • Assembly language code that spawns a shell • Return address (into the beginning of the overflowing buffer) • Need to guess approximate location of the buffer • Use current stack pointer to estimate beginning of buffer

More Related