一次网络流量分析引发的思考

阅读量    187815 | 评论 7   稿费 300

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

前言

闲来无事,做了做最近安恒8月比赛的流量包,发现有些题目给的分析不够详细。本着学习知识的心态,重新梳理下思路,稍加扩展,再谈谈个人对网络流量取证方面的一些见解。

 

题目分析

ps:这是详细的比赛题目和分析详见这个网站(此处建议详细看看,最好数据包自行下载分析一遍),下面介绍下题目背景,再挑出几道题目深度分析下。

题目背景

某公司内网网络被黑客渗透,黑客首先攻击了一台web服务器,破解了后台的账户的密码,随之利用破解的密码登录了mail系统,然后获取了vpn的申请方式,然后登录vpn,在内网pwn掉一台打印机。

题目线索总分析

根据题目背景,我们把握下总体脉络,顺着黑客的思路走一番:

首先,黑客攻击公司的一台web服务器。走的是以tcp为载体的http请求,所以过滤http数据分组,成为解题最基本的分析思路。

接着,黑客破解了后台的账户的密码,随之利用破解的密码登录了mail系统。通过这点,我们追踪http,发现更多的线索,比如黑客破解的是哪个账号的哪个密码、登录了mail系统后获取的vpn是什么等等内容。

最后,黑客获取了vpn的申请方式,然后登录vpn,在内网pwn掉一台打印机。至此,黑客登录了vpn,那么是否通过分析此时的流量推出黑客登录时所用的ip,亦或者其他信息呢?

至此,基本脉络分析完毕。当然,以上脉络在没有具体分析数据包前,都只是靠推测去模拟出黑客的种种行为,具体如何分析才是最值得深究的一块。这时,可能又会有人问到,黑客就一定按照你想的去做吗?请注意,凡事没有证据(流量包)之前,我们都不能确定事情的真相如何,分析前的推测更多地是指引我们可以从什么角度去分析,而不是说黑客按照我们怎么想的去怎么做。推测不一定都成立,同样,成立的不一定是推测,推测更多的是给我们一个取证的方向。这也正是数据包取证分析的有趣之处,处处悬疑,步步惊心,但真相出来之际,又有恍然大悟之感的喜悦之情。

迷之坑点

疯狂踩坑—tcp重传机制

某公司内网网络被黑客渗透,请分析流量,得到黑客上传的webshell文件名是,内容是什么,提交webshell内容的base编码

这个问题,比赛时,死活找不到答案,但是在浏览webone.pcap数据包的末尾,发现a.php里面有1234为传递值,自己构造了个一句话木马:<?php @eval($_POST[1234]);?>,然后base64提交完成的。

1535690664219

当然,得到了此题比赛的分数,但是,不是为了比赛而做题,而是通过以赛督学。比赛结束后,细细分析,上传shell需要提交POST的请求,于是httpPOST请求包浏览一遍,发现目录为/admin/article.php?rec=update的请求页面非常可疑,但是,却始终没有找到含有一句话木马的上传页面?怎么办呢?苦苦思想,咦,有没可能tcp这个载体漏传了,造成了包丢失?随后,过滤语句tcp contains "<?php @eval"一试,终于找到了正确答案,再试http contains "<?php @eval"依旧没找到,十有八九是丢包了,但这到底是为什么,还需进一步分析。

1535282630426

随后我追踪了下tcp流,发现了在http中没找到的一句话木马上传页面。

1535690893424

仔细分析了下这个tcp流的来往,我想我找到了真相。

1535690519402

首先,看看上图的733791序号分组,我们可以看到"TCP Previous segment not captured",提示“存在没有抓到的数据包”,也就是意味着:在当前包的捕获中,缺少了本应出现的某些包。紧接着733793序号分组,"Tcp Retransmission",提示“Tcp包重传”。很明显,存在了丢包,引发了TCP的重传机制。

1535693859074

随后我寻找了下tcp重传的相关文档rfc2001,该文档是描述TCP慢启动,避免拥塞,快速重传和快速恢复算法相关机制的文档。其中快速重传有这么一句描述

1535692779265

翻译下:“当收到一个出问题的分组,Tcp立即产生一个应答。这个相同的ack不会延迟。这个相同应答的意图是让对端知道一个分组被收到的时候出现问题,并且告诉它希望得到的序列号。”

那么接下来的733794序号分组,"Tcp Dup ACK 733789#1",这就代表着,继733789分组序列号后,提示重新传输因某些原因导致的丢包数据。于是,733801序号分组,开始重新传输这段数据。当然,我们可以通过每个分组后面的Seq值,验证是否是重传包。

比如:733794序号分组,此时的Seq值为1,Ack值为3606(与733789序列号相当);733801序号分组,此时的Seq值为3606Ack值为1len值为1460733802序号分组,此时的Seq值为1Ack值为5066733805序号分组SeqAck值刚好与此相反);通过验算,3606+1460=5066,至此,完全符合重传后每个包的SeqAck对应值。这样,我们成功了解决的了这题的疑问,上传的是文本内容为<?php @eval($_POST[1234]);?>1.php文件。

疯狂踩坑—社工?还是溯源?

10、黑客使用了什么账号登陆了mail系统(形式: username/password)

此题说来有趣,此题答案跟原关卡3答案相同,说解法是社工(我想跟大佬们学下怎么社工),但是对比了下,两个关卡中所用到的数据包给的源服务器ip并不一样。当然,管他白猫黑猫,抓到老鼠就是好猫,比赛时能做出来的确厉害。比赛完后的题目说了“利用破解的密码登录了mail系统”,好吧,这个我也勉强能够接受。以下的内容是根据请教三斤鱼大佬,赛后复现出来的,在此再次谢过。

这题需要看mailtwo.pcapmailtwo1.pcap两个数据包。

首先在mailtwo.pcap中过滤http,分组序号3Cookie中就发现 login_name=wenwenni字段,并且是action=logout1535267557510

继续观察数据包,发现分组序号28Get登录请求,再看看分组序号35的响应,猜测系统是通过验证cookies信息允许其免密登录,并在其中发现了输入密码后的加密函数:

1535268095509

取出来发现是AESCBC加密,填充格式为ZeroPadding,密钥为字符串1234567812345678hash值,偏移量为1234567812345678

var key_hash = CryptoJS.MD5('1234567812345678');
var key = CryptoJS.enc.Utf8.parse(key_hash);
var iv  = CryptoJS.enc.Utf8.parse('1234567812345678');
 form.password.value = CryptoJS.AES.encrypt(form.password.value, key, { iv: iv,mode:CryptoJS.mode.CBC,padding:CryptoJS.pad.ZeroPadding});

在下一分组序号42请求对应的分组序号45返回的响应报文中出现{"success":true},表示登陆成功。

1535268433463

既然如此,我们使用(http contains "{"success":true}" or http.request.method=="POST") and ip.addr==192.168.94.59过滤一下,显示出post请求及成功的返回结果,浏览一下发现是在爆破,并且到mailtwo.pcap的最后也未爆破成功。相同的过滤条件上在mailtwo1.pcap上试试,发现几条数据,从后往前看,发现分组序号18152是登陆成功的返回结果,那对应的分组序号17126则就是正确的加密后的密码。这里可能会有疑问,黑客不是能成功登录wenwenni用户嘛,为啥还要爆破admin用户?(⊙o⊙)…,说个实在话,那个时候我也有这个疑问,不过后面想想,咱们自己渗透的时候不也是习惯先注册一个账号登录玩玩嘛?

1535269130976

那么解密网址进行aes解密即可得到admin账号的密码。此题最终答案即为:admin/admin!@#PASS123

1535267206637

疯狂踩坑—vpn流量分析学习

11、某公司内网网络被黑客渗透,请分析流量,黑客获得的vpn,ip是多少

此题答案,额,也不知道算不算不难,额,比赛时,给的两个vpn的数据包,其中ip没几个,一个一个去试,也就出来答案了。下面讲讲自己的做法。

首先,放出个PPTP 理解以及报文的分析学习下先,磨刀不误砍柴工嘛。看懂数据包是分析流量包的第一步。打开vpn.one数据包,之前对vpn的数据包没啥研究,不过借此机会好好学习一番。按照正常的分析流程,wireshark三板斧分析一番。

1535701649090

可以发现GREUDPTCP中三者中,GRE在整个传输层所占比例最大。GREGeneric Routing Encapsulation,中文名为通用路由封装协议,是VPNVirtual Private Network)的第三层隧道协议。再看图分析,GRE封装着PPPPoint-to-Point Protocol点到点协议),相应的学习链接放置文章末尾(两个协议所在哪一层要先了解)。

1535702884388

其次我们再看看对话,可以清晰的发现,192.168.32.131是基本上每个对话都用到了,可以锁定这条ip地址。并且,我们还发现对话中,192.168.32.255192.168.94.59两个ip与192.168.32.131对话都很多,那么就很明显,忽略网关后,那就只剩192.168.94.59这个ip了。

在此分析过程中,我们会遇到其他的“干扰选项”,这些都需要自行筛选分析,比如上图的209.244.0.3192.168.32.131的对话就如下,一看就知道是无关信息咯。

1535703395820

知道可疑ip后,过滤下,过滤语句ip.addr == 192.168.94.59

1535703698549

过滤后,映入眼帘的pptp首个分组序号4527start-control-connection-reply ,这个消息是由PPTP服务器发出,回应start-controlconnection-request消息。那就有点奇怪了,这条消息是回应的,那请求的去哪了?不知道你是否发现分组序号4527前几个分组的消息,没错,正如你所想的,又发生了丢包情况。那我们往下滑,看看完整的分组。

1535704979291

很清晰,192.168.94.59192.168.32.131通过三次握手时,出现了分组序号4581start-control-connection-request ,这是由PPTP客户端发出,请求建立控制连接。PPTP隧道要求在发送任何其他PPTP消息之前,先建立一条控制连接。那么很好,可以确定,黑客此时的ip192.168.94.59

再回看题目,黑客获得的vpn,ip是多少?难道是这个?不,天真了。问的应该是分配vpnip。接着往下分析,发现了黑客登录vpn时失败的消息:Authentication failed

1535705605064

再往下翻翻,不久,你就会发现

1535705793769

黑客登录成功了,登录的用户名为xiangh,额,做到这里,其实我想知道vpn的密码,后面发现还是天真了,大佬们具体可以参照下CHAP验证中的密码问题。再接着,通过网站寻找资料学习了一波,发现文档rfc1332有以下描述:

1535706575546

又发现PPP协议其中有这么一段描述

1535707113943随后,翻翻数据包,找到了最终的答案,分组序号4953192.168.94.59192.168.32.131发送了一个请求,内容如下,可以发现全部为0.0.0.0

1535707460046

紧接着分组序号4954返回了一个期望的值(即规定给的vpn的ip)

1535707586841

再接下来的两个连续分组序号4955表示192.168.94.59再次询问能否以192.168.94.59刚刚发送的期望值,作为192.168.94.59的详细内容,分组序号4956表示接受这个请求。

此题到此分析完毕,最终答案就是10.3.4.3咯。

 

一些看法

之所以想谈谈这些看法,一是经常有人问流量分析有那么重要吗?每次分析出事情的真相又如何,都已经发生了,改变不了结果的;二是针对最近的某酒店用户信息重大泄露事件;

这个时代科技的风云聚变,我想每个人都有各自的感受,对于我而言,大一听到的网络安全,大二听到的人工智能,直到现在,以太坊、区块链等等。这些东西,之前不是没有,而是突然间变“火”了。对于网络安全而言,它的特点是革新的速度,这不单单是网络技术迅猛发展的护航需要,更是”道高一尺魔高一丈“的比拼。相对而言,网络流量的取证分析,好像都是”黑与白“之间较量后,才显露出的结果(这个结果往往是不好的)。其实不然,取证的目的就在于揭示那些”黑与白“较量之间的、有意义的、先前不为人知的、被人忽视的细节。网络取证看似亡羊补牢,但这又何尝不是还原每个事件真相的必要呢?只有知道那些真相的细节之处,才会促进网络安全的发展,提升网络安全的防护意识。

取证是一门艺术,“真的假不了,假的也真不了”。对于这些大大小小的安全事件而言,取证分析后,分析出造成不良结果的种种原因,或许让人觉得搞笑,亦或者震惊。但仔细想想,何尝不是给每个人敲响了警钟,让每个人多了点意识,每个团队学习了新的技术,每个“白帽子”心中的那份正义呢?

网络取证,流量分析,可能不是一项关于安全的技术,而是一项关于“不安全”的技术?你觉得呢?

 

文章相关资料学习链接:

对TCP重传的进一步认识

浅析GRE协议(通用路由封装协议)

GRE、PPTP、L2TP隧道协议

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多