WebShell Detection Technology

 

I. Common Webshell implant Methods

 

-Starling Leylo Trent

WebShell attacks are common attacks used to control Web servers. WebShell files are usually executable script files, such as asp, php, and jsp files. Some workers can exploit web Server defects, it is also valid to pretend to be an image file or other file type. WebShell is one of the most common web attack methods. Therefore, WAF products have the Webshell detection and protection capabilities. Common Webshell Implantation Methods:

1. using the web upload service to upload webshell scripts, the uploaded directory usually has the execution permission, which is common.

Many Web websites have businesses that allow users to upload data, such as uploading portraits and sharing data. After uploading some files, they sometimes report the complete URL Information of the uploaded files to the client, although some do not provide feedback, the stored file paths can be guessed. For example, common directories include/photo,/image,/upload, and so on.

If the Web site does not strictly control the access permission or folder directory permission, it may be exploited to launch webshell attacks. For example, when uploading an avatar, upload a script file and then access the script through the url. The script is executed.

2. Use other Web Service defects, such as SQL Injection defects, and implant Webshell scripts.

In essence, injection vulnerabilities allow attackers to execute commands on Web servers with certain privileges. Once the Web Service has an injection vulnerability, attackers can easily use scripts to operate directories or files and write webshell scripts to the specified directory.

3. Capture the Web Server System and upload the webshell file in the web service directory.

 

In addition to the hidden risks of Web application vulnerabilities, Web servers, as a server, may also have system-level vulnerabilities. If the server system is compromised and attackers obtain permissions, they can operate the Web server at will. Attackers may leave Webshell scripts on the Web server to facilitate continuous control.

 

The implanted Webshell Plugin may be exploited by other attackers. Attackers can guess the existing webshell file,

 

For example, common webshell file names are diy. asp, wei. asp, 2006.asp, newasp. asp, myup. asp, log. asp, phpspy. php and so on. Once speculation succeeds, attackers can use the "attack results" of their predecessors to launch attacks. If a password is set for webshell, you can analyze some comments and other information of the Webshell source file to further guess the password. Attackers can also use some major search engines to search for some existing webshells. Take google as an example, enter inurl in the search bar: "phpspy. php ", you can see a lot of pages that require password input. Most of these pages are embedded webshells.

 

2. Webshell Detection

Currently, webshell feature detection methods include dynamic feature detection and static feature detection. Static feature detection means that attackers can discover webshells by using feature matching when uploading webshell files, that is, a malicious character string feature library is created first. Different web languages may be different and then the matching is checked in various script files.

Generally, all functions of webshell appear in independent files. You can create different Script Function interfaces as feature strings based on different web programming languages, if a file contains more than two functions, this file can be considered webshell:

1. File Operations: copying, deleting, changing file names, uploading, downloading, viewing file lists, searching for files, viewing file attributes, and other functions

2. Directory operations: delete directories and Change directory names

3. Database: add, query, delete, change, database connection, establishment, and Compression

4. network function: Port Scanning

5. Registry operations: Open the registry, read the registry, delete the registry, and write data to the Registry.

6. Run the application, such as WScript. Shell.

7. view system information function: view the local IP address (NIC information), System User information, system environment variables, disk information,

8. Web server support group check: ADOX. Catalog, wscript. shell, Adodb. Stream, Scripting. FileSystemObject

9. Trojan mounting

10. web applications are encrypted: sensitive code is encrypted using common vbscrip. encode, jscrip. encode, javascrip. encode, base64_decode, gzinflate, gzuncompress, and str_rot13.

11. Other system sensitive functions.

Of course, one problem facing this static feature detection is false positives. Some feature strings are usually used by normal programs. For example, a user-published article may contain more information and more information about key feature strings. One such problem is false positives.

Generally, attackers can use variable name letters to facilitate kill-free purposes. However, some key library functions or script interface names are not changed, we can define two or more groups of basic events to detect the script language:

Example 1 Define the packet direction as the request packet

Basic Event 1: detected database operations: add, query, delete, and change related functions

 

Database Operation statements Detected

 

SQL statement execution Detected

 

 

 

Basic Event 2: application operations such as WScript. Shell, var. Run, shell_exec, and exec are detected.

The wscript. shell component is detected in basic events.

 

 

It is detected that the ws. run execution file is used as the script.

 

 

 

The above two basic events detected that the file upload contains the script code for database operations and execution files. The associated events can be considered as a very suspicious webshell upload event.

 

 

 

 

Example 2 define the packet direction as the request packet

 

Basic Event 1: web page encryption detected: sensitive code is encrypted using common vbscrip. encode, jscrip. encode, javascrip. encode, base64_decode, gzinflate, gzuncompress, str_rot13, and so on.

Detected web application encryption using vbscrip. encode

 

 

 

Basic Event 2: Other system sensitive functions are detected. Detected file operation components

 

 

When uploading a file for use, it is very suspicious to encrypt the application and use the file operation component. Of course, you can also add basic event 3 as the database operation class to make the event judgment more accurate, therefore, it is determined to be a very suspicious webshell upload event.

 

Dynamic Feature Detection

 

Dynamic Feature Detection means that webshell has been uploaded to the web server and intercepted when the web shell page is opened in the browser. At this time, the Code interpreted and executed by the web application is detected from the network, the biggest disadvantage of this method is that it is underreporting. As long as attackers make slight changes to webshell, they can easily detect devices and update the library when a new webshell comes out, therefore, the feature library to be maintained is huge.

 

 

Iii. WebShell detection in WAF

Traditional firewalls are difficult to defend against webshells. Generally, webshells access the port 80 ingress line, and the intrusion path has no obvious characteristics (the Webshell file itself is characteristic ), if you are not an experienced website administrator, it is difficult to detect attacks by accessing Web logs. For Webshell detection and defense, WAF products should be able to make up for the shortcomings of traditional firewalls. WAF products can be unwrapped to the application layer, you can perform in-depth analysis on the Data embedding at the application layer to detect and defend against Webshell embedding. Webshell files generally have features such as FSO functions and encryption methods, you can perform detection on some feature analysis features. And WAF product license can set some applications

 

Use level-based legitimacy rules to control file uploads and other behaviors. For example, you can set the types of files allowed to be uploaded, set filtering rules for uploaded file names, and so on. The example can effectively defend against webshells. Traditional gateway products provide better protection for the leakage of server systems.

To sum up, a comprehensive defense means is required to effectively defend against webshell attacks on websites. A good case is to first use a local webshell scanning tool to check whether the website has been implanted with webshell scripts. After cleaning, deploy WAF products and gateway products, block subsequent webshells. The complete attack protection is as follows: