RuCTFE 2012参赛记

海底捞火锅

RuCTFE 是一个面向全世界的信息安全比赛,每个队伍保护自己的机器,攻击其他队伍的机器,长达8个小时紧张激烈的对抗和赛前犒赏队员的火锅标志着它是这一年我参与的最有意义的事之一,因而在这里简要记录下来。有幸收到《Metasploit渗透测试指南》的译者孙松柏的邀请,成为 blue-lotus 队的一员,和网络安全实验室的同学一起出发,晚上一群人去吃牡丹园的海底捞火锅壮行。

RuCTFE

吃完火锅回到比赛地点(实验室)时已经近21:00了,大家都在忙着配置比赛需要的网络环境。此时我对比赛还是处于零准备状态……临时看了些 OpenVZ ConTainers control utility 的操作指南,在杨坤挂载的 RuCTFE2001 镜像上测试了单行 shell 脚本列出所有监听 tcp 端口的进程及其 /proc/$pid/{cwd,exe,cmdline},分享在 Google Docs 协作文档上。之后我的网络就一直挂,连接不上我们队的镜像服务器,得依靠别人的 ssh 做一次跳板……吴育昕的跳板也一直挂……呃……挺奇怪的问题,不知道原因。

mch

我和吴育昕一起研究 mch 服务和它依赖的 mongodb,可恨以前没认真研究过 mongodb 的配置以及客户端 shell 使用,不知道如何给 admin 添加密码,临时想了个粗糙的办法:在配置文件中用 bind_ip = 127.0.0.1 来防止别的队伍连接我们的 mongodb。朱文雷一人利用其他队伍的这个漏洞获取了大量 flags,得了很多分(现在还是没搞清楚分数是怎么计算的)。

flybook

从源文件 .d 可以看出来用的是 D语言,views/ 中的 .dt 是个类似 jade/slim 的简洁模板引擎。代码说真的看不大懂,仅知道和 gds 有密切联系。

gds

吴育昕通过 strings 研究出 /home/gds/service 有一些字符串信息,使用 HE 即可得到帮助,CP 则是修改密码的指令。 /home/booking/config 是 booking 连接 gds 使用的用户名、密码和监听端口信息,可以看出用户名和密码都是 booking,那么可以大胆猜测别的队伍的密码也是这样。我写了个脚本批量改了别人的密码,不过只能阻止别人获得 flags,而我们也迟迟没能发现漏洞利用方法,这一招可谓损人不利己……这里主要用到了两个命令,xargs(-P 选项可以并发执行)和 coreutils 中的 timeout。

flightprocess

Python 写的服务,王康和俞则明研究发现了服务的漏洞并找到了漏洞利用方法。我这时已经觉得很疲惫了,不想再多看其他题目源代码了,和王康、吴育昕一起看怎么写 Python 脚本自动化获取提交 flags 的流程。依旧用到了 xargs -P 来并发执行,这时候 shell 是实现快速粗糙原型的绝佳方式。

apache2

80端口的 apache2 服务孙松柏后来发现可以用 http://$host/db/sessions 获取 flags。我赶忙写了个脚本自动化操作,不过发现时里比赛开始已经过了很久了,获得的 flags 很少。

其他

还有很多其他同学的工作,我不明真相就没法在这里列举出来了。

后勤

感谢不知名同学提供的食物和饮料,是我们能坚挺下去的动力之一……希望以后食物能多点。我必须承认尽管吃火锅时,我吃的肉应该是最多的,但是消化太快下半夜非常饿…… 还有负责卫生的同学,队员们离开时必然是一片狼藉,新苦了! 还要感谢几位老师和很多忙碌与其他事的同学们的精神支持。

总结

比赛结束了,我们队第29名,不知道是不是大家认可的排名,我之前因为没参加这类比赛,不好说着是不是一个让人满意的成绩。但从种种不利因素看来,这个名次是值得骄傲的。这次比赛无论是天时还是地利,我们都没有占到优势,大家从上半夜工作到下半夜,疲惫不堪,严重影响到看源代码、分析流量、找漏洞、打补丁的效率; 地利,我们的网络不畅,从 scoreboard 上能获知有不少时候因为延时而导致服务被判成 down 了; 而且队伍人数和其他队伍相比较应该也算是少的。

从这次比赛看出我们很多可以改进的地方。以我自己为例,

  • 没有认真看完协作文档
  • 没有在之前的镜像服务器上练习
  • 临时抱佛脚学习 vzctl
  • 没有参加之前组织的几次培训
  • 对比赛规则迷迷糊糊

总之有很多做得不好的地方。

另外:

  • 大家使用 qq 联络而不是 irc。官方实时信息也用了irc,所以人手一个客户端还是很有必要的。 Chrome 里访问 web.qq.com,desktop notification 着实烦人。 irc daemon 可以采用 inspircd,默认配置就能用。
  • 不能有效地通知他人自己的工作进展。Google Docs 上有基于文本的简单任务认领机制。 但很容易出现:好不容易发现的问题和别人刚刚研究出来,不能有效利用人力。 这里我觉得可能给每个任务都建立单独的讨论区(比如irc的频道)可能比较好。
  • 没有良好的文件分享机制,FTP/NFS/WebDAV/Samba 等都没有配置。
  • 没有准备好批量在其他队伍服务器上利用漏洞的脚本。脚本语言的多线程模块,对于这个任务, xargs -P,GNU Parallel 都是不错的工具。 据说此次比赛的 flags 得分是线性的模式,有很多队伍应该都开着类似的脚本。