A Real World Example Of Classic Remote Command Execution (RCE)

Remote command execution is a vulnerability that allows an attacker to execute os commands on the web server by injecting them through a web application. Depending on the privilege, the attacker will automatically become a user of this server.

Upon successful execution of the os command, the attacker can gain shell access on the server and can then further plan its attack over other components in the network, hence, the vulnerability RCE is considered a critical one.

Recently, I was working on a pentesting engagement on one of the client’s complex applications having multiple components. This is a straightforward write-up on RCE that I discovered.

Application Background:

The target application is a backend application of custom-built supplier collaboration software to automate some parts of the procurement cycle specifically for suppliers to accept and collaborate PO, create shipments, put invoices, and view payment details, and it also has a different application for supplier deviation requests (SDR). This is used by a large set of teams across the globe for this organization.

The target application helps all the documents to manage and send them to NAS. A job is a script written by the admin and the collection of jobs is called a job stream that is written to manage a set of teams.

Exploitation:

Here we have access to the application as a read-only user. The user cannot write these jobs but can only view name and status, and search for jobstreams according to the jobstream id. Upon looking up a jobstream id, the following request gets triggered:

Providing an arbitrary text in jobstream_id parameter value reflects that arbitrary text in the response. Yes, we would go for an XSS (yes, it did pop up) but since these jobs are performing network operations too, giving a chance to RCE won’t harm. Concluding this as I am aware of the network architecture as well.

Initially, I tried to send out basic command injection payloads manually which didn’t work. Later tried to use a comprehensive list of payloads with intruder.

After a bit of analysis from the intruder results, I found a difference between the usual response length and the one I noticed. Here is what I found upon checking that up in repeater:

It was time to see how further I could escalate this:

Followed by:

Boom!! A full fledge web shell.

Conclusion:

Many times we aren’t aware of how the code implementation is, or how the deployed architecture works. As a pentester or bug hunter, one should try each and every test case irrespective to think of the logic behind it. If it is possible to run that test case, execute it.

Let me know your thoughts about it. Reach out on twitter or linkedin.