2015/03/30 11:00

from:http://resources.infosecinstitute.com/log-analysis-web-attacks-beginners-guide/

0 x00 preface


Reality may often appear some signs of being hacked web log, such as a site for your URL to SQL injection test and so on, at this moment need you what situation, from the analysis of the log if very serious, may require investigation who will do this thing, what’s it like in attack process.

There are other scenarios.

As an administrator, it is really important to understand how to analyze logs from a security perspective.

This article covers the basics of log analysis to address the above requirements.

0 x01 to prepare


For demonstration purposes, I do the following.

Apache server

Preinstalled on Kali Linux

This can be enabled with the following command:

service apache2 start
Copy the code

MySQL

Preinstalled on Kali Linux

This can be enabled with the following command:

service mysql start
Copy the code

Create a buggy Web application using PHP-mysql

I developed a buggy Web application using PHP and put it in the apache-mysql mentioned above.

Once that was done, I used some of the automated tools in Kali Linux (ZAP, W3AF) to scan the URL of the buggy application.

Now let’s look at the different situations in analyzing logs.

0x02 Logs Recorded in the Apache Service


Debian system default location is: the Apache server log on/var/log/apache2 / access. Log

Logging simply stores logs on the server. I also need to analyze the logs to get the right results. In the next section, we’ll see how we can analyze the Apache server access logs to find out if there are attack attempts on the Web site.

Analysis of the log

Manual inspection

In the case of small log volumes, or if we are looking for a specified keyword, a tool like grep expression can be used to observe the log.

In the figure below, we try to find all requests with the keyword “union” in the URL.

In the figure above, we can see the “union select 1,2,3,4,5” request in the URL. Obviously, someone at IP address 192.168.56.105 has attempted SQL injection. Similarly, we can search for specific keywords when we have our own.

In the figure below, we are searching for a request to read “/etc/passwd”, which is obviously a local file inclusion attempt.

As shown in the screenshot above, we have many local files containing attempts, and these requests are sent from IP address 127.0.0.1.

Most of the time, it’s easy to tell from the logs if it’s an automated scanner.

IBM AppScan, for example, uses the word “appscan” in many attacks on payloads. So, by looking at this request in the log, we can basically tell that someone is using AppScan to scan the site.

Microsoft Excel is also a great tool for opening log files and analyzing logs. We can use Excel to open log files by specifying “space” as the separator.

This is also useful when we don’t have log analysis tools at hand.

In addition to these keywords, understand the basics of HTTP status code during analysis. Below is a table of advanced information about HTTP status codes.

0x03 Web shells


Webshell is another problem with web sites/servers. Webshell can control the server with Web Server permissions.

In some cases, we can use Webshell to access all other sites that are hosted on the same server.

The following screenshot shows the same access.log file opened in Microsoft Excel.

We clearly see that a file called “b374k.php” has been accessed. “B374k” is a popular Webshell, so this file is very suspicious.

Looking at the corresponding code “200”, this line indicates that someone uploaded a Webshell and accessed it.

In many cases, attackers rename the Webshell to avoid suspicion. We have to be smart and see if the files being accessed are regular files or if they look different. We can go one step further and look at the file type and timestamp if any files look suspicious.

One single quote for the win
Copy the code

SQL injection is one of the most common vulnerabilities in Web applications. Most people who learn Web application security start by learning SQL injection.

It is easy to identify a traditional SQL injection by adding a single quote to the URL parameter to see if an error is reported.

Anything we pass to the server is logged and can be traced back.

The following screenshot shows that a single quote is passed to the user parameter to test for SQL injection.

%27 is the single quoted URL encoding.

For administrative purposes, we can also run query monitoring to see which requests in the database are executed.

If we look at the picture above, the SQL statement passing a single quotation mark to the parameter “user” is executed.

0x04 Analysis using an automated tool


When there are a large number of logs. Manual inspection becomes difficult. In this scenario, we can use automated tools in addition to some manual checks.

There are many effective commercial tools out there, but I’d like to introduce you to a free tool called Shine.

According to their official link, the SHINE is a log analyzer that is used on Apache servers to find security problems. The idea is to browse through a large number of log files and extract possible attacks from HTTP/GET.

Taint can be downloaded from the following link:

https://code.google.com/p/apache-scalp/

Shine is a Python script, so python is required to be installed on our machine.

The following image shows the tool’s help.

As we can see in the figure above, we need to use the -L flag to provide the log files to analyze.

At the same time, we need to provide a filter file for shine to identify possible attacks in the access.log file using the -f flag.

We can use filters in the PHPIDS project to detect any malicious attempts.

The file is called default_filter.xml and can be downloaded from the following link:

https://github.com/PHPIDS/PHPIDS/blob/master/lib/IDS/default_filter.xml

The following code block is taken from part of the link above.

#! html <filter> <id>12</id> <rule><! [CDATA[(?:etc\/\W*passwd)]]></rule> <description>Detects etc/passwd inclusion attempts</description> <tags> <tag>dt</tag> <tag>id</tag> <tag>lfi</tag> </tags> <impact>5</impact> </filter>Copy the code

It is a set of rules defined using XML tags to detect different attack tests. The above code snippet is an example of an attempt to detect a file inclusion attack.

After downloading this file, put it in the same folder of the SHINE.

Run the following command to use the Shine analysis log.

#! Bash python scalp - 0.4. Py - l/var/log/apache2 / access. The log - f filter. The XML output - o - HTMLCopy the code

“Output” is the directory where the report is saved. If no shine exists, create the SHINE automatically. – HTML is used to generate reports in HTML format. As we can see in the figure above, the Shine result showed that it had analysed 4001 rows, over 4024 and found 296 attack patterns.

Run the above command to generate a report in the output directory. We can open it in a browser and view the results. The output shown in the screenshot below shows a small portion of the directory traversal attack attempt.

Logging in MySQL


This section discusses methods for analyzing attacks in databases and monitoring them.

The first step is to see what variables are set. We can use “Show variables”; Complete, as shown below.

The output of the above command is displayed next.

As we can see in the figure above, logging is enabled. The default value is OFF.

The other important record here is “log_output”, which means that we are writing the result to a file. In addition, we can also use a watch.

We can see that “log_slow_queries” is ON. The default value is OFF.

All of these options are explained in detail and can be read directly in the MySQL documentation link provided below:

http://dev.mysql.com/doc/refman/5.0/en/server-logs.html

MySQL query monitoring


Request logging records statements received and executed from the client. The default record is turned off because of loss performance.

You can enable them from the MySQL terminal or you can edit the MySQL configuration file, as shown below.

I am using the VIM editor to open the “my.cnf” file in the /etc/mysql directory.

If we scroll down, we can see that the log is being written to a file called “mysql.log”.

We can also see that logging “log_slow_queries” is a log of SQL statements that take a long time to execute.

Everything is now ready. If someone is querying the database maliciously, we can observe it in these logs. As follows:

The figure above shows the query hitting a database named “WebService” and trying to bypass authentication using SQL injection.

0x05 More logs


By default, Apache logs only GET requests. To log POST data, we can use an Apache module called “mod_dumpio”. For more information on the implementation section, please refer to the following links:

http://httpd.apache.org/docs/2.2/mod/mod_dumpio.html

Alternatively, we can use “mod Security” to achieve the same result.

Reference: http://httpd.apache.org/docs/2.2/logs.html