This article describes the concepts, intrusion principles, and preventive measures to take in regard to Webshell attacks, helping you defend against Webshell intrusion and prevent damages such as data leakage.
Literally, “Web” indicates the Web service to be opened by the server, and “shell” indicates a certain permission obtained to operate the server. A Webshell is a script through which an anonymous user (intruder) gains certain operation permissions of the website server over one or more website ports.
A Webshell is usually a command execution environment in the form of Web files such as ASP, PHP, JSP, ASA, or CGI. It is also known as a webpage backdoor. A hacker who successfully intrudes a website usually uploads normal webpage files mixed up with Webshell backdoor files to the website server. Then, the hacker can access the backdoor files from a web browser to gain the command execution environment for controlling the website or Web system server.
The hacker has to use some special functions to trigger the Webshell for some malicious purposes. If the eigenvalues of these functions are compared and checked, the Webshell can be identified. However, the Webshell itself can be encrypted to bypass this detection.
A Webshell is usually implanted through any of the following ways:
Exploit upload vulnerabilities to upload Webshells.
The system’s front-end upload service can be used to upload Webshell scripts, and the executable permission on the destination directory is usually allowed for the client. Images and data files of a website are usually uploaded to their respective directories, which are typically named “image” or “upload.” Their full URLs are usually returned to the client.
If the access permissions or permissions on folders and directories for the website are improperly configured on the Web server, the upload vulnerabilities may be exploited to initiate Webshell attacks. An attacker can upload a script file, access and run the script through the URL, and then upload a Webshell to an arbitrary directory to gain the administrator’s control permissions of the website.
The hacker obtains the administrator’s backend password, logs on to the backend system, and uses the backend administration tool to write the Webshell Trojan to the configuration file. Alternatively, the hacker may add upload types, allowing to upload script files in ASP, PHP, and more.
Obtain a Webshell using the backup and restoration functions of the database. For example, the suffix of the backup file is changed to “.asp” during data backup. If the backend provides the MySQL data query function, the hacker can run
select..in To outfileto query the output PHP file and insert the code into MySQL to generate the Webshell Trojan.
Other websites in the system are attacked, or an FTP server is installed on the server. When the FTP server is attacked, it is injected with the Webshell Trojan, causing infection of the website system.
The hacker directly attacks system vulnerabilities on the Web server for intrusion. The Web server may have vulnerabilities in the system. When attacking the server system through the vulnerabilities, the hacker can upload Webshell files in the Web server directory after obtaining the permissions.
In summary, a Webshell can intrude the system generally due to the following reasons:
A Webshell is uploaded through the website vulnerabilities.
If a Webshell can be injected, it is highly possible that the server or middleware has security vulnerabilities. For example, the following common vulnerabilities may be exploited to inject Webshells: Directory parsing vulnerability on the IIS of earlier versions, file name parsing vulnerability, exposed application backend and weak passwords, Fast-CGI parsing vulnerability, Apache file parsing vulnerability, truncated upload, backend database backup function upload vulnerability, and database statement upload vulnerability.
A Webshell file is incorporated when the website is deployed.
When a large number of users use third-party open source code downloaded from the Internet, the Webshell malicious scripts may have been incorporated into the code, causing second intrusion or multiple intrusions. In the early stage of deployment, all the code other than the new code must be scanned to detect and kill malicious files to prevent intrusion after the website goes online.
Configure necessary firewall and enable the firewall policies. This prevents exposure of unnecessary services that may be used by hackers.
Perform Security hardening on the server. For example, disable the remote desktop function, periodically change the password, prohibit the user with the maximum permissions from running the program, and use the HTTPS encryption protocol.
Enhance permission management, set permissions for sensitive directories, restrict script execution permissions for uploaded directories, and prohibit execution permission configuration.