ある会社で開発したSNSのシステムにセキュリティ上の問題があると指摘されていたにも関わらずそのまま運用を続けていたところ、何者かに攻撃されてしまったようです。あなたのチームは、攻撃の全貌を解明できるでしょうか。

――どうやら今回はセキュリティ上の問題を指摘されたわけではなく、攻撃を受けてしまったようです。果たして、参加者は再び訪れたこの会社の危機を救えたのでしょうか？

どうもこんにちは！MBSDに所属する『とある診断員』の洲崎です。今回で三回目となる専門学校・高等専門学校生を対象としたセキュリティコンテスト「MBSD Cybersecurity Challenges 2018」が開催され、12月12日に最終審査会が行われました。ちなみに筆者は今回のコンテストにて初めて運営に参加し、課題コンテンツの作成や審査員などを担当しておりました。最終審査会の模様や運営側の裏話などについて今回ブログに書こうと思います。

本題に入る前に、まずは今回のコンテストの概要と最終審査会に至るまでの審査について、簡単に説明します。第一回、第二回までのコンテストでは、「システムにおける脆弱性の調査」が課題でしたが、今回は前回までとは趣向を変えた「攻撃を受けてしまったWebサイトの調査」が課題であり、いわゆるデジタルフォレンジックをテーマとしたものとなっております。参加者の方には、攻撃を受けてしまったLinuxで構築されたWebサイトのVMデータを課題としてお渡しして解析していただき、調査結果をまとめたレポートを作成していただきました。なお、レポートには以下のような項目をまとめていただきました。

• 攻撃に使われた脆弱性（攻撃者はどのような脆弱性を使って、どのような手順で攻撃を行ったのか）
• 被害の範囲（どのようなデータがどのくらい、漏えいや破壊されたのか）
• 対応方法（直近で行うべき暫定対策や、長期的に取り組む恒久対策など、対応方法の提案）
• 調査で行った工夫（ツールを使った・作った、チームメンバーの役割分担、調査手法など、解析を網羅的・効率的に実施するために行った工夫）

今回のコンテストでは、全国36校より106チームのエントリーをいただき、80チームの方より調査レポートをご提出いただきました。最終審査会については前回までと同様に、一次審査の結果勝ち残った上位10チームにてプレゼンを行い、レポートとプレゼンの結果を併せて審査し、上位3チームを表彰するというものでした。詳しくは詳細ページをご覧ください。

最終審査会の結果は？

一次審査を突破し、最終審査会に勝ち進んだ上位10チームについてはこちらのページに掲載されています。最終審査会では私も審査員として参加しておりましたが、攻撃を再現するデモを行ったチームや利用者への損害賠償金額を算出していたチームなどもいらっしゃり、どのチームもバラエティに富んだ素晴らしいプレゼンテーションでした。また、個人的に素晴らしいと感じたのは、いくつかのチームが、「このプレゼンテーションはSNSサイトの経営者に対するもの」など、「誰に対して、何を伝えたいのか」ということを意識されて、発表内容をまとめていらっしゃったことです。セキュリティエンジアには、技術力はもちろん必要ですが、同じくらい伝える力も必要となるため、上記のような意識は非常に大切なことであると思います。

最終審査の結果、チーム「IPFactory」が見事1位を獲得されました！1位の「IPFactory」と2位となった「MOFFU_MOFFU_ISC」については、両者とも攻撃の真相をほぼ全て解明されており、いずれのレポートも審査員全員を唸らせる素晴らしいクオリティでした。そのため、最終審査は運営側も非常に悩むものとなりました。厳正なる審査の結果、今回総合的な評価から、「IPFactory」がやや優勢と判定し、優勝とさせていただきました。「IPFactory」は2017に続き見事二連覇となりました。おめでとうございます！

どのような攻撃が行われたのか？

さてさて、ここからがコンテストの舞台裏に関するお話です。ここではSNSサイトは一体どのような攻撃を受けてしまったのかをちょっと紹介いたします。今回課題となったSNSサイトはざっと以下のような攻撃を受けていました。

• MySQLサービスに対する不正ログインよるシステム情報・データベース情報の窃取
• 複数のWebアプリケーションの脆弱性（SQLi、XSS、CSRF、認可制御不備、etc…）を悪用した攻撃よる情報漏洩、改ざん、システム内への侵入
• システム内へ侵入後の権限昇格による管理者権限の奪取
• 侵入した攻撃者によって複数のＷｅｂコンテンツを改ざん（Topページが改ざんされたり、ログインフォームが改ざんされ、ユーザのパスワード情報を窃取されていた）

etc…

ご覧の通り、攻撃者によってかなりボコボコにやられています。 いくつかのチームはレポートで攻撃者に関する色々な考察を書かれていましたが、今回運営側が事前に想定していた攻撃者は以下のような感じです。

