CTF 流量分析

Wireshark

主窗口

注意，数据包详情面板中展示的信息是经过 Wireshark 解析并”格式化”过的，方便阅读。最下面的数据包字节面板里才是这个包的真实数据。

过滤器栏

在主窗口的过滤器栏中输入过滤指令来筛选数据。

常用过滤指令

• ip 地址筛选
  • ip.addr == x.x.x.x 筛选 ip 地址为 x.x.x.x 的（包括源 ip 地址与目标 ip 地址）
  • ip.src eq x.x.x.x 筛选源 ip 地址为 x.x.x.x 的（eq 即 ==）
  • ip.dst ne x.x.x.x 筛选目标 ip 地址不是 x.x.x.x 的（ne 即 !=）
• mac 地址筛选
  • eth.addr == x:x:x 筛选 mac 地址（包括源地址与目标地址）
  • eth.src == x:x:x 筛选源 mac 地址
  • eth.dst == x:x:x 筛选目标 mac 地址
• 协议筛选
  • tcp / udp / http / ftp / ftp-data / icmp / dns / 等等协议
  • 注意，ftp 与 ftp-data 分别代表 ftp 命令流与 ftp 文件数据流，二者是分开的
  • 注意，筛选底层协议会包含上层协议，比如筛选 tcp 流量包，也会把 http、ftp、ftp-data 等基于 tcp 协议的流量筛选出来。
  • 注意，我发现一个问题。比如说如果一个 http 包太大，被拆分成3个包。那么在包列表面板中，前两个包可能只被识别为 tcp 流量包，只有最后一个包才被识别为 http 流量包。啊不，甚至可能出现所有拆分包都只能被识别为 tcp 流量的情况。好自为之吧 🙏
• 端口筛选
  • tcp.dstport == 80 筛选 tcp 协议的目标端口为 80 的流量包
  • tcp.srcport == 80 筛选 tcp 协议的源端口为 80 的流量包
  • udp.dstport == 1024 筛选 udp 协议的目标端口为 1024 的流量包
• 包长度筛选
  • frame.len >= 1024 筛选大于等于 1024 字节的帧（一整条流量包）
  • tcp.len >= 20 筛选大于等于 20 字节的 tcp 流量包
  • ip.len == 20 筛选㩐于 20 个字节的 ip 包
• 内容筛选 contains
  • tcp contains flag 筛选内容包含字符串 “flag” 的 tcp 流量包（包括 http、ftp）
  • http contains “reply=4” 筛选内容包含字符串 “reply=4” 的 http 流量包
  • ftp-data contains “zip” 筛选内容包含字符串 “zip” 的 ftp 数据流包
  • 注意，后面的字符串如果包含非英文字符，必须使用双引号包裹起来
  • 注意，contains 对字符串是大小写敏感的
• 内容匹配 matches
  • http.request.uri matches “login$” 筛选请求地址以 “login” 为结尾的 http 流量包（$ 在正则匹配中代表结束符）
  • http.user_agent matches “chROme” 筛选 http 浏览器字段中任意位置包含 chrome 的流量包，且对 chrome 大小写不敏感
  • 注意，matches 后面跟的字符串是正则表达式，且默认是大小写不敏感的。
• http 筛选
  • http.request.method == GET 筛选 http 的 GET 请求包（因为 “GET” 字符串不包非英文字符 ，可不加双引号）
  • http.host contains baidu 筛选目标域名包含 “baidu” 的请求包
  • http.request.uri == “/index.php” 筛选 http 请求地址为 “/index.php” 的流量包（因为字符串中有斜杠，需要用双引号包裹）
  • http.request.uri contains eval 筛选 http 请求地址中包含 evel 字符串的流量包
  • 注意，uri 不包含目标域名
  • http.respnose.code == 404 筛选 http 响应为 404 的流量包

组合过滤指令

可以通过 and, &&, or, ||, not, ! 来组合使用过滤指令。

• ip.dst==52.69.16.17 and http 筛选目标 ip 为 52.69.16.17 的 http 流量包
• tcp.stream eq 7 && http 筛选 tcp 数据流 7（或者理解成会话 7）中的 http 数据包

过滤器函数

upper(string-field) 将字符串字段转换成大写（http.user_agent 就是字符串字段，ip.addr、http 就不是）

lower(string-field) 将字符串字段转换成小写

len(field) 计算字节长度（可以是字符串字段，也可以是字节字段）

