Hacking Blind

Editor's Notes

• #3 Open-source software is most within reach since attackers can audit the code to find vulnerabilities. Hacking closed-source software is also possible for more motivated attackers through the use of fuzz testing and reverse engineering. Fuzz testing or fuzzing is a software testing technique, often automated or semi-automated, that involves providing invalid, unexpected, or random data to the inputs of acomputer program. The program is then monitored for exceptions such as crashes, or failing built-in code assertions or for finding potential memory leaks. Fuzzing is commonly used to test for security problems in software or computer systems. It is a form of random testing which has been used for testing hardware or software. Reverse engineering is taking apart an object to see how it works in order to duplicate or enhance the object. The practice, taken from older industries, is now frequently used on computer hardware and software. Software reverse engineering involves reversing a program's machine code (the string of 0s and 1s that are sent to the logic processor) back into the source code that it was written in, using program language statements. At first sight this goal may seem unattainable because today’s exploits rely on having a copy of the target binary for use in Return Oriented Programming (ROP)
• #4 To answer this question we start with the simplest possible vulnerability: stack buffer overflows. One can only speculate that bugs such as these go unnoticed in proprietary software, where the source ( and binary) has not been under the heavy scrutiny of the public and security specialists. However, it is certainly possible for an attacker to use fuzz testing to find potential bugs through known or reverse engineered service interfaces. Alternatively, attackers can target known vulnerabilities in popular opensource libraries (e.g., SSL or a PNG parser) that may be used by proprietary services. The challenge is developing a methodology for exploiting these vulnerabilities when information about the target binary is limited. . Load balancers are also increasingly common and often distribute connections to large numbers of identically configured hosts executing identical program binaries. Thus, there are many situations where an attacker has potentially infinite tries (until detected) to build an exploit.
• #5 We present a new attack, Blind Return Oriented Programming (BROP), that takes advantage of these situations to build exploits for proprietary services for which both the binary and source are unknown. The BROP attack assumes a server application with a stack vulnerability and one that is restarted after a crash. The attack works against modern 64-bit Linux with ASLR (Address Space Layout Randomization), nonexecutable (NX) memory, and stack canaries enabled. While this covers a large number of servers, we can not currently target Windows systems because we have yet to adapt the attack to the Windows ABI. Generalized stack reading: this generalizes a known technique, used to leak canaries, to also leak saved return addresses in order to defeat ASLR on 64- bit even when Position Independent Executables ( PIE ) are used. Blind ROP: this technique remotely locates ROP gadgets. Both techniques share the idea of using a single stack vulnerability to leak information based on whether a server process crashes or not. The stack reading technique overwrites the stack byte-by-byte with possible guess values, until the correct one is found and the server does not crash, effectively reading (by overwriting) the stack. The Blind ROP attack remotely finds enough gadgets to perform the write system call, after which the server’s binary can be transferred from memory to the attacker’s socket. At this point, canaries, ASLR and NX have been defeated and the exploit can proceed using known techniques. The threat model for a BROP attack is an attacker that knows an input string that crashes a server due to a stack overflow bug. The attacker must be able to overwrite a variable length of bytes including a return instruction pointer. The attacker need not know the source or binary of the server. The attacker is able to crash the server as many times as he wishes while conducting the attack, and the server must restart.
• #6 The BROP attack has the following phases: Stack reading: read the stack to leak canaries and a return address to defeat ASLR. Blind ROP: find enough gadgets to invoke write and control its arguments. Build the exploit: dump enough of the binary to find enough gadgets to build a shellcode, and launch the final exploit. The first phase is needed so that a starting point address for scanning gadgets is found. Gadgets are then searched for until enough are found to invoke write. After that, the binary is transferred over the network from memory, enabling known techniques to be applied toward building the final exploit.
• #7 In the early days of stack buffer overflows, it was common for an attacker to include malicious code as part of the payload used to overflow the buffer. As a result, the attacker could simply set the return address to a known location on the stack and execute the instructions that were provided in the buffer. Such “code injection” attacks are no longer possible on contemporary machines because modern processors and operating systems now have the ability to mark data memory pages as non-executable (e.g., NX on x86). As a result, if an attacker tries to run code on the stack, it would only cause an exception. An innovative technique, known as return-oriented programming (ROP) [1], was developed to defeat defenses based on non-executable memory. It works by linking together short code snippets already present in the program’s address space. Such code snippets, called gadgets, can be combined to form arbitrary computation. As a result, attackers can use ROP to gain control of programs without any dependence on code injection. Simpler variations of ROP are sometimes possible. For example, with return-to-libc attacks, a high-level library function can be used as the return address. In particular, the system() function is useful for attackers because it can run arbitrary shell code with only a single argument [6]. These attacks were very effective on 32-bit systems where arguments were passed on the stack, already under control of the attacker. On 64-bit systems, arguments are passed in registers, so additional gadgets are needed to populate registers. Address space layout randomization (ASLR) [7], [8] was introduced as an additional defense against buffer overflow attacks. It works by randomizing the location of code and data memory segments in the process address space. In many implementations code segment randomization is only applied to libraries, but full address space randomization is also possible. ASLR creates a major challenge for attackers because it makes the address locations of code (or even the stack) impossible to predict in advance. Unfortunately, on 32-bit platforms, ASLR is constrained by the number of available bits (usually 16) for randomization. As a result, brute-force attacks can be quite effective [9]. However, on 64-bit platforms there are typically too many random bits for brute-forcing to be feasible. In such cases, ASLR can still be circumvented, but only when combined with a vulnerability that leaks information about the address space layout, such as a format string [10]. Canaries [11] are another common defense against buffer overflow attacks. Canaries cannot prevent buffer overflows, but they can detect them retroactively and terminate the program before an attacker can influence control flow. For example, with stack canaries, a secret value that was determined in advance is placed just before each saved frame pointer and return address. Then, when a function returns, the secret dup2(s, 0); dup2(s, 1); dup2(s, 2); execve("/bin/sh", 0, 0) ; value is checked to make sure it has not changed. This can prevent stack buffer overflows from being exploited because an attacker must correctly overwrite the secret value in order for the program to actually use an overwritten return address. However, just as with ASLR, canaries can be defeated through an additional vulnerability that leaks information about the secret value. The layout of stack memory can be an important consideration for canary implementations. One common approach is to place all buffers at the top of the frame so that if they overflow it will not be possible to overwrite other variables before corrupting the canary [12]. The motivation is to protect pointers because sometimes they can be used to overwrite arbitrary memory [13]. Unfortunately, canaries are not a perfect solution, as even with layout precautions, the structure of a buffer overflow can sometimes permit an attacker to bypass canary words and access critical state directly, as happened with unsafe pointer arithmetic in yaSSL [3].
• #8 On most contemporary operating systems, where NX and ASLR are common, an attacker must fulfill at least two requirements in order to gain full control of a remote program’s execution: Hacking without binary knowledge is useful even in the not-completely-blind case (e.g., open-source) because it makes it possible to write generic, robust exploits that work against all distributions and are agnostic to a specific version of the binary. Today, attackers need to gather exact information (e.g., binaries) for all possible combinations of distribution versions and vulnerable software versions, and build an exploit for each. One might assume attackers would only bother with the most popular combinations. An implication of our work is that more obscure distributions offer little protection (through obscurity) against buffer overflows. To defeat NX, the attacker must know where gadgets reside inside the program executable. To defeat ASLR, the attacker must derandomize the location at which the executable’s text segment is actually loaded in memory. The first requirement in practice means that the attacker must have a copy of the vulnerable binary to disassemble and find gadgets. To our knowledge, our proposed BROP attack is the first general-purpose technique that can be used to defeat NX when the binary code is completely unavailable. Defeating ASLR is also a significant challenge without BROP, but there are some possible strategies. Firstly, an information leak might reveal the address location of a code segment. Secondly, it may be possible to exploit any code that remains statically positioned across executions. For example, on Linux it is usually the case that the executable’s code is mapped to a fixed address even though dynamic libraries and other data memory regions are randomized with ASLR. As a result, an attacker could simply apply ROP to the program’s text segment directly. Additionally, on some platforms, such as Windows, there are shared libraries that are incompatible with ASLR, and thus such libraries are mapped to static locations.
• #9 . Modern exploits rely heavily on ROP. Once a shell is executed, the attacker can execute more commands to continue the attack. Traditionally, exploits would inject off-the-shelf shellcode into the process and execute it. Figure 1 shows typical shellcode that pipes the attacker’s socket to standard input, output and error and executes a shell. Of course injecting shellcode is no longer possible because these days writable memory (e.g., the stack) is non-executable, and so ROP must be used instead. The stack is overflowed so that the addresses of all the gadgets are present in sequence. Each gadget ends with a return so that the next gadget can execute. In practice, each ROP gadget will be a short sequence of machine instructions terminated by a return. Executing a simple system call like dup2 will require multiple gadgets because arguments are passed in registers so gadgets to populate these will be needed. Figure 3 shows the required gadgets for dup2. Registers rdi and rsi control the first two arguments to system calls, and rax controls the system call number. Registers can be controlled by using pop gadgets and placing the value to load on the stack. By chaining enough gadgets, complete shellcode can eventually be built.
• #10 VII. STACK READING: ASLR DE-RANDOMIZATION Exploits must have a method of defeating ASLR for configurations where PIE is used. We present a new stack reading technique that generalizes a known technique used for leaking canaries. It is useful even in cases where the binary is known and a full BROP attack is not required. The basic idea in leaking canaries is to overflow a single byte, overwriting a single byte of the canary with value x. If x was correct, the server does not crash. The algorithm is repeated for all possible 256 byte values until it is found (128 tries on average). The attack continues for the next byte until all 8 canary bytes ( on 64-bit) are leaked. Figure 5 illustrates the attack. We generalize the attack to leak more words from the stack (“stack reading”). After the canary, one typically finds the saved frame pointer and then the saved return address, so three words need to be read. Figure 6 shows a typical stack layout. There are a few subtleties that apply to generalized stack reading but not to reading canaries. With canaries, exact values will always be returned because there is only one value canary that is correct. In general though, stack reading will not necessarily return the exact saved instruction pointer present on the stack. It is possible that a slightly different value is returned depending on whether another value still resumes program execution without causing a crash. For example, suppose that 0x400010 was stored on the stack and the value 0x400007 is currently being tested. It is possible that the program keeps executing without crashing and 0x400007 is obtained from stack reading. This is OK as the attacker is searching for any valid value in the .text segment range and not for a specific one. It is possible that stack reading does not return an address in the application’s own .text segment, but rather a return address in a library. This can happen, for example, when the vulnerability lies in a library, or a callback happens. This is fine because gadgets can be found in the library instead. One can also stack read further to find more return addresses, if needed. On 64-bit x86 systems only a portion of the address space is made available to the operating system (canonical form addresses). This allows us to skip several bytes when reading pointers. For user space processes the top two bytes are always zero. In fact, on Linux the third byte is 0x7f for libraries and the stack. The main binary and heap are usually stored at 0x00 for executables compiled without the PIE flag. Thus we can skip on average three bytes (384 requests) when reading addresses. The fact that stack reading succeeds tells the attacker that the BROP environment exists and that a stack overflow, rather than some random bug, is being triggered. A bug like a null pointer dereference may cause a crash for all possible byte values being probed, or a no crash for multiple possible values The words returned by stack reading give further evidence of the BROP attack working because the values can be somewhat sanitized: e.g., a random canary (which always starts with zero on Linux), a frame pointer, and a return address with known upper bits (0x40 for non-PIE or 0 x7f ). buffer canary saved frame pointer saved return address Figure 6. Typical stack layout. The canary protects saved registers. If it is overwritten (by an overflow) then the program aborts prior to returning to the saved return address.
• #11 One may notice a crash when using a remote service or discover one through remote fuzz testing. A popular SSL library for example may have a stack vulnerability and one may speculate that it is being used by a proprietary service. This applies to manually compiled installations or source-based distributions such as Gentoo.
• #12 VIII. BROP ATTACK The BROP attack allows writing exploits without possessing the target binary. It introduces techniques to find ROP gadgets remotely and optimizations to make the attack practical.
• #13 We implemented the BROP attack in a tool called “Braille” that automatically goes from a crash to a remote shell. It is written in 2,000 lines of Ruby code. Braille is essentially a meta-exploit that takes a driver function that can crash a server, and figures out all the information needed to build an exploit. The interface is as simple as: try_exp(data) -> CRASH, NO_CRASH, INF The driver needs to implement the try_exp() function and guarantee that when given enough “data” bytes it will end up overwriting a saved return address on the stack. The function returns CRASH if the socket closes after sending the data, NO CRASH if the application appears to behave normally, or INF if the socket stays open for longer than a timeout. The timeout is automatically determined by the framework based on how quickly a crash is detected. The NO CRASH def try_exp(data) s = TCPSocket.new($victim, 80) req = "GET / HTTP/1.1\r\n" req << "Host: site.com\r\n" req << "Transfer-Encoding: Chunked\r\n" req << "Connection: Keep-Alive\r\n" req << "\r\n" req << "#{0xdeadbeefdead.to_s(16)}\r\n" req << "#{data}" s.write(req) if s.read() == nil return RC_CRASH else return RC_NOCRASH end end Figure 12. nginx exploit driver code. It merely wraps the input string provided by Braille into an HTTP chunked request and returns a CRASH signal if the connection closes. return code is useful for probing the length of the buffer being overflowed or when stack reading. This return code is expected when no overflow occurs or when the same value was overwritten on the stack. The INF return code is expected when looking for gadgets as it indicates that the stop gadget ran (“infinite loop”). In later phases of the attack where data is expected from the socket, for example after write has been found and the binary is being dumped, a raw flag can be passed to return the actual socket instead of the CRASH / INF result code.