上記図のように、狙いや手口などが違う複数の攻撃者がSNSサイトに対して攻撃をしているというシナリオでした。運営側としては攻撃者が複数存在するように見せるために、攻撃する際にIPアドレスや接続するブラウザ・ツールなどを変更して攻撃を試行していました。また、同じ攻撃者が単にIPアドレスを変更しているだけと思われてしまうかもしれなかったので、意図的に重複するような内容の攻撃を試行したりもしておりました。調査レポートにて複数の攻撃者が存在した可能性について指摘していたチームが多かったこともあり、狙い通り上手くログなどに痕跡を残せたのではないかと思っています。

実は攻撃を試行している中で想定外なこともありました。Webサーバのログを調査すると、攻撃者が設置したWebshell経由にて攻撃者のサーバ対して複数回リバースコネクトを行っている形跡がありますが、よく見ると一回だけ突然今まで登場しなかったレンジのIPアドレスに対してリバースコネクトを試みていることが分かります。実はこれは私の大失敗でネットワーク設定の問題で上手くリバースコネクトできなかったため、焦った結果、コピペミスして間違ったIPアドレス宛に接続を試みてしまったのです。おかげで恥ずかしいミスがばっちりログに残ってしまいました…。もし次回があればオペレーションはちゃんと全てスクリプト化しておこうと思います。そんな背景もあり、実は私がポカした痕跡を見つけてくれるチームはいらっしゃるのかなと思って密かに期待をして、レポートを審査していたのですが、いくつかのチームは別のIPアドレスに対して接続を試行していた旨についてちゃんと報告をしてくれていたので、若干救われました（笑）私のミスをちゃんと見つけてくださりありがとうございました！

また、これもちょっとした小ネタですが、改ざんされていたSNSサイトのTopページに「Mr.AYUSAM」という攻撃者の名前と思われる文字列が書かれています。

いくつかのチームのレポートではこの名前の由来などを色々推測されていて、読んでいて面白かったです。ちなみに、これは完全に私のジョークで逆さにすると私の席の近くにいるブログ執筆者一覧にも載っているある同僚の名前になります（笑）ただ、レポート応募いただいた80チーム中で、1チームだけこのジョークを看破されたチームがいらっしゃり、これはあまり想定していなかったのでレポートを読んでいて本当にビックリいたしました。名推理お見事です…！

コンテスト準備の裏話

ここからは、最終審査会の懇親会にてちょっとお話したコンテストの準備における運営側の裏話について記載いたします。今回コンテストの課題作成に当たって運営側で苦労したのは以下の二点です。

• 攻撃シナリオの作成
• SNSサイトの準備

攻撃のシナリオを作るのに意外と苦戦？

ネタばらしをしてしまうと、今回の課題となった攻撃を受けたWebサイトは「MBSD Cyber Security Charenge 2016」にて出題したSNSサイトを実はほぼそのまま利用しています（ログ出力などの設定は一部変更しておりますが、Webアプリケーションなどは完全にそのままです）。つまり2016年の参加者の皆さんが詳細に脆弱性を指摘してくださっていたにも関わらず、この会社はそのまま放置して運用していたということですね。全くひどい会社ですねー（笑）

もちろん０から攻撃を受けるWebサイトを構築することもできたのですが、少しでも楽がしたい運営側としても今回は攻撃の調査という新しいテーマであり、事前の検証などに力を入れたかったので、過去の資産を利用することにしました。また、今回既存のシステムをそのまま使ったのは、今回の課題用に色々作りこむとその改変の痕跡が残り、システムとして不自然で、攻撃との区別もつきにくくなるからです。というわけで、運営側は既に構築済みのサイトをどのように攻略するか検討していました。

