Remote Code Execution (RCE) is a category of vulnerabilities. These allow an attacker to execute system commands on the server. A lot of vulnerabilities allow direct system command execution. The following is only a subset of possibilities:

• Random object deserialization
• Random file include
• Insecure file upload
• Command injection
• XXE
• …

Being able to execute commands on the server is like having an SSH session directly into the server. If you are asking “what exactly can I do with Remote Code Execution (RCE) vulnerabilities ?” then you are in the right place. Let’s explore the possibilities available for the hacker.

Retrieve the server’s configuration

With command execution on the server, an attacker can retrieve details on the server’s configuration.

In some cases, the vulnerable application will not show you the result of the command you execute. It is still possible to retrieve the result. You can, for example send a configuration file to your own web server via an HTTP request. Or you can send it to yourself via email, or get hold of it using one of many available means.

To get the result of a command, you can write the result of that command to a file, and then retrieve that file.

What kind of configuration information would an attacker retrieve? Good question, here are examples of information that can be useful for an attacker:

• Environment variables: could contain application secrets
• The name of the machine: could give a hint on the server’s role
• The list of system users
• The operating system version and the list of installed software. This could give an attacker ideas on how to escalate his privileges on the machine (become root on Linux or Administrator on Windows)
• …

Edit the server’s configuration

Depending on the privileges of the application on the server, an attacker could change some or all of the server’s configuration.

With RCE vulnerabilities, the attacker gives the application system commands to execute. The application that executes the commands has certain permissions on the operating system. If the application has high privileges (root on Linux or Administrator on Windows), the attacker can change the server’s configuration.

With high privileges, an attacker could:

• Change the network configuration of the server (IP address, DNS server …) to redirect network traffic through his own server. This allows him to intercept requests and even alter them.
• Add, Edit or delete OS users.
• Create a backdoor to the server, so that he can access the server even if the RCE vulnerability gets fixed.
• Disable logging of server requests, so that he can operate without being detected by security teams.
• Encrypt all the files on the server, and ask for a ransom to decrypt them (Ransomware). This is especially effective if administrators don’t have a recurring backup job. To retrieve their files, they might have to pay the ransom.
• …

Retrieve the application’s source code

Since the application is running on the server, the attacker can retrieve the application source code. The application source code might be directly accessible as plaintext files (case for interpreted languages like PHP or Python). Or, it can be in the form of a compiled project (like WAR files containing the compiled Java code).

Once the attacker retrieves the code, he can analyze it and try to identify other weaknesses in the application.

The source code might also contain proprietary features. So leaking the code publicly, or selling it to a competitor might cause financial harm to the company.

Edit the application’s source code

Depending on the level of privileges an attacker has, he might be able to change the source code of the targeted application. In some instances, you can edit the source code file (like edit PHP file). In others, you need to re-compile the code and deploy the new application (like .war files for Java applications).

Why would an attacker alter the source code? Here are some possibilities:

• Add logging instructions to retrieve user passwords when they attempt to log in.
• Add a backdoor to the application so you can log in with a certain username and password.
• Alter application logic so that the application behaves a different way. For example, get a big discount if the username is “hacker123”
• Send malicious Javascript code to the users of the application. This code would spy on them, or retrieves their session cookies and impersonate them.
• Send users of the application malicious files. The attacker exploits the users’ trust in the application to make them launch malicious malware. He thus takes control over their machines.

Direct access to the database

The application communicates with a database. Thus, the connection information is stored somewhere on the server. Connection information includes the database server’s address, port number, username and password.

This information might be stored in environment variables, application configuration files, Cloud KMS services, or simply hardcoded in the source code.

With these details in hand, the attacker can connect directly to the database, using a database client on his computer. He thus gains unrestricted access to the database. There are lots of actions he can take:

• Steal user details: he can sell these to competitors, or leak them online. The database might contain sensitive personnel information (credit cards, social security numbers, addresses, phone numbers, emails …). The reputation of the hacked website will take a hit that might be difficult to recover from.
• Alter user details: for instance, the attacker might edit his own user records to make himself administrator of the platform.
• Recover or edit other records. The possibilities depend on the context of the application. For instance, on an e-commerce website, he might want to recover a discount code from the database. Or, he can create his own discount code, or reduce the price of a certain product he wants to buy.

You might say “but I have IP whitelisting on my database, only the production server can communicate with the database server”. That’s actually very trivial to bypass.

When you have RCE on a server, you can set up network traffic tunneling. In this scenario, all network traffic from the attacker’s machine will go first to the vulnerable server. The vulnerable server then will forward that traffic to the final destination.

So, connecting to the database this way will work. And from a forensics viewpoint, all traffic to the database originated from the vulnerable server. Thus, the unrestricted access will not get flagged as an attack.

Retrieve application configuration secrets

An attacker can access configuration files, environment variables, source code secrets or cloud KMS services, in the hopes of finding other configuration secrets. These can be API keys or passwords for other services. Here again, the possibilities depend on the application context:

• FTP passwords: The application might communicates with an FTP server. The attacker can retrieve the secret and perform a direct FTP connection from his own computer.
• SMTP password: if the application uses SMTP to send emails. An attacker could retrieve the SMTP credentials and use them to send emails impersonating the vulnerable application. This can be useful to launch phishing attacks against clients.
• Payment processor secrets: an attacker gaining access to payment processor secrets (like Paypal or Stripe) can use them to request refunds or maybe even to transfer funds and steal money from the application account.
• API keys: The application might use some third party API. Getting access to the application’s API keys allows the attacker to impersonate the application on these APIs. For example, if an application uses an API to issue a shipping order (drop shipping store). An attacker can issue shipping orders for himself without paying the e-commerce website.

The possibilities here depend on the context of the application, and what secrets can be found on the server.

Lateral movement

Web servers are usually hosted inside a sensitive network called DMZ (DeMilitarized Zone). These could be inside a company internal network, or they could be private networks in the cloud (VPC).

If an attacker gains access to a vulnerable server via an RCE vulnerability, he can set up network tunneling on the server. In that case, all network traffic from his computer will pass first by the vulnerable server. The vulnerable server then forwards the traffic to the final destination.

This allows the attacker to communicate with all the resources on the internal network as though he was physically plugged to it. He can try to find vulnerabilities on other systems on the network in the hopes of hacking other machines and moving laterally inside the network.