7月31日
我和Kelwin、zTrix、LittleFatter等同行，在大本營集合，並領到了隊服：
隊服背面logo總感覺需要重新設計一下。另外三名隊員已經到達拉斯維加斯了，而Fish尚未啓程。在UA888飛機上待了三個多小時，因爲飛機故障我們被安排在北京臨空皇冠假日酒店住一宿。
8月1日
在San Fransisco轉機後飛抵Las Vegas，分組乘出租車到Rio All-Suite Hotel and Casino。有點驚奇的是這裏的駕駛員也知道DEFCON。
會場入口處的標識牌：
進入會場需要一個白色badge的，受邀請的人可以免費得到，而其他人需要花$180購買，入場費還是比較貴的。
晚上大家在附近一家自助餐館吃飯，但分成好幾個小組，彼此不知道對方的位置，感覺我們特別像某個地下組織的成員接頭……後來好不容易8名隊員都聚合在一起，不少對隊員是第一次見面。DEFCON CTF主辦方安排在21:00舉辦一個聚會，讓個支參數隊伍見面。我們整體感覺都很靦腆，只有Kelwin勇敢地站出去一直在和其他隊伍聊天，而其他人都是和隊友聊。越南隊clgt可能更靦腆些吧，都沒有來參加聚會。
DEFCON 21 CTF
DEFCON 21 Capture the Flag比賽總共有52小時，分爲2日~4日三天舉行，前兩天的10:00到20:00以及4日的10:00到14:00在DEFCON會場的CTF房間進行，在這段時間那些帶有vulnerability的服務對外開放（可以登錄給服務打patch，也會遭受到其他隊伍的攻擊），其他時間段選手們一般在賓館，無法訪問vuln機器，但是可以進行離線分析。
8月2日
8:30左右我所在的Blue-lotus的隊員們聚集起來去Burger
King吃早餐，趕到賽場已是9:00多了。賽場上有20支隊伍，每支隊伍都有一份規則說明書。這次CTF採用attack
and
defense的形式，每支隊伍都有一個編號，被分配到一個10.5.$team_id.0/24子網，10.5.$team_id.2爲部署了很多需要保護的服務的機器。
10.5.$team_id.2即vuln，是運行在ODROID-U2(ARMv7 little
endian)上的Ubuntu
12.04.2系統，啓用了ASLR(印象中/proc/sys/kernel/randomize_va_space是1)和NX，所有需要保護的服務都對應/home/下的一個elf比如/home/bookwarm/bookwarm，所有服務都由xinetd代爲監聽端口，xinetd運行服務時會把權限drop至服務名對應的用戶比如bookwarm。選手們擁有10.5.$team_id.2的chroot環境中ctf用戶的密碼，但沒有提供root權限（也不能sudo成root）。內核被修改過，proc下相同UID的很多文件如/proc/self/maps、/proc/self/mem等都無法訪問，很多軟鏈接如/proc/self/fd/0等也無法readlink。vuln上安裝的軟件非常少，gdb等很多工具都沒有提供，開啓了ptrace
protection。
/home/tokens/下有各個服務對應的tokens文件如/home/tokens/bookwarm，權限爲-rw-r----- 1 root bookwarm的形式。假如bookwarm被其他隊伍攻陷，被獲取shell（uid爲相應的服務名bookwarm），他們就可以cat /home/tokens/bookwarm獲取token並在https://scorebot.ctf上提交。每5分鐘爲一輪，主辦方會更新一次token，如果這段時間某個服務的token被其他隊伍提交，會被扣19分(即丟失19個flags)，這些flags會被平均分配給攻擊者。主辦方還會對服務做service
level
agreement檢測，如果檢測到下線或者不正確，也會扣19個flags。這些flags會被分配給其他19支隊伍。比賽開始時20支隊伍每支分到2500個flags即2500分，比賽中的分數變化理論上應該是零和的(但後來可以看到分數總和減少了，是因爲主辦方出了些bug)。
10.5.$team_id.1爲網關，每支隊伍分配到一個網口，使用的有限網絡也屬於這個子網。
10.5.$team_id.3不提供登錄，但開放了sftp，允許以sftp -i ~/.ssh/bluelotus_capture bluelotus@capture:latest.cap /tmp/latest.cap的方式
下載到5分鐘更新一次的tcpdump capture file，數據包的延時約爲15分鐘。其中來自其他隊伍子網的數據包的IP地址的主機號都被設置爲2即10.5.$other_team_id.2了。
首先要做的就是配置比賽環境，網線只有一根，卻有8臺電腦需要上網，zTrix同學的小路由器不夠用了，緊急打電話給諸葛老師要買一個大的路由器。我們也沒有準備好接線板和網線，好在men
in black
hats隊友情給我們提供了好多根網線，非常感謝他們！服務器是ARM，我們對此都沒有經驗。Kelwin分析lonetuna，他還帶了一塊Raspberry
Pi，ARMv6的，我跟着zTrix琢磨怎麼在上面安裝系統、配置環境，但是沒有成功；另外就是配置QEMU，裝好了Ubuntu
9.04，但是不能更新和裝gdb。Fish配置的系統沒有網絡，也不能用。不過好在後來遠在大洋彼岸的cbmixx給我們配置好了ARMv7l環境。到大概16:00多似乎都沒有隊伍發現並利用漏洞，沒有出現攻擊流量。之後PPP發現了lonetuna程序的拒絕服務漏洞，其他各隊都遭到攻擊。這個就是tuna：
讓人想到清華大學學生網管會TUNA。
還有段小插曲，有場外黑客利用藍牙漏洞控制了主辦方的蘋果電腦。
大約18:39新的服務reeses出現了。一直到20:00我們對各個服務的分析都沒取得進展，由於服務持續處於拒絕服務狀態，我們一度墊底，不過到20:00結束時達到了倒數第二。回到賓館大家分析失利的原因，摩拳擦掌準備第二天的逆襲。我用DNS反查把各個隊伍和子網列了出來：
1 | PPP 10.5.1.2 |
又寫了個簡單的腳本每個一段時間檢測其他各個隊伍服務的在線情況，並打算開個nginx供隊員們下載數據包。不過只是簡單的nmap -sS -p $ports，沒有使用服務特定的判定，很多服務失常的情況無法檢測出來。
8月3日
昨晚大家通宵修補了三個服務，通過分析流量捕獲強隊的atmail及reeses的exploit，我們運行腳本對其他隊伍批量實施replay
attack。我們的排名在逐步回升，而逐漸地，有近一半隊伍的分數掉至了0分。
11:34左右又出現了兩個服務：avoir和trouver。下午我們注意到last命令顯示vuln被10.5.1.2登錄過，而這個子網是屬於PPP的，和主辦方交涉後才知道主辦方僞造了源IP。這纔想到主辦方做service
level
agreement的時候會僞裝成來自其他隊伍的子網。所以抓包文件中有部分流量是屬於主辦方的。外援任勝韋(似乎還是高中的學長耶)給我們提供了抓取排名數據的程序，我把它集成到檢測服務在線情況的腳本中。flanker017寫了腳本通過檢測數據包中的1100字樣判斷是否有token泄漏了。
運行atmail
exploit腳本的DeadCat突然表示Mac電腦的很多應用程序都被刪除了，最後分析得出是因爲把類似curl -F 'tokens[]=%s' --cacert ca.crt -E bluelotus.crt --key bluelotus.key https://10.3.1.5/redeem的命令行誤用python
os.system了。而有隊伍故意讓服務泄漏出1100;' rm -rf /#類似的串。DeadCat運行的腳本先篩選出包含1100的行，然後構造出的curl命令行被os.system執行，單引號被閉合導致rm -rf /命令執行，而Mac用的不是coreutils的高版本，沒有--preserve-root的保護機制，導致這條惡意命令被執行。好在數據沒有丟失，腳本也仍在執行中，但單點故障讓我們覺得exploit運行在一臺機器上實在是太危險了，zTrix和flanker017也趕緊運行腳本，避免單點故障。而我一直無法curl
HTTPS的10.3.1.5，後來總算發現原來是缺乏client
certificate，certificate和private
key是curl的-E及--key選項指定的。Chrome則需要在Settings - Certificate manager裏導入PKCS #12格式的certificate及private
key。今天比賽截止時我們在第10名左右。晚上衆人繼續奮戰，Fish、zTrix、LittleFatter等熬夜分析avoir和強隊的exploit，還有一部分隊員研究trouver。我試圖對各隊的分數做時序分析觀察各個隊伍解題情況，flanker017研究了好多token泄漏的數據包，同時打算在第二天用帶有錯誤token的虛假數據包僞造攻擊流量欺騙其他隊伍。
一個小插曲：有個老外來找我們隊伍聊了幾句，初始還以爲是來社工的其他隊伍的領隊什麼的，後來知道原來是Black Hat和DEFCON的創始人Jeff Moss。今天賽場裏社交活動挺多的，還有幾位之前參加Black Hat的中國一些安全公司的朋友來給我們加油。
8月4日
9:00多到達賽場，發現我們的座位被移動到角落了。主辦方的意思是背景音樂有點響，要讓各個隊伍受到平等待遇，有點主客場的感覺。
我們打patch並緊急趕製avoir
exploit的自動化。不過我們的分數還是狂掉，另外也注意到昨天的兩個replay
attack的效果明顯變差了。強隊在攻擊時已經採取長連接的持續利用方式，昨天看到這條命令時還不以爲然，因爲服務的漏洞被修復了，大概是今天修補服務時出現了差錯。各個服務都是以用戶名爲服務名的用戶執行的，而那些服務的用戶都無法登錄，我們沒有辦法斷開連接，後來才發現可以sudo -u reeses成相應用戶執行pkill操作殺掉長連進程。這裏又是個比較奇怪的地方，就是bookwarm用戶密碼和ctf相同，可以su bookwarm；但是其他服務的用戶都無法su。
aay觀察到我們的vuln機器上各個服務的連接數都在14~27之間，方差比較小，令人生疑，猜測強隊利用弱隊作爲肉雞向我們發動DDOS。今天流量分析的準確度也大打折扣，流量中瀰漫着僞造的token包。flanker017的exploit流量檢測腳本精度大幅下降，我這才開始弄/home/tokens/的自動備份。這些腳本應該提早些寫的。這個時候我大概跑了這幾個腳本：檢測vuln狀態(ssh vuln $command)、定期抓取分數榜顯示爲網頁(有隊伍還把scoreboard可視化了)、定期抓取/home/tokens/、定期抓取數據包、兩個vulnerability
exploit腳本。這一天迷惑流量特別多，很多隊伍都在payload中加上了1100這樣的token疑似字樣，幹擾分析。我們用了三個工具，tcpdump、tshark(和tcpdump相比慢很多，而且容易崩潰)和tcpflow。因爲迷惑流量，我之前用的tcp contains 1100誤報率極大。除了三四支強隊，其他隊伍的分數都在狂掉不止，我們對此卻無能爲力。離比賽結束還有一小時時主辦方停止更新分數榜。光靠修補漏洞加幾個奪取token的exploit已經不夠用了，我們亟需能夠彈shell的exploit。可惜Kelwin在比賽結束前幾分鐘才寫出本地利用的彈shell
exploit，已經沒法挽回局勢了。最後PPP(Plaid Parliament of
Pwning)以相當於第二、三名分數和的巨大優勢奪得第一，獎品是8個黑色badge；Men
in Black
Hats奪得第二，獎品是比賽中用到的20個ARM開發板；韓國的raon_ASRT獲得第三；我們Blue
Lotus第十一。
反思
今年起Blue Lotus的戰力有了長足的進步，吸納了Web安全方面諸多高手，在各個CTF比賽中開始嶄露頭角，有好幾個比賽都打入了決賽。但我們和最頂級的隊伍還有不少差距：
- 交流不暢，協作不順。我們也不熟協作工具的使用，對題目分配人員的方式上也處於摸索階段。我們使用了Google Docs，也用了口頭提醒的方式，但還是有很多隊員相互間缺乏瞭解，發現的東西難以有效分享給大家。
- 使用的分析工具、設備和其他隊伍相比較爲落後。頂級隊伍似乎都有高版本IDA pro；包括ARM在內的反彙編器；chromebook、樹莓派等ARM環境設備。缺乏漏洞自動利用、入侵檢測等工具。
- 缺少自動利用、分數榜可視化、入侵檢測、系統加固等方面的工具，導致很多人力浪費在了一些機械重複的勞動中。
- 分析能力，包括二進制、web、數據包等多方面。隊中擅長二進制的人數不夠，而主辦方Legitimate
Business
Syndicate出的題目清一色二進制。資格賽時web題目也都是被“秒過”的，主辦方出web題目的經驗不足可以想象。我和flanker017也是在比賽中學習
tcpflow、tshark命令行的使用，在數據包分析上和其他隊伍有很大的差距。分數榜的可視化做得太晚，可以看到韓國隊伍繪製了漂亮的曲線(可能是matplotlib)。 - 缺乏attack and defense經驗。我們參加的jeopardy比賽不少，但攻防就很少，對這方面的經驗幾乎爲零。
- 思路不夠開闊。比如有隊伍想到了泄漏
1100;rm -rf /#的惡意子串反害攻擊者。強隊想到了長連接nc多次提交token實施ATP、僞造攻擊流量給對手造成分析上的麻煩、利用肉雞實施DDoS攻擊等。
最後第11名，但是沒有自主開發的成功exploit，感覺不好。另外背景音樂有點響，很受幹擾。
8月5日
8月5日一行人從Rio All-Suite Hotel and Casino離開，入住The Quad Casino and Resort。在Check in的地方看到一張中國面孔。他從我們面前經過，走了很遠又回頭看了看，沒過多久他又走回來了，問我們：“Are you from China?”“Yes.”“我們能用中文嗎？你們是Blue-lotus嗎？”原來是HITCON的PK叢培侃，果然在這個地方過往的每一個旅人都可能是位頂級黑客。
很榮幸能參加這次CTF，爲了這次比賽受到的困阻兩隻手肯定數不清。好多次我都感到絕望了，能堅持下去克服重重艱險多虧了同學朋友們的支持，組織不出什麼語言來，但我真的很感謝你們。除了以前就見到的Kelwin、zTrix、Fish，還有資格賽時見到的flanker017、DeadCat這次又見到aay和LittleFatter。LittleFatter胖乎乎地很可愛，aay也有和遠小於的萌形外表，認識諸位並一起爲夢想奮鬥感到非常高興。和幾位交流中瞭解到網絡安全的很多資訊受益匪淺，最後祝Fish一路順風，Blue Lotus的各位都會繼承你的未完的理想的！
8月21日更新：SQL數據分析
賽後主辦方提供了比賽中的一些數據：http://blog.legitbs.net/2013/08/2013-finals-scorebot-sql-download.html。
- 最後的分數榜上20支隊伍的flags數之和爲42372，而初始時是50000，這是因爲剩餘的flags都被分配給21號虛擬隊伍了，用處是在
19 / number_of_explots不能整除時，把餘數分配給虛擬隊伍，之後虛擬隊伍趲足了flags再交還這些flags。但實際的實現存在問題，導致flags總和變少了。從數值上講，這個bug對非掉flags的所有隊伍的影響從絕對值上來說是均等的，所以還算公平，可以看作規則更改了。 flags表表示各個flag的最終歸屬，但captures/redemptions表的處理順序並非是id/created_at/updated_at，所以要確定出所有歷史時刻的分數表是不可行的。