当初は、「コンテスト用に作ったボコボコのサイトなんだから侵入するのは多分朝飯前だよね～」とか高を括っていたのですが、大きな落とし穴がありました。それは、「実際にやってみたら意外とシステム内への直接侵入につながる脆弱性は少なかった」ということです。SNSサイトには手っ取り早く侵入できるRCE(遠隔からの任意のコード実行）の脆弱性が一つだけ作りこまれていたのですが、以下のようなものでした。

SNSサイトのファイルアップロード処理において、本来の仕様ではJPEGファイルのみのアップロードを想定したものとなっているのですが、コード上の不備によりそれ以外の任意のファイルを公開領域にアップロードすることが可能となっています。SNSサイトはPHPで動作しており、この問題を利用して任意のPHPファイルをアップロードすることで、Webサーバが動作する権限にてOSコマンドを実行することが可能となるわけです。現実世界でも、Webアプリケーションのファイルアップロード処理に非常にありがちな脆弱性の一つですね。ちなみに、この処理のコードは2016年度セキュリティコンテストについてのブログに記載されています。一見この問題を利用して侵入すれば全く問題ないように思えますが、実はアップロードしたPHPのファイルパスの生成ロジックが以下のようになっています。

(ファイルをアップロードした時間＋ユーザIDに割り振られた番号)をmd5ハッシュした値＋アップロード時に指定したファイル名

このファイルパスの生成ロジックは非常に単純であるため、これはこれで問題があるのですが、一番の問題は利用者側からだとこの脆弱性の存在に気づくことがなかなか難しいという点です。筆者は実際にこの脆弱性を試してみた結果、「初見でこの脆弱性を速攻悪用できるヤツは、ソースコードの内容を知っている内部犯、もしくはかなりエスパーでは…」と正直思いました。そうなんです！この脆弱性を突くことで、簡単に侵入することはできるのですが、そのままだとちょっとシナリオとしてリアリティがなくなってしまうのではないかと感じたので結構困りました…。この問題については、運営内にて色々議論し、検討した結果、

攻撃者は、ソースコードの中身を見てこのロジックに気づいたことにすれば不自然じゃない

↓

何かソースコードの値を取得できるような脆弱性はないものか…

↓

そういえばMySQLのパスワード設定が脆弱だった！LOAD_FILE関数を使えばイケる！

上記のような発想に至り、「攻撃者はMySQLサービスに不正ログイン後、LOAD_FILE関数を利用してシステム内の様々な情報を収集し、その情報を元にWebアプリケーションの脆弱性を突いて侵入する」というシナリオが完成しました。実はこのようなことが他にもあり「一切コンテンツは変更しない！」という運営自ら設けた縛りプレイによって、攻撃のシナリオを組み立てることが意外と大変だったということがありました（笑）色々試行錯誤して、無事最終的には作りこまれていた脆弱性を活用した様々な攻撃をシナリオに盛り込むことができました！

SNSサイトの準備には実は涙ぐましい努力が…。

もう一つの苦労した点は、攻撃を受けるSNSサイトの準備です。「あれ？既存のサイトをそのまま利用しているんだからむしろ準備は簡単では？」と思いますでしょうか？今回の課題の文章をもう一度ご覧ください。

ある会社で開発したSNSのシステムにセキュリティ上の問題があると指摘されていたにも関わらずそのまま運用を続けていたところ、何者かに攻撃されてしまったようです。

お気づきでしょうか？そうなんです、課題となるSNSサイトは「運用」されている必要があるのです！以前のコンテストにて出題したSNSサイトについてはデータが全く登録されていない状態のものでした。今回の課題では、SNSサイトのサービスが利用されている状況で、攻撃を受けるシナリオとなっているため、そのための状況を作り出す必要があります。 というわけで、その準備のために運営みんなで、仕事の隙間時間で約一ヶ月間このSNSサイトを頑張って利用していました。ちなみに実はSNSサイトに登録されていたユーザ名はMBSDの筆者チームに所属する社員に由来するものが多く、少しでも多くデータを残したかったので一人が複数ユーザを演じて日記を投稿したり、メッセージのやり取りなどしていました。日記などはある程度リアリティがあった方が良いと思いましたので割と現実にあったネタなどを含めて書いています。というわけで、攻撃をしているよりも、稼働状態のSNSサイトを作り出す方が、地味に時間がかかる作業が多く色々大変だったのです。また、こちらもちょっとした小ネタですが、今回のコンテスト参加者の中には、この私達が日々日記を投稿していたSNSサイトのユーザにおけるフレンド状況（このSNSにはフレンド機能があります。）の相関図を作成し、やり取りの内容からなんとユーザ間の人間関係などを解析されていたチームもいらっしゃいました！

正直、このSNSサイトの日記やメッセージなどの内容に関する解析をしていただけるとは思っていなかったので、レポートを読んでいて非常に面白かったです（笑）運営側を楽しませていただきありがとうございました！

ご参加いただいた皆様、いかがだったでしょうか？

さて、参加者の皆様、今回のセキュリティコンテストはいかがだったでしょうか？ 近年ではセキュリティチームの性質について色を使って表現することが良くあります。攻撃技術を専門とするチームはRed Team、セキュリティ監視やインシデント対応などを行うセキュリティ運用チームはBlue Teamと呼ばれていたりします。前回までのコンテストは、「システムの脆弱性を発見する」というRed側の技術が主なテーマでしたが、今回は「ログなどから攻撃内容を解析する」というどちらかといえばBlue側の技術に焦点を当てたものでした。今回の課題を企画するにあたって、このような技術をあまり経験されてなかった方に課題を通して防御側の視点やログを解析する楽しさなどを体験していただければ良いなと思っておりました。運営側も色々と試行錯誤でしたが、最終審査会の懇親会にて、今回初めてログ解析に取り組めて非常に良い経験になったとおっしゃっていた何人かの学生の方がいらっしゃったので、運営側としては非常に嬉しかったです。今回のコンテストにご参加いただき、ありがとうございました！

以上、『とある診断員』からのコンテスト舞台裏の種明かしでした！

洲崎 俊 の他のブログ記事を読む