Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Exploits Against Software and Defences Nicolas T. Courtois - University College London."— Presentation transcript:

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

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

3 Nicolas T. Courtois, January 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 unsafe calls to the sprintf function alone… Main Learning Objective: Understand the principal sources of attacks and what the defences are.

4 Goals of Attackers

5 CompSec COMPGA01 Nicolas T. Courtois, December 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.

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

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

8 What’s Wrong?

9 CompSec COMPGA01 Nicolas T. Courtois, December Software Vulnerabilities 1.Input validation problems 2.Buffer overflow 3.Format string vulnerabilities 4.Integer overflows, 5.CPU bugs 6.Failing to handle errors / exceptions properly 7.etc …

10 Vectors of Attack - Inputs

11 CompSec COMPGA01 Nicolas T. Courtois, December 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

12 CompSec COMPGA01 Nicolas T. Courtois, December 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…

13 CompSec COMPGA01 Nicolas T. Courtois, December 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!

14 CompSec COMPGA01 Nicolas T. Courtois, December 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…

15 CompSec COMPGA01 Nicolas T. Courtois, December More Attacks on PATH in Unix

16 CompSec COMPGA01 Nicolas T. Courtois, December 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 …

17 CompSec COMPGA01 Nicolas T. Courtois, December 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 …

18 Buffer Overflow

19 CompSec COMPGA01 Nicolas T. Courtois, December 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.

20 CompSec COMPGA01 Nicolas T. Courtois, December 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 …

21 CompSec COMPGA01 Nicolas T. Courtois, December Can Programmers Get It Right? Lot of evidence around that they cannot. 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).

22 CompSec COMPGA01 Nicolas T. Courtois, December 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

23 CompSec COMPGA01 Nicolas T. Courtois, December 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

24 CompSec COMPGA01 Nicolas T. Courtois, December **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.

25 CompSec COMPGA01 Nicolas T. Courtois, December 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 …

26 CompSec COMPGA01 Nicolas T. Courtois, December Exploit = specially crafted input that 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.

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

28 CompSec COMPGA01 Nicolas T. Courtois, December 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.

29 CompSec COMPGA01 Nicolas T. Courtois, December 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.

30 CompSec COMPGA01 Nicolas T. Courtois, December Process Memory Layout Stack Grows toward low memory Heap Grows toward high memory Text 0xC x x

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

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

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

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

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

36 CompSec COMPGA01 Nicolas T. Courtois, December 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. shell codeNOP slide

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

38 What Hackers Do?

39 CompSec COMPGA01 Nicolas T. Courtois, December 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 …

40 CompSec COMPGA01 Nicolas T. Courtois, December 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 …

41 CompSec COMPGA01 Nicolas T. Courtois, December ***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 …

42 Can We Fix It?

43 CompSec COMPGA01 Nicolas T. Courtois, December 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 (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…

44 CompSec COMPGA01 Nicolas T. Courtois, December 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 Time performance overhead: about +10%. Is this secure? Can the attacker predict the canary? Can he learn it from several exploit attempts?

45 CompSec COMPGA01 Nicolas T. Courtois, December 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

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

47 CompSec COMPGA01 Nicolas T. Courtois, December 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.

48 CompSec COMPGA01 Nicolas T. Courtois, December Bypassing DEP ? Yes! 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… Stack return address saved bottom of stack local variables shell code 0x command123 system()

49 CompSec COMPGA01 Nicolas T. Courtois, December Preventing Attacks on System Calls 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) Stack return address saved bottom of stack local variables shell code 0x command123 ms*.dll

50 CompSec COMPGA01 Nicolas T. Courtois, December 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()

51 CompSec COMPGA01 Nicolas T. Courtois, December C Tips – Replace by sprintf(buf, … ) snprintf(buf, buflen, … ), scanf( “ %s ”, buf) scanf( “ %10s ”, buf), strcpy(buf, input)strncpy(buf, input, 256) etc …

