1 / 33

COUNTERMEASURE #3

COUNTERMEASURE #3. Ibnu Mubarok. Introduction. Exploit memory corruption change in control flow execution of the shellcode. 1. Buffer Restrictions Polymorphic Printable ASCII Shellcode 2. Non-executable stack ret2libs return into system() 3. Randomized Stack Space

bandele
Download Presentation

COUNTERMEASURE #3

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. COUNTERMEASURE #3 Ibnu Mubarok

  2. Introduction • Exploit • memory corruption • change in control flow • execution of the shellcode. • 1. Buffer Restrictions • Polymorphic Printable ASCII Shellcode • 2. Non-executable stack • ret2libs • return into system() • 3. Randomized Stack Space • Investigations with BASH and GDB • Bouncing-off linux-gate

  3. 1. Buffer Restrictions • Program put restrictions on buffer to prevent vulnerabilities • Example program, update_info.c • Restriction: input length, input printable character

  4. 1. Buffer Restrictionexploit strcpy() vulnerability Target : write shellcode that will get past the printable character check.

  5. 1. Buffer RestrictionPolymorphic Printable ASCII Shellcode • Write new shellcode using limited instruction set? • Simple methods to build more complex shellcode on the stack. • Zero out registers • Can’t use XOR to zero-out, use AND instead • Operation AND with EAX register assembles into %  Zero out EAX

  6. 1. Buffer RestrictionPolymorphic Printable ASCII Shellcode • Shellcode Location • Set ESP behind loader code • Build shellcode from end to start • ESP will move backward as values are pushed to the stack • EIP will move forward as the loader code executes • EIP and ESP will meet up, and the EIP will continue executing into the freshly built shellcode

  7. 1. Buffer RestrictionPolymorphic Printable ASCII Shellcode • Set ESP location • Loader code ‘length’, 555 bytes and assume ~300 bytes shellcode •  Add 860 bytes into ESP (for 555 bytes loader code + 305 bytes shellcode) • No need to have exact value  slop fix it • Addition operation = Subtracting until it wraps around. • register 32 bits, so adding 860 to a register is the same as subtracting 860 from 232, or 4,294,966,436. • Also, this subtraction must only use printable values, so split the instructions which all use printable operands.

  8. 1. Buffer RestrictionPolymorphic Printable ASCII Shellcode • Value to ESP not EAX • sub esp is non-printable ASCII character • So, current value of ESP -> EAX for subtraction • Then, new value of EAX -> ESP • movesp,eaxand moveax,espis non-printable, so use POP/PUSH TX-3399-Purr-!TTT-P\ will add 860 to ESP

  9. 1. Buffer RestrictionPolymorphic Printable ASCII Shellcode • Construct Shellcode to the stack • From end to start • Same concept, by subtracting eaxto get desirable value, then move the eaxvalue to espusing push-pop • Use printable_helper.c program to help calculate the necessary printable values

  10. 1. Buffer RestrictionPolymorphic Printable ASCII Shellcode • Printable Shellcode

  11. 1. Buffer RestrictionPolymorphic Printable ASCII Shellcode • Execution

  12. 2. Non-executable Stack • most applications never execute data on the stack • defense memory policy -> disallows execution from the stack

  13. 2. Non-executable Stackret2libc • return to libc • libcis a standard C that contains various basic functions, such as printf() and exit() • shared function-> any program that uses the printf() function directs execution into the appropriate location in libc. • An exploit can do the exact same thing and direct a program’s execution into a certain function in libc.

  14. 2. Non-executable Stackreturning into system() • Simplest libc function, for this example is system() • takes a single argument and executes that argument • Target : Exploit the vulnerable program to spawn a shell, without executing anything on the stack, by returning into the system() function • Find location of the system()function • Direct program execution into the system()function • Define argument for system() function, which is the /bin/sh

  15. 2. Non-executable Stackreturning into system() • Simple vulnerable program • Find system() location

  16. 2. Non-executable Stackreturning into system() • Vulnerable will execute system("/bin/sh") to provide a shell, so an argument must be supplied. • When returning into libc, the return address and function arguments are read off the stack • 4 bytes Function address = system() location • 4 bytes Return address = don’t care, since program will open shell • Argument 1 = (pointer of) /bin/sh • Now, we just need the location pointer of the argument

  17. 2. Non-executable Stackreturning into system() • Execution

  18. 3. Randomized Stack Space • Randomizes the stack memory layout • the attacker won’t be able to return execution into waiting shellcode • enabled by default in the Linux kernel since 2.6.12 • file config : /proc/sys/kernel/randomize_va_space • Every time a program starts, the stack begins at a random location, including environment variables

  19. 3. Randomized Stack SpaceInvestigations with BASH and GDB • ASLR doesn’t stop the memory corruption • Exploit can work by changing control flow. • We can overwrite return address, by first finding offset from the beginning of the buffer • But, we still cannot execute shellcode since its location is randomized • Info: when a program exits, the value returned from the main function is the exit status (this value stored in the BASH variable $?)

  20. 3. Randomized Stack SpaceInvestigations with BASH and GDB • Finding offset using BASH script …

  21. 3. Randomized Stack SpaceInvestigations with BASH and GDB • GDB investigation • This instruction returns EIP to the return address stored on the stack • When an exploit overwrites the return address, this is the last instruction where the original program has control.

  22. 3. Randomized Stack SpaceInvestigations with BASH and GDB • notice how similar the address in ESP is to the address of the buffer - since the stack pointer points to the stack and the buffer is on the stack.

  23. 3. Randomized Stack SpaceInvestigations with BASH and GDB • do stepi to single step, to check ESP’s value after the ret instruction has executed 0xbfd1ccfc 4 bytes increases 0xbfd1cd00 From buffer to return address = 80 bytes

  24. 3. Randomized Stack SpaceInvestigations with BASH and GDB • Since the return address’s offset was 19 words, this means that after main’s final ret instruction, ESP points to stack memory found directly after the return address. • useful if there was a way to control EIP to go where ESP is pointing instead  Target : jump EIP to where ESP is pointing • find jmpesp instruction

  25. 3. Randomized Stack SpaceBouncing-off Linux Gate • Bouncing off Linux-gate refers to a shared object, exposed by the kernel, which looks like a shared library. • We examine ldd, a program’s shared library dependencies. • linux-gate.so.1 is always present at the same address, Even in different programs and with ASLR enabled

  26. 3. Randomized Stack SpaceBouncing-off Linux Gate • Every process has a block of memory containing Linux-gate’s instructions, which are always at the same location, even with ASLR. • we will search jmpesp instruction on this block memory Machine code forjmpesp

  27. 3. Randomized Stack SpaceBouncing-off Linux Gate • Next : Find location of this jmpesppattern

  28. 3. Randomized Stack SpaceBouncing-off Linux Gate • Finally, we overwrite the return address with the address 0xffffe777 • execution will jump into Linux-gate when the main function returns. • In jmpesp instruction, execution will immediately jump back to wherever ESP happens to be pointing • we know that at the end of the main function, ESP is pointing to memory directly after the return address. So, if shellcode is put here, EIP should bounce right into it. bouncing off Linux-gate only works with older Linux kernels under 2.6.18.

  29. 3. Randomized Stack SpaceExploit ASLR using execl() • execl() family of functions • The exec() family of functions replaces the current process image with a new process image. • there could be a weakness if the memory layout is randomized only when the process is started.

  30. 3. Randomized Stack SpaceExploit ASLR using execl() • there is some degree of randomization happening when the new process is executed with execl().

  31. 3. Randomized Stack SpaceExploit ASLR using execl() • Using execl() at least make some clear address range • The remaining uncertainty can be handled with a NOP sled • Quick examination in GDB Need 80 bytes to overwrite the stored return address on the stack

  32. 3. Randomized Stack SpaceExploit ASLR using execl() • Since we will probably want a rather large NOP sled, in the following exploit the NOP sled and the shellcode will be put after the return address overwrite. • This allows us to inject as much of a NOP sled as needed. In this case, a thousand bytes or so should be sufficient.

  33. 3. Randomized Stack SpaceExploit ASLR using execl()

More Related