Memory Corruption, Also Known As Binary Exploitation, is The Process of Providing a Malformed input To A Program in order to change the execution path, Or Simply to Write/Read data to/from the Process's Memory, This Can Compromise The Whole Operating system, By Targeting a High Privilieges Vulnerable Proccess, Fortunately, This Was in the past,
in The 1980s, There is No ASLR Security, There is No NX/DEP Security Enabled, A Simple Script kid can cause a Denial Of Service, Experts Can Compromise The Whole Computer, Gaining root Privilieges Easily, The Escalation Process is Easy, Once You Have A Shell, You Can Compromise Any root-process running Localy, Easily, I'm Talking in The 1980s
As An Example, This Photo Shows An insecure Memory Fetch Of User Input (stdin in this context), the gets() Function in libc, It Fetches Data From STDIN in a fixed length Memory, Without Any Security Check, So, Attacker Can Easily Control The Program Execution By Overflowing The Buffer With Random Values Or NOP Bytes, Until The First Byte of the return address, Now, The Attacker Can Change The Return Address, Triggering The Program To Run An Arbitrary Code.
Basically, BoF is About Overflowing an Allocated Buffer in The Memory, By Providing A Block Of Data That Doesn't Fit in this buffer, This will cause the Buffer Overflow Problem, Overwriting Other Data in the Process's Memory.
The Attacker Will Exploit This Vulnerability in order to manipulate Data in the memory, in order to Bypass some Conditions, (See More About The cmp Assembly Instruction), Or Simply To Overwrite The Pushed RIP, This Will Cause An Arbitrary Code Execution.
This Picture Shows That We Successfully Overwrited The Pushed RIP Register (Instruction Point Register), Then, When The CPU Reach The End of the code, it will load the pushed RIP From Stack, So A Direct Jump into 0x41414141 is gonna Happen Because we overflowed the buffer with AAAA...., Raising The Segmentation Fault Error By The Kernel, The Segmentation Fault Simply Means That The Program Tried To Access Memory That Shouldn't Be Accessed By This Process (Like Forbidden in The Web Field), Okay, Great, The Hacker Can Directly put A Binary Code That Spawns a shell, connect-back/bind shells..., in the buffer, then overflowing it until the first byte of the Pushed RIP Register, Finally Overwriting it with the address of the first byte of the buffer, that contains the binary code, Okay, This Binary Code That Spawn a shell or do anything malicious to the machine, is named Shellcode, We Now Discussed About the Simplest And Easiest Exploit Against Bufferoverflows, Stack-Based, With Simple Shellcode Injection. Believe This is the most simple one, there are more techniques and bypasses for Bufferoverflows Problems.
As The NX/DEP And The Return Address Checker ( __builtin_return_address() Compiler's Function) Security Defenses Comes Out (We'll Discuss Later About NX/DEP, just keep reading), The Kernel Will Always Check if it is gonna do a JMP or CALL To a Non-Executable Memory, if yes then a Segmentation Fault is Raised, The Attack was Detected, logged, Because The Stack Memory is Not Dedicated For Code Execution, And It is marked Non-Executable, so, the simple exploit against BOFs Will Not Work, We need a way that we can inject our code in an executable memory, but our Buffer Is Stored on the Stack?! How ?
There is a function Named 'system()' in libc (Basically Libc is the standard C Library, stdio.h stdlib.h....) that's used to execute commands with $SHELL -c, The Surprise is This function takes it's Arguments From The Stack !!!!!! So, No Need to have an Executable-Stack in order to exploit bufferoverflow !!, So How The Return To Libc Attack Works ?, Simple, We Overflow and Overwrite The Pushed RIP, To Jump into The Libc::system(char*) function, Sure, it is placed in an executable Memory !, The Commands we Want To Executes Are Stored On The Stack That We've Overflowed !! Sounds Great !!!, For Evasion techniques We Can Simply Put The Address of the libc::exit(int) After The Libc::system Address, Then, We Did A Successful Exploit, No Detection, No Noise, Everything is Legit, But, Unfortunately, There is a Security Mechanism Against This technique, So, What ?
We Are Here, The ROP technique, The Hardest Exploit Ever, The Success rate of ROP is 95.5% With ASLR/NX/DEP/RetValidator/..., Because, Our Shellcode is in the Program's '.text' Section !!, how ?
I Think You've Got The Idea, How Hard it is, And The Success Rate, You need To Assemble Your Own Shellcode From The Program's Memory, Putting The Gadget Addresses in a Way to form Your Shellcode Based On Your Goal!, CRAZY !! It is really hard to detect this exploit.
No need To Explain, This Photo Contain Everything You Want about the exploit.
SO SIMPLE, At the end of your exploit, be sure that the program gonna jump back to the normal execution, or do an exit(int) syscall, or to detach from the process., As An Example:
In This Picture, I Injected the execve /bin//sh shellcode into the _start section in the ELF Binary File, Simply, The _start Code Section is the first thing to run when The Kernel Has Successfully Loaded the Binary into Memory, the _start section run before the 'int main(int^NULL, char**^NULL)' function, anyway, when the execution reach the 0x401015, What's Next ?? there is no jump to the __libc_start_main !, This Will Cause the Segfault !, Yes, Logged, Detected!, How Can You Avoid That !!, Simply, exit(int) or return to the normal execution !!, This Type Of Shellcode is very-bad.
\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x54\x53\x50\xb0\x3b\xcd\x80
Okay, Another Shellcode, Can You Guess if this is a good or bad shellcode ? mmmm think, This Shellcode is bad, Kinda Crazy You'll Say What !!, How Can You Understand Hex Codes ?!! Listen and Focus with me, There is One Byte of 0x80 or the 'int 0x80' for x86 and 'syscall' for x86_64, this means that the shellcode is gonna execute only the execve without an appropriate exit() or jmp-back instruction to evade Logging the Error. simple.
You Are Changing the RIP Register, Evasion From Logs And Detection is Hard, if your exploit failed, big problem.
To Prevent Bufferoverflows, Every Function You Use Make Sure that it is designed to do a check on the memory size, or simply let you specify the Count of data to write, (Every C/C++ Programmer Now that it's the 'int n' Argument.), why, if you have a 5 Bytes Buffer, You need to write 5 Bytes into it ONLY !, if the function detect that you're trying to write more data, it returns, or simply write the n bytes you passed to it via the 'int n' Arg..
Protections, ASLR, Being a Postman in the city where they change the street name.
DEP/NX, Trying to swim in your car.
mmmm, I'm Trying to explain, ASLR, Address space Layout Randomisation, randomly moves around the address space locations of data regions. Typically, buffer overflow attacks need to know the locality of executable code, and randomizing address spaces makes this virtually impossible.
NX/DEP, No Execute Bit, Data Execution Prevention, flags certain areas of memory as non-executable or executable, which stops an attack from running code in a non-executable region.
SEHOP, Structured exception handler overwrite protection, helps stop malicious code from attacking Structured Exception Handling (SEH), a built-in system for managing hardware and software exceptions. It thus prevents an attacker from being able to make use of the SEH overwrite exploitation technique. At a functional level, an SEH overwrite is achieved using a stack-based buffer overflow to overwrite an exception registration record, stored on a thread’s stack
It Requires alot of skills in different fields, Those Are Some Basic Skills That every Binary Exploiter Should Have:
Want to Start Doing Binary Exploitation ??, I Recommend You First, To Learn Shellcode Writing, Everyone in the BE should Write Their own exploits/shellcodes, Diving into BE is Hard, Painful.
| Hacker | Learn Binary Exploitation | Why |
|---|---|---|
| IoT Hackers | Yes | IoT Devices Do Not Support Neither ASLR, Nor NX/DEP, Nor SEHOP, ..... |
| Web Hackers | No | It is Dead in the Web Field |
| Local Softwares/Services Pentesters | Keep it Knowledge, Do not Put A Big Effort in it | ASLR, DEP, There is No PC in 2022 with ASLR DEP Disabled.!. |
Yes I Know It's a Hobby, But Can You Get a Job With it? 0x00, So Don't Put Your 24 on it