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 得分是線性的模式,有很多隊伍應該都開着類似的腳本。