日志文件是服务器提供的非常有价值的信息，几乎所有的服务器、服务和应用程序都提供某种类型的日志记录，用来记录服务或应用程序运行时发生的事件和操作。
日志文件为我们提供了服务器行为的精确视图以及关键信息，例如何时、如何以及由谁访问了服务器。这类信息可以帮助我们监视性能、排除故障和调试应用程序，并帮助调查取证人员展开可能导致恶意活动的攻击链。
以web服务为例，访问日志access.log记录了所有对Web服务器的访问活动。假设访问者访问 www.example.com/main.php，将在日志文件中添加以下记录：
88.54.124.17 - - [16/Apr/2019:07:44:08 +0100] "GET /main.php HTTP/1.1" 200 203 "-" "Mozilla/5.0 (Windows NT 6.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
上述日志显示，IP地址为88.54.124.178的访问者于2019年4月16日07:44访问了main.php页面，并且访问成功。
这个信息可能不太重要，但如果日志文件显示IP为88.54.124.178的访问者在2019年4月16日07:44访问dump_database.php页面，并且请求成功，该怎么办？如果没有该日志文件，我们可能永远不会知道有人发现并运行了网站上的受限脚本，从而转储数据库。
在确定了日志文件是一项关键资产之后，让我们通过一个攻击案例来进行web日志安全分析，还原攻击路径。
攻击案例
假设我们管理的WordPress网站遭到篡改：
发现网站被攻击之后，运维团队将服务器断网下线处理，保持系统及其日志的当前状态，以便能够进一步分析调查。
通常我们需要创建一个服务器硬盘镜像备份，然后在镜像虚拟机做一些操作去溯源。但是，由于仅用于进行演示，在这种情况下，调查取证小组可以处理原始数据。
调查取证
为了开始调查，我们需要确定要寻找的证据。通常，攻击证据包括攻击者直接访问隐藏或异常文件，对管理员权限区域内的非授权访问，远程执行代码，SQL注入，文件包含，跨站点脚本（XSS）以及其他可能表明异常的行为漏洞扫描或侦察活动。
比如，我们的Web服务器 access.log 可以有效记录访问来源。
root@secureserver:/var/log/apache2# less access.log
access.log 可以按天生成保存，一般来说，如果网站在某一天遭受漏洞扫描，那么这一天它的日志文件会比平常大很多。
84.55.41.57 - - [16/Apr/2019:20:21:56 +0100] "GET /john/index.php HTTP/1.1" 200 3804 "-" "Mozilla/5.0 (Windows NT 6.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"84.55.41.57 - - [16/Apr/2019:20:21:56 +0100] "GET /john/assets/js/skel.min.js HTTP/1.1" 200 3532 "http://www.example.com/john/index.php" "Mozilla/5.0 (Windows NT 6.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"84.55.41.57 - - [16/Apr/2019:20:21:56 +0100] "GET /john/images/pic01.jpg HTTP/1.1" 200 9501 "http://www.example.com/john/index.php" "Mozilla/5.0 (Windows NT 6.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"84.55.41.57 - - [16/Apr/2019:20:21:56 +0100] "GET /john/images/pic03.jpg HTTP/1.1" 200 5593 "http://www.example.com/john/index.php" "Mozilla/5.0 (Windows NT 6.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
每个日志文件包含几千条请求纪录，检查每一行明显是不切实际的，因此我们需要过滤掉一些可能无关的数据，包括图像和CSS、JS等资源文件。
由于网站正在运行WordPress，在这种情况下，我们可以通过关键字过滤 access.log 来获取满足WordPress特定特征的访问请求。
root@secureserver:~#cat /var/log/apache2/access.log | grep -E "wp-admin|wp-login|POST /"
通过上面这行命令会筛选access.log ，仅显示包含wp-admin、wp-login以及POST等关键字的记录。其中，wp-admin 是WordPress的管理后台，wp-login 是WordPress的登录页面，POST表示使用POST方法将HTTP请求发送到服务器，一般来说主要是登录表单和数据提交。
在筛选之后的结果中，我们会注意到这样一个访问请求：
84.55.41.57 - - [17/Apr/2019:06:52:07 +0100] "GET /wordpress/wp-admin/ HTTP/1.1" 200 12349 "http://www.example.com/wordpress/wp-login.php" "Mozilla/5.0 (Windows NT 6.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
我们看到IP:84.55.41.57成功访问了WordPress管理界面。
让我们看看这个IP地址的用户还做了什么，我们再次使用grep命令来筛选。
root@secureserver:~#cat /var/log/apache2/access.log | grep 84.55.41.57
发现以下有趣的记录：
84.55.41.57 - - [17/Apr/2019:06:57:24 +0100] "GET /wordpress/wp-login.php HTTP/1.1" 200 1568 "-"
84.55.41.57 - - [17/Apr/2019:06:57:31 +0100] "POST /wordpress/wp-login.php HTTP/1.1" 302 1150 "http://www.example.com/wordpress/wp-login.php"
84.55.41.57 - - [17/Apr/2019:06:57:31 +0100] "GET /wordpress/wp-admin/ HTTP/1.1" 200 12905 "http://www.example.com/wordpress/wp-login.php"
84.55.41.57 - - [17/Apr/2019:07:00:32 +0100] "POST /wordpress/wp-admin/admin-ajax.php HTTP/1.1" 200 454 "http://www.example.com/wordpress/wp-admin/"
84.55.41.57 - - [17/Apr/2019:07:00:58 +0100] "GET /wordpress/wp-admin/theme-editor.php HTTP/1.1" 200 20795 "http://www.example.com/wordpress/wp-admin/"
84.55.41.57 - - [17/Apr/2019:07:03:17 +0100] "GET /wordpress/wp-admin/theme-editor.php?file=404.php&theme=twentysixteen HTTP/1.1" 200 8092 "http://www.example.com/wordpress/wp-admin/theme-editor.php"
84.55.41.57 - - [17/Apr/2019:07:11:48 +0100] "GET /wordpress/wp-admin/plugin-install.php HTTP/1.1" 200 12459 "http://www.example.com/wordpress/wp-admin/plugin-install.php?tab=upload"
84.55.41.57 - - [17/Apr/2019:07:16:06 +0100] "GET /wordpress/wp-admin/update.php?action=install-plugin&plugin=file-manager&_wpnonce=3c6c8a7fca HTTP/1.1" 200 5698 "http://www.example.com/wordpress/wp-admin/plugin-install.php?tab=search&s=file+permission"
84.55.41.57 - - [17/Apr/2019:07:18:19 +0100] "GET /wordpress/wp-admin/plugins.php?action=activate&plugin=file-manager%2Ffile-manager.php&_wpnonce=bf932ee530 HTTP/1.1" 302 451 "http://www.example.com/wordpress/wp-admin/update.php?action=install-plugin&plugin=file-manager&_wpnonce=3c6c8a7fca"
84.55.41.57 - - [17/Apr/2019:07:21:46 +0100] "GET /wordpress/wp-admin/admin-ajax.php?action=connector&cmd=upload&target=l1_d3AtY29udGVudA&name%5B%5D=r57.php&FILES=&_=1460873968131 HTTP/1.1" 200 731 "http://www.example.com/wordpress/wp-admin/admin.php?page=file-manager_settings"
84.55.41.57 - - [17/Apr/2019:07:22:53 +0100] "GET /wordpress/wp-content/r57.php HTTP/1.1" 200 9036 "-"
84.55.41.57 - - [17/Apr/2019:07:32:24 +0100] "POST /wordpress/wp-content/r57.php?14 HTTP/1.1" 200 8030 "http://www.example.com/wordpress/wp-content/r57.php?14"
84.55.41.57 - - [17/Apr/2019:07:29:21 +0100] "GET /wordpress/wp-content/r57.php?29 HTTP/1.1" 200 8391 "http://www.example.com/wordpress/wp-content/r57.php?28"
84.55.41.57 - - [17/Apr/2019:07:57:31 +0100] "POST /wordpress/wp-admin/admin-ajax.php HTTP/1.1" 200 949 "http://www.myw ebsite.com/wordpre ss/wp-admin/admin.php?page=file-manager_settings"
我们来进一步分析这些记录。
攻击者访问了WordPress网站的登录页面：
84.55.41.57 - GET /wordpress/wp-login.php 200
攻击者提交了登录表单（使用POST方法），并被重定向（302 HTTP状态代码）。
84.55.41.57 - POST /wordpress/wp-login.php 302
攻击者被重定向到wp-admin（WordPress管理后台），这意味着攻击者已成功通过了身份验证。
84.55.41.57 - GET /wordpress/wp-admin/ 200
攻击者访问了网站的主题编辑器：
84.55.41.57 - GET /wordpress/wp-admin/theme-editor.php 200
攻击者试图编辑404.php文件，攻击者经常使用这种方式将恶意代码写入文件，但由于缺少文件写入权限，所有并没有成功。
84.55.41.57 - GET /wordpress/wp-admin/theme-editor.php?file=404.php&theme= twentysixteen 200
攻击者访问了插件安装程序。
84.55.41.57 - GET /wordpress/wp-admin/plugin-install.php 200
攻击者安装并激活了file-manager插件。
84.55.41.57 - GET /wordpress/wp-admin/update.php?action=install-plugin&plugin= file-manager &_wpnonce=3c6c8a7fca 20084.55.41.57 - GET /wordpress/wp-admin/plugins.php?action=activate&plugin=file-manager%2Ffile-manager.php&_wpnonce=bf932ee530 200
攻击者使用file-manager插件上传了r57.php，这很可能是一个PHP Web Shell脚本。
84.55.41.57 - GET /wordpress/wp-admin/admin-ajax.php?action=connector& cmd= upload&target=l1_d3AtY29udGVudA&name%5B%5D=r57.php&FILES=&_=1460873968131 200
日志表明，攻击者访问了r57.php ，查询字符串?1和?28表明攻击者通过脚本代码进行操作，但并未发现任何有趣的东西。
84.55.41.57 - GET /wordpress/wp-content/r57.php 20084.55.41.57 - POST /wordpress/wp-content/r57.php?1 20084.55.41.57 - GET /wordpress/wp-content/r57.php?28 200
攻击者的最后一个动作是通过file-manager插件编辑主题的索引文件，并将其内容替换为HACKED！。
84.55.41.57 - POST /wordpress/wp-admin/admin-ajax.php 200 - http://www.example.com/wordpress/wp-admin/admin.php?page=file-manager_settings
根据上述信息，我们可以看到攻击者的行为时间表，但是，目前还有一个问题没有弄清楚，攻击者是如何获得登录凭据的？
假设管理员密码没有泄漏也没有被暴力破解，让我们回头看看我们是不是忽略了什么信息。
在当前的access.log中并未发现任何有关管理员密码泄露的线索，但我们可以查看所有存档的access.log文件，来拼凑出攻击者的行为轨迹。
首先，我们可以过滤日志出包含IP地址：84.55.41.57的日志记录。我们发现，其中有一条日志疑似SQL注入攻击的记录：
84.55.41.57- - [14/Apr/2019:08:22:13 0100] "GET /wordpress/wp-content/plugins/custom_plugin/check_user.php?userid=1 AND (SELECT 6810 FROM(SELECT COUNT(*),CONCAT(0x7171787671,(SELECT (ELT(6810=6810,1))),0x71707a7871,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) HTTP/1.1" 200 166 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.3) Gecko/20100401 Firefox/4.0 (.NET CLR 3.5.30729)"84.55.41.57- - [14/Apr/2019:08:22:13 0100] "GET /wordpress/wp-content/plugins/custom_plugin/check_user.php?userid=(SELECT 7505 FROM(SELECT COUNT(*),CONCAT(0x7171787671,(SELECT (ELT(7505=7505,1))),0x71707a7871,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) HTTP/1.1" 200 166 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.3) Gecko/20100401 Firefox/4.0 (.NET CLR 3.5.30729)"84.55.41.57- - [14/Apr/2019:08:22:13 0100] "GET /wordpress/wp-content/plugins/custom_plugin/check_user.php?userid=(SELECT CONCAT(0x7171787671,(SELECT (ELT(1399=1399,1))),0x71707a7871)) HTTP/1.1" 200 166 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.3) Gecko/20100401 Firefox/4.0 (.NET CLR 3.5.30729)"84.55.41.57- - [14/Apr/2019:08:22:27 0100] "GET /wordpress/wp-content/plugins/custom_plugin/check_user.php?userid=1 UNION ALL SELECT CONCAT(0x7171787671,0x537653544175467a724f,0x71707a7871),NULL,NULL-- HTTP/1.1" 200 182 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.3) Gecko/20100401 Firefox/4.0 (.NET CLR 3.5.30729)"
假设这个插件是系统管理员从网上直接下载并拷贝到网站之中的，脚本安装路径：
/wordpress/wp-content/plugins/custom_plugin/check_user.php
通过分析check_user.php文件，发现存在SQL语句拼接，导致网站存在SQL注入漏洞。
<?php//Include the WordPress headerinclude('/wordpress/wp-header.php');global $wpdb;// Use the GET parameter ‘userid’ as user input$id=$_GET['userid'];// Make a query to the database with the value the user supplied in the SQL statement$users = $wpdb->get_results( "SELECT * FROM users WHERE user_id=$id");?>
access.log记录表明，攻击者使用了SQL注入自动化工具来查找数据库名称，表名称和列，日志中的记录将类似于以下内容：
/wordpress/wp-content/plugins/my_custom_plugin/check_user.php?userid=-6859 UNION ALL SELECT (SELECT CONCAT(0x7171787671,IFNULL(CAST(ID AS CHAR),0x20),0x616474686c76,IFNULL(CAST(display_name AS CHAR),0x20),0x616474686c76,IFNULL(CAST(user_activation_key AS CHAR),0x20),0x616474686c76,IFNULL(CAST(user_email AS CHAR),0x20),0x616474686c76,IFNULL(CAST(user_login AS CHAR),0x20),0x616474686c76,IFNULL(CAST(user_nicename AS CHAR),0x20),0x616474686c76,IFNULL(CAST(user_pass AS CHAR),0x20),0x616474686c76,IFNULL(CAST(user_registered AS CHAR),0x20),0x616474686c76,IFNULL(CAST(user_status AS CHAR),0x20),0x616474686c76,IFNULL(CAST(user_url AS CHAR),0x20),0x71707a7871) FROM wp.wp_users LIMIT 0,1),NULL,NULL--
上面的SQL代码非常有力地表明WordPress数据库已被盗用，并且该SQL数据库中的所有敏感信息都有可能被泄露。
分析
通过这次调查，我们还原了攻击事件链：
不过仍然存在一些疑问，比如说攻击者到底是谁？从目前来说，我们只知道攻击者的IP地址，而且攻击者一般都会使用代理服务器或匿名网络（例如Tor）来掩盖其真实的IP地址。除非攻击者留下了与他真实身份有关的证据，否则我们很难得知攻击者的真实身份。
通过日志分析，我们发现了攻击者的攻击路径和安全事件的根本原因：管理员所使用的那款自定义WordPress插件中存在SQL注入漏洞，导致攻击者通过SQL注入漏洞获取管理员账号密码，从而登录管理后台进行网页篡改。修复SQL注入漏洞并清除webshell，从备份文件中恢复被篡改的文件，使网站恢复正常。
在上述虚构的示例中，攻击者入侵后的处理其实是非常草率的，留下了大量攻击痕迹和取证证据，而这些信息将给调查人员提供很大的帮助。但在真实的攻击场景中，攻击者往往会清除很多关键信息，这势必会加大调查人员的取证难度。
注：本文由Bypass翻译并整理，文章来源：
https://www.acunetix.com/blog/articles/using-logs-to-investigate-a-web-application-attack/
