An automatic Blind ROP exploitation python tool
BROP (Blind ROP) was a technique found by Andrew Bittau from Stanford in 2014.
Most servers like nginx, Apache, MySQL, forks then communicates with the client. This means canary and addresses stay the same even if there is ASLR and PIE. So we can use some educated brute force to leak information and subsequently craft a working exploit.
There is 3 customs vulnerable examples provided in this repository. You can run it directly or build the Dockerfile
BROPPER will then dump the binary :
It's then possible to extract all ROP gadgets from the dumped binary using ROPgadget for example :
$ ROPgadget --binary dump
Gadgets information
============================================================
0x0000000000001177 : adc al, 0 ; add byte ptr [rax], al ; jmp 0x1020
0x0000000000001157 : adc al, byte ptr [rax] ; add byte ptr [rax], al ; jmp 0x1020
0x0000000000001137 : adc byte ptr [rax], al ; add byte ptr [rax], al ; jmp 0x1020
...
...
...
0x0000000000001192 : xor ch, byte ptr [rdi] ; add byte ptr [rax], al ; push 0x16 ; jmp 0x1020
0x000000000000182e : xor eax, 0x891 ; mov rdi, rax ; call rcx
0x0000000000001861 : xor eax, 0xffffff22 ; mov rdi, rax ; call rcx
Unique gadgets found: 235
To use this script:
python3 -m pip install -r requirements.txt
python3 bropper.py -t 127.0.0.1 -p 1337 --wait "Password :" --expected Bad --expected-stop Welcome -o dump
$ python3 bropper.py -h
usage: bropper.py [-h] -t TARGET -p PORT --expected-stop EXPECTED_STOP --expected EXPECTED --wait WAIT -o OUTPUT [--offset OFFSET] [--canary CANARY] [--no-canary] [--rbp RBP] [--rip RIP] [--stop STOP]
[--brop BROP] [--plt PLT] [--strcmp STRCMP] [--elf ELF]
Description message
options:
-h, --help show this help message and exit
-t TARGET, --target TARGET
target url
-p PORT, --port PORT target port
--expected-stop EXPECTED_STOP
Expected response for the stop gadget
--expected EXPECTED Expected normal response
--wait WAIT String to wait before sending payload
-o OUTPUT, --output OUTPUT
File to write dumped remote binary
--offset OFFSET set a offset value
--canary CANARY set a canary valu e
--no-canary Use this argument if there is no stack canary protection
--rbp RBP set rbp address
--rip RIP set rip address
--stop STOP set stop gadget address
--brop BROP set brop gadget address
--plt PLT set plt address
--strcmp STRCMP set strcmp entry value
--elf ELF set elf address
Pull requests are welcome. Feel free to open an issue if you want to add other features.
A DLL Loader With Advanced Evasive Features
"Atom"
function via the command line.CRC32
string hashing algorithm.AtomLdr's unhooking method looks like the following
the program Unhooking from the \KnwonDlls\ directory is not a new method to bypass user-land hooks. However, this loader tries to avoid allocating RWX memory when doing so. This was obligatory to do in KnownDllUnhook for example, where RWX permissions were needed to replace the text section of the hooked modules, and at the same time allow execution of functions within these text sections.
This was changed in this loader, where it suspends the running threads, in an attempt to block any function from being called from within the targetted text sections, thus eliminating the need of having them marked as RWX sections before unhooking, making RW permissions a possible choice.
This approach, however, created another problem; when unhooking, NtProtectVirtualMemory
syscall and others were using the syscall instruction inside of ntdll.dll module, as an indirect-syscall approach. Still, as mentioned above, the unhooked modules will be marked as RW sections, making it impossible to perform indirect syscalls, because the syscall instruction that we were jumping to, can't be executed now, so we had to jump to another executable place, this is where win32u.dll
was used.
win32u.dll
contains some syscalls that are GUI-related functions, making it suitable to jump to instead of ntdll.dll. win32u.dll is loaded (statically), but not included in the unhooking routine, which is done to insure that win32u.dll can still execute the syscall instruction we are jumping to.
The suspended threads after that are resumed.
It is worth mentioning that this approach may not be that efficient, and can be unstable, that is due to the thread suspension trick used. However, it has been tested with multiple processes with positive results, in the meantime, if you encountered any problems, feel free to open an issue.
PayloadConfig.pc
file, that contains the encrypted payload, and its encrypted key and iv.PayloadConfig.pc
file will then replace this in the AtomLdr
project.AtomLdr
project as x64 Release.AtomLdr.dll
using rundll32.exe, running Havoc payload, and capturing a screenshotAtomLdr.dll
's Import Address TablePayloadBuilder.exe
, to encrypt demon[111].bin
- a Havoc payload fileAtomLdr.dll
using rundll32.exeropr is a blazing fast multithreaded ROP Gadget finder
ROP (Return Oriented Programming) Gadgets are small snippets of a few assembly instructions typically ending in a ret
instruction which already exist as executable code within each binary or library. These gadgets may be used for binary exploitation and to subvert vulnerable executables.
When the addresses of many ROP Gadgets are written into a buffer we have formed a ROP Chain. If an attacker can move the stack pointer into this ROP Chain then control can be completely transferred to the attacker.
Most executables contain enough gadgets to write a turing-complete ROP Chain. For those that don't, one can always use dynamic libraries contained in the same address-space such as libc once we know their addresses.
The beauty of using ROP Gadgets is that no new executable code needs to be written anywhere - an attacker may achieve their objective using only the code that already exists in the program.
Typically the first requirement to use ROP Gadgets is to have a place to write your ROP Chain - this can be any readable buffer. Simply write the addresses of each gadget you would like to use into this buffer. If the buffer is too small there may not be enough room to write a long ROP Chain into and so an attacker should be careful to craft their ROP Chain to be efficient enough to fit into the space available.
The next requirement is to be able to control the stack - This can take the form of a stack overflow - which allows the ROP Chain to be written directly under the stack pointer, or a "stack pivot" - which is usually a single gadget which moves the stack pointer to the rest of the ROP Chain.
Once the stack pointer is at the start of your ROP Chain, the next ret
instruction will trigger the gadgets to be excuted in sequence - each using the next as its return address on its own stack frame.
It is also possible to add function poitners into a ROP Chain - taking care that function arguments be supplied after the next element of the ROP Chain. This is typically combined with a "pop gadget", which pops the arguments off the stack in order to smoothly transition to the next gadget after the function arguments.
Easy install:
cargo install ropr
the application will install to ~/.cargo/bin
From source:
git clone https://github.com/Ben-Lichtman/ropr
cd ropr
cargo build --release
the resulting binary will be located in target/release/ropr
Alternatively:
git clone https://github.com/Ben-Lichtman/ropr
cd ropr
cargo install --path .
the application will install to ~/.cargo/bin
rax
with a value from another register I may choose to filter by the regex ^mov eax, ...;
: