2017 DCTF 第三届上海市大学生网络安全大赛决赛(AWD) 小记

参考新闻稿

永信至诚网安竞赛中国行上海站-第三届上海市大学生网络安全大赛完美收官

结果

  1. r00t (东华大学)
  2. BXS (中国矿业大学)
  3. 介绍一下这是我的patch (上海科技大学)
  4. Syclover (成都信息工程大学)
  5. 4jia1 (西安通信学院)
  6. S3cN0tB4d (三江学院)
  7. LifeTime (上海电子信息职业技术学院)
  8. BOI (国防科技大学)
  9. SeeSea (西安科技大学)
  10. X1cT34m (南京邮电大学)
  11. Apocalypse (东华大学)
  12. 彼岸花 (江苏科技大学)
  13. Jnsec (江南大学)
  14. Xp0int (暨南大学)
  15. 广外男生 (广东外语外贸大学)
  16. kn0ck-TEC (国防科技大学)
  17. 基因瓢虫 (复旦大学)
  18. H1terHub (哈尔滨工业大学(深圳))
  19. GoSSIP (上海交通大学)
  20. MSI (信息工程大学)

另外 参赛队伍A (赞助商, 来自上海揆安网络科技有限公司的队伍) 实际取得第二,不过该队伍不参与最终排名。

AWD 赛制简介

比赛平台是i春秋提供的,比赛时间为6小时,每轮5分钟。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
172.16.8.0/24 # 团队成员网段
172.16.9.0/24 # Gamebox网段
172.16.5.0/24 # 对抗区
http://172.16.4.1 # 答题平台
# 选手机
172.16.5.10-31 (共22支队伍,参赛队伍A和参赛队伍B均为赞助商队伍)
# NPC机
172.16.5.32 (NPC)
# 裁判机
172.16.0.2
172.16.5.200
172.16.5.201

比赛前主办方提供的参考手册说明了相关网段信息(具体到IP),因此不需要进行全网段(Masscan)的扫描。

每队一个路由器,路由器在对抗网段。
Gamebox的端口被映射到路由器所在的对抗区。

每队需要维护两个Gamebox(Gamebox即是参赛选手需要维护正常运行的服务器),一道是web题(web2),另一道是pwn题(web18)。

web2 的源码是修改后的 Metinfo CMS。

本地环境准备

使用 Windows
XShell 连接管理 (传输文件不太方便)
其他常见渗透测试工具

正式比赛

前期

(和实际状况不完全一致,穿插某种理想状态)
后门1 http://172.16.5.32:5051/about/show.php
文件包含2 http://172.16.5.32/product/picture.inc.php?img_tet=/flaflag
漏洞3 与数据库相关

我先处理了一下环境发现,使用Nmap的fast-plus模式对网段172.16.5.0/24进行扫描。

队友A 使用D盾对Web源码进行扫描,发现其中一个后门1,并尝试进行patch。

队友B 使用AntSword连接对手某台服务器,直接上传文件并未成功,直接以编辑文件方式将原先的正常文件修改为webshell(大马/小马)均有。
成功上传大马后,发现执行命令(读/flag)无回显。
直接对AntSword的编辑操作进行抓包,修改相关路径参数,读取到flag,拿下一血。

我则是先用AWVS黑盒扫描了一波,只发现几个盲注和XSS,并没有太大利用价值。

队友A 对web发现的后门进行patch后,对pwn服务上了(事先准备好的)wrapper,该wrapper会以日志方式记录服务收录的数据,并且检查服务输出,如果包含flag等字段会进行拦截替换。

拿下一血后的这段时间并没有很好的利用,自动化脚本跟进较慢,主要是队友B在手动操作提交flag,在此期间,团队此前的webshell陆续被发现删除,无法持续获得有效flag,后门1也逐渐被发现修补。
(除了拿下flag以外,最好破坏服务,如果将其他所有队伍的服务都破坏,只留1个队伍,这种情况下得分惊人)

之后web1似乎出现patch失败,被裁判机判服务失效,开始持续掉分。
中途尝试了回滚服务重新patch以遏制掉分。

中期

参赛队伍逐步挖掘了新的漏洞(文件包含2)
团队控制的服务器的flag开始被提交。
通过Nginx日志审计发现Syclover攻击我们时所使用的payload(/product/picture.inc.php?img_tet=/flaflag),开始编写脚本攻击其他队伍。

1
2
cat access.log | grep 200 | grep 172.16.5.200
tail -100 access.log | grep 172.16.5.200

与此同时,我尝试用HP Fortify进行代码审计,不过最终的输出结果除了提供少量危险函数的告警并没提供太大帮助。

期间同时重点关注一些强队对我们的访问日志。

后期

后期发现参赛平台上虽然未显示服务宕机,但实际上访问主页时服务已经宕机。
发现是数据库配置文件被其他队伍修改。
经过日志审计,发现第三个漏洞。
发现大约有一半的队伍服务宕机而未恢复(然而裁判机并未发现)

pwn题相关似乎题目存在问题,最终并没有队伍做出。

理想状态

写的针对服务器脚本注意不能使用第三方lib。(比赛环境不通外网)

对 Web 和 Pwn 进行代码备份 (每次进行patch之后的版本也需要做备份)
将所有 Web 目录设置为不可写
(可选: 对所有页面上通防waf, 注意观察本队服务状态,如果裁判机判断服务失效可能会掉分)
D盾等webshell查杀

对web目录的文件修改写监控脚本
对ssh的用户情况(who)写监控脚本

漏洞挖掘 -> 编写批量脚本处理

环境感知
将 IP 和参赛队伍队名一一对应
这样在平台公告栏里如果告知被攻击的队名,可以及时调出日志分析。
此外没事干的时候可以重点关注一些强队对我方控制的服务器的访问日志

分析日志,尝试找出裁判机IP.(虽然有时候可能是进程check,具体得看比赛平台)
有时候由于多种混淆机制,可能难以及时patch。可以使用以下的思路,
当裁判机进行check时,将请求代理到NPC机,之后会给裁判机。

其他AWD参考资料

[XDCTF-2017-Final] 经验总结
http://www.jianshu.com/p/35af80b97ee6

利用 PyInotify 来监控 Web 目录 WebShell
http://www.jianshu.com/p/b5f92d070829

CTF线下赛AWD套路小结 (先知) tinyfisher

提前装好pwntools(https://docs.pwntools.com/en/stable/)和
ctf-tools(https://github.com/sciencemanx/CTF-Tools)