Web 日志分析过程
文章目录
- Web 日志分析过程
- 一、日志格式学习
- 二、入侵日志分析
- 2.1 网站被入侵，分析解决思路:
- 2.1.1 下载日志分析 access.log+error.log
- 2.1.2 找到攻击者的 IP 地址
- 2.1.3 攻击者是如何找到网站后台的？
- 2.1.4 攻击者如何进入后台？
- 2.1.5 攻击者修改了什么文件来写一句话？
- 2.1.6攻击者通过一句话后门做了什么？
- 三、通过 SQL 注入日志分析
- 3.1 sql 入侵了，你现在需要做的是
- 3.1.1**下载日志文件之后，发现是都是类似的请求**
- 3.1.2 攻击者使用的方法属于 sql 注入中的什么方法?
- 3.1.3攻击者从什么时候开始用脚本跑数据的？
- 3.1.4攻击者的 payload 格式是怎样的，解译一下。
- 3.1.5攻击者拿到了什么数据？数据内容是什么？
Web 日志分析过程
日志分析，其实涵盖的面是很广的，什么地方都可以有日志。而本篇文章主要针对 web 日志做一下分析。因为之前去学校里授课的时候有讲过一次，感觉内容挺不错的，就写到了文章里。（可绝不是偷懒什么的呢o(´^｀)o）
相关资料及工具【链接: https://pan.baidu.com/s/1o7FcHui 密码: jpdn】
一、日志格式学习
一条访问信息记录如下：
218.19.140.242 - - [10/Dec/2010:09:31:17 +0800] “GET /query/trendxml/district/todayreturn/month/2009-12-14/2010-12-09/haizhu_tianhe.xml HTTP/1.1” 200 1933 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)”
共有九项内容：
- 218.19.140.242 ：这是一个请求到 apache 服务器的客户端 ip, 默认的情况下,第一项信息只是远程主机的 ip 地址,但我们如果需要apache 查出主机的名字,可以将 HostnameLookups 设置为 on, 但这种做法是不推荐使用,因为它大大的减缓了服务器。另外这里的 ip 地址不一定就是客户主机的 ip 地址，如果 客户端使用了代理服务器,那么这里的 ip 就是代理服务器的地址,而不是原机.
- -：The “hyphen” in the output indicates that the requested piece of information is not available. In this case, the information that is not available is the RFC 1413 identity of the client determined by identd on the clients machine. This information is highly unreliable and should almost never be used except on tightly controlled internal networks. Apache httpd will not even attempt to determine this information unless IdentityCheck is set to On
- -: 这一项又是为空白,不过这项是用户记录用户 HTTP 的身份验证,如果某些网站要求用户进行身份验证,那么这一项就是记录用户的身份信息
- [10/Dec/2010:09:31:17 +0800] ：第四项是记录请求的时间,格式为 [day/month/year:hour:minute:second zone], 最后的
+0800表示服务器所处的时区为东八区 - “GET /query/trendxml/district/todayreturn/month/2009-12-14/2010-12-09/haizhu_tianhe.xml HTTP/1.1”：这一项整个记录中最有用的信息,首先,它告诉我们的服务器收到的是一个 GET 请求,其次,是客户端请求的资源路径,第三,客户端使用的协议时
HTTP/1.1, 整个格式为"%m %U%q %H",即"请求方法/访问路径/协议" - 200 ：这是一个状态码,由服务器端发送回客户端,它告诉我们客户端的请求是否成功,或者是重定向,或者是碰到了什么样的错误,这项值为 200，表示服务器已经成功的响应了客户端的请求,一般来说,这项值以 2 开头的表示请求成功,以 3 开头的表示重定向,以 4 开头的标示客户端存在某些的错误,以 5 开头的标示服务器端存在某些错误,详细的可以参见 HTTP specification (RFC2616 section 10)
http://www.w3.org/Protocols/rfc2616/rfc2616.txt - 1933 ：这项表示服务器向客户端发送了多少的字节,在日志分析统计的时侯,把这些字节加起来就可以得知服务器在某点时间内总的发送数据量是多少。
- -：HTTP Referer：告诉服务器我是从哪个页面链接过来的,没有值时可能是直接打开网页的原因。
- “Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)”： user-agent 这项主要记录客户端的浏览器信息
二、入侵日志分析
2.1 网站被入侵，分析解决思路:
- 下载日志分析
- 找到攻击者的 IP 地址
- 攻击者是如何找到网站后台的？
- 攻击者如何进入后台？
- 攻击者修改了什么文件来写一句话？
- 攻击者通过一句话后门做了什么？
2.1.1 下载日志分析 access.log+error.log
可以看到是两个黑嫲嫲的日志，看起来不太方便，我们可以使用工具【apache log viewer】看。
世界就变成彩色的了，还有过滤功能，很方便。
2.1.2 找到攻击者的 IP 地址
因为一般来说，如果不能一下子找到后台的话，就需要用一些目录爆破工具，而爆破的过程中，因为请求了很多不存在的目录，就会出现很多 404 状态的日志。
我们可以看一下报错状态的记录，点击【status】，就能发现了有几个 IP 的请求出现了404。
再往下拉，可以发现很明显的带有 payload 的恶意请求，它们都来自 IP【219.239.105.18】，说明这个 IP 地址就是攻击者的地址。
2.1.3 攻击者是如何找到网站后台的？
复制这个 IP 地址。
放到过滤器里，使用包括【include】的方式，然后应用该过滤【Apply Filter】
过滤出来的数据，点击【Date】按递增时间排序，就可以看到第一条记录是【2016/8/9 2:54:12】，即是攻击者第一次访问时间。
往下看，可以看到出现大量 404 的访问记录，说明是在爆目录。
到了【2016/8/9 22:17:02】之后明显没有 404 访问记录，说明已经停止了爆目录，并且可以看到攻击者开始访问后台了。
2.1.4 攻击者如何进入后台？
从【2016/8/9 22:37:30】开始可以看到大量的 POST 请求，几秒之内就有多个请求，说明这是在进行爆破。
而在【2016/8/9 23:02:28】从【http://192.168.0.104/phpcms/index.php?m=admin&c=index&a=public_current_pos&menuid=10】这一条开始，请求的内容都是后台界面才有的，可见攻击者成功爆破出密码并登录后台。
2.1.5 攻击者修改了什么文件来写一句话？
我们可以看到最后这一句
GET /index.php?%20%20m=search&c=index&a=public_get_suggest_keyword&url=asdf&q=…/…/phpsso_server/caches/configs/database.php HTTP/1.1
通过搜索相关资料
http://blog.csdn.net/god_7z1/article/details/7816389
可以知道该漏洞的利用方法如下：
这一部分即是攻击者在修改的时候发起的请求：
2.1.6攻击者通过一句话后门做了什么？
可以看到读取了数据库的帐号密码和系统的帐号密码。
三、通过 SQL 注入日志分析
3.1 sql 入侵了，你现在需要做的是
- 下载日志分析
- 攻击者使用的方法属于 sql 注入中的什么方法?
- 攻击者从什么时候开始用脚本跑数据的？
- 攻击者的 payload 格式是怎样的，解译一下
- 攻击者拿到了什么数据？数据内容是什么？
3.1.1下载日志文件之后，发现是都是类似的请求
3.1.2 攻击者使用的方法属于 sql 注入中的什么方法?
GET /?id=1%27%20and%20ascii(substr((select%20database()),1,1))%3E104%23 HTTP/1.1
很明显是通过盲注的形式跑数据的。使用盲注的脚本可以参考：
https://github.com/yuesecurity/sqli-exploit/blob/master/sqliblind/sqlibaseblind.py
3.1.3攻击者从什么时候开始用脚本跑数据的？
从【2017/9/2 12:20:42】开始短时间内发起大量请求。
3.1.4攻击者的 payload 格式是怎样的，解译一下。
payload 为
/?id=1%27%20and%20ascii(substr((select%20database()),1,1))=114%23】
其中读取 database()，然后 substr 选择。
选择出来的数据用 ascii 编码，与后面的数字 114 比较。
3.1.5攻击者拿到了什么数据？数据内容是什么？
拿到 database() 和 user()。
仔细观察，可以发现是后面的 1 去比较这个 database() 的 1 到 15 位。然后再用 2 去比较 1 到 15 位。
而判断是否匹配的方法是看返回的包的大小：
【654】包的数量比【665】的多很多，【665】的包是盲注匹配成功时候返回的包。
于是把【665】的包里的数值一个个写到表格里，用 http://evilcos.me/lab/xssor/ 转成对应的字符。当然我比较懒，这里没有填完。
还是用脚本跑一下比较爽：
可以看到 database 是【security】，user 是【flag0isfjisas8hh@loc】。