欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

通过服务器日志溯源web应用攻击路径

来源:本站整理 作者:佚名 时间:2017-07-03 TAG: 我要投稿

无论是我们使用的个人计算机还是服务器都为我们提供了强大的日志记录功能。例如系统日志,可以为我们记录系统硬件、软件和系统问题的信息,用户可以通过它来检查错误发生的原因,或者寻找受到攻击时攻击者留下的痕迹。
而服务器日志,则主要包括访问日志和错误日志。访问日志记录了该服务器所有的请求的过程,主要记录的是客户的各项信息,如访问时间、内容、地址等。错误日志则记录服务器出错的细节等数据。同时,这些日志记录信息也为安全事件的取证分析提供了强有力的证据和溯源的渠道。
我们以Web服务器为例。最常见的Apache HTTP Server一般会为我们提供两个主要的日志文件 – access.log和error.log。access.log记录所有文件请求。如果访问者请求www.example.com/main.php,则日志文件中将添加以下条目。
88.54.124.17 - - [16/Apr/2016: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"
从以上日志可以看出,一个访问者在2016年4月16日的07:44分成功请求了main.php文件。
试想该访问者请求的不是一个普通文件,而是一个转储数据库的文件例如dump_database.php。如果没有日志文件,那么我们可能永远不会发现有人或许已经将我们的重要数据窃取了。
下面让我通过一个简单的示例来为大家演示下,如何通过一个日志文件溯源web应用的攻击者。
调查
我们假设我们运行的一个最新的WordPress站点受到了黑客的攻击,并且该站点运行在没有任何补丁问题的Ubuntu服务器上。

在接到任务后,为了防止系统及其当前的日志状态发生改变,以及阻止攻击者可能的远程访问和与其他机器的网络交互,我们的分析取证小组首先对服务器进行了“离线”操作。
注:按照正常流程我们需要创建一个当前系统的副本,但由于我们是以演示为目的故跳过该步骤的操作,我们将直接以原始数据为演示对象。
寻找蛛丝马迹
在调查取证之前,我们首先要知道哪些证据是我们所需要的。通常攻击者都会直接访问一些“隐藏”或特殊的文件,或需要身份验证的管理区域,远程执行代码,SQL注入,文件包含,跨站点脚本(XSS)等异常行为,这就表明有攻击者可能利用了漏扫工具或手工对我们的站点进行了探测。
这里我们假设我们的access.log日志文件保存完好并且可用。
root@secureserver:/var/log/apache2# less access.log
access.log往往是一个相当大的文件,通常包含了数千条的请求记录。
84.55.41.57 - - [16/Apr/2016: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/2016: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/2016: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/2016: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、JavaScript这类文件。
由于我们的演示站点为WordPress,所以我们可以通过筛选的方式找出所有具有WordPress特征的access.log记录。
root@secureserver:~#cat /var/log/apache2/access.log | grep -E "wp-admin|wp-login|POST /"
以上命令将过滤access.log,并只显示包含wp-admin的字符串的记录,wp-admin是WordPress的默认后台管理文件夹,wp-login则是WordPress(wp-login.php)登录文件的一部分。最后的POST将筛选出所有通过POST方法发送的HTTP请求,这些请求很可能是在提交登录表单。
筛选完成后以下的日志记录引起了我们的注意:
84.55.41.57 - - [17/Apr/2016: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我们继续筛选有关它的信息:
root@secureserver:~#cat /var/log/apache2/access.log | grep 84.55.41.57
我们得到了以下过滤内容:
84.55.41.57 - - [17/Apr/2016:06:57:24 +0100] "GET /wordpress/wp-login.php HTTP/1.1" 200 1568 "-"
84.55.41.57 - - [17/Apr/2016: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/2016:06:57:31 +0100] "GET /wordpress/wp-admin/ HTTP/1.1" 200 12905 "http://www.example.com/wordpress/wp-login.php"

[1] [2] [3]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载