Over the past two decades, web applications as an alternative to traditional desktop application have been on to rise.
As their name suggests, they are installed on web servers and accessed via a web browser. This gives web apps a rather long list of advantages: multi-platform cross-compatibility, no installation required for the users, cheap and fast development, easier maintenance and support, universal access, and so on.
But what about their downsides? Well, in their biggest strength lies also their arguably most important disadvantage: vulnerability. Since they are being deployed online they are prone to hackers.
Among the many different threats, today we are going to talk about WEB SHELLS.
So, what exactly are web shells?
Simply put, they are pieces of code, uploaded to a web server which allow to access it remotely. They act as a command-line interface and can be written in any language supported by the server. The most usually observed web shells are written in widely supported languages, such as PHP and ASP. Perl, Python, Ruby, and Unix shell scripts are also used.
The most common way these malicious web shells are exploited by attackers is by creating backdoors - access points to a site or system. These opened “doors” allow hackers to bypass the usual authentication and can lead to wider network compromise. An attacker can use a web shell to issue commands, perform privilege escalation on the web server, and the ability to upload, delete, download and execute files on the web server.
Backdoors can be hard to find because they are usually hidden in files that are already part of the site or downloaded as new files with innocent names, most often placed in a directory with many files. Due to the potential simplicity and ease of modification of web shells, they can be difficult to detect. For example, anti-virus products sometimes produce poor results in detecting web shells.
So, how can we try to detect them?
There are a number of different indicators which we should be on the lookout:
1. Abnormal periods of high site usage (due to potential uploading and downloading activity);
2. Files with an unusual timestamps (more recent than the last update of the web applications installed);
3. Suspicious files in Internet-accessible locations (web root);
4. Files containing references to suspicious keywords such as cmd.exe or eval;
5. Unexpected connections in logs. For example: A file type generating unexpected or anomalous network traffic (e.g., a JPG file making requests with POST parameters);
And what measures can we take?
We could set up an automated system which checks all newly uploaded or changed files and see if they match a known web shell, similar to how an antivirus software does with other forms of malware.
Due to the fact that backdoors scripts often need to use non-legitimate PHP commands, we could look for these commands in the files on your server. Search programs which search for text in files could be helpful.
Another possibility is comparing the different app versions to see if there are any differences which could be a sign of unusual activity. Moreover, by using web traffic monitoring tools, we can check for any eventual anomalies.
But the ultimate question is - how to prevent attacks in the first place?
Installation of a web shell is commonly accomplished through server configuration weaknesses or web application vulnerabilities.
Let’s focus on the latter:
Most web apps have permission to make modifications directly to an accessible web directory. As a result, the systems themselves open the door seamlessly for attackers. It is therefore recommended that modification permissions be blocked. However, if this is not possible, there are other more sophisticated options:
Using Intrusion Detection System (IDS) and/or Intrusion Protection System (IPS)
Both these systems operate at the network layer, watching network traffic and are a step up from a firewall. An IDS matches data within packets against a signature database while simultaneously searching for and detecting anomalies against a pre-defined "normal" traffic profile. An Intrusion Protection System (IPS) goes even further by reacting or responding to what it detects. Both technologies are complementary but share the same inherent shortcoming, as they operate on known signatures and therefore have trouble with newer attacks and unknown signatures.
Using Web Application Firewall (WAF)
WAF can be described as “reverse proxy”. They too, similar to IPS, sit in-line, but operate at the application layer. They job is to monitor network traffic to and from a specific web application or server. That implies that it is dealing with the data stream, not the network stream. This means they are applied after decryption, gaining them full access to the request and response header and body. And a WAF can generally be expected to focus on application-specific signatures, more so than an IDS/IPS. WAF is also more likely to look at things like JSON or XML format validation; looking for things that aren't right instead of just looking for things that are wrong.A WAF can provide protection against threats like Cross-Site-Scripting or SQL injection, but can only detect an attack when it looks like a pattern that the WAF is configured to expect.
The two technologies are intersecting sets - in an attack, some traffic will trigger both the WAF and the IDS/IPS; some will only trigger the WAF; some will only trigger the IDS/IPS. The recommended way is to use a multi-layered approach to data security, including all of the components listed above.
Confirming that web shells are indeed a formidable problem, The U.S. National Security Agency (NSA) and the Australian Signals Directorate (ASD) have jointly released a Cybersecurity Information Sheet on mitigating web shell malware. The CSI provides techniques to detect—and recommendations to prevent—malicious web shells.
Moreover, NSA published a repository on Github where we can find a wide list of methods and tools that will help protect your system from web shell malware.
Web security is undoubtedly one of the most important aspects to keep in mind when developing web applications. Making sure to stay up-to-date when it comes to new threats as well as possibilities of their prevention is a task all developers should take seriously.