Photo by Florian Olivo on Unsplash

How I got my first RCE

Geni_Wazir

--

As a penetration tester, the task of uncovering all vulnerabilities can be quite challenging. Clients expect to identify numerous critical issues commensurate with their investment. While discovering intriguing vulnerabilities such as SQL injection, Broken Authentication and authorization, and Privilege Escalation is not uncommon, but identifying Remote Code Execution (RCE) instances is less frequent.

In this article, I share my experiences with my first RCE discovery, highlighting the unique challenges and insights gained during the process.

Unfortunately, I can’t unveil the direct images and URLs, but the journey to obtain them is an intriguing adventure.

Given the project information and the customary deadline for each project, I encountered a multi-role system. Typically, in such scenarios, most pentesters initially focus on privilege escalation before exploring other attack vectors. I also do the same, I was fortunate to discover both privilege escalation and broken access control issues. As I was preparing to conclude the assessment, I identified 4 critical and 5 high-severity issues on the website.

The findings were impressive, and they were sufficient to showcase my skills to the client while raising some concerns for the developer.

However, I felt a sense of dissatisfaction with the testing at some point. I had a lingering feeling that something was still missing, prompting me to go back to square one and reassess all my findings along with the website’s functionalities. I discovered an endpoint accessible with the admin role, allowing image uploads. I already identified a stored cross-site scripting vulnerability there. When attempting to upload a file other than an image, the website triggered a file type error. By capturing the request in Burp, I manipulated the MIME type, successfully uploading files beyond just images.

I had a pre-existing PHP file designed for testing PHP file uploads, and I made some modifications to it for my latest project. Initially, I uploaded the old PHP file and attempted to access it. While successful in accessing the uploaded PHP file, I encountered an issue where I received no output.

Upon inspecting the file, I realized it contained gibberish code. I proceeded to modify it and applied a specific payload.

<?php echo file_get_contents('/etc/passwd'); ?>

The purpose of this PHP code is to display the content of the file passed to the function. In this case, I specified the location as /etc/passwd, which in Linux contains sensitive information.

After uploading the modified PHP file, my joy and excitement were palpable as the code was executed successfully.

I employed this method to attain a reverse shell. Subsequently, I revisited all my findings to meticulously proofread and ensure thorough testing for every functionality and scenario, mirroring the practices of a real-world hacker.

Upon discovering these vulnerabilities, the client expressed satisfaction to some extent, knowing that their server would now be safeguarded against critical threats. However, I am well aware that the developer is in for a challenge and surprised upon receiving my final report, which comprehensively outlines all identified vulnerabilities.

--

--