string(field) 将非字符串字段转换成字符串字段

举几个例子：

• upper(http.user_agent) contains “CHROME” 将 http.user_agent 转换成大写后使用 contains 筛选
• lower(http.user_agent) contains “chrome” 将 http.user_agent 转换成小写后使用 contains 筛选
• string(ip.addr) contains “25.128” 将 ip.addr 转换成字符串后再使用 contains 筛选

添加自定义过滤器

点击过滤器栏右边末尾的加号 ➕ 即可添加自定义的过滤器按钮，方便后续过滤操作。

数据搜索

在 Wireshark 主界面按下 「ctrl + F」键即可进行关键字搜索。

如果在使用过滤器之后再搜索，那么搜索就会只针对过滤器筛选出来的数据包。

搜索功能支持字符串搜索、十六进制搜索、正则匹配。通常使用字符串搜索即可。

要注意最左边的搜索“位置”，选择是要在分组详情里搜索，还是在分组列表里搜索，或者是在分组字节流里搜索。

最常用的是在「分组详情」里搜索「字符串」。

信息统计

统计协议分级信息

菜单 – Statistics – Protocol Hierarchy

可以用来快速判断这个捕捉文件中使用最多的是什么协议。大概可以判断这题目主要考什么

另外有一个小技巧。如果你想过滤某种协议，但又不知道他的过滤器指令是啥。

那么就可以在协议分级窗口中，右键点击想要过滤的协议，选择”作为过滤器应用 – 选中”。它就会自动添加到过滤器栏中了。😁

统计会话

菜单 – Statistics – Conversations

显示节点之间的会话信息。

统计节点

菜单 – Statistics – Endpoints

显示该捕捉文件中有哪些节点（或者叫端点吧 🤷‍♂️ ）。

数据流追踪

在数据包列表面板，右键点击一条想要追踪的数据包，选择 “追踪流 – TCP 流”。就会弹出一个新窗口，列出了跟该数据包上下文相关的所有数据流。

我个人理解，这个追踪 tcp 流的子窗口中，列出的是同一个 tcp 会话中的所有 http 请求/响应数据。

红色的代表请求数据包，蓝色代表响应数据包。

可以通过右下角的 “流 [n]” 按钮来切换 tcp 流（可以认为是切换另一个 tcp 会话）。

如果你之前在右键菜单中选择的是 “追踪流 – HTTP 流”，那么就不会有这个切换 “流 [n]” 的按钮，不如直接追踪 tcp 流方便。

一个强烈建议！在追踪数据流的时候，不要使用全屏窗口。因为你在追踪流的子窗口中点击一个数据包，主窗口的数据包列表也会跳转到相应的那一行。查看数据会方便很多。

数据导出

导出过滤后的数据包

有时候给我们的捕捉文件中包含太多数据包，我们只想专注于使用过滤器筛选出来数据包。

使用菜单栏中的 “文件 – 导出特定分组” 来导出筛选出来的数据包，并另存为一个新的捕获文件。

导出自动识别的文件

菜单栏 “文件 – 导出对象 – HTTP”，可以直接导出 Wireshark 从数据流中自动识别到的文件。（为什么不能识别 ftp 流中的文件呀？ =。=）

导出分组字节流

在包详情面板的某个包的某一层协议上右键”导出分组字节流”，可以很方便的将包中的二进制数据导出。

如下图所示，在 http 协议再上一层的 Media Type 上点击右键，就可以导出该 http 流中包含的业务数据（这里是一个zip包）。

但是要注意如果传输文件过大的话，数据可能会被切分成多个数据包分组传输，这样的话就需要自己把每个分组导出再整合成一个文件。

文件提取（binwalk / foremost）

通过 Wireshark 导出来的二进制文件，你可能不知道它是什么类型，或者这个二进制文件包含文件隐写（文件套文件）。

那么这时候就需要使用文件提取工具 binwalk 或者 foremost，来帮忙检查该二进制文件中包含什么类型的文件并提取出来。

• binwalk x.bin 分析二进制文件
• binwalk -e x.bin 提取文件
• foremost x.bin 提取文件

另外，我也不清楚为什么，有的题目的 ftp-data 无法通过 “导出分组字节流” 导出正确的文件，这个时候，甚至可以先通过 binwalk x.pcapng 检查一遍捕获文件，直接使用 binwalk -e 从捕获文件中导出需要的文件来。

解密 https 流量

由于 https 是加密过的，直接用 Wireshark 打开在包列表面板中能看到的只有 tcp 与 tls 数据包。

如果没有服务器的私钥，是无法解密出 http 明文的。这种题通常要先想办法获得私钥。（比如说可能隐藏在 ftp-data 流中）

假设已经获得了服务器私钥文件：server.key.insecure。

使用 wireshark 导入服务器私钥：编辑 – 首选项 – Protocols – SSL 或 TLS – RSA keys list 点击 edit 然后添加。

列表中各字段的含义为：

• 服务器 ip 地址（写 any 即可）。
• https 端口（ 默认是 443，当然也有可能有些网站会使用 1443、8080 等其它端口）。
• 表示 tls/ssl 里加密的是什么协议，对于 https，这项应该填 http。
• <key_file_name> 服务器密钥文件，文件里的私钥必须是明文（没有密码保护的）。

导入证书后，重新加载数据包。即可在 tls 流中解密出 http 流了。在过滤器栏中也可以直接使用 http 指令筛选出 http 数据包了。

例题

例题1 内容提取（01.pcapng）

01.pcapng

1. 在过滤器栏输入 ftp-data，发现它下载了一个 key.zip 文件！

   

2. 在该数据包的详情面板中，选择该数据包的最上层协议 FTP Data，然后右键选择 “导出分组字节流”，另存为 1.zip 文件。

   （这题其实可以直接对 .pcapng 文件使用 binwalk -e 命令进行拆解，也能直接提取出 .zip 文件。）

   

3. 尝试解压该 1.zip，却发现需要密码。
4. 追踪 tcp 流，发现在流 [0] 中，可以看到用户的 ftp 指令流。其中包括 ftp 密码。尝试使用该密码解压 1.zip 文件。Bingo！✌️

   

例题2 https 解密（TheGreatEscape.pcapng）

TheGreatEscape.pcapng

1. 虽然这里面都是加密的 https 数据流，但发现有一个 ftp-data 数据包，里面涉及到 key 文件，尝试把它导出。

   

2. 在这个 ftp-data 数据包的详情面板右键点击 “导出分组字节流”。另存为 ssc.key。

   

3. 在 Wireshark 的首选项中导入该私钥文件，然后重新加载 pcapng。

   在过滤器栏中输入 http contains FLAG，然后选择任一个 http 包进行追踪流，就会发现 flag。

   

例题3 内容提取（666666.pcapng）

666666.pcapng

1. 先在过滤器中使用 http 指令，筛选出 http 数据包。
2. 追踪 tcp 流，发现在 流[9] 中有疑似数据。似乎它要通过 /upload/1.php 来打开某个文件，结果返回了一串二进制数据以及 “you need passwd”。

   

3. 我们尝试拿 base64 解码一下它 POST 过去的数据，看看它到底是执行了什么指令。

   

   可以看出，它是打印了 z1 参数代表的这个文件。（同时在打印有效数据前后加上了 >| 与 |< 这两个字符串）

   再拿 base64 解码 z1 参数，发现就是 hello.zip。

   所以这个 POST 请求，就是想打印出 hello.zip 文件内容。

4. 针对这个 POST 请求的响应数据包，导出分组字节流为 666.zip 文件。
5. 尝试解压 666.zip 文件，但 zip 文件是加密过的，所以需要去找解密信息。

   （可能有的解压缩软件会报文件错误。因为我们直接导出 666.zip 的时候，没有去掉头尾无效的 >| 与 |< 这两个数据块。所有要么换一个牛逼点的解压软件；要么导出之前先删除这两个数据块；要么就用 binwalk -e 666.zip 重新提取一次 666.zip。）

6. 接下来就是要去找到解压密码，这应该也藏在数据流中。

   在追踪流窗口中切换流 [n]，到流 [7] 的时候会发现它卡了一会儿。大概扫了一眼会看到它是先上传了一些东西，然后再 ls 出当前目录。ls 出来的结果中有一个角 6666.jpg 的文件挺可疑的。再看它上传的那个 http POST 数据包，有一个 z2 参数明显就是一张图片（因为 jpg 的文件头就是 FFD8）。所以尝试将该参数导出。

   

7. 在包详情面板，右键该 http 数据包的 z2 参数，选择 “copy as Printable Text”。然后再使用二进制工具，比如 winhex，将这一串代表 16 进制的字符串另存为二进制文件。这里我们把它另存为 666.jpg。

   

   

8. 打开 666.jpg，发现密码。

   

9. 使用该密码解压之前得到的 zip 文件，即可得到 flag。

例题4 复杂流量分析（安恒8月应急响应题目）

题目

某公司内网网络被黑客渗透，简单了解，黑客首先攻击了一台 web 服务器，破解了后台账户密码，随之利用破解的密码登录了 mail 系统，然后获取了 vpn 的申请方法，登录 vpn，在内网 pwn 掉了一台打印机，请根据提供的流量包回答下面有关问题。
流量包文件：https://pan.baidu.com/s/13SoD6xB7YBiqpUDCIcb8mg

1、给出黑客使用的扫描器
2、得到黑客扫描到的登陆后台是(相对路径即可) /admin/login.php
3、得到黑客使用了什么账号密码登陆了web后台(形式:username/password)
4、得到黑客上传的webshell文件名是什么，内容是什么,提交webshell内容的base编码
5、黑客在robots.txt中找到的flag是什么
6、黑客找到的数据库密码是多少
7、黑客在数据库中找到的hash_code是什么
8、黑客破解了账号ijnu@test.com得到的密码是什么
9、被黑客攻击的web服务器，网卡配置是是什么，提交网卡内网ip
10、黑客使用了什么账号登陆了mail系统（形式: username/password）
11、黑客获得的vpn,ip是多少

Writeup 1 给出黑客使用的扫描器

首先介绍一下扫描器，专业术语应该叫做“漏洞扫描软件”。

要区分漏洞扫描与代码审计啊。我的理解是，漏洞扫描是利用已知的漏洞库（常见的 web 框架漏洞、SQL 注入测试、代码泄漏测试）针对远程的 web 服务器发起 http 访问请求，测试是否存在该漏洞。代码审计则是利用漏洞库以及编码安全规范（高危函数）对已有的服务端代码进行审查。

常见的漏洞扫描工具有：AWVS、BugScan、AppScan 等等。

1. 由于捕获文件实在太大了，可以先通过过滤器 http.request 过滤出所有 http 请求包。（因为题目问的是黑客使用什么扫描器，扫描器是发起请求的一方，所以如果有信息，必定是在 http 请求包中的。）
2. 然后使用 「ctl + F」筛选出来的 http 请求包进行关键字搜索。要搜什么关键字只能说是看经验了 =。 =# 比如说搜索几个常见漏洞扫描工具的厂牌。

   

3. 这个 Acunetix 就是 AWVS 的厂家了。

答案：AWVS

Writeup 2 得到黑客扫描到的登陆后台是

1. 首先网站登录肯定是使用 POST 方法。所以过滤指令是 http.request.method == POST。
2. 过滤后立马就能看到后台登陆地址 /admin/login.php。

   

答案：/admin/login.php

Writeup 3 得到黑客使用了什么账号密码登陆了web后台

1. 接着第 2 题往下走，既然已经知道了后台登录地址。那么我们先尝试使用 http.request.uri contains "login.php" 进行过滤。

   

2. 可以看到，筛选出来有几千条访问 login.php 的记录，这肯定是黑客在暴利破解后台登录密码。

   再认真看一下这个筛选结果，发现只有一开始的 [86] 和 [490] 两条流量包，他们的源 ip 地址是 94.233，而后面几千个请求的源 ip 地址则都是 94.59。所以这两个请求可能有所不同，它可能不是黑客而是正常的合法用户。我们来看一下这两个包的详情信息，看着更像一个正常用户了，但不是管理员帐号。

   

3. 接着随便对这两个包选一个进行追踪 tcp 流。可以看到它的响应是 302 临时重定向。

   

   这里放上 mozilla.org 对 302 状态码的解释：

   

   简单来说，就是这个登录地址是对的，帐号密码也是对的，登录成功之后被重定向到了 /admin/index.php 这个管理员首页。

4. 但是”人事”这个帐号明显不是管理员帐号，我们又没那么多时间去追踪剩下的几千条访问记录。怎么办呢？

   我们可以从这个登录成功后的重定向出发，反向追踪看看有没有其他帐号成功登录过后台。因为不管暴利破解的过程中有多少条错误尝试记录，最终成功的那一次，服务器肯定也是返回了 302 重定向。

   那么我们需要先把所有 302 重定向到管理员首页的 http 响应包筛选出来。

   这个过滤指令就是: http.response.code == 302 && http contains "/admin/index.php"

   

   很明显可以看出，包 [89] 和包 [493] 就是上面那两个 “人事” 帐号登录的。而后面这两条 [728915] 与 [733519]，客户端 ip 地址是 192.168.94.59 的，这可能就是黑客登录的。

5. 选中包 [728915]，进行追踪 tcp 流。因为追踪流窗口显示的信息是连在一起的看着不清晰。所以可以在追踪流窗口中点击红色所代表的请求包，然后在主窗口的包详情面板中，就能看到这个黑客发起的登录请求啦！😎

   

6. 所以，这一题的答案就是 admin / admin!@#pass123。另外，这个 192.168.94.59 就是黑客的 ip。

答案：admin / admin!@#pass123

Writeup 4 得到黑客上传的webshell文件名是什么，内容是什么，提交webshell内容的base编码

1. 从上面我们已经看到这个网站应该是 php 网站，那么 php webshell 的关键字就是 eval。那么使用过滤指令：

   ip.src == 192.168.94.59 && http contains "eval"

2. 然后我们看到筛选出来好多 /image/article/a.php 的访问请求，看一下它的包详情，妥妥的一句话木马。

   

3. 但是这题除了要找到 webshell 的文件名，即 /image/article/a.php。

   还要我们找 webshell 的代码内容。在上图中我们找到的只是它的用法。

   （网上找到的这题答案几乎都是根据这个用法盲猜出它的源码。这。。。只能说选手们经验丰富 🐮 。我们还是一步一步来看看怎么反查出源码吧）

4. 那么我们就需要找到黑客是在哪里上传了这个 a.php 文件。我首先想到的是 ip.src == 192.168.94.59 && http contains "a.php" && http.request.method == POST，因为上传文件，肯定是用 POST 方法。但很不幸过滤出来的还是只有调用 webshell 的记录。

   

5. 最傻的方法就是在黑客第一次调用 a.php 的流量包上选择追踪 tcp 流，然后再一个个往上翻。因为他在调用这个 webshell 之前必须先上传。最后在 tcp 流 [71859] 中找到疑似的上传记录。

   

   但是它这个流为什么会变成这样，在包列表面板中只被识别为 tcp 而不是 http。而且上图中上传的文件名明明是 1.php，后面调用的时候怎么又变成了 a.php？我也不清楚。🤷‍♂️

   （找到网上一位同学的解释，《一次网络流量分析引发的思考》。这里应该是丢包了，有数据没捕获到。）

答案：webshell 文件名是 a.php，
内容是 ，
内容的 base64 编码是 PD9waHAgQGV2YWwoJF9QT1NUWzEyMzRdKTs/Pg==

Writeup 5 黑客在robots.txt中找到的flag是什么

1. 送分题，直接过滤 ip.src == 192.168.94.59 && http contains "robots.txt"，然后追踪 http 流既可以看到。

   

答案：87b7cb79481f317bde90c116cf36084b

Writeup 6 黑客找到的数据库密码是多少

1. 这题要从黑客角度出发，上传 webshell 之后要怎么找出数据库密码呢？

   数据库的密码肯定写在网站的某个配置文件中，所以只要在 webshell 中 more 或者 cat 该文件即可。然后服务器会返回这个数据库配置文件的内容，凭借个人开发经验猜测，配置文件中密码的变量名肯定跟 pass、passwd、password 这几个词有关，另外文件中应该也会有 database 这个关键字。

2. 使用过滤指令：ip.dst == 192.168.94.59 && http contains pass。

   但是这个指令筛选出来的还是有很多条数据，有一个小花招就是，你可以直接看最后一条数据包。因为黑客如果成功拿到想要的信息了，后面就不会再进行类似尝试了，所以最后一条数据有很大可能就是黑客成功的那一条。

   

   或者，就是再增加过滤精度，比如加上 http contains "databse"。

3. 注意，我后来想起来，这题其实就更应该用 matches 而不是 contains，因为 matches 是大小写不敏感的，配置文件中的变量名可能包含大小写。

答案：e667jUPvJjXHvEUv

Writeup 7 黑客在数据库中找到的hash_code是什么

1. 这题应该使用到 webtwo.pcap 捕获文件。里面有大量的 mysql 数据流。
2. 首先直接先过滤一下：mysql contains "hash_code"。发现在数据包 [17] 中，有一条去数据库中查找 hash_code 值的语句。那么其一定在这个请求包的响应中了。

   

3. 尝试对这一条数据包使用追踪 tcp 流。Wireshark 对 mysql 数据流的解析不大行的样子，几条数据包都糊在一起了。

   

4. 在上图的追踪流中发现一串长度位32的字符串，疑似哈希码。点击这一串字符，发现主窗口的包列表跳转到了数据包 [18]。

   

   从数据包列表中很容易看出来，包 [18] 正是对包 [17] 这个查询请求的响应。

   展开包 [18] 的详情，发现返回了5个 mysql 协议的数据。其中1，2，3，5应该都是 mysql 的系统信息。只有4这一行看着像是正经数据。

   所以，猜测 SELECT value FROM dou_config WHERE name = 'hash_code' 这个查询请求，返回的值应该就是 d1c029893df40cb0f47bcf8f1c3c17ac。

答案：d1c029893df40cb0f47bcf8f1c3c17ac

Writeup 8 黑客破解了账号ijnu@test.com得到的密码是什么

1. 直接对 webtwo.pcap 文件过滤：mysql contains "ijnu@test.com"，得到如下包列表。

   

2. 看一下包的详情，发现里面就是 mysql 返回的用户信息列表。按「ctrl + F」搜索 ijnu 关键字，找到该帐号。

   b78f5aa6e1606f07def6e839121a22ec 这一串应该就是该帐号的密码，当然这是加密过的。

   大多数防御意识薄弱的网站，只会对用户密码明文进行 md5 计算后当作密文来用。而且这一串数字长度正好是32，很像 md5 哈希值。

   所以尝试找一个 md5 破解网站 https://www.somd5.com/，对该值进行破解。

   得到用户密码的明文：edc123!@#。

3. 延伸一下，如果这题再难一点点 🤏 ，网站对用户密码的加密方式是 password_value = md5(password_str + salt)，那么我们就还得去找出这个 salt 值。

   简单的 salt 有两种，一种是所有用户统一 salt，那么多看几个用户密码的明文就能看出来这个 salt 值是多少了。另一种是使用用户名当作 salt，也是一眼能看出来的。

答案：edc123!@#

Writeup 9 被黑客攻击的web服务器，网卡配置是是什么，提交网卡内网ip

1. 其实这题都不用额外查询，从上一题 mysql 的流量就能看出。

   黑客攻下 web 服务器后，肯定是直接从 web 服务器上对 msyql 服务器发起链接。

   webtwo.pcap 流量捕获包里，使用的都是内网地址。

   其中 mysql 请求方，肯定就是被攻陷的 web 服务器。所以其内网地址是：10.3.3.100。

2. 如果要正经解题，那么得从黑客的思维角度出发。

   当黑客从互联网上获取 web 服务器的 webshell 之后，如果想查看它的物理地址。应该会通过 webshell 使用 eval(system('ifconfig -a')); 指令，这时候服务器就会通过 http 响应返回物理地址。那么其中的关键字就会包括 eth0 对吧。

   这一系列动作是发生在互联网上的，所以应该找的是 webone.pcap 这个流量捕获文件。

   所以直接使用过滤指令：ip.src == 192.168.32.189 && http contains "eth0"，得到如下结果。

   

   题外话，有人说凭什么断定它返回的数据里肯定有 eth0？如果操作系统是 AIX 或者 Windows 呢？这两个系统上使用 ifconfig / ipconfig 命令返回的数据中未必会有 eth0 关键字呀。首先，这是凭经验猜测它的 web 服务器是 Linux。再者，其实做上面几个小题的时候，如果你足够细心或者有经验，就能在追踪流里看到，这台 web 服务器的操作系统是 centOS。

答案：10.3.3.100

Writeup 10 黑客使用了什么账号登陆了mail系统

大哥你这个流量捕获文件也太大了吧 =。=#

1. 载入 mailtwo.pcap 捕获文件，首先看到数据包 [3] 有一个 logout 的动作。先尝试追踪一下这个包的 tcp 流。

   

   可以发现这位叫做 wenwenni 的同学，在退出之后，又重新登录了。

   登录的请求地址是 /webmail/index.php?module=view&action=login&mode=browser 。

   （PS：我有一点不解的是，他这次请求中并没有夹带密码信息啊，只有 cookie 中的 PHPSESSID 与 login_name。那么可能是用 cookie 登录的。但是他上次不是退出登录了嘛！帐号退出不是要清 cookie 跟 session 嘛！他怎么还有有效 cookie！所以我怀疑他这次登录其实使用的是客户端 ssl 证书登录，因为可以看到登录页面的源代码中包含 “ssl login” 的代码。）

   之后服务器返回的 {"success": true} 这句话似乎代表登录成功了。

   登录成功之后的下一跳地址应该是 /webmail/index.php?module=view&action=index&mode=welcome。

   另外，在追踪流中还会发现登录页面的源码泄漏了密码的前端加密逻辑。采用 AES-CBC 加密模式，填充为 ZeroPadding，偏移量为 1234567812345678，加密用的密码为小写的 md5('1234567812345678')。

   

2. 既然确定了登录请求的地址，那么使用过滤指令：http.request.method == POST && http.request.uri contains "login"。可以看到有好多条尝试登录的数据包，估计都是在暴力破解。

   即使再加上 http contains "username=admin"，也有一百多条登录尝试记录。（这里有一点要注意，虽然在包详情面板中 HTML 表单数据被格式化成了 "username" = "admin"，但在 http 数据包中实际上是没有这个引号与空格的，这点可以在最底下的包字节面板中求证。所以要想过滤这一个表单数据，必须得用 http contains "username=admin" ）

   

   通过追踪 tcp 流，可以看出这些个登录请求都是登录失败了。在追踪流窗口中也搜索不到 success 关键字。

   

3. 因为这题还有第二个捕获文件 mailtwo1.pcap，加载该文件。同样的使用过滤指令 http.request.method == POST && http.request.uri contains "login" && http contains "username=admin"。

   

4. 万幸这里只有四条数据包了（包 [17194] 看起来像是 包[17126] 的重传）。选择最后的一条数据包进行追踪 tcp 流，也能在追踪流中搜索到 success 关键字了。（这个追踪流其实有点问题，感觉请求与响应顺序不大对的上。它自己也说了有数据丢失。。。但是管不了了，既然有 success 关键字了，就当它是对的吧）

   

5. 所以得到密码前端加密后的密文：+ZgE14UGcFcyRGLI0/ZXPQ==。然后根据之前泄漏的前端加密逻辑进行解密，找一个在线的 AES 解密网站http://tool.chacuo.net/cryptaes。（这里注意，它在前端 AES 加密用到的 key 是小写的md5）

   

答案：admin/admin!@#pass123

Writeup 11 黑客获得的vpn,ip是多少

1. 这题可以无脑做，直接使用 Wireshark 的节点统计功能。

   vpnone.pcap 文件里都是外网 ip，其中数据包最多的是 192.168.32.131（估计就是 vpn 服务器的外网地址），第二的是 192.168.94.59（上面的题目已经发现这个是黑客的 ip 了）。

   vpntwo.pcap 文件里都是内网 ip，其中数据包最多的是 10.3.4.3（估计就是黑客获得的 vpn 地址了）。

   所以提交这几个地址试一下就知道正确答案了。😊

   

   

2. 这题的正经解法呢，首先需要知道 vpn 的逻辑。（要理解 vpn 与 proxy 的区别，现在常用的”科学上网”软件我觉得应该属于 proxy）

   黑客先从外网使用某种 vpn 协议连接到一台边界服务器上（既有内网地址又有外网地址）。

   建立 vpn 连接的过程，可以理解成 vpn 客户端以 vpn 服务器为路由器，申请分配一个内网 ip 地址（当然也可以使用事前协商好的固定地址）。

   然后 vpn 客户端就可以作为“内网节点”加入到内网中啦。

3. 建立 vpn 连接，协商 vpn 客户端 ip 地址的过程，是在外网上进行的。所以应该看的是 vpnone.pcap 文件。

   使用 Wireshark 统计协议分级的功能。发现黑客使用的是 pptp 协议（好像是说 ppp 是 pptp 的底层协议，我没搞清楚 =。=）

   

4. 然后我查到的，ppp 协议协商 ip 地址的过程是 ppp ipcp 协议。右键选中”PPP IP Control Protocol”协议并过滤。

   

5. 然后可以在包列表面板中看到，最后 vpn 服务器给黑客分配了一个内网地址 10.3.4.3。

   

6. 关于 ppp ipcp 地址协商的原理，参考：https://blog.csdn.net/tushanpeipei/article/details/111225252

答案：10.3.4.3