RootMe

Enumeration

nmap

Initial enumeration with nmap

nmap 10.10.88.1    
Starting Nmap 7.94SVN ( https://nmap.org ) at 2023-11-21 05:03 PST
Nmap scan report for 10.10.88.1
Host is up (0.32s latency).
Not shown: 996 closed tcp ports (conn-refused)
PORT     STATE    SERVICE
1/tcp    filtered tcpmux
22/tcp   open     ssh
80/tcp   open     http
2200/tcp filtered ici

Nmap done: 1 IP address (1 host up) scanned in 27.19 seconds

After conducting the initial enumeration using Nmap, I discovered two open ports: port 22, typically used for Secure Shell (SSH) connections, and port 80, which is the default port for HTTP traffic. This finding suggests potential avenues for further investigation, such as examining the HTTP service for web vulnerabilities or exploring the SSH service for secure remote access possibilities.

80 - HTTP

Let’s begin by enumerating port 80, often a primary entry point. To gather more detailed information about the target on port 80, I utilized tools like Nuclei and Wappalyzer. Nuclei is adept at identifying vulnerabilities and security-related configurations, while Wappalyzer helps in detecting various technologies and services running on the web server. This approach ensures a thorough examination of the web server’s configuration, security posture, and the technologies in use, paving the way for a more informed and strategic exploration of the target system.

Having gathered initial information about the target, the next step involves enumerating interesting folders and files on the HTTP server. This process is critical in identifying potentially sensitive directories, misconfigured files, or hidden resources that could provide further insights into the server’s structure and vulnerabilities. Tools like DirBuster, Gobuster, or ffuf can be employed for this purpose. They systematically scan the web server for known paths and can be configured with wordlists tailored to the server’s profile, enhancing the chances of uncovering significant findings in the server’s file and directory structure. This step is pivotal for a comprehensive security assessment, often revealing avenues for deeper exploitation or data extraction. I particularly like theghobuster.

I came across two intriguing folders named ‘upload’ and ‘panel’. These directories hinted at more complex functionalities within the server’s architecture. Notably, the ‘panel’ folder contained an upload feature, which immediately piqued my interest as a potential security vector.

I attempted to upload a PHP file, anticipating some level of interaction or perhaps even a breakthrough. However, instead of success, I was met with an error message. This outcome, while initially seeming like a setback, actually opens up new avenues for investigation. It suggests that there are underlying controls or filters in place, which now become a focal point of my analysis. Understanding and potentially circumventing these restrictions could be key to uncovering deeper vulnerabilities within the system.

Then, I decided to employ a straightforward yet potentially effective tactic: I simply renamed the file to have a .png extension. This approach aimed to test the server’s file validation mechanisms — to see if it merely checks file extensions superficially or delves deeper into the actual file content. Renaming a PHP file to a .png could potentially bypass basic filters that only scrutinize file extensions, allowing for further exploration of how the server handles unexpected file types under familiar extensions.

The file goes to the upload page:

In my initial attempt to exploit the discovered vulnerability, I sent a simple PHP reverse shell script. However, it didn’t work on the first try. This led me to a phase of trial and error, experimenting with various forms of PHP shell scripts, and trying to pinpoint the reason for the failure. During this process, I realized that the issue might not be with the shell scripts themselves, but rather with the file extension.

Originally, I was removing the .php extension to upload the shell, which seemed like a reasonable approach given the server’s file validation system. But then, I had an insight: What if the server was still processing PHP, but only with a different extension? Acting on this hunch, I renamed the shell to have a .php5 extension. To my satisfaction, this small tweak was the key. The server accepted the file, and I successfully gained a reverse shell.

This breakthrough was a testament to the importance of persistence and creative thinking in penetration testing. It highlighted how even seemingly minor details, like a file extension, can be critical in security testing scenarios.

I used the PHP-reverse-shell from pentestmonkey:

php-reverse-shell

When the usual search in common folders didn’t yield the flag, I resorted to using the find command to search for the user.txt file. This approach is often necessary in capture the flag (CTF) challenges or penetration testing scenarios when the flag, a text file containing a specific string used for scoring or verification purposes, isn’t located in the standard directories.

Executing a command like find / -type f -name user.txt allowed me to scan the entire file system for any file named user.txt. This method is thorough and ensures that no directory is overlooked, but it can be time-consuming and may require sifting through a lot of data. Nonetheless, it’s an effective technique when the location of a target file is unknown or hidden in an unconventional location.

Privilege Escalation

When searching for potential privilege escalation avenues, I turned my attention to files with SUID (Set Owner User ID upon execution) permissions. SUID is a special type of file permission given to a file. It enables users to execute the file with the permissions of the file owner, which could be the root user.

Noticing that Python had SUID permissions set, it immediately stood out as a promising target. Python being SUID enabled could be a significant misconfiguration, allowing for privilege escalation. In a typical Linux environment, Python with SUID permissions could be exploited to execute arbitrary commands with elevated privileges.

For instance, one could invoke a Python shell with elevated permissions using a command like /usr/bin/python -c 'import os; os.system("/bin/sh")'. This could potentially provide a shell with root-level access, assuming Python’s SUID bit is set and the binary is owned by the root.

After running the exploit I got the shell, and the flag was in the root folder.