Protecting Applications From RCE with a Single Function: a Cheat Sheet

Anyone who has ever developed web applications knows that threats posed to them are indeed numerous – starting from SQL injection, Cross-site Scripting, CSRF, and SSRF, and ending up with DoS and DDoS attacks – web applications are a huge target for an attacker.

With that being said, though, while there is a wide majority of attacks targeting web applications, there is another attack targeting them – and we have already talked about it in the past. The name of the attack is remote code execution, or RCE for short – and it’s essentially the type of attack that makes it possible to remotely execute malicious code inside of an application.

As we have already noted in the previous blog post, most RCE attacks usually employ benign-looking functions in Linux – they are then utilized to do harm to a server. Most remote code execution attacks utilize one of the following functions in a malicious way:

1. shell_exec() allows an attacker to execute commands and returns the output of those commands as a string.
2. system() executes a Linux command inside of itself and displays its output.
3. passthru() can be used to execute an external program.
4. eval() can be used to evaluate a malicious command as PHP code. Such a command makes RCE able to be combined with other types of web application flaws, if these are prevalent (think SQLi, CSRF, XSS, etc.)

With that being said, developers caneasily build functions that protect their web applications from this kind of attack. Here’s how such a function would look like when using PHP:

Seeing through such a function is relatively simple – you provide some “needles” (malicious functions), and the haystack you’re searching for those needles in is a specific parameter – if any of those malicious functions appear in the parameter, the request should get blocked. In this specific example, the request shouldn’t get blocked, but replace “shell” with your parameter and input either shell_exec() or passthru() in it, and the application should block the request.

This function can be adapted to other programming languages, too – no matter if you’re working with .NET, Ruby, Python, or C#, the code will differ somewhat, but the entire logic will remain the same – provide a haystack, then search for a needle inside of it. It’s that simple! However, do keep in mind that such functions would need to be very frequently updated to be effective, so that means that you should keep an eye on the security world every once in a while. That’s not that hard to do, though. Once you’re all done on that front, it’s time to start by securing yourself and the infrastructure of your company by implementing the API offered by BreachDirectory inside of it, tell your employees to search whether they’re at risk of identity theft by making use of the data breach search engine, and you should be good to go.