Please enable JavaScript.

Coggle requires JavaScript to display documents.

Protection Mechanisms, References, Other ways to protect (Not sure),…

- - - - If attacker know the base address, he can go by the offset to get the address of the main binary. The base address can be found in proc maps while the binary is running
      - Note: If the address for a function is really small like main at 0x804, then it is likely that there is position-independent code executables
      - Note: gdb disable ASLR by default so if hit run again in gdb, the address will not change ==> do not hard code the higher bit of the address
- - - - Application's main binaries are usually compiled to run in a fixed known memory address
      - Use ret2get when possible
      - Use mmap-ret2gets-code to create a W+X section, read code into it, and jump
      - Try to make the application supply the addresses for attacker
      - [vdso] on /proc/<pid>/maps - Page containing glue code for programs to use when calling system calls and coming back from signals
        
        Some systems map it always at fixed location ==> Target for ret2syscall or ret2code
    - - Factors like How often the addresses change; Allow multiple tries or not; memory sections maintain their distance from each other; Footprints; etc.
    - - On local privilege escalation exploit, memory map may be available through " /proc/<pid>/maps"
        
        Brute-forcing
      - On remote exploit, example for remote memory mapping is format string bugs where attacker can see the rendered output
      - Several Remote Procedure Call interfaces leak internal memory addresses as "handles" that are passed to the client
      - On multithreaded applications, the address space can't be randomized per thread. However, if a thread crashed, the application dies
      - On Unix systems, when a process fork(), its memory layout is replicated to new process, if one process die, the other survives
        
        Realizing this, OpenBSD team started changing the more critical applications to re-execute themselves, instead of just fork(), to force re-randomization
        
        Note: linux gate
    - - Blind ROP
        
        If the server restart on a crash but not re-randomize
        
        Read the stack to leak canaries and a return address
        
        Find gadgets (at run-time) to effect call to write
        
        Dump binary to find gadgets for shellcode
        
        Does not know the location of the gadgets
      - Rather than use a single (libc) function to run the shellcode, string together pieces of existing code, called gadgets, to do it instead
        
        Find the gadgets, which are instruction groups that end with ret
        
        String them together, gadgets invoked via ret instruction ==> rop chained
        
        Gadgets get their arguments via pop, etc - these arguments are also on the stack between the gadgets' address
      - Tools
        
        ROPGadget
        
        dmesg
        
        Ghidra
        
        pwntools - ROP
        
        rp++
        
        Binary Ninja Cloud
        
        nm
        
        screen
        
        ipython
        
        tmux
      - Techniques
        
        Janitorial Gadgets
        
        pop garbage
        
        clean up rsp
        
        Storing values into register
        
        pop rax; ret
        
        Storing addr into reg
        
        push rsp; pop rax; ret
        
        add rax, rsp; ret
        
        xchg rax, rsp; ret
        
        Stack pivot
        
        Move stack frame into a more convenient space
        
        pop rsp; ... ; ret
        
        xchg rax, rsp; ret
        
        Data transfer into mem
        
        add byte [rcx], al; pop rbp; ret
  - - - Bypass by only overflow the least significant bit so that the esp might point to the buffer which is a bit above
        
        This needs the try several time since the stack is re-randomized
- - - - Memory areas (such as the stack and heap) are not executable, and others, such as the code section, cannot be written
    - - DEP features
        
        SafeSEH - The software Safe Structured Exception Handling implementation
        
        The hardware NX support for W^X
        
        Software only W^X supports
    - - PaX
- - - - Possible
        
        ret2text
        
        ret2plt
        
        chained ret2code
        
        ret2dl-resolver
- - - - PLT - Procedure Linkable Table
    - - return to strcpy() with src parameter pointing to the injected code and dst parameter pointing to writable and executable memory address
      - The same method could be applied to function like sprintf(), memcpy(), etc.
    - - Place injected code/egg/shellcode in the data section.
        Need way to place code in the memory. Ex: buffered I/O used heap to store data
    - - return into the code for ELF's dynamic linker's resolver (ld.so)
      - When an ELF binary is executed, all PLT entries point to code that dynamically resolved the address for the called function, update changes, and then calls the function
      - Entry point for all this logic is a single function (dl_linux_resolve() on Linux, _dl_bind_start() on OpenBSD and FreBSD)
    - - (gdb) print system
      - (gdb) info proc map
        
        $ strings -a -t x /lib/libc-2.11.2.so | grep "/bin/sh"
        
        This show relative address of /bin/sh to libc address
        
        Add the relative address with libc address in the program to get the actual address of /bin/sh in the binary
      - payload = padding + system + return_after_system + bin_sh
- - - - NUL canary
        
        0x00000000
      - Terminator canary
        
        0x000aff0d
        
        \x00 to stop strcpy()
        
        \x0d and \x0a to stop gets()
        
        \xff (EOF) to stop some other functions and hardcoded loops
        
        If try to overwrite the canary with original value, the string functions will stop writing data info buffer
      - Random canary
        
        Need read canary from memory, altered, or just predicted to perform successful attack
        
        Brute force canary in x84
    - - StackGuard only protect the saved return address
        
        canary placed between saved ebp and return address
    - - Not all buffer overflows are on stack. StackGuard cannot prevent heap-based buffer overflows
      - An information disclosure flaw in a different part of the program could disclose the global __stack_chk_guard value.
      - out-of-bounds write bugs can allow the attacker to write to the stack frame after the canary, without overwriting the canary value itself
      - If a function has multiple local data structures and pointers to functions, these are allocated on the stack as well, before the canary value. If there is a buffer overflow in any one of these structures, the attacker can use this to overwrite adjacent buffers/pointers which could result in arbitrary code execution.
      - On some architectures, multi-threaded programs store the reference canary stack_chk_guard in Thread Local Storage, which is located a few kb after the end of the thread's stack. In these circumstances, a sufficiently large overflow can overwrite both canary and stack_chk_guard to the same value, causing the detection to incorrectly fail.
  - - - Implemented in ProPolice. Reorders data stored in the stack into what's called ideal stack layout
        
        arg copy
        
        var2
        
        var1
        
        buf
        
        canary
        
        saved ebx
        
        saved ebp
        
        return address
        
        Stack layout above is the result of compiling with ProPolice (-fstack-protector option on modern GCCs)
      - Scenarios where ideal stack layout not exist
        
        Buffers dynamically created on stack using alloca() will be placed on top of the stack frame
        
        Structure members can't be rearranged so when they contains a buffer, this buffer will stay in the location defined by struct's or class's declaration.
        
        Multiple buffers are all placed one after other in the stack ==> Overflow from one buffer to the next (Ex: CVE-2004-0460)