【Micro Hardening v2】やさしめセキュリティインシデント体験記

どうも、システムソリューション部の Inusuki です。

セキュリティインシデントというのは、ユーザーから見ても身近なもので、ある日利用しているサービスがサイバー攻撃の標的となり、サービスが利用不可となったり、一部機能の利用を停止して縮退運用するということがあります。

今回はそんなセキュリティインシデントを実際に体験できるイベント『Micro Hardening』に参加してきましたので、体験談をブログにまとめました。

お断り

・本ブログではネタバレを控えるため、Micro Hardening で行われた攻撃の実例、及びその詳細な対処法は含めておりません。
・Inusuki の個人的な見解が大いに含まれています。
・演習は全6セットありますが、ダイジェストでお送りいたします。

Micro Hardening って何？

Hardening サブプロジェクトの一つ、1~4人のチームでクラウド上に構成された小規模環境を、様々なサイバー攻撃から守り、攻撃を受けた際の対応能力を磨く演習です。短期間かつ複数セットに分けて、毎回同じ攻撃が行われます。

本家の Hardening Project は求められるレベルや参加ハードルが高いため、インシデント対応経験がなくとも気軽に参加することのできる Micro Hardening は、非エンジニアやセキュリティを学び始めた方にオススメのハードニングイベントだと思います。

バージョンによる違い

Micro Hardening v2 は v1 と比べてインシデントの数が多めです。

また、業務要件を満たす基準として SLA（Service Level Agreement）が新たに導入されています。競技においてはサービス品質というよりも、定められた業務要件（稼働時間や売り上げ）を満たすといった意味合いが強かったです。

本編

導入

競技会場のある淡路島へと向かうべく、地下鉄、JR、バスと乗り継いで現地入り。
前日に数々のインシデントに怯え楽しみ過ぎて眠れなかったこともあり、乗り継ぎ後のバスで仮眠を取りました。

それはさておき、淡路島。
やはり観光で人気ということもあり、ロケーションがとても良く、競技会場の SAKIA（サキア）からも瀬戸内海が一望できるほどでした。

また、SAKIA は閉校した小学校を、リノベーションしたコミュニティ施設でレストランやホテル・コワーキングスペースなどあり、親しみやすい雰囲気が良い感じです。

事前説明とチーム分け

事前資料をもとに、イベントの説明とチーム発表がありました。
（資料内のメインは競技環境情報に関するものなので、ここでは割愛します）

チーム構成については当日に発表されたので、事前にコミュニケーションをとることはできませんでしたが、Inusuki の居たチーム1は、プログラマーの方が3名&Inusukiでした。

人によってはバックグラウンドもイベントに参加した経緯も違ったので、話してて面白かったです。

イベント開始

〇 第1セット

"GET /_________________________________________________ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /_____aaaaa______a_____a_____a__aaaaaaa___________ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /____a_____a____a_a____aa___aa__a_________________ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /____a_________a___a___a_a_a_a__a_________________ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /____a__aaaa__a_____a__a__a__a__aaaaa_____________ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /____a_____a__aaaaaaa__a_____a__a_________________ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /____a_____a__a_____a__a_____a__a_________________ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /_____aaaaa___a_____a__a_____a__aaaaaaa___________ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /_________________________________________________ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /_________________________________________________ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /_____aaaaa___aaaaaaa_____a_____aaaaaa___aaaaaaa__ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /____a_____a_____a_______a_a____a_____a_____a_____ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /____a___________a______a___a___a_____a_____a_____ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /_____aaaaa______a_____a_____a__aaaaaa______a_____ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /__________a_____a_____aaaaaaa__a___a_______a_____ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /____a_____a_____a_____a_____a__a____a______a_____ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /_____aaaaa______a_____a_____a__a_____a_____a_____ HTTP/1.1" 404 486 "-" "curl/7.29.0"
"GET /_________________________________________________ HTTP/1.1" 404 486 "-" "curl/7.29.0"

ゲーム開始とともアクセスログに出力される[GAME START]のアスキーアート、始まった……Micro Hardeningが。
とりあえず最初は『見』に徹して事象を整理し、タイムラインを作成するという方針をもとに、ノーガードでいくことになりました。

開始から数分経過。
特にインシデントらしきインシデントは起こらず、内心緊張感が薄らいでいました。
（これが、嵐の前の静けさだったことを、この時の Inusuki は知らない）

少しして、チーム内でサイトタイトルが改ざんされているとの報告が……
ECサイトをリロードすると、サイトタイトルに表示される『hacked anonymous』の文字。
なんて大胆な宣戦布告なのでしょうか。

とりあえず、該当期間近辺のアクセスログ調査に入ると、不審なURIに対してのリクエストがありました。
しかも、HTTPステータスコードの200を返している。
ドキュメントルート配下を見ると、ありがちなファイル名で見覚えのないphpファイルが存在していました。
どうやら何らかの脆弱性をつかれて、バックドアを仕掛けられたようです。

そうこうしているうちにECサイトの商品価格を不正に操作される事件が発生しました。
恐らくはECサイト用データベースの管理ユーザ情報が漏洩したか、もしくはSQLインジェクションによってレコードの Update が不正に行われた可能性があります。
前者であれば、この時点で大体収集がつかないかもしれません。

並行して、商品ページにユーザーが誤認するようなログインフォームを埋め込まれたり、目がチカチカするような攻撃者のお気にのページレイアウトに変更されたりと……
そして、最終的にはサービスがダウンし、ボロボロになりながら1セット目が終了したわけです。
ほんと、散々な目に遭いました。楽しい。

1セット目の結果はどのチームも停滞していました。

防御列は評価項目をいくつクリアしたかによって増減します。
今回はノーガードだったので、自チームの防御点は0点です。
ただ、ガチガチに防御してしまうと、正規クローラーの購入ステップに影響を及ぼす可能性があり、必ずしも防御したからといって、SLAが向上するわけではないようです。

〇 第2・3セット
続く第2・3セットでは、具体的な侵入経路の特定や根本的な対策までは目途が立っていなかったため、方針としては『手分けしてサービスを停止することなく耐えよう！』くらいの感じで、準備期間内に諸々の設定修正、セキュリティパッチの適用を済ませて臨みました。

前述の通り、タイムラインから決まったタイミングで決まった攻撃、インシデントが発生するので、一度対策を講じてしまえば、後々の心持ちが比較的楽かと思います。

…………しかし、サービスが停止する事象は変わらずでした。
ただ、暫定的ではあるものの侵入や改ざんの一部を食い止めることには成功しました。

〇 第4・5セット
上記の結果を受け、第4、5セットでは改善箇所の見直しと、3セット目までに表面化した脆弱性、インシデントを踏まえて、再度改善・緩和策を練ることになりました。

特にある時点でサービスが停止してしまうのは致命的であるため、ここは回避しなければなりません。
事象からWebサーバーへ到達する前に、タイムアウトを返しているので、それとは異なるレイヤーで何らかの問題が発生している可能性があると考えました。

競技環境には複数のサーバーが混在しているため、この辺りの仕様はチーム内で詳細に把握、整理しておく方が今更ながらよかったと思います……
結局のところ、このセットで適用した改善・緩和策もあまり効果的ではなく、SLA の低下を免れることはできませんでした……

〇 第6セット
最終セット前に部分的なヒントをいただける機会があり、そのヒントをもとに改めて確認することになりました。
結果からすると、とあるサービスを再起動するだけで改善しました。

目星を付けていたサービスだけに他のインシデント対応にかまけて、該当サービスログの精査を疎かにしたことを、このブログを執筆している時でさえすごく後悔しています……
その後は前述の施策が評価されたようで、停滞することなくSLAが向上していきました。

最終セットを含めた結果は以下の通りです。


最初は50%のパフォーマンスしか発揮できないといわれる通り、1セット目と6セット目では、各チーム2倍以上スコアに差があることがわかります。
反復して取り組むことの重要さが窺えますね。

実際、1セット目の時と6セット目の時では、チーム内でもスムーズにインシデントに対応できていたと思います。

Micro Hardening を100%楽しめるコツ

今後イベントに参加される方向けに Micro Hardening を100%楽しめるコツ（Inusuki の反省点を含む）を以下にまとめます。

1. 事前知識はある程度必要
非エンジニアや初学者の方であれば、LPIC-1 に出題される範囲のコマンドの使い方は抑えておいた方がよいかと思います。

演習では基本的な仕様であったり、サービスの再起動方法の補足はありますが、コマンドの説明まではされないためです。

2. チームビルディングがめちゃ大事
セットの目的や誰がどの役割を担うのか、次のセットではどう取り組むのか、というところを詰めていきましょう。

今回の場合だと、第1セットでタイムラインを作成するのみで、別途チーム内で仕様書を把握・整理するなどの時間を取らなかったことが、後々響いてきたのだと痛感しています。各自で把握されているのだとしても、一度チームで目を通し、認識を合わせるということが大切です。

3. 作業証跡を残そう
これは Slack でも Google スプレッドシートでもよいので残しておきましょう。
後々誰がどのような対応をしたのか、整理するうえでも大事です。

4. 外部サービスやツールの利用を検討しましょう
問題を顕在化したり、サービス品質を保つためには、やはり外部サービスやツールを駆使する方が現実的です。

Inusuki のように我が身一つでどうにかなると思わないでください。
スコア上位に上がっているチームはこの辺りの使い方が上手かったです。

5. 業務要件を満たすことを意識しましょう
単にサービスが稼働しているだけではスコアが伸びません。
どのようにしてスコアが上がるのか、また業務要件を満たすとはどういうことなのか、一度考えてみてください。

まとめ

競技会レベルの環境をすぐに実装するのは難しいかもしれませんが、社内でもセキュリティインシデントの体験会くらいは行いたいですね。

ここまでご閲覧いただきありがとうございました！