2017 未解之谜：树莓派 Writeup（内附全部 Wp 链接） LCTF-长亭安全课堂
在刚刚结束的LCTF 2017中，仍有一些未解的题目，今天笔者就来和各位胖友分享第一道未解之谜—— Misc 类下的「树莓派」麻阳红网，Writeup 来自本次比赛主办方 L-Team 。
PS: 其它未解之谜见文末链接。
所有 Writeup 目前已发布，欢迎移步：LCTF 2017 官方Writeup0X01 刚上线
题目介绍只给了个 IP ，有师傅当做 Web 题，发现点不开。
扫了一波端口后，只有 22 开着，所以入口点肯定在这里。
根据题目的提示，按照正常的思维确实应该登录 `pi:raspberry` ，本来也是打算设置成这样，但是这个密码太弱了，题目还没上线就被黑铲扫了好几波，直接改密码种木马一波带走了。所以就改了一个需要一些脑洞的密码 `pi:shumeipai` ，可能有师傅在这里卡了一下。0X02 第一个hinthint1：都告诉你密码了
1. 这个 hint 主要提示弱密码是什么，因为不想让师傅们耽误太多时间，给出后很多师傅都上来了。
2. 这时候 SSH 进去会发现是一个低权限帐号，很多操作都受限了，`uname` 看内核版本也很高，这之后很多师傅就开始四处搜刮 `flag` ，`bash_history` 、`.swp` 等等，还看了所有文件的修改时间。
3. 但是一番搜索后除了那个假 flag 什么发现也没有张嘉蓉。在搜索的过程中，查看主机的网络状态`netstat -autpn`，会发现所有的 SSH 连接来源都是 `172.18.0.3` ，在这里应该会产生一些疑问，ping `172.18.0.1`、`172.18.0.3` 都是通的，pi 本机是 `172.18.0.2` 。
4. 这时候可以猜测陶驷驹，SSH连接被 `0.3` 动了手脚唐子义，通过 SSH 的指纹完全可以验证 `0.3` 是师傅们和 `0.2` 之间的中间人。
5. 下图是我们 SSH 连接时收到的公钥指纹
6. 下图是 `172.18.0.2` 主机 SSHD 配置文件夹中的公钥:
7. 可以看出两者是不一样的，所以验证了 `0.3` 在做 SSH 连接的中间人的猜测，这样一来有很大可能真的flag在 `0.3` 里。0X02 第二个hinthint：pcap
1.这是一个很重要的 hint ，流量中出现的主要IP是 `172.18.0.2` `172.18.0.3` ，在流量包里可以看到明显的特征：在建立了 SSH 连接后，外网发给 `0.3` 的加密数据包，`0.3` 会先与 `0.2` 通信，`0.2` 返回给 `0.3` 数据后，`0.3` 再返回给外网的 IP ，在这里也能够证实 `0.3` 在做 SSH 的中间人。
2. 一般打 CTF 的流量包里面都会藏一些有用的东西，所以这里设了个坑，下载了一个 `53.bin` ，但是文件的具体内容没有什么用，此文件实际上是之前部署在公网的蜜罐捕获到的 DDoS 木马，所以先对执行了此文件的师傅说声对不起。
3. 但是下载这个 `53.bin` 也不完全是坑人的，流量包里的 Http 都很重要，过滤一下 Http 可以看到只有几个数据包，`User-Agent` 是 wget ，wget 了 `http://cip.cc` ，并重定向到了 `http://www.cip.cc` ，这么做的初衷了为了暴露题目的公网 IP ，但是师傅们后来决定先不放这个流量包，所以题目描述直接把 IP 给出来了，这里也没什么用了。
4. 那为什么 `53.bin` 有 `request` 没有 `response` 捏，实际上 Follow 一下 TCP stream 就能看到后面的都是二进制的数据，Wireshark 没有把他们识别为 HTTP 协议。
5. 实际上这个包最关键的地方在下图中两个 `GET 53.bin` ，这里涉及到一些蜜罐的东西，玩过 SSH 蜜罐的师傅可能了解，入侵者下载的恶意文件很可能随着执行而自动删除博恩崔西，所以绝大多数 SSH 蜜罐，无论低中高交互都会有一个功能，就是碰到 wget 命令田明健 ，会解析命令并自动下载里面包含的恶意文件，这也就解释了为什么 wget 命令在两台主机上都执行了一次。
6. 所以如果 wget 命令及参数没有解析好的话，是有可能导致命令注入的。这一点在后面的 hint 也有提示。这个漏洞我比较粗暴的设置为，当 `0.3` 主机得到了攻击者的命令，如果命令以 wget 为开头，则直接 `os.system(cmd)` ，当然还是做了一些过滤的良宵赠千金 。
7. 可以看到 Shell 里常见的引入新的命令的符号大多数都做了过滤，比如 `& | $()` ，但是还是留下了姿势可以绕过，比如 ` ` ，
8. ssh tunnel 的应用除了我们常用的 shell ，实际上还有 exec ，此应用不会在 sshd 上请求 shell ，只执行一条命令，比如 `sshpi@123.123.123.123'ls'`
9. 但为了方便构造，可以使用 python 的 `paramiko` 库来 Get flag
10. 实际上也可以直接 Getshell0X03 最后
1. wetland 是我之前写的一个高交互 SSH 蜜罐，基于 python 的 `paramiko` 库。这个题就是直接拿它改动了一点。地址在本 github 账号的 wetland 仓库里。
2. 题目的架构为真实云主机上跑两个 Docker 容器，分别为 `wetland(172.18.0.3)` 和 `sshd(172.18.0.2)` ，其中 wetland 是蜜罐程序，sshd 用于执行黑客的命令。
3. 两个容器的 Dockerfile 在 docker 文件夹中，sshd 是对 `rastasheep/ubuntu-sshd` 的修改，降低了权限。wetland 是对 docker hub 上 `ohmyadd/wetland` 镜像的修改，修改了两个文件，加上了命令注入。
4. 最后既然是蜜罐，肯定会记录执行的操作啦，日志文件都有保留，但不知道公开合不合适，就先不放出来了。
5. 最后一张用 bearychat 来实时看都有什么操作 :-)
LCTF 2017 其它未解之谜在这里：
LCTF 2017 未解之谜：BeRealDriver && YublKey Writeup
（https://blog.pwnhub.cn/2017/11/21/LCTF-2017-%E6%9C%AA%E8%A7%A3%E4%B9%8B%E8%B0%9C%EF%BC%9ABeRealDriver-Writeup/）
LCTF 2017 未解之谜：Py.trade2 Writeup
（https://blog.pwnhub.cn/2017/11/21/Py-trade2-Writeup/）
本文转载自知乎长亭技术专栏，欢迎各位在评论区留言，与我们交流喔！陈子湄
在刚刚结束的LCTF 2017中，仍有一些未解的题目，今天笔者就来和各位胖友分享第一道未解之谜—— Misc 类下的「树莓派」麻阳红网，Writeup 来自本次比赛主办方 L-Team 。
PS: 其它未解之谜见文末链接。
所有 Writeup 目前已发布，欢迎移步：LCTF 2017 官方Writeup0X01 刚上线
题目介绍只给了个 IP ，有师傅当做 Web 题，发现点不开。
扫了一波端口后，只有 22 开着，所以入口点肯定在这里。
根据题目的提示，按照正常的思维确实应该登录 `pi:raspberry` ，本来也是打算设置成这样，但是这个密码太弱了，题目还没上线就被黑铲扫了好几波，直接改密码种木马一波带走了。所以就改了一个需要一些脑洞的密码 `pi:shumeipai` ，可能有师傅在这里卡了一下。0X02 第一个hinthint1：都告诉你密码了
1. 这个 hint 主要提示弱密码是什么，因为不想让师傅们耽误太多时间，给出后很多师傅都上来了。
2. 这时候 SSH 进去会发现是一个低权限帐号，很多操作都受限了，`uname` 看内核版本也很高，这之后很多师傅就开始四处搜刮 `flag` ，`bash_history` 、`.swp` 等等，还看了所有文件的修改时间。
3. 但是一番搜索后除了那个假 flag 什么发现也没有张嘉蓉。在搜索的过程中，查看主机的网络状态`netstat -autpn`，会发现所有的 SSH 连接来源都是 `172.18.0.3` ，在这里应该会产生一些疑问，ping `172.18.0.1`、`172.18.0.3` 都是通的，pi 本机是 `172.18.0.2` 。
4. 这时候可以猜测陶驷驹，SSH连接被 `0.3` 动了手脚唐子义，通过 SSH 的指纹完全可以验证 `0.3` 是师傅们和 `0.2` 之间的中间人。
5. 下图是我们 SSH 连接时收到的公钥指纹
6. 下图是 `172.18.0.2` 主机 SSHD 配置文件夹中的公钥:
7. 可以看出两者是不一样的，所以验证了 `0.3` 在做 SSH 连接的中间人的猜测，这样一来有很大可能真的flag在 `0.3` 里。0X02 第二个hinthint：pcap
1.这是一个很重要的 hint ，流量中出现的主要IP是 `172.18.0.2` `172.18.0.3` ，在流量包里可以看到明显的特征：在建立了 SSH 连接后，外网发给 `0.3` 的加密数据包，`0.3` 会先与 `0.2` 通信，`0.2` 返回给 `0.3` 数据后，`0.3` 再返回给外网的 IP ，在这里也能够证实 `0.3` 在做 SSH 的中间人。
2. 一般打 CTF 的流量包里面都会藏一些有用的东西，所以这里设了个坑，下载了一个 `53.bin` ，但是文件的具体内容没有什么用，此文件实际上是之前部署在公网的蜜罐捕获到的 DDoS 木马，所以先对执行了此文件的师傅说声对不起。
3. 但是下载这个 `53.bin` 也不完全是坑人的，流量包里的 Http 都很重要，过滤一下 Http 可以看到只有几个数据包，`User-Agent` 是 wget ，wget 了 `http://cip.cc` ，并重定向到了 `http://www.cip.cc` ，这么做的初衷了为了暴露题目的公网 IP ，但是师傅们后来决定先不放这个流量包，所以题目描述直接把 IP 给出来了，这里也没什么用了。
4. 那为什么 `53.bin` 有 `request` 没有 `response` 捏，实际上 Follow 一下 TCP stream 就能看到后面的都是二进制的数据，Wireshark 没有把他们识别为 HTTP 协议。
5. 实际上这个包最关键的地方在下图中两个 `GET 53.bin` ，这里涉及到一些蜜罐的东西，玩过 SSH 蜜罐的师傅可能了解，入侵者下载的恶意文件很可能随着执行而自动删除博恩崔西，所以绝大多数 SSH 蜜罐，无论低中高交互都会有一个功能，就是碰到 wget 命令田明健 ，会解析命令并自动下载里面包含的恶意文件，这也就解释了为什么 wget 命令在两台主机上都执行了一次。
6. 所以如果 wget 命令及参数没有解析好的话，是有可能导致命令注入的。这一点在后面的 hint 也有提示。这个漏洞我比较粗暴的设置为，当 `0.3` 主机得到了攻击者的命令，如果命令以 wget 为开头，则直接 `os.system(cmd)` ，当然还是做了一些过滤的良宵赠千金 。
7. 可以看到 Shell 里常见的引入新的命令的符号大多数都做了过滤，比如 `& | $()` ，但是还是留下了姿势可以绕过，比如 ` ` ，
8. ssh tunnel 的应用除了我们常用的 shell ，实际上还有 exec ，此应用不会在 sshd 上请求 shell ，只执行一条命令，比如 `sshpi@123.123.123.123'ls'`
9. 但为了方便构造，可以使用 python 的 `paramiko` 库来 Get flag
10. 实际上也可以直接 Getshell0X03 最后
1. wetland 是我之前写的一个高交互 SSH 蜜罐，基于 python 的 `paramiko` 库。这个题就是直接拿它改动了一点。地址在本 github 账号的 wetland 仓库里。
2. 题目的架构为真实云主机上跑两个 Docker 容器，分别为 `wetland(172.18.0.3)` 和 `sshd(172.18.0.2)` ，其中 wetland 是蜜罐程序，sshd 用于执行黑客的命令。
3. 两个容器的 Dockerfile 在 docker 文件夹中，sshd 是对 `rastasheep/ubuntu-sshd` 的修改，降低了权限。wetland 是对 docker hub 上 `ohmyadd/wetland` 镜像的修改，修改了两个文件，加上了命令注入。
4. 最后既然是蜜罐，肯定会记录执行的操作啦，日志文件都有保留，但不知道公开合不合适，就先不放出来了。
5. 最后一张用 bearychat 来实时看都有什么操作 :-)
LCTF 2017 其它未解之谜在这里：
LCTF 2017 未解之谜：BeRealDriver && YublKey Writeup
（https://blog.pwnhub.cn/2017/11/21/LCTF-2017-%E6%9C%AA%E8%A7%A3%E4%B9%8B%E8%B0%9C%EF%BC%9ABeRealDriver-Writeup/）
LCTF 2017 未解之谜：Py.trade2 Writeup
（https://blog.pwnhub.cn/2017/11/21/Py-trade2-Writeup/）
本文转载自知乎长亭技术专栏，欢迎各位在评论区留言，与我们交流喔！陈子湄