Detection and Prevention – An Introduction to Web-Shells – Final Part

webshells

In part 4 of this series, we looked at web shells in action by using Weevely as an example. In the final part of this series, we’ll be looking at web shell detection and how to prevent them.


Detection

If an administrator suspects that a web-shell is present on their system (or during a routine check), the following are some things to examine.

Firstly, the server access and error logs must be filtered for common keywords that are being used by web shells. This includes filenames and/or parameter names. The example below looks for the string ‘file’ in URLs in Apache HTTP Server’s access log

root@secureserver:/var/www/html# cat /var/log/apache2/access.log | awk -F\" ' { print $1,$2 } ' | grep "file"

--> 192.168.5.26 - - [30/Apr/2016:08:30:53 +0100] GET /demo/shell.php?file=/etc/passwd

The filesystem (usually the web server root) must be searched for common strings in files or filenames.

root@secureserver:/var/www/html/demo# grep -RPn "(passthru|exec|eval|shell_exec|assert|str_rot13|system|phpinfo|base64_decode|chmod|mkdir|fopen|fclose|readfile) *\("

--> Shell.php:8: eval($string);
eval.php:1:?php system($_SERVER['HTTP_USER_AGENT']); ?>
Ad.php:9: eval($string);

Search for very long strings which may indicate encoding. Some backdoors have thousands of lines of code.

root@secureserver:/var/www/html/demo# awk 'length($0)>100' *.php

--> eval(gzinflate(base64_decode('HJ3HkqNQEkU/ZzqCBd4t8V4YAQI2E3jvPV8/1Gw6orsVFLyXefMcFUL5EXf/yqceii7e8n9JvOYE9t8sT8cs//cfWUXldLpKsQ2LCH7EcnuYdrqeqDHEDz+4uJYWH3YLflGUnDJ40DjU/AL1miwEJPpBWlsAxTrgB46jRW/00XpggW00yDI/H1kD7UqxI/3qjQZ4vz7HLsfNVW1BeQKiVH2VTrXtoiaKYdkT4o/p1E8W/n5eVhagV7GanBn0U7OCfD7zPbCQyO0N/QGtstthqJBia5QJsR6xCgkHpBo1kQMlLt6u++SBvtw5KSMwtG4R2yctd0mBNrlB3QQo4aQKGRgRjTa0xYFw1vVM9ySOMd44sSrPe…

Search for modified files in the last X day/s. In the following example we searched for *.php files changed within the last day but it is recommended to search for any file change as a web-shell can also be embedded into an image or any other file.

root@secureserver:/var/www/html/# find -name '*.php' -mtime -1 -ls

--> root@secureserver:/var/www/html/# find -name '*.php' -mtime -1 -ls
2885788 4 drwxrwxr-x 2 secuser secuser 4096 Apr 30 06:590 /demo/shell.php
2886629 4 -rw-rw-r-- 1 secuser secuser 260 Apr 29 11:25 /demo/b.php
2897510 4 -rw-r--r-- 1 root root 35 Apr 29 13:46 /demo/source.php
2883635 4 -rw-r--r-- 1 www-data www-data 1332 Apr 29 12:09 ./ma.php

Monitor network for unusual network traffic and connections.

root@secureserver:/var/www/html/demo# netstat -nputw

--> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.5.25:37040 192.168.5.26:8181 ESTABLISHED 2150/nc
tcp 0 0 192.168.5.25:22 192.168.5.1:52455 ESTABLISHED 2001/sshd: secuser
tcp6 1 0 ::1:46672 ::1:631 CLOSE_WAIT 918/cups-browsed
tcp6 0 0 192.168.5.25:80 192.168.5.26:39470 ESTABLISHED 1766/apache2
tcp6 1 0 ::1:46674 ::1:631 CLOSE_WAIT 918/cups-browsed

Analyze .htaccess files for modifications. The following are examples of changes an attacker might make to .htaccess files.

# The AddType directive maps the given filename extensions onto the specified content type
AddType application/x-httpd-php .htaccess
AddType application/x-httpd-php .jpg

Prevention

The following is a non-exhaustive list of preventive measures to take in relation to web-shells.

  1. If not used, disable potentially dangerous PHP functions such as exec(), shell_exec(), passthru(), system(), show_source(), proc_open(), pcntl_exec(), eval() and assert()
  2. If it’s an absolute necessity to have those commands enabled, make sure that unauthorized users do not have access to these scripts. Additionally, use escapeshellarg() and escapeshellcmd() to ensure that user input can not be injected into shell commands, resulting in command execution vulnerabilities.
  3. If your web application is using upload forms make sure they are secure and that they only allow whitelisted file types to be uploaded.
  4. Never trust user input
  5. Do not blindly use code that you may find on online forums or websites.
  6. In the case of WordPress, try to avoid installing third-party plugins if you do not need them. If you need to make use of a plugin, ensure it is reputable and frequently updated.
  7. Disable PHP execution in sensitive directories like images or uploads
  8. Lock-down web server’s user permissions

Final Remarks

As we have seen, coding and using a web-shell is not difficult. Unfortunately, many web servers are setup in such a way where even a simple script is enough to cause significant damage. This is the main reason as to why there are thousands of publicly available web-shells. The fact that so many variations exist, make it difficult for intrusion detection and intrusion prevention systems (IDS/IPS) to detect them; especially if they are using signatures to detect such web shells. Some web-shells are very sophisticated and they are almost impossible to be detected, even with behavioral analysis.

Having said this, early on in this article series, we had established that web-shells are post-exploitation tools. This means that the best way to prevent exploitation, is to prevent them from being uploaded in the first place.

Since Acunetix Vulnerability Scanner tests websites and web applications for thousands of vulnerabilities, including code execution and arbitrary file upload vulnerabilities, it can find entry points that could allow attackers to upload web-shells before an attacker would.

Additionally, when making using Acunetix’ AcuSensor Technology, since a sensor is deployed inside the web application, the scanner can retrieve a list of files on the server back-end, meaning that the scanner can detect web shells and other malicious scripts even if they are buried deep within directories.


 

Part 3

Keeping web-shells under cover

Part 4

Web-shells in action

Part 5

Detection & Prevention

Share this post

Leave a Reply

Your email address will not be published.