Posts

[NahamconCTF] Pwn Challenges (So Much Cache & Gopherflow Returns)

Image
  ( بِسْمِ اللَّـهِ الرَّحْمَـٰنِ الرَّحِيمِ ) (إن أحسنت فمن الله، وإن أسأت فمن نفسي والشيطان) Hoy, let's go through the challenges from NahamconCTF . I wanna thank Mohamed (ixSly) for his support in this CTF. 1. So Much Cache (hard) This one was easy and direct if we understand what it is doing we finish, let's start. it gives us the ability to allocate places in memory, free it, and jump to a location that the binary chooses, if we can control this location it will be a simple "ret2win" (we have a win function to read the flag). we can write in our allocation with size (input size * 3) if we create an allocation 8 we can write into the memory (8*3) size which will overflow and corrupt the next heap allocation metadata and that is what we need. what we will do? create allocation with size "16" (you can do it with different size). fill this allocation with "(A* ((16*3)-1) )" the "-1" for the "0x0a" newline. choose "Prepare

DEFCON Qual CTF 2024 - PWN - suscall challenge

Image
( بِسْمِ اللَّـهِ الرَّحْمَـٰنِ الرَّحِيمِ ) (إن أحسنت فمن الله، وإن أسأت فمن نفسي والشيطان) Solving "suscall" challenge from DEFCON Qual 2024. (challenge solved after the CTF) The first thing is reversing it with Ghidra and after some static and dynamic analysis we can see that there is a struct is created in the start of main if the file start with "sus" we will call the second function which is the challenge and this is a part of it we can notice that there is call to our input file " (*ppcVar1[5])(file_path); " with whatever in " ppcVar[5] " and it point to a function that print if there is a sus file detected and this var is an allocated location so i added a break point on it and did more dynamic analysis. lets say if we control it and added "system" and replace the function that print sus detection with filename "sus;sh;" to give us our shell code but how we can get the system function and control this location? if we c

[Debug/Exploit CVE-2022-24355] TP-Link TL-WR940N Stack-based Buffer Overflow

Image
( بِسْمِ اللَّـهِ الرَّحْمَـٰنِ الرَّحِيمِ ) (إن أحسنت فمن الله، وإن أسأت فمن نفسي والشيطان) We will try to debug and exploit CVE-2022-24355, i wanna thank my friend Sameh ( s4muii ) for his help through this exploit. It was a little bit hard because this is my first time with MIPS. The Exploit on  GitHub . About the Bug TP-Link TL-WR940N router's firmware before v5_211111 is vulnerable to Stack Overflow, the vulnerability in "httpd" binary in function "httpRpmFs" and we can know that from ZDI report (https://www.zerodayinitiative.com/advisories/ZDI-22-265/) we will try to reproduce this finding in firmware "v4_160617" which will be emulated in our device because we do not have the router itself.

Lets Analysis STM32F103 Chip Firmware from Attify

Image
( بِسْمِ اللَّـهِ الرَّحْمَـٰنِ الرَّحِيمِ ) 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

Exploit & Debug Looney Tunables CVE-2023-4911 Local Privilege Escalation in the glibc's ld.so

Image
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