2020年8月28日

NEC サイバーセキュリティ戦略本部セキュリティ技術センターの木津です。
CTF(*1)は競技者として参加する方が多いですが、毎年、NECセキュリティスキルチャレンジ(*2)は、運営側として関わっています。今期も作問側として参戦しようと新たな問題コンテンツの作成に着手し始めました。作問の前に前回分を振り返っていたところ、前回色々な気づきが得られたことを思い出しました。
blogでその一部を共有してみたいと思い、書いてみることにしました。

*1: 情報セキュリティの技術力を競う競技"CTF(Capture The Flag)"のこと
*2: NECセキュリティスキルチャレンジは、2015年度の初開催から過去5年開催してきた大会であり、参加者に2週間で約100問の問題に挑戦してもらう、年に一度の大規模な社内CTFイベントです。

CTF作問での新たな挑戦

作問を始めた時期は、NECセキュリティスキルチャレンジの立ち上げ時からですので5年前くらいになります。作問メンバが足りなくて開始したというのがきっかけでした。

今まで、色々失敗してきました。
難しくし過ぎてしまった結果、競技期間中に誰にも解かれず悲しい経験をしたことがありました。最終的に得られるフラグが曖昧になり、参加者アンケートの結果で低評価になったこともありました。

失敗ばかりではなく、PPAPという名前のReversing分野の問題を作ってみたところ、多くのコメントをもらって嬉しかったこともありました。競技参加者アンケートの結果で決まる優秀作問賞に選出されたこともありました。

様々な経験を通し、できる限り今までにないタイプの問題を作って、「あの問題、おもしろかった！勉強になった！」と感じてもらえるような問題を作ってみたいと、作問への思いは変化していきました。
上記のような流れで、前回はGitLab Community Edition(以降GitLabと記載*3)の自動デプロイ/自動テストの機能を使った問題作りに挑戦してみました。

*3: GitLab はDevOpsライフサイクル全体をカバーするオールインワンのアプリケーションです。ソース管理だけでなく、wikiの機能やタスク管理機能、CI/CD(Continuous Integration／Continuous Delivery)機能など多くの機能をもつツールです。
URL : https://gitlab.com/gitlab-org/gitlab
ライセンス: 機能制限のあるCommunity EditionはMITで、全機能が使える有償版が存在します。

GitLabを使って作問を進めることにした理由は概ね次の通りです。

GitLab組み込み時の課題

CTFで使うことを想定しつつ、GitLabを触りはじめて感じた主な課題を以下に記載します。
GitLabが想定している使用目的から外れ、想定外の利用になりますので色々課題がでてきます。

例えば、上記のscriptの部分に任意のコードを埋め込んで、デプロイ先端末で指定コマンドを実行し、GitLab上で結果を得ることなどが可能ですので危険です。

図1の通り高機能ですので、何をしたらよいか混乱を招く可能性があります。例えばwiki機能やSnippets機能は、CTFで必要ありません。

課題に対する対策

すべて記載すると長くなりそうですので、aとbを中心に記載します。

前述の課題a「自動デプロイ・自動テストを行う際の設定ファイルの改ざん」については次の3つの対策で対応しました。

まずxについてですが、改ざんが発生しても影響がでないようにするため、次のようなシステム構成にしました。

すべてを1つの装置として構成することも可能ですが、セキュリティの観点から分けるべきと考え、分けて構成するようにしました。
前述のschroot、テスト制御用Webサーバ、Dockerコンテナから外部NW(インターネット)にパケットが出て行かないようファイアウォールやルーティングテーブルの設定などを工夫しました。

また、どんなテストがDockerコンテナ上で実施されているか競技参加者に見えないよう実装しました。実施されているテスト内容が分からない場合、どこまで修正したらよいか見通しが立たず、問題難度が跳ね上がると思いましたので、そのように設定しました。逆にテスト内容が分かると対処方法が明確になります。テスト内容は競技参加者が減点覚悟でヒントをオープンした際に参照できるようにしました。

yの改ざん検知およびリカバリ処理は、 自動デプロイ/自動テストの手前で呼ばれるプログラムで行い、必要に応じてリカバリ処理を行った後、デプロイおよびテストを実行するよう実装しました。
改ざん検知は単純にファイル差分を比較して行い、リカバリ処理は元の設定ファイル.gitlab-ci.ymlをリポジトリに再登録するというシンプルな内容にしました。

設定ファイル.gitlab-ci.ymlの具体例を以下に記載します。

zのSystem hooks APIの機能を利用した通知は、GitLabのAPI機能が充実しているため、簡単にスクリプトで実装できました。リポジトリの更新を検知してすぐ改ざん検知・リカバリまで行う方法も検討しましたが、タイミング的な制御が難しく、検知・リカバリ漏れが出てきそうでしたので、最終的には前述の通り、自動デプロイ・自動テストの直前で行う方法にしました。

課題b「自動デプロイ・自動テストのJobの並列処理」については、設定のみで対応できそうでしたが、思い通りにGitLabが動作してくれず、多くの時間を要しました。

GitLabで自動デプロイ・自動テストを行うコンポーネントはRunnerと呼ばれています。試行錯誤の結果、一つのRunnerで同時に処理できるJobの数を一つにして、複数のRunnerでJobを処理する構成にしました。

設定の具体例を以下に記載します。

Runner全体で同時に処理することのできるジョブの数を設定ファイル中のconcurrent で指定できます。concurrentの値を増加させて、各Runnerに複数のJobを同時に処理させた場合、他の競技参加者のソースコードが参照できてしまう可能性があるという問題が見つかり、最終的に各Runnerが同時に処理できるJob数を一つに制限し、runnerの数を増やすことで対応することにしました。

最初はRunnerを8つ作っておき、足りなくなった場合は随時追加していく方針にしました。各Runnerにそれぞれ負荷が偏らないよう各ユーザのネームスペースにあるプロジェクトを割り当てていくことにしました。

cとdは設定および簡単なスクリプトの作成で対応しました。

上記の他、競技開始前に何度か問題の微調整を行ったのですが、問題コンテンツ(ソースコード)の更新履歴にフラグやヒントに類する情報が残ってしまったため、一部の更新履歴をファイルごと一旦消して対応するという方法をとりました。
普段の開発では行わない操作と思いますので、以下に記載しておきたいと思います。

出題した問題の概要

登録した問題コンテンツの概要を以下に記載します。4つの問題を登録しました。

a-1,a-2はソースコード修正後に予め用意してある正常系および異常系の自動テストを実行し、すべてのテストにパスするとフラグが表示される問題です。
a-2は、シェルが取れるとなんでもできてしまうため、出題しづらかったタイプの問題です。更新されたプログラムを基に正常系および異常系のテストを実施するだけにしましたので、安心して見ていることができる問題になりました。

b-1,b-2はバッファーオーバーフローに関する問題ですが、ASCIIコードしか入力できないように入力チェックを加えた問題です。CTFで稀に見かける問題にしました。
b-2はb-1とリモートサーバの作りは同じですが、10回中10回確実に攻略できるプログラムを作成するためには一工夫必要で、その解き方は検索エンジンで探しても見つからないことを確認した上で出題しました。

どのような別解がでてくるか、どのような攻撃(不正にフラグを取得しようとする試み)があるか、期待できそうな問題を色々考えた結果、上記で結果を見てみることにしました。

対策の効果と得られた気づき

対策は概ね機能したものの、競技期間中に、自動デプロイ・自動テストの設定ファイル改ざん事象が発生しました。

改ざんおよび自動リカバリをする設定にしていましたが、改ざんチェックが一部の問題コンテンツで外れていたこと(問題の最終調整時に一旦外して、そのままの設定になってしまっていたこと)が原因で、検査をすり抜けたことが分かり手動対応しました。ホストの隔離設定やWebサーバでの厳密な入力チェックにより、不正にフラグが取得される可能性は少ないと思っていましたが、想定外の事象でしたので冷や汗がでました。無事、不正にフラグを取得されることなくリカバリできましたが、急ぎ対応が必要なプレッシャーで対応時に手が震えました。

対応後も数回、改ざんを検知する事象が発生しましたが、以降は想定通り対策が動いてくれて、安心してみていることができました。

上記の他、今回の実装の穴をつく攻略法でフラグ奪取を狙う競技参加者も現れました。

例えば、b-2の問題ですが、一つのexploit中で複数回接続試行してフラグを奪取する、という試みが行われました。
exploitのエントリポイントになっているシェルスクリプトに次のような行が複数行入っていました。
(printf
"1234¥nRRYh00AAX1A0hA004X1A4hA00AX1A8QX44Pj0X40PZPjAX4znoNDnRYZnCXA¥n"; sleep $n ; printf "cat ./info.txt¥n") | nc $1 $2

コネクション数の制御も必要と気づかされました。想定できていませんでした。1回の試行のタイムアウトを3秒にしていましたので、攻略まではできなかったようです。
その他にも色々な別解、想定外の攻略法がでてきて大変勉強になりました。
競技後に2週間くらい問題コンテンツのヒントおよび解説を全公開するのですが、公開のタイミングで、別解として問題コンテンツの解説に追記して競技参加者にも別解を共有することができました。

その他の得られた気づきを以下に記載します。

初めての試みということもあり手探りで動いていますので、まだ気づいていない課題やもっとエレガントな対策があったかもしれません。様々な視点で議論してみるといろいろ面白いアイデア出てきそうな気がします。もし、CTFについてお話できる機会がありましたら、競技に関することだけでなく、過去に出題した問題などについても意見交換できるとうれしいです。

まとめ

GitLabのようなCI/CD機能を持つツールで、今までできなかったタイプのCTFの問題が色々作れることが分かりました。少しでも参考にしていただけるような情報がありましたら幸いです。

まだまだ同じ仕掛けで違うタイプの問題が作れそうです。セキュリティとAIを絡めて、作成したモデルの予測精度を問う問題とかもできそうです。色々アイデアが浮かんできます。
競技者としてではなく、作問をやっていても、色々な気づきが得られます。視点を変えると色々見えてきて視野が拡がります。
作問仲間もできますし、勉強会で話のネタになりそうな経験ができるかもしれません。
競技者の想定外の行動にドキドキすることがありますが、それも楽しみの一つになりました。

最近、Hack The Boxをやってみて、ペンテスト力向上につながるタイプの問題作成、ハードウェア分野の問題作りにも興味を持つようになりました。得られた経験を基に、新しいタイプの問題作成に挑戦し続けていきたいと思います。

執筆者の他の記事を読む