アルゴリズム弱太郎

Twitter @01futabato10

MBSD Cybersecurity Challenges 2022 優勝記

コンテスト セキュリティ

この記事は IPFactory Advent Calendar 2022 の 18 日目の記事です。

qiita.com

こんにちは、futabatoです。

MBSD Cybersecurity Challenges 2022 にチーム IPFactory として出場し、2022年12月15日に開催された最終審査会にて最優秀賞を獲得しました。

本稿は、MBSD Cybersecurity Challenges 2022 の参加記です。
文章は推敲せずに書いたままを投稿するので少し読みにくいかもしれません。

メンバーは y0d3n, n01e0, morioka12でした。他のメンバーの参加記も併せてご覧ください。

y0d3n.hatenablog.com

feneshi.co

今のお気持ち

率直に心から安心しています。安心しすぎて、「安堵&安堵」というフレーズを思いつきました。
今年 IPFactory はエントリー時のアピール文に「IPFactoryの名に恥じない結果を残します。」と宣言したので、偉大な先輩たちが築き上げた IPFactory で出場する以上絶対に負けられないと自分に課してしました。

setten.sgec.or.jp

加えて、サークルを背負っているプレッシャーがあったのは確かですが、MBSD Cybersecurity Challenges で最優秀賞を獲得することは僕にとって在学中の絶対に成し遂げなければならない密かな一番の目標でした。

自分が入学したときに IPFactory は MBSD Cybersecurity Challenges で 2 連覇していました。誰かにこのコンテストでIPFactory として優勝してほしいと頼まれたわけではありませんが、入学したての当時の自分に強烈な印象を与えるものだったので、自分もそうなりたいなぁと 3 年間ずっと思い続けていました。

scan.netsecurity.ne.jp

おそらく IPFactory のメンバーは同じようなことを考えていて、 それを n01e0 は 「世代交代しても勝てたという事実が嬉しいですね。」と表現しています。

feneshi.co

昨年はあらゆる能力が足りず 3 位で終わってしまい数か月引きずるレベルで落ち込んでしました。

2022 年では y0d3n とともにリベンジが成功し、IPFactory の名に恥じない結果を残すことができて本当によかったです。

IPFactory の先輩たちには一生追いつけないのかもしれませんが、この同じ景色を見ることができたのはとても感慨深いもので、入学したときに憧れた先輩の姿に一歩近づけたのかなと思います。

コンテストの概要

MBSD Cybersecurity Challenges 2022 のテーマは「Web アプリケーションの脆弱性診断」でした。

setten.sgec.or.jp

大まかなスケジュールとしては 1か月間の予選と、1週間結果待ち、1か月最終審査会に向けた準備 という流れでした。

MBSD 側のコンセプトとしては「診断したくないサイト」ということでした。

確かに複雑な権限管理・状態管理が必要なアプリケーションで、脆弱性診断の基礎技術だけでなく、コンテストや診断に対する強い熱意や根気が求められるものだったと思います。正直に話すと、自分には脆弱性診断士は向いていないなと感じるコンテストでした。複雑すぎて脆弱性診断ツール君は何も検出してくれないし、慣れていないと全然手が動かないし、でも脆弱性は見逃すわけにはいかないし、y0d3n の力添えができなかったので彼にすべてを任せてしまう形になっていました。

コンテストの講評では「ここがつらいよ脆弱性診断士」と診断士は診断対象のアプリケーションを選べるわけではないというお話を聞きました。もちろんセキュリティには興味があるけれど、自分にはその脆弱性診断のつらさを乗り越えられる熱量があるのかというとやや怪しいです。基本診断のみを専門にする職ではない少し別の領域で戦っていくのがよさそうだなと感じるコンテストでした。

プロジェクトを管理する立場になって

今回のコンテストでは、放任的なマネジメントを意識していました。

事務的な手続きはもちろん責任を持ってやりましたが、タスクをしっかりと管理してチームをけん引していくようなことはしませんでした。 コンテストの 2 カ月間で全員が集まって MTG をした日は 3 日のみでした。

IPFactory はフルフレックスで裁量労働制を導入しており、気が向いたときにガーっと作業できるメンバーが揃っています。無理に時間を合わせて VC しながら一緒に作業するよりかは、チャットベースで議論をして VC は都合がつく時間帯のみふらっと参加する形にしていました。MTG も議題を用意してから集まってもらったので、そのあたりのストレスをあまりかけないよう意識していました。

コンテストの評価ではプロジェクト管理をうまくアピールできていたチームが工夫点として評価されていました。そういった、チーム体制をしっかり整備して4人の足並みを揃えて一丸となって戦う団子方式はそれはそれでよいのですが、技術力のあるメンバーが揃っている場合はマネジメントは最低限でよく、指示や管理をせずとも勝手に作業して勝手に進捗を生んでくれるので、比較的短期間のコンテストではマネジメント力より技術力が正義なんだなと感じました。

ただこの疎な体制はしっかりとメンバーを見極めたうえでやるべきで、密な連携を取ること自体は全く悪くないと思います。

もう一つ、放任的なマネジメントになった理由はそれぞれのメンバーの忙しさからスケジュール通りに進むことが難しいと踏んでいたからです。常に何かに追われながらこのコンテストに取り組んでいたので、ベストエフォートな感じで取り組んでもらいました。

  • futabato: SecHack365

  • morioka12: セキュリティ・ミニキャンプ講師

  • y0d3n: セキュリティ・ミニキャンプ受講生

  • n01e0: CTF4b, ゴルフ * 10

全員忙しい中、献身的なハードワークをしてくれたので最優秀賞を獲得できたのだと思います。

この放任的なマネジメントは結果的に最優秀賞を獲得したので悪くは無かったものと感じてしまいますが、それだけで片付けてしまうのはいけませんね。あまり介入しなかったことによって診断関係の誰もやらないことはすべて y0d3n に任せることになってしまっていたので、必要以上のプレッシャーを与えて精神的に彼を苦しめてしまったと思っています。これが今回一番の反省で、日々過ぎていく中でも自分はうまくそこから改善することはできませんでした。

y0d3n が宇宙と交信しているのを隣で見ていましたが、僕はうまく声をかけてあげることができませんでした。

y0d3n.hatenablog.com

チーム内に責任を持って精力的に頑張ってくれている人の負担を分散させる簡単な方法はおそらく自分自身が一兵隊として非常に強くなることです。技術的な基礎理解を頭に入れるだけでなく、体に染みつくまで実際に手を動かして粘り強く学び続けて、その人と議論できるレベルにまで知識を吸収していかないと、自分ができないタスクをすべてその人に任せてしまうことになります。それはただただ歯がゆく、自分の無力さを感じるもので、最優秀賞を獲得して自分の力で道を切り開いたのかというと怪しくなってきます。

「放任的なマネジメント」と偉そうに表現していますが、実際は僕はリーダーシップを発揮していたわけではなくチームに頼りっぱなしで依存していました。自分が強くなれば仲間は信頼して自分を頼ってくれるようになると思うので、タスクを分散することができるように自分自身が強くなるよう、精進していきたいです。

意識のすり合わせ

課題が配布される前に、意識のすり合わせのために一度 MTG をしました。 コンテストなので、見つけた脆弱性の数だけでなくそれ以外のところでアピールが必要というのは昨年のコンテストからの学びでした。 今年は"うまくアピールする"というのを頭に入れており、そのアピールのためにルールで明文化されていないことについてはやっていいものとして意識をすり合わせました。

例えば VM が配布されることがわかっていたので VM を解析をしてソースコードをぶっこ抜く方針だったわけですが、この解析は明示的に禁止されていないものだったので解析はしていいものと決めました。もし IPFactory は解析しないという選択肢を取ったとしても他の 1 チームでも解析をして解析による恩恵を受けていたら最優秀賞の獲得に対して大きなビハインドを負います。私たちは最優秀賞しか望んでいないのです。予選を通過してくるようなチームは当然のようにソースコードを抜いてくるとして IPFactory は構えていました。

VM の解析以外にも、いくつかの準備をしながら英気を養いつつ課題配布日を待ち望んていました。

  • 診断管理のためのスプレッドシート整備
  • 脆弱性にかかわる診断ツールの用意
    • 2021 のコンテストで開発した Himawari がどこまで戦えるのだろうかとわくわくしていました。
  • 脆弱性の評価指標
    • 「脆弱性をして報告書を提出するだけでなく、今回コンテストではその報告書をもとに脆弱性をして再診断を行う」という前提にあったので、修正の優先順位が提示できる評価指標にしようとしていました。CVSS v3 の基本評価基準単体では対応の優先度が決まるものではないのでリスクレベルと攻撃難易度の組み合わせの独自評価にしようと考えをまとめました。
  • 報告書のテンプレート作り

他にも課題が配布されてからアピールのための工夫をした点として適切な診断管理や齟齬が生じないようにするための報告書の書き方には気をつけました。
IPFactory はプロジェクトのマネジメントについてはあまりアピールしていませんでしたが、工夫点が 2 位だったのはこれらの要素が積み重なったものなのでしょうか。

ありがとう FTKImager

課題が配布されて n01e0 はバイナリエディタでせっせと頑張ってくれてたのですが、「ガチじゃん」と苦戦していました。課題配布から 2 日くらい経ったころに y0d3n が FTKImager で .vdi ファイルからシュッとコードを抜いてくれたので、グレーボックスな診断ができるようになりました。

今年の課題は Web アプリケーションの脆弱性診断だったわけですが、FTKImager でソースコードを抜いてあらゆるファイルを確認していったので「今年の課題はフォレンジックだね」とチーム内で話していました。

delta と ripgrep が無二の親友

脆弱性診断が始まると、y0d3n は片っ端から診断をやってくれました。 僕は脆弱性ツールを使った自動診断を当初はやっていましたが、ツールで報告できる脆弱性はほとんどなかったので結果的にそこまで活躍できなかったです。

ただソースコードを抜いたので、grep による検索やコードリーディングに時間を割くことができました。実装コードが見えるのでミニマルに実装して該当部分の挙動を確認したり、PHP や Apache の設定ファイルから脆弱性情報を検索して試したりしていました。

最終審査会に向けた再診断も同様に FTKImager でソースコードを抜くことができたので、diff を取ってから挙動を確認する診断形態を取っていました。修正前後の diff を見ると、初回診断では変数名が明らかに雑だった箇所が修正されていたりするなど、脆弱性を埋め込んだポイントをコンテスト側は把握できるようにしていたのかなと考えていました。

最終審査会

予選を突破した後は最終審査会での発表になるわけですが、アピールできる場所がこの発表の場でしか無いというのが僕らを悩ませるものした。

昨年は一次審査の書類を読んでくれる前提で発表をしたのですが、おそらくその書類を読んでいない人から質問をいただいたので、最終審査会当日のみ審査員として採点に関わる人がいるものとしてメタ読みをしていました。

今年は昨年の反省を生かして以下の観点から精一杯アピールしたつもりです。

  • 読んでくれないかもしれないが再診断報告書を提出すること
  • スライドの発表には一次審査の書類を見ていない人もわかるような説明を意識すること
  • 発表内容も単に再診断の結果をお伝えするだけではつまらないので、何かテーマをもって発表すること

最終版のスライドは以下のものになります。

speakerdeck.com

テーマは「脆弱性の対策には根本的な対策が必要」です。
Cookie に SameSite 属性が Strict に明示的に付与されても、悪用可能な脆弱性は存在したままなので根本的に修正しましょうといった内容をデモを踏まえて解説させていただきました。

課題の 「MBSD 塾は通い形式の学習塾である」ことを利用した攻撃を予選の段階からどこかで入れたいねと話していたので、最高の形で発表シナリオに組み込むことができたと思います。

ただスライドが完成したのは最終審査会当日の朝 4 時だったので、デザインをもう少し改善したかったなと思います。
スライドに誤字もありますし、あと 2 日くらい寝かしているともう少し完成度の高いスライドを作ることができたのかなと思います。

今年も発表練習をする時間が確保できなかったので、内心ドキドキしていました。チームの皆が積み上げてきてくれたものを僕の拙い発表によってぶち壊してしまうのが頭によぎっていたからです。

スライドの遅延が酷かったようで音声と話しているスライドがリンクしていなかったらしいです。すみません。
うまく伝わっているか不安でしたが、発表点は 2 位だったので発表シナリオ自体は論理的に説得力のあるものだったのかなと思います。

リスクレベルの高い脆弱性は CSRF しか残っていないと IPFactory は判断していたので、RCE を発表されたら負けとドキドキしていました。89 チームの予選を突破してきたチームが発表するので当然のようにソースコード抜いて、最悪全チーム CSRF を取り上げて解説してくると踏んでいました。

ただ仮に CSRF を取り上げてきたとしても、共用 PC までを想定した攻撃シナリオが被らなければ優勝と踏んでいたので、全チームの発表を聞いて優勝できてそうと思えました。

ずっしりと構えるメンタル

「どうにかなるやろ」という心構えができる人は、ある意味それだけで才能を持っていると考えています。 僕は心配性なので、なかなか「どうにかなるやろ」と考えづらい性格をしています。僕にとっては結構羨ましい才能です。

コンテストにはメンタルも非常に重要な要素になり得ます。プロジェクトを進める中で少し行き詰ったりスケジュールが迫ってきている中で「どうにかなるやろ」と根拠は無くとも言ってくれるのは結構ありがたいものです。昨年はみんな心配性な性格だったので、うまく物事が進まなくて空気が重くなってしまったときもありましたが、今年はメンバーに n01e0 がいてくれたので、何度か「どうにかなるやろ」と言ってくれました。

筋肉でメンタルは鍛えられるのかなと思っていましたが、最終審査会の結果発表直前 n01e0 はかなり日酔っていました。

しかし最優秀賞が決まった後のインタビュー時には自信満々のコロンビアをしていました。

コロンビア
コロンビア

setten.sgec.or.jp

世界一を獲ると見える景色が違うこと、そして世界一の獲り方が分かると、その考え方は他の分野にも応用できる

この言葉は 2022 年度 SecHack365 第 2 回イベントデイでの情報通信研究機構 井上大介さんの講演で出てきた言葉です。

sechack365.nict.go.jp

何かで一番になることはおそらく僕の人生で初めてのことです。
先に述べたように最優秀賞を獲得することでなんとなく新しい景色が見えました。

この学校に入学してからインプットしてきた努力の質と量がこの MBSD Cybersecurity Challenges 2022 という場で最優秀賞というアウトプットになってくれました。

自分を高めていくには、努力のベクトルの向きが正しい方向を向いていて、大きさが大きい努力を継続する必要があることは当然のことです。
これまでのプロセスに大きな間違いは無かったんだなという確認ができたのは自分に自信を形作るとても良い結果になってくれました。

昨年の悔しい結果からいろんなやり方を工夫してここまで来れたのだと思います。昨年一緒にコンテストに参加してくれたメンバーに改めて感謝して、単に「これからも頑張ります」で終わらずにじっくり考えて反省も交えつつこれからに繋げられるようにしたいです。

優勝したのも束の間ですが、今日(参加記を書いているコンテスト当日)から切り替えてまた走り出します。 あとは卒業までじっくりと休んでもよいのですが、心が軽くなって何でも出来そうな今の勢いのまま、これまでと同じように今の自分に手の届く範囲で精いっぱい手を伸ばし続けることを継続していきたいです。

最後になりましたが、MBSD Cybersecurity Challenges 2022 に携わっていただいたコンテスト事務局の皆様、三井物産セキュアディレクション株式会社の皆様本当にありがとうございました。
今年も楽しいコンテストを、成長できる場として提供いただきありがとうございました！

最後までご覧いただきありがとうございました。
この記事は IPFactory Advent Calendar 2022 の 18 日目の記事です。

qiita.com

今年 IPFactory に加入してくれた 1 年生が命のリレーを繋いでくれたのでカレンダーが埋まってとても嬉しいですね。

昨日は n01e0 による MBSD Cybersecurity Challenges 2022 参加記でした。

feneshi.co

明日は 0kq くんによる投稿です。お楽しみに！