はじめに
※ 2022/08/01 タイトルを「Mciro Hardening の紹介」から「Micro Hardening 体験記」へと変更して再公開しました
ＦＦＲＩセキュリティエンジニアの新宮です。先日 Micro Hardening というセキュリティ系のイベントに参加する機会がありました。 本記事はその体験記です。
Micro Hardening は実践的なインシデント・レスポンスを体験できる参加型のイベントで、経験者・初心者問わず、興味があれば誰でも参加することができます。今回、私も未経験ながらに参加することとなりましたが、勇気を出して飛び込んだ甲斐もあり、学べることは多かったです。「未経験だから怖い」と尻込みしていれば、学習機会はどんどん減っていきます。物怖じせずにここ一番で踏み出す思い切りが、何事においても大事なのだと思います。
とは言え、正体不明の催事よりも、少しでも内情を把握できているイベントの方が、やはり参加への心理的障壁は少なく済むでしょう。この体験記が誰かの背中を後押しする一助となれば幸いです。
なお、ネタバレは禁止されておりますが、本記事につきましては主催の川口さんに掲載許可をいただきました。この場をお借りしてお礼申し上げます。
経緯
きっかけは週次の定例会でした。部署の方針として、メンバーには積極的にセキュリティ系のイベントに参加してほしいとのことです。タイムリーなことに、部長の中西さんがいうには、近々おあつらえ向きのイベントが開催されるというではありませんか。
そうです。それが Micro Hardening です。
実は中西さんは Micro Hardening の元となった Hardening Project の企画者の一人です。中西さん曰く Mirco Hardening は実践的なインシデント・レスポンスを体験できるイベントで、初心者でも気軽に参加できるとのことでした。
「初心者でも気軽に参加できる」
私は以前からセキュリティ系のイベントに興味がありましたが、自分の技術力に自信がないこともあり、参加に高い壁を感じていました。そのため、その文句は私にとって大変魅力的に響きました。技術力の向上には自主性を持った勉強が必要です。もしかすると、今がそのスタートを切る絶好の機会なのかもしれません。
本イベントは定期的に開催されており、今回のイベントの開催日は土曜日だといいます。休日に参加するのは正直気が引けましたが、これについては許可を取れば代休を取得可能とのことでした。
こうして、セキュリティイベント調査係の先鋒として、私に白羽の矢が立ったのです。
参加申請と代休の申請を済ませ、あとは当日を待つのみとなりました。当日に備え、Micro Hardening についてもう少し詳しく調べてみることにしました。
Micro Hardening とは
平たくいってしまえば、Micro Hardening とは Hardening Project の「ハードニング競技会」のカジュアル版です。といっても、セキュリティに馴染みのない方は Hardening Project という言葉自体を聞いたことがないかもしれません (かくいう私も、セキュリティ従事者の端くれですが寡聞にして知りませんでした)。
Hardening Project とは、「衛る技術」の価値を最大化することを目指す、10 年続くセキュリティ・プロジェクトです (公式ページより引用)。
「衛る」は「まもる」と読むそうです。カッコいいですね。
本プロジェクトは非営利のセキュリティ堅牢化競技会である「ハードニング競技会」を主催し、サイバーセキュリティ人材の能力向上に貢献してきました。ハードニング競技会では、8 時間に及ぶ実践的なセキュリティインシデント対応シナリオを体験できます。
まず、参加者は複数のチームに振り分けられます。そして、各チームはビジネスシステムを展開するための仮想ネットワーク環境を与えられ、商品を販売する EC サイトを運営します。この架空の EC サイトでは定期的にクローラが巡回し、買い物をします。この売上 (販売力) がスコアとして反映され、競技としての順位が決まります。
このまま何も起きずにサイトが安定稼働を続けるのであれば、売上は順当に伸びていくでしょう。しかし、現実はそう甘くありません。当然、EC サイトには予め用意されたシナリオに沿って様々な攻撃が試みられます。これらの攻撃を防ぐことだけを考えれば、サービスを停止するのが最も確実です。ただ、サービスを停止すれば、当然商品の売上は完全に滞ります。これでは本末転倒です。
高得点を目指すためには、サービスを停止せずに済むようなセキュリティ対策を迅速に見出し、それを適用する必要があります。
このように、ハードニング競技会では 8 時間に及ぶ攻撃シナリオを通して、実際のインシデント対応現場の空気感、その過酷さを経験できます。インシデント対応の事前予習として、これほど適切な催しは他にないでしょう。
かといって、インシデント対応の経験もなく、セキュリティやあまつさえ IT の知識が希薄な人にとっては、いきなりそのようなハードな現場に身を投じることはハードルが高いかもしれません。ハードニング競技会のコンセプトを保ちつつ、初心者に優しく、もう少し気軽に参加できる、そんな都合の良いハードニングイベントはどこかにないでしょうか。
実は、あります。
そうです。それが Micro Hardening です。
正確には、ハードニング競技会のカジュアル版として Mini Hardening というものがあり、更にそれをカジュアルにしたものが Micro Hardening となります。つまり、カジュアル版のカジュアル版というわけですね。しかし、カジュアルといってあなどることなかれ。
Micro Hardening は 1 セットが 45 分間ですが、その中にこれでもかというほど攻撃シナリオが凝縮されており、短時間で実際のインシデント対応の空気感を知ることができます。
小規模ですが、ルールについてはハードニング競技会と変わりありません。参加者は複数のチームに分かれ、架空のショッピングサイト (EC サイト) を運営し、あらゆる手段を以て、そこに向けられる攻撃からサイトを防衛します。
ハードニング競技会との最大の違いは、ハードニング競技会は 8 時間 1 セットを 1 回やるのに対し、Micro Hardening は 1 セット 45 分を 3 回やるということでしょう。また特筆すべきは、セット毎に異なる攻撃がなされるわけではなく、毎回全く同じ攻撃が、全く同じタイミングで行われるという点です。これにより、参加者はセットを繰り返す毎に試行錯誤でスコアを伸ばすことができます。俗にいう覚えゲーというやつです。
ここまで聞くと、こう疑問に思われる方もいるかもしれません。
──全く同じシナリオを経験しても、新手の攻撃に対する咄嗟の判断力は身につかないのではないか。
──どうせ複数セット行うなら、色々な攻撃パターンを経験した方がよいのではないか。
しかしながら、同じシナリオを経験することにも意味があるのです。
実際のインシデント・レスポンスでは、「この攻撃どこかで見たことがある」「前にも似たようなログを読んだことがある」といった過去の経験が物をいいます。Micro Hardening では、まさにその「どこかで見たことがある」を体験し、実際に前セットの経験則を元に予防策・対策を打つことで、効率的にインシデント対応の勘所が掴めるということなのです。
どうでしょうか。ここまでで、Micro Hardening の何となくのイメージは付きましたでしょうか。前置きが長くなりましたが、次章からはいよいよ Micro Hardening の体験記を書き綴っていきます。
なお、今回私が参加したのは、Micro Hardening v1 の改訂版となる Micro Hardening v2 となります。v1 との主要な差異は以下の 5 点です (以下、公式ページより引用)。
- 競技環境を更新
- 新しい脆弱性やソフトウェアを導入
- サービスの稼働率を SLA ポイントとして集計
- 業務要件の制約の中でセキュリティ対策を実施することを実装
- v1 の難易度を 10 とすると v2 の難易度は 15 程度
演習当日
※重ねて申し上げますが、ネタバレ禁止と釘を刺されているため、詳細な演習内容を語ることはできません。ご理解のほどよろしくお願いいたします。
演習当日。
8:45 に Zoom のオンライン会議がオープンするということなので、普段よりもかなり早起きする必要がありました。目覚ましを何重にもかけることで最悪の事態だけは免れることができましたが、やはりコンディションは万全とは言い切れませんでした。寝ぼけ眼を擦りながら、オープニングに臨みます。
参加者は 40 人強から 50 人弱くらいだったでしょうか。Zoom の一画面に全参加者のアイコンが一斉に表示される様は中々に壮観です。見知った顔ぶれはありませんが、皆一様にこの業界に携わるいわば同胞であり、その彼らが今日、図らずも共通の志を持ちこの場に集まったことを思うと、そこはかとなく感じ入るものがありました。
しみじみしているうちに時間となり、主催の川口さんからの説明が始まります。以下はその概要となります。
まず、Micro Hardening では基本的に答えは教えないとのことです。非営利の活動ということもありますが、演習および振り返りを重視することで、参加者の自発的な成長を促しているようです。
演習の始め方ですが、こちらから何かアクションをするわけではなく、開始時間になると自動的に開始されます。前述の通り、全く同じ演習を 45 分間 3 セット行い、参加者は試行錯誤してスコアの向上を目指します。実際のサイバー攻撃のインシデントレスポンスでは 45 分どころか一日かけても終わらないなんていうことはザラにありますが、演習を通して少しずつ出来るようになっていく実感を持つことが肝要だといいます。
演習の取り組み方としては、共同作業と役割分担が重要です。やるべきことを考えて、うまく分担して作業することが、スコアを伸ばす秘訣です。
スコアの変動はスコアボードに反映され、リアルタイムで我々も確認できます。演習における我々の対応が正しいか誤っているかは、スコアによって判断します。スコアが上がっていれば正しく、スコアが横ばいになっていれば何かをしくじっているということです。スコアの増加は、先述した通りクローラの定期的な買い物による売上によってもたらされますが、その他にも 2 つの要素がスコアに反映されます。
ひとつは SLA。SLA とは顧客との間で取り決められたサービスの品質保証水準の合意のことです。今回の場合はサービスの安定稼働率が SLA で保証されているという設定で、それをどれだけ満たせているかがスコアに反映されます。いわゆる可用性に関わる部分ですね。
もうひとつは防御点。用意された攻撃をどれだけ防げたかを示す指標です。攻撃の種類による得点の差異はなく、単純に防御した攻撃の数のみがスコアに反映されます。
演習の進行についての説明を終えたあと、川口さんは Micro Hardening の理念についても語ってくださいました。
Micro Hardening には、演習を通して参加者に失敗を経験してほしいという想いがあるそうです。世にある演習と呼ばれるものは基本的に解けることを前提として作られていますが、Micro Hardening では全体の 3 割程度しか解けないことを前提としており、その失敗から学びに変えてほしいとのことです。
そのためには、記録を取ることが非常に大事です。いつ誰が何に気づいたか、気づいてどういう対応をしたかを意識して記録することで、初めて演習の経験が学びに変わります。記録は最後に参加者全員で共有するので、いい加減なものは書けません。
最後に、演習環境の説明がありました。以下に OS、使用ツールの情報を記します。
- OS
- Linux
- データベース
- MariaDB(MySQL): WordPress 管理用
- PostgreSQL: ショッピングサイト管理用
- その他主要な使用ツール
- WordPress: Web ページ管理用
- Flat CMS GRAV: Web ページ管理用
- EC-CUBE: EC サイト管理用
- Apache: Web サーバ
- Nginx 81: システム管理用
ここまでが演習内容のあらましとなります。
説明を終えて、各々演習の準備を始めます。私もこの間にチームメンバーの方と顔合わせをしました。
チームの枠は 1 から 10 の合計 10 チーム設けられており、参加者は申請の際に希望のチームに参加します。1 チームごとの受け入れ可能人数は 6 人までですが、参加者が集まらなければそれを下回ることもあります。私は特に何の考えもなく、単に端っこのほうが落ち着くという点でチーム 10 を選択しました。
私の所属するチーム 10 は J さん、M さん、私の 3 人構成でした。当然ですが、作業の分担を考えると人数が多いチームほど有利になります。人数の上限は 6 人ということを考えると、3 人は多いとは言えません。これは増々気を引き締めて臨まなければなりません。
チームメンバーのお二人は普段から IT 関連の業務に携わっているということで、とても心強かったです。むしろ、私が何か足を引っ張ってしまうのではないかと気が気ではありませんでした。
自己紹介を済ませると、自然と話題は演習の作戦会議へと移りました。演習をどう攻略するか、どのような方針でスコアを伸ばすか。私は、参加する前に中西さんから伝えられていたことを思い出しました。
「Micro Hardening には定石のようなものがあり、第 1 セット目ではとにかく情報収集に務めるべき。そうして手に入れた情報を元に第 2 セットでは出来得る限りの対策をうち、第 3 セット目で最適化を目指す。それが最も効率の良い立ち回りである。」
これをチームメンバーと共有し、演習の大まかな方針とすることで合意しました。
私の役割としては、第 1 セットはとにかくログを読み込んで情報を集めることになりました。開始時間が迫ってきたため、Apache のログファイルに tailf コマンドを実行し、リアルタイムでログを表示できるようにします (tailf: ログ追跡用のコマンドで、ファイルに追加される行を同期的に表示できる)。
さあ、いよいよ演習が始まります。
第 1 セット
演習が始まってすぐ、J さんが検索フォームの脆弱性を発見しました。J さんは更に稼働中のサービスや導入しているプラグインの中で必要のなさそうなものを特定するなど大活躍でした。
その他は何も起きた様子がなく、最初の数分はただ流れていくログを眺めていました。
ところが、開始から 4 分くらいの時点で、チーム間にスコアの差が付き始めました。Web サイトを見たり、ログを追ってみたりしても何か異常があったようには思えません。どうやら、スコア反映のタイミングにチーム間で差があるらしく、これについてはそれが原因だろうと結論付けました。
その後、M さんがサイトの更新内容を確認していると、明らかな攻撃の痕跡が見つかりました。スクリプトがそれと分かる形で仕組まれており、これについても第 2 セットでの対策が必須となるでしょう。
開始からしばらくたった頃、Web サイトのレイアウトが改ざんされました。これが売上にどう影響を与えるのかは分かりませんが、外部からレイアウトを改ざんできるような操作が可能ということは事実であり、原因の特定は急務でしょう。
WordPress のダッシュボードにも攻撃の痕跡が見られ、レイアウトの改ざんにはこれが絡んでいそうだと推測できました。攻撃の性質から認証情報が漏れているのではないかと推察できるため、第 2 セットではまずパスワードの変更を試みようという話になりました。
また、これらの攻撃以外にも、EC サイトが度々停止する事態が発生したため、その都度サービスを再起動する必要がありました。サイトが停止している間は売上も停止するので、迅速な復旧のため、常にサイトの稼働状況を把握できるようにしていなければなりません。ブラウザーで Web サイトを閲覧するとキャッシュが表示される可能性があるため、クローラの巡回状況からサイトの稼働を確認するのがセオリーです。
その他にも、名前解決ができなくなったり、ファイアウォールの設定が改ざんされたらしい痕跡が見つかったりするなど、稼働しているサービス全般に目を光らせる必要がありました。そうして攻撃の波に圧倒されるまま、第 1 セットが終了しました。
以下が第 1 セットのスコアになります。
J さんと M さんはとても集中しており、私が第 1 セットの終了を告げると驚いたような反応を示しました。実際、体感としては 45 分間とは思えないほど濃い時間を過ごした気がします。対応しなければならないインシデントの量があまりにも多く、時間内に全てを把握し切るのは難しいと感じました。なるほど、これが「3 割しか解けない」ということでしょうか。
第 1 セット終了後に 2 時間半ほどインターバルがありました。この間に各チームは休憩を取ったり次セットへの対策を練ります。
まず、必要のないサービスやプラグインを停止・削除する必要があるでしょう。また、特定サービスにアカウントが追加されていたことから、データベースへの外部からのアクセスを禁止できれば安心です。
ファイアウォールの設定が改ざんされていることから、Linux のログイン情報が漏れている可能性も考慮しなければなりません。
他にも複数のサービスのパスワードを変更するなどして、次のセットに備えました。
私はここまでお二人に頼り切りだったため、何か自分にも貢献できることはないかと思索を巡らせました。ブログを書くことはこのとき既に決まっていたこともあり、何か爪痕を残そうと必死だったのです。
私は、先程のスクリプトを仕込んだ攻撃をファイアウォールで防御できないかと思い至りました。しかし、お二人に意見を仰ぐと、ログの量が膨大で攻撃元の IP アドレスの特定に時間がかかるため、一旦放置した方がよいだろうということでまとまりました。
そうは言っても他に出来ることも思い浮かばなかったため、私は休憩時間の間にログを精査し、IP アドレスを特定できないか試してみることにしました。
まずはログファイルを開いて眺めてみます。大量のログの羅列にめまいがします。
このままでは当然探し出すことができないため、grep で絞り込むことにします。攻撃があったページの URL を使い grep を試してみたところ、案外簡単に絞り込むことができました。絞り込んだ IP アドレスは 3 つでしたが、これはそのページの更新のあった回数と一致していました。攻撃のあった具体的な時間帯は特定できませんでしたが、WordPress からアクセスのあった順番は判別できます。
そうして特定した IP アドレスを共有し、ufw (簡単な操作でファイアーウォールを設定できるコマンド) でフィルタリングしました。この他にも M さんがログ情報から別の攻撃元の IP アドレスを特定し、同じくフィルタリングしました。
果たして、これにより先程の攻撃を防ぐことができるのでしょうか。答えは第 2 セットになれば自ずと分かるでしょう。
第 1 セットは膨大な情報量を処理するのに全てのリソースを注ぐ必要がありました。第 2 セットでは、きっとこれらの情報をもとに我々の逆襲が始まることでしょう。
第 2 セット
第 2 セットでは、第 1 セットで集めた情報を元に、先述の通りいくつかの対策を実施することにしました。インターバルの間に対策を済ませたため、第 2 セットでは新たな攻撃の発見にリソースを注げます。
まず個人的に気になることとして、ファイアーウォールの設定は上手くいったのでしょうか。先程スクリプト攻撃があったページを監視してみても、攻撃の痕跡は確認できません。結局、最後まで攻撃者からのアクセスは無かったため、先刻特定した IP アドレスは攻撃者のものだったということになります。これでようやく肩の荷が下りました。
さて、わだかまりも無くなったところで、第 2 セットの進展を詳述しましょう (といっても、細かい部分は描写できませんが……)。
先程のアカウント追加の件について、これは第 1 セットの冒頭で判明した検索フォームの脆弱性を利用しているのではないかという考察に至りました。この脆弱性を修正するにはプログラムに手を入れる必要があるため、原因が分かっていながら、第 2 セットでもそのまま残されていました。つまり、このまま行けば再びアカウントが追加されてしまうということです。
他にも、新たな見解として、商品の値段や購入時のロジックが書き換えられていることが判明しました。スコアが横ばいになるのはこれが原因だったのでしょうか。急いで WordPress の設定を修正します。
第 1 セットからの発展はこれくらいでしょうか。以下が第 2 セットのスコアになります。
事前に打った対策が奏功し、第 1 セットよりもスコアが伸びていることが分かります。防御点は 1 から 7 に上昇しており、我々の考察が間違っていなかったことを裏付けています。
しかし、第 1 セットと同様、途中からスコアが横ばいになってしまっています。購入できなくなっていることは分かりますが、攻撃の詳細が分かりません。先程の WordPress の修正のあとでもスコアの推移は変わっていないため、何か他の理由があるのかもしれません。第 3 セットでは、この原因の解明を目指します。
さて、第 3 セットに向けてできることは何でしょうか。
まずは、これまでに WordPress への攻撃が目立ったこともあり、WordPress にアップデートを施したほうがいいという話になりました。演習資料にはプロキシ設定をすることでインターネットにアクセスできると記載されていたため、それを参考に設定を試みます。
また、アカウント情報の保護のためにデータベースのバックアップを取ることになりました。データベースは WordPress 管理用に MariaDB、ショッピングサイト管理用に PostgreSQL の 2 つが用意されており、それぞれについてバックアップ方法を調べることにしました。
しかし、これらの設定方法はインターバルの間に調べ切ることができず、第 3 セットにもつれ込むこととなります。
第 3 セット
第 3 セットでは、第 2 セットで得られた情報を元に、さらなる効率化を目指しました。
まず、第 2 セットで行った対策と同様の対策を第 3 セットにも流用します。さらに、LAN 内のあらゆる IP アドレスからのデータベースへのアクセスを禁止することにより、ユーザーを追加される可能性を潰します。
第 3 セットでも、私はログの調査を継続しました。また、定期的にサイトを確認してサイトレイアウトが改ざんされた痕跡を確認し、その部分を WordPress で修正しました。
第 2 セットからの進展の話をしましょう。
WordPress をアップデートするためにプロキシを設定してインターネットにつなげようとしましたが、こちらについては結局終了時間まで設定方法が分かりませんでした。
データベースのバックアップについては、M さんが MariaDB のバックアップ方法を調べてくださり、バックアップを取ることに成功しました。私は PostgreSQL のバックアップ方法を調査しましたが、こちらは演習時間中にバックアップを取ることができませんでした。
また、肝心の購入できなくなる問題ですが、これは 3 人で考えても最後までよく分かりませんでした。WordPress の不具合を修正したあと、ローカルで購入できることは確認できましたが、クローラの巡回状況を見る限り、そちらでは上手くいっていないようでした。
総評として、結局第 2 セットから大きな発展はなかったということになります。
以下が第 3 セットのスコアになります。防御点の分わずかにスコアが増加していますが、ほとんど第 2 セットと変わらない結果になりました。
振り返り
演習終了後にチームで振り返りを行いました。
やはり、購入できなくなる問題を特定できなかったことが心残りです。経験者チームであるチーム 1、2 を除きこれを打破できたチームはチーム 3、6 だけなので、他チームにとってもここが鬼門だったのでしょう。
プロキシ設定やバックアップについても未練がありますし、結局ファイアーウォール等の Linux の設定を書き換える攻撃者 (おそらくシェルにログインしている) の足取りは分かりませんでした。
また、ログチェックの簡易化のため、異常なログのアラートを通知するスクリプトをささっと書ければ、大分余裕が生まれたかもしれません。
私個人としては、少しでもチームに貢献した実績を残すことができたため、当初は何 1 つ貢献できずに終わることを恐れていたことを考えれば上出来なのかもしれないと感じました。
演習を通じて感じたことは、セキュリティの専門的な知識がなくても、インフラや Web といった分野ごとの知識があれば、ある程度脆弱性の予想ができそうだということでした。むしろ、セキュリティの知識をかいつまんで覚えるよりも、全般的な IT の知識を養うほうが、セキュリティの技術力を高める近道な気がします。
当面の課題を再認識し、Web サイトのインシデント・レスポンスという新鮮な体験もできたため、今回の Micro Hardening 参加は私にとって大変貴重な経験になったと思います。
次に参加する機会があれば、もう少し事前に必要な知識を蓄えて、今回超えられなかった壁を超えられるようにしたいですね。
おわりに
今回は、Micro Hardening についての体験記でした。
インシデント・レスポンスは 1 年前に研修で経験したことがありますが、今回はまた新鮮な気持ちで臨むことができました。研修内容を忘れていたという意味ではありません。研修では Windows のローカルなログを精査して概要を把握するという流れでしたが、今回は外部に公開するサーバーを含むある程度大規模なシステムを相手取ることになったので、インシデント・レスポンスといって一絡げにはできないのだなと実感したのです。
今回、セキュリティ系のイベントに初めて参加したことで、自分の殻を破れた感があります。代表的なセキュリティイベントである CTF にも興味があるため、常設のものから始めて、そのうち小規模のものでもいいので実際の大会に参加していければと考えています。
これが単なる虚勢でなければ、きっとまたブログを書くことになると思いますので、その折にはよろしくお願いいたします。その時には、もう少し技術的なことに焦点を絞って記事を書けるようになっていたいですね。
ＦＦＲＩセキュリティはこの他にも様々な技術紹介ブログを公開しています。多くは案件の知見がベースとなっているため、セキュリティ系の仕事に興味のある方がいましたら、ご一読いただけると面白いかも知れません。
ＦＦＲＩセキュリティではサイバーセキュリティに関する研究開発を希望するエンジニアを募集しています。セキュリティに興味がある IT 従事者の方々、あるいは、セキュリティ業界に関心のある学生の方々。少しでも心惹かれるところがありましたら、是非こちらの採用ページをご覧ください。
ともにＦＦＲＩで、衛る仕事をしてみませんか。
