Mohamed Sayed - Blog

( بِسْمِ اللَّـهِ الرَّحْمَـٰنِ الرَّحِيمِ ) Let's start our blog. As we know any IoT device should have a firmware to run it and there is a thought that it is secure by default because it is in a board, but we know that we can dump this firmware, our firmware know is already shared with us something like training to learn basics of reversing firmware. you can download the firmware from here . if we run the file command on the firmware we will find this "STM32F103C-firmware.bin: data" and if we try to get the architecture using binwalk it will return empty result "binwalk -A STM32F103C-firmware.bin" but we don't need this because it is a famous chip and we can know what we want from google. After searching for the chip name STM32F103C we will open its default page you will know that it run using "ARM Cortex M3" we will need that later, it is time to analysis using Ghidra. Analysis Dropping the firmware file to Ghidra but it will not detect anything

Hoi, let's try to debug and explain CVE-2023-4911 which is a buffer overflow in the glibc loader my debugging and exploit tested on Ubuntu 22.04.2 (Jammy Jellyfish), you can read the analysis and more information from the Qualys Security writeup . POC to check if you are vulnerable or not env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" "Z=`printf '%08192x' 1`" /usr/bin/su --help My exploit POC video takes 5m but I speeded up the video Preparing let's disable ASLR and debug our exploit echo 0 | sudo tee /proc/sys/kernel/randomize_va_space you have to know (from qualys security): On Linux, the stack is randomized in a 16GB region, and our environment strings can occupy up to 6MB (_STK_LIM / 4 * 3, in the kernel's bprm_stack_limits()): after 16GB / 6MB = 2730 tries we have a good chance of guessing the address of our environment strings. using the buffer overflow vulnerability in the tunables we will overflow the link_map struct wh

CVE-2021-3156 is a Heap-Based-Buffer overflow in sudo, in this blog I will share my walkthrough of this CVE and my final exploit for it, let's start with POC. First, I used AddressSanitizer(ASan) which is used to detect memory access errors such as use-after-free and memory leaks this is a sample output of it, and we can see the file which cause the crash with the line number and this is the command used to compile sudo with ASan We can check the root cause of the crash in gdb by passing the payload and breakpoint on line number 868 in file sudoers.c if we used the next instruction(ni) to follow the code and we can see when we reach the backslash(\) the code is passing the next value after it but our backslash is at the end of the string so what it will be passed? yes, it will be the Null Byte that is used to end the string, what do you think will happen if we do not have the end of our string? it will continue writing into the allocated memory and overflow it. The vulnerable code