WCTF2020
この記事はCTF Advent Calendar 2020の11日目の記事です。前回の記事は @bata_24 さんによるgefを改造した話でした。その前の一週間も @bata_24 さんによる記事でした。今年のAdvent Calendarの3分の1は @bata_24 さんによって埋められたことになります。なお現時点で、明日を含む10日分は担当が決まっていません。過疎っていますね。
私がインターネット上に公開しているブログは大きく分けて二つあり、非技術系のトピックを投稿するこのブログと、技術系のネタを投稿するblog.tonkatsu.infoがあります。
もともと今日の記事では、WCTFというCTF中に見つけた、Discordというアプリを使った面白いバグについての話をするつもりだったのですが、修正されてまだ時間が経ってからでないと公開しちゃダメとDiscordの人に言われたので今日は書けません。もうちょっとしたら書きます。
代わりにと言ってはなんですが、そのWCTFというCTFの話をしようと思います。技術的なことにはあまり触れない (+日本語でしか書かない) ので、こっちのブログに投下しています。
WCTFとは
CTFとは何か、という説明については流石に省略します。コンピュータ総合格闘技ですね。
CTFはいろんな国の企業や団体によって開催されていますが、WCTFというのは中国最大といわれているアンチウイルスベンダー Qihoo 360 という会社が主催しているCTFです。
普通のCTFは事前に運営が用意した問題に参加者がチャレンジしますが、WCTFで採用されているBelluminarは参加者が問題を持ち寄って解く形式です。凄腕の参加者が問題を用意するので必然的に難易度が担保されます。(本当?)
Belluminarというのはもともと韓国のPOCというカンファレンスで開かれていたCTFの形式です。 本家は2015年に始まり、その後2016年からQihoo 360によってWCTFがBelluminar Beijingとして開催されています。
What is BELLUMINAR
Belluminar, hacking contest of POC, started at POC2015 in KOREA for the first time. Belluminar is from ‘Bellum’(war in Latin) and ‘seminar’. It is not a just hacking contest but a kind of festival consisted of CTF & seminar for the solution about challenges. Only invited teams can join Belluminar. Each team can show its ability to attack what other teams want to protect and can defend what others want to attack.
Belluminar will not be restricted in one area but emerged as a worldwide hacking event. The beginning of Belluminar seemed to be humble, so properous will the future of it be.
歴史的にはBelluminar Beijingと呼ぶのが正しいのですが、面倒なので以降もWCTFと呼びます。
で、↑の説明だとちょっとわかりにくいのですが、WCTFは問題を解くことに加えて "seminar" と呼ばれるフェーズがあります。
このseminarでは、自分で作成した問題の解説を、他のチームと大会のジャッジがいる場で発表し、その問題に対する評価を得点とします。つまり、いわゆるクソ問を作ってきたらここで干されるわけですね。
最終的な得点は、他のチームが作ってきた問題と (当然ですが、自分のチームが用意した以外の問題を解きます) seminarの得点を合計して算出されます。
seminarで評価される項目は以下の4つです。
- innovative (新規性, 問題のアイデアが新しいか)
- reasonable (合理性, 問題の構成に無理がないか)
- flawless (完全性, 問題に穴がないか)
- stable (安定性, 問題が安定しているか)
これらの指標について、100点満点で評価をつけ、全部の平均がそのチームからの評価点ということになります。最終的な得点は、チームからの評価とジャッジからの評価にそれぞれ重みをつけて合計したものです。
実をいうとこれはあまり良い指標とは言えません。問題によっては評価不可能であるからです。
例えばこんな問題に対する評価を考えてみましょう。「独自実装のCPUのエミュレータが動作しており、サンプルコードが与えられている。解法はCPUのある命令にバッファオーバーフローが存在するのでそれを使ってexploitする」
ちなみにこれは経験談ではなく、あくまでも架空の一例です。
まずinnovativeについて評価します。独自実装のCPUが動作していますから、当然こんな問題を見たことはありません。新規性の塊でしょう。でも独自CPUは結構見たことあるので80点。
reasonableはどうでしょう。まずブラインドで仕様書すら存在しないCPUの命令列をguessingしなければならない上に、その命令にバッファオーバーフローがあることを突き止める必要があります。できるか?0点。
flawlessはというと、そもそも問題に穴がないか評価できません。 0点はかわいそうなので20点くらいあげます。
stableもflawlessと同じで評価できません。まあ30点くらいあげてもいいんじゃないですか?
次はこんな問題を考えてみましょう。再度いいますが、これは経験談ではなく、あくまでも架空の一例です。
「参加者に与えられているのはある環境に対するシェルだけである。実はこの環境はブラウザ上のJavaScriptで動作するOSで動作しており、busにペイロードを流すとXSSが発火する」
innovativeから見ていきましょう。busでXSSする、こんなアイデアは見たことがありません。控えめに言っても100点でしょう。
reasonable。busでXSSする、こんなアイデアを思いつくはずがありません。0点。
flawless。そもそも問題に穴がないか評価できません。 0点はかわいそうなので20点くらいあげます。
stableもflawlessと同じで評価できません。まあ30点くらいあげてもいいんじゃないですか?
このように、問題があまりにも奇抜すぎる場合はflawlessとstableをつけることができなくなります。 また、人によっては不快な思いをした問題に対して意味もなく低い点をつけたりすることがあるので、やはり合理的な指標ではなさそうです。
ここまで説明するとわかると思いますが、WCTFにおいて最適な戦略は難しい問題を作り、かつ低評価をつけられない問題をつくることです。
この「低評価をつけられない」というのがミソで、例えば1day exploitで世の中にPoCが出回っていない問題とかにすると、低コストで解くのに時間がかかる問題が作れるわけです。
実際にESPRは基本的にこの方針で問題を作っており、毎年seminarの点数を稼ぎつつ他のチームに解かれにくい問題に仕上げています。ずるいね
WCTF2020
の話を書こうと思ったんですが、疲れたのでまた今度にします。
明日のCTF Advent Calendarの担当はいません。誰か書いてくれ