Simple Remote Code Execution Vulnerability Examples for Beginners
Especially when I talk with newbie security researchers/bug bounty hunters, they always make me feel as not thinking theirselves capable of finding Remote Code Execution vulnerabilities because they are super-complex. Because of this misconception, these people are actually not trying to find any of them or stop looking after some time. I think maybe the reason behind it is most of the examples/write-ups are really super complex bugs leading to the RCE from several different root causes with chaining one to another. While I am always impressed by these well-written write-ups & new ways of exploitations, I still continue to look for the easy ones too when hunting. Due to this, I decided to share some of the real world examples that I found on the Synack targets for a while, which were actually low-hanging-fruits and could be found/exploited by anyone. Just a few different tricks may actually exploit a vulnerability which seems not-exploitable at first.
#Example 1 — Unrestricted File Upload 1
On a host system I was looking, i found a login page under /support/ directory within fuzzing directories. Within the help of the javascript files loaded on that login page, I enumerated some of after-login endpoints and within directly accessing this endpoints, I found out that some of the administrator pages are accessible without login. One was including upload file page, which was allowing asp file extensions too. Sounds really easy right?
Well, after upload, I tried to enumerate the upload directory of the files within both fuzzing and from javascript files but it was not possible. After that I tried to upload the file to the upper directories within trying directory traversal vulnerability on file name and it worked.
I used Burp Suite’s “Fuzzing-Path Traversal” dictionary for an easy & automated attack to find the vulnerability. But please be advised that while it doesn’t conduct any problem on file gathering, it could be a problem on file creation/update/deletion functionalities since all working payloads will create a new file on the server.
Please note that, this vulnerability is found on a target which was active for 2 weeks at least. Payout was around 3k.
#Example 2— Unrestricted File Upload 2
On a web system I was testing, I found a web form which was not existing on the web application site map or UI at all within the help of Google Dorks such as searching site:domain.com ext:aspx. That web form also had a file upload section, which was allowing to upload asp extensions.
In this time, the challenge was also for finding the directory of the upload was too. No matter what I did, I couldn’t enumerated the upload directory and also didn’t found any vulnerability to chain with such as directory traversal as on the first example. After that, I went back to the web form which I was filling. It was an application form for something I do not remember. I filled the huge form and send it. After a few minutes, I got an e-mail from the web application about my application. That e-mail was including all the information I filled out to the form, including a link to the my uploaded document which was at the same application in-scope. Clicking the link returned my same webshell as on the first example, as well as with the approximately 3k payout from platform.
Target was alive for 2 days when I submitted that vulnerability, in-which the 24-hour rule was already passed and nobody reported yet.
#Example 3— Known RCE Exploitation
On a host testing, I found a version of SugarCRM application running on an in-scope IP address. Within the gathering version of the software & searching for vulnerabilities on Google for it, I easily detected that the version was vulnerable for a PHP Code Execution vulnerability, even within a Metasploit module! Easy one, right?
Well, while exploit is completed, the session was not created. I tried to use different msf payloads from the framework but none of them worked, probably a firewall was blocking both incoming and outgoing requests for bind/reverse shells. After that, I opened the exploit code and analyzed it from here. Exploit code was creating a random named file under /custom/ directory and after that creating a reverse shell to the supplied IP address from that created php file. When I directly accessed the file created on my exploitation attempts above (in the picture, you can see it as /custom/svbGhtxS.php), it returned empty response, meaning that the file is actually created & exploit worked.
After that, on the below code, I noticed that a special payload header is sent to the server from this file for full exploitation which is base64 encoded, via this code:
So I encoded my payload as @system(whoami); for:
Requesting the file created by Metasploit with the payload header as created on the below image returned the output of the whoami command, along with the around 3k payout again.
When I was trying to delete my created webshells for clean-up process on this, I found other webshells created before mine’s and not by me (Figured it out from the file names & creation date-times), meaning that other researchers were also found this vulnerability but didn’t exploited it because the Metasploit module didn’t worked completely and they didn’t read the source code of the exploitation. Vulnerability was found after a day from target activation and outside of the 24-hour rule, meaning that I didn’t duplicated any other researcher.
#Example 4 — Application Level Command Injection
This one is a little more complicated than the other examples, but still wanted to add to this post because the exploitation technique is different.
On an authenticated web application testing, there was a functionality existing for adding custom expressions to the cases created by users. E.g. if the case is about a payment, you can return the firstAmount — lastAmount on the output of the case if needed. For this expressions, custom created functions are used such as addDate and diffDate functions:
Since the extension was .do, the underlying technology was Java and I thought that maybe on the input script stage, they are allowing also Java functionalities as well as custom created functions?
I appended my Java one-liner new java.io.DataInputStream(java.lang.Runtime.getRuntime().exec("whoami").getInputStream()).readLine() under the custom created addMessage function for returning me to the output of the code and I saved the expression.
After triggering it from another page, I got the output as:
Which returned a successful and pure Java code injection. After some research I found a similar vulnerability on another functionality of the application, which bringed me around 6k payouts in total.
Last Words
I hope this post inspires & encourages especially rookie researchers to hunt for both complicated and simple command execution vulnerabilities. As I always tell in my speaks, lectures and posts; all you need is a simple bug.