52 CompSec COMPGA01 Nicolas T. Courtois, December Solutions (4) Automated tools working on: Source code: – Coverity: test trust inconsistency. – Microsoft program analysis group: PREfix: looks for fixed set of bugs (e.g. null ptr ref) PREfast: local analysis to find prog errors. – [Wagner, et Berkeley]: Test constraint violations. These find lots of bugs, but not all. Ready exe: Taintcheck: fix ready exe files … –At runtime mark memory locations as tainted by user data. –Slow. Up to 25x. Web servers cost lots of $$$, cannot afford to do it..

53 CompSec COMPGA01 Nicolas T. Courtois, December Solutions (5) Replacement libraries: Example: libsafe – dynamically linked library, will intercept calls to strcpy and check buffer sizes.. StackShield – an assembler file processor for GCC keeps backup copies of SFP and RET at the beginning of local variables, compare before exiting the function.

54 CompSec COMPGA01 Nicolas T. Courtois, December Solutions (6) Instruction Set Randomization (ISR) – runtime encryption of CPU instructions … different for each program, makes code injection impossible. Has been done. not widely used. network-intensive applications run smoothly CPU-intensive applications: 20x slower

55 END

56 *Heap Overflow: consider as home reading, not at the exam

57 CompSec COMPGA01 Nicolas T. Courtois, December Process Memory Layout Stack Grows toward low memory Heap Grows toward high memory Text 0xC x x

58 CompSec COMPGA01 Nicolas T. Courtois, December Right Proportions Not always this area is a heap. It can be fragmented. More generally term “ heap exploits ” refers to all kinds of attacks on data structures dynamically allocated/freed within RAM. Stack Heap Grows toward high memory Text can take most of the 2-4 Gbytes space

59 CompSec COMPGA01 Nicolas T. Courtois, December Insights How Memory Management is implemented? (harder to design a working attack, less standard than stack attacks … ) Implemented by a compiler through its standard dynamic libraries, example: msvc*.dll that contain executable already compiled functions. Main idea: the design of these memory management routines can be exploited. How? A bit complex.

60 CompSec COMPGA01 Nicolas T. Courtois, December Insights Heap managers have linked lists with forward/backward pointers, sizes, and data fields.

61 CompSec COMPGA01 Nicolas T. Courtois, December What the attacker can do? shell code

62 CompSec COMPGA01 Nicolas T. Courtois, December What the attacker can do? What happens when the routine freeing the memory is called? On this picture, allocations 1 and 2 are already freed, which maybe happens a bit later during the same function call … The next step is to merge these two free blocks. Why? shell code

63 CompSec COMPGA01 Nicolas T. Courtois, December Concatenation after free() Defragmentation is important: otherwise allocation of large blocks might fail and the program would terminate with an out of memory message though there is plenty of memory left … This mechanism is typically automatic and sometimes is also done with a certain delay, but frequently will be called before the current C or C++ function exits … hdr  next = hdr  next  next hdr  next  next  prev = hdr  next  prev shell code

64 CompSec COMPGA01 Nicolas T. Courtois, December Insights In heap attacks none of these addresses will ever be used as jump address. Seems hopeless? It is more subtle than that. What we do is to overwrite a return address elsewhere. On the stack. By abusing this specific “ defragmentation ” method/routine, when it is called (immediately or later). The attacker can control both: the address where a certain pointer will be written automatically by the heap Mgmnt the value of this pointer to be overwritten shell code hdr  next = hdr  next  next

65 CompSec COMPGA01 Nicolas T. Courtois, December Insights Suppose I override these links to point hdr  next = to the return address of the function on the stack. hdr  next  next = a pointer to code (probably just in the buffer I overran) When the heap manager merges the two blocks, it will actually overwrite the return address on the stack with a pointer to code I control. This will be called after the current function exits. shell code


Download ppt "Exploits Against Software and Defences Nicolas T. Courtois - University College London."

Similar presentations


Ads by Google