Exploits Against Software and Defences

1. Exploits Against Software and Defences Nicolas T. Courtois - University College London

2. How to Break Into Computers? • Stack attacks: Chapter 10.4. • SQL injection: not at the exam: see our lab. • Defences: Chapter 10.7. Nicolas T. Courtois, January 2009

3. Is that All? There is MUCH more (not covered here): • Language Based Security COMPGS10 course (Term 2)… • Government agencies and hackers have found LOTS of software security holes, • AUTOMATION, formal methods • Requires source code (cf. Common Criteria evaluations) • Example: in just one Huawei Chinese router firmware experts found 10 000 unsafe calls to the sprintf function alone… Main Learning Objective: Understand the principal sources of attacks and what the defences are. Nicolas T. Courtois, January 2009

4. Goals of Attackers

5. Break In Stage 1: Get to run some code (even without privileges). Stage 2: Gain admin access, usually by calling other local programs and exploiting their vulnerabilities. Nicolas T. Courtois, December 2009

6. Later… • create a backdoor for later access • cover your traces • e.g. disable anti-virus, erase log files, etc… • payload: execute extra tasks Nicolas T. Courtois, December 2009

7. Goals for Software Exploits these also happen accidentally… • crash software (can be DOS) • crash hardware (e.g. hard drive) • get some data or side channels • inject arbitrary code Nicolas T. Courtois, December 2009

8. What’s Wrong?

9. Software Vulnerabilities • Input validation problems • Buffer overflow • Format string vulnerabilities • Integer overflows, • CPU bugs • Failing to handle errors / exceptions properly • etc… Nicolas T. Courtois, December 2009

10. Vectors of Attack - Inputs

11. Software Input Exploits Exe programs: • command line arguments • environment variables • configuration files / settings changed in the registry by another program… • network packets • etc… Dlls / Unix runtime precompiled libraries: • function calls from other programs Nicolas T. Courtois, December 2009

12. Danger of Environment Variables In UNIX: • Set LD_LIBRARY_PATH system variable to avoid the standard precompiled libraries… • Hacker puts his own libraries in his own directory… BTW. Fix: modern C runtime libraries in Unix stopped using LD_LIBRARY_PATH at least in many cases… Nicolas T. Courtois, December 2009

13. Revision: set-uid programs Def: A “set-uid program” (property acquired at install) is a program that assumes the identity and has euid and privileges of the owner of the program, though a different user runs it. Examples: • passwd • su, sudo BTW: if copied to a “user” directory, stop working! Nicolas T. Courtois, December 2009

14. More Attacks on PATH in Unix Now imagine that any “setuid program” contains the following line: system(“ls … ”); OOPS… there are several ways to use this to run any program as root… Nicolas T. Courtois, December 2009

15. More Attacks on PATH in Unix A “setuid program” ABC contains the following line: system(“ls …”); The user sets his PATH to be =“.” and places his own program ls in the current directory. This program ls will be run as root. (remark: the program A can reset PATH or do checks on PATH…) Nicolas T. Courtois, December 2009

16. Another Known Exploit in Unix • The IFS variable: the characters that the system considers as white space • now add “s” to the IFS set of characters • system(ls) becomes system(l) • a function l in the current directory will be run as root… Nicolas T. Courtois, December 2009

17. Can this be done remotely? • In PHP language, used by all web servers, they have PASSTHRU() function that executes arbitrary code… • Assume it contains a user input that comes from the web client browser. • insert “; command231” or “| command231”. • This will make the server execute command231 and output the result to the web page displayed. PHP have later banned this and many other things from the PHP language… Nicolas T. Courtois, December 2009

18. Buffer Overflow

19. Software Buffer Overflow Exploits I will explain in details only 1 type of code injection attack… “Buffer Overflow through Stack Smashing” There are many other types of software vulnerabilities… Study of these requires a lot of technical expertise about programming, compilers, assembly and CPUs… Discovery of new attacks is like a 1 G$ project: it requires:source code + formal methods + maths + software solver technology + lots of experimentation + machine learning + extensive knowledge of what’s out there etc. Nicolas T. Courtois, December 2009

20. Buffer Overflow History Extremely common since the 1980s. Consistently about 50 % of all CERT advisories still in late 2000s… Usually leads to a total compromise of the machine… Nicolas T. Courtois, December 2009

21. Can Programmers Get It Right? Lot of evidence around that theycannot. • the behavior of Turing machines is very HARD to analyse, • cf. Rice thm. • it is usually easier to rewrite code from the scratch than to find all bugs in it, open source software was like a virus… • software economics, time to market, code re-use etc… Major problems also occur at the compiler and runtime level… (even CPUs have bugs that can be used for exploits). Nicolas T. Courtois, December 2009

22. Problems with C and C++ • C and C++ particularly dangerous • Fast, therefore used in servers and all critical code (fast data manipulation, crypto and security functions) • allows arbitrary manipulation of pointers • but not outside the virtual 2 Gbyte space allocated by the OS Nicolas T. Courtois, December 2009

23. Problems with C and C++ • Memory Safety = a restriction on copying data from one memory location to another, except for if types clearly allow assignments. • closely related to type safety: …preventing type cast and copy data that don’t have the same type. • Java and C# offer (imperfect) memory safety. • hard to prove, actually shown not quite true for Java Nicolas T. Courtois, December 2009

24. **Dangling Pointers = pointers that do not point to a valid object in the program For example in C use malloc, realloc and free, Then the pointer is not automatically reset to NULL.Good practice is to do it manually all the time. Nicolas T. Courtois, December 2009

25. Software Under Attack Main goal: inject arbitrary code through standard input channels of the program. Input-dependent vulnerabilities. Excessively common in software we use every day… Unix and Windows alike… Nicolas T. Courtois, December 2009

26. Exploit = specially crafted inputthat allows a certain task to be accomplished compromising the security policy usually executing arbitrary code. Goal: execute with the privilege level of the program: • web server running as superuser… • Ordinary programs running as user… Furthermore, injected code may use another vulnerability to permit privilege escalation. Nicolas T. Courtois, December 2009

27. Buffer Overflow Attack:Stack Smashing and Code Injection in C

28. Buffer Overflow in C char command[256]=“”; allocated from the stack. Now imagine we input longer data than 256 bytes and use strcpy(command,*input_data). In theory: “undefined behaviour”.. In practice: we can predict what will happen. Nicolas T. Courtois, December 2009

29. historical roots Since ever, in CPU assembly and in compiling structured programs, the habit is to save the state of the CPU when calling a sub-routine. And saving the return address. It is essential which comes first…otherwise there would be no such attack. This is saved on the process stack. Nicolas T. Courtois, December 2009

30. Process Memory Layout 0x08048000 Text • Text: loaded from exec code and read-only datasize fixed at compilation • Heap: runtime allocated objects, large (2 Gb) • Stack: LIFO, holds function arguments and local variables, small size (256 K) Heap Grows toward high memory Grows toward low memory 0x40000000 Stack 0xC0000000 Nicolas T. Courtois, December 2009

31. Calling a Sub-Routine in C • PUSH PULL • on every CPU since ever… Stack Stack Stack Nicolas T. Courtois, December 2009

32. Stack Frames for one C Function f local variables built in this order saved bottom of stack return address params of f Stack Stack Stack Nicolas T. Courtois, December 2009

33. exploit on f void f(params){ char command[256]=“”; … strcpy(command,sth)} increasing addresses local variables saved bottom of stack overwrite return address size easy to guess params of f Stack Nicolas T. Courtois, December 2009

34. exploit on f void f(params){ char command[256]=“”; … strcpy(command,sth)} increasing addresses local variables shell code saved bottom of stack overwrite return address 0x80707050 easy to guess params of f Stack Nicolas T. Courtois, December 2009

35. when f finishes the frame buffer was de-allocated, data still there local variables shell code saved bottom of stack return address return address 0x80707050 params of f Stack Nicolas T. Courtois, December 2009

36. Is It Easy? • for strcpy() avoid 0’s in exploit code. • predict the size of all local variables. • IMPORTANT: does never need an exact value. • patch with many NOP instructions to work for a range of addresses… • put several copies of the new return address • must be able to predict the stack address. • not hard for simple programs… • open source: MUCH easier to attack. • many copies of the same program – easier. • this is how Slammer infected 75 K MS-SQL servers. NOP slide shell code Nicolas T. Courtois, December 2009

37. Reliability up to very high, up to 100% (there are stable exploits, never ever fail and produce consistent results) Nicolas T. Courtois, December 2009

38. What Hackers Do?

39. Finding Exploits Closed source: • try at random with long inputs ending by $$$$ • if the program crashes, look at core dumps for $$$’s • later use debuggers and disassemblers to design precise exploits… Open source: • easier! Hackers have automated tools for finding exploits… Nicolas T. Courtois, December 2009

40. Example With XBox 360 Microsoft made it very hard to install other OS, like Linux. Why? The console sale price was subsidized by Microsoft. Legitimate reason (!). Hackers found a buffer overflow attack on James Bond 007 game when it restored from saved game, to take over the boot loader… Very impressive… Nicolas T. Courtois, December 2009

41. ***Ethical Code Injection Exists? Wikipedia: code injection can "trick" the system into behaving in a certain way without any malicious intent. Code injection could, for example: • introduce a useful new column that did not appear in the original design of a search results page. • offer a new way to filter, order, or group data by using a field not exposed in the default functions of the original design. Someone might resort to this sort of work-around because … software … becomes too frustrating or painful. Some developers allow or even promote the use of code injection to "enhance" their software, usually because this solution offers a less expensive way to implement new or specialized features… Nicolas T. Courtois, December 2009

42. Can We Fix It?

43. Solutions (1) • use type and memory safe languages (Java, ML) • clean the de-allocated frame buffer: slow!!! Partial solutions (not perfect) • certain forms of access control? • yes, replace pointers by use of “un-forgeable reference” tokens • sandboxing and “secure” VM techniques. • store things in a different order: ASLR = Address Space Layout Randomisation – at the runtime! • suddenly it makes a lot of sense to recompile the Apache web server software on each server. Reason: 75 K copies, Slammer worm. • OpenBSD (enabled by default) • Linux – weak form of ASLR by default since kernel 2.6.12. (much better with the Exec Shield patch for Linux). • Windows Vista and Windows Server 2008: • ASLR enabled by default, although only for those executables and dynamic link libraries specifically linked to be ASLR-enabled. So only very few programs such as Internet Explorer 8 enable these protections… Nicolas T. Courtois, December 2009

44. Solutions (2) Automated protections with canaries: store known data at the end of the buffer. Check. • StackGuard, ProPolice, PointGuard= extensions of GCC, automatic. • similar protections also by default since MsVisual Studio 2003. Time performance overhead: about +10%. Is this secure? • Can the attacker predict the canary? • Can he learn it from several exploit attempts? Nicolas T. Courtois, December 2009

45. Canaries Two types known: • random canaries: known but random data canaries • terminator canaries: not the same at all, special ‘terminator’ values • \0 to stop strcpy() • {newline} + {linefeed} to stop fgets() • EOF to stop fread()… • can combine all these after each buffer Nicolas T. Courtois, December 2009

46. One Attack Against StackGuard and Canaries Nicolas T. Courtois, December 2009

47. Solutions (3) • hire a programmer with extensive understanding of software attacks • less attacks, will not eliminate them Cheaper solutions: • make sure that stack space is marked as impossible to execute () • NX bit + Windows DEP = Data Execution Protection. • Linux WX : text pages: X, not W, data (stack, heap) pages: W, not X • blacklist parts of C language! • ongoing process. Nicolas T. Courtois, December 2009

48. Bypassing DEP ? Yes! system() • only prevents simple injection of assembly code on the stack… • can inject some other sort of code… • like system calls + parameters that will contain instructions for the shell (!!!). • The simplest example: • System(“command123”) • Details depend a lot on OS and installed software. • Modern versions: call some API, some dll, OS routines to disable DEP or manage memory etc… local variables shell code saved bottom of stack return address 0x80707050 command123 Stack Nicolas T. Courtois, December 2009

49. Preventing Attacks on System Calls ms*.dll • Can we prevent the exploits with Windows dlls? • Answer: In Windows, at boot time the order and location of system calls WILL be randomised. • Lowers considerably the chances to succeed,(does not eliminate the attack) local variables shell code saved bottom of stack return address 0x80707050 command123 Stack Nicolas T. Courtois, December 2009

50. Input Validation • Application-specific: check if intended length and format. • use special encoding for inputs • use encrypted inputs, check length • the attack is unlikely to do anything intended? • If stream cipher, can flip bits to change one character… • Routines that remove dangerous characters. • In PHP, using the htmlentities() function. • In an SQL request, use mysql_real_escape_string() Nicolas T. Courtois, December 2009