Trace attackers through web log security analysis

On April 25, 2013, 4959 words of web security were watched 28975 times+

abstract

As an important part of web server, web log records the access request of client to web application and the running state of server in detail. Similarly, the attacker's invasion to the website will also be recorded in the web log. Therefore, in the daily operation and security emergency response process of the website, we can trace the attacker and restore the attack process by analyzing the WEB logs and combining with other situations. This paper mainly describes the thinking and common skills of Web log security analysis, and through a complete example, how to trace attackers by analyzing Web log and combining other clues after security events.

Web log structure

Before the security analysis of Web logs, we need to understand the structure of Web logs. From the current log types supported by mainstream web servers, there are two common types: 1. NCSA log format adopted by Apache and 2. W3C log format adopted by IIS.

NCSA log format can be divided into two types: NCSA general log format (CLF) and NCSA extended log format (eclf). The specific usage can be defined in the web server configuration file. Apache also supports custom log formats, which users can customize in their configuration files. For example, in Apache, you can modify the httpd.conf configuration file.

Figure 1

Next, let's look at an Apache access log:

192.168.1.66 - - [06/Sep/2012:20:55:05 +0800] "GET /index.html HTTP/1.1" 404 287 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0"

Here is a specific explanation:

192.168.1.66: indicates the IP address of the client

[06 / SEP / 2012:20:55:05 + 0800]: access time and server time zone

Get: the packet submission method is get. There are two common types: get and post.

/Index.html: URL of client access

Http / 1.1: protocol version information

404: status code of web server response. 404 indicates that there is no such file on the server, and 200 indicates that the response is normal. 500 indicates a server error.

287: bytes transferred during this access

Mozilla / 5.0 (Windows NT 6.1; RV: 15.0) gecko / 20100101 Firefox / 15.0: client browser, system environment and other information.

IIS access log format and save path can be configured in IIS manager. The following picture:

Figure 2

Here is the W3C extended log format for IIS:

Figure 3

It is worth noting that the access time in the W3C log format of IIS is Greenwich time, 8 hours less than our Beijing time. And there is no way to change it.

Principle of Web log security analysis

Through the above knowledge, we know that the web log will record the client's access request to the web application, including the normal user's access request and the attacker's malicious behavior. So how do we distinguish between normal users and malicious attackers? Through a large number of analysis, we find that when an attacker invades the website, the requests to the website will have specific attack characteristics. For example, when using web scanner to scan the website for vulnerabilities, a large number of 404 error logs will be generated.

Figure 4

When someone detects SQL injection vulnerability in the website, the following logs usually appear in the web access log:

Figure 5

Therefore, we can distinguish the access behavior of attackers and normal users by analyzing whether there are specific attack characteristics in Web logs.

However, web access log is not omnipotent. Some attacks will not be recorded in web access log. For example, post SQL injection will not be recorded in the web access log. At this time, we need to monitor this kind of attack by other means.

Security analysis of Web log

In the security analysis of Web logs, we can proceed according to the following two ideas, step by step, and restore the whole attack process.

1、 First, determine the time range of the attack and invasion, take this as a clue, search for suspicious logs within this time range, further investigate, finally determine the attacker, restore the attack process.

Figure 6

2、 After intruding into a website, an attacker usually uploads a backdoor file for later access. We can also use this document as a clue for analysis.

Figure 7

Web log security analysis skills

Web log files are usually large and contain rich information. When we do security analysis on Web logs, we usually only focus on the logs with attack characteristics, and other logs are useless for us. At this time, we can extract and analyze the log content we are concerned about by hand or with the help of tools to improve efficiency. Several commands that are often used in log analysis are "find", "findstr", "grep", "egrep", etc. for the usage of these commands, please find the relevant information by yourself.

1. Extract the log whose data submission method is "get"

Figure 8

The above command means to find the log content with get character from iis.log and save the result to iis_get.log.

Figure 9

2. Check whether there is any attack in the web log that exploits IIS write permission vulnerability

Figure 10

3. Manual log analysis is time-consuming and inefficient. Therefore, I developed a web log security audit tool to realize the automation of Web log security analysis. You can download the software at http://secsky.sinaapp.com/157.html. The following is the interface of the software and the generated analysis report.

Figure 11

Figure 12

Example analysis

We have talked about some skills often used in the process of Web log security analysis. Now we have a complete understanding of how to trace attackers and restore the attack process by analyzing Web log through an example.

Background:

One day, a file named shell.php.jpg was suddenly added to the web directory of the company's website server. After checking the contents of the file, it was found that the file was a backdoor file of the website, which is often called webshell. Therefore, it is suspected that the website has been hacked. Next, the webmaster successfully traced the attacker and restored the whole attack process by analyzing the web log and combining with other situations. In this process, we also found the security loopholes in the website, repaired the loopholes in time after the event, and carried out a comprehensive security inspection on the website to improve the security of the website.

Analysis ideas:

According to the current information analysis, we know that there is a suspicious file in the web directory. We will take the file as a clue, first find out which IPS have accessed the file, and then check what operations have been done by these IPS step by step, and finally confirm the attacker and the attack means he uses.

Analysis process:

1. First find the existing website backdoor file, which is the webshell file mentioned above. It was found that the file was created on February 7, 2013.

Figure 13

2. First, let's find out which IP addresses have accessed this file. You can extract the relevant log content through the following command.

Figure 14

Figure 15

3. From the above figure, we can confirm that only 192.168.1.2 has access to the file. This IP is very suspicious. Let's find out what the IP has done.

Figure 16

Figure 17

4. From the above log, we can see that this is a typical SQL injection. After further analysis, it is found that the attacker obtained the website background administrator account and password by SQL injection.

192.168.1.2 - - [07/Mar/2013:22:50:21 +0800] "GET /leave_show.php?id=40%20and%201=2%20union%20select%20unhex(hex(concat(0x5e5e5e,group_concat(id,0x5e,user,0x5e,pwd,0x5e,userclass,0x5e,loginip,0x5e,logintimes,0x5e,logintime),0x5e5e5e))),0,0,0,0,0,0,0, 0%20from%20(select%20*%20from%20(select%20*%20from%20admin%20where%201=1%20order%20by%201%20limit%201,100)%20t%20order%20by%201%20desc)t%20-- HTTP/1.1" 200 18859 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322)"

5. Then the attacker uses the obtained account to enter the website background successfully. See the following log for details:

192.168.1.2 - - [07/Mar/2013:22:51:26 +0800] "GET /mywebmanage/web_manage.php HTTP/1.1" 200 5172 "http://192.168.1.107/mywebmanage/" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:51:44 +0800] "POST /mywebmanage/check.php HTTP/1.1" 200 47 "http://192.168.1.107/mywebmanage/web_manage.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:51:45 +0800] "GET /mywebmanage/default.php HTTP/1.1" 200 2228 "http://192.168.1.107/mywebmanage/check.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

6. Then the attacker visited the page add_link.php, which is a page for adding friendship links:

Figure 18

By analyzing the source code of the website, it is found that there is a file upload vulnerability in the upload picture of the page. The attacker just used this vulnerability to upload a backdoor file named shell.php.jpg, and successfully obtained a webshell by using Apache's parsing vulnerability. For details of Apache parsing vulnerability, please refer to a previous article I wrote (http://secsky.sinaapp.com/89.html), which has a detailed description of the vulnerability.

192.168.1.2 - - [07/Mar/2013:22:53:40 +0800] "GET /mywebmanage/link/add_link.php HTTP/1.1" 200 3023 "http://192.168.1.107/mywebmanage/LeftTree.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:54:50 +0800] "POST /mywebmanage/link/add_link_ok.php HTTP/1.1" 200 77 "http://192.168.1.107/mywebmanage/link/add_link.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:55:48 +0800] "GET /link/shell.php.jpg HTTP/1.1" 200 359 "-" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:55:54 +0800] "POST /link/shell.php.jpg HTTP/1.1" 200 132 "http://192.168.1.107/link/shell.php.jpg" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

7. By now, we can understand the attack process of the attacker. The details are as follows:

First, we detect the vulnerability of the website, and find that there is a SQL injection vulnerability -- > we can get the account, password and other information of the website background administrator by using the SQL injection vulnerability -- > log in the website background as an administrator -- > we can successfully upload a backdoor file named shell.php.jpg by using the file upload vulnerability of a page, and we can successfully obtain a web by combining the analysis vulnerability of Apache Shell.

summary

Through the above security analysis of Web log, we not only trace the attacker, but also find out the vulnerability of the website. Next, we should delete the back door file uploaded by the attacker and fix the existing security vulnerability. Then we should carry out comprehensive security detection on the website, and strengthen the security of the web server to prevent such security events from happening again.