CrowdStrikeのインシデントを掘ってみる
はじめに
既に２ヶ月前のお話になっていますが、CrowdStrikeのインシデントによるWindowsブルースクリーン問題を興味本位で掘っていこうかなと思います。
自社だけでなく他社の事例も知っておくことで、自社のシステムに対するリスクを見直すきっかけになるかもしれません。有り難くポストモーテムを読んでいきましょう！
何があったのか？
ざっくり言うと 「CrowdStrike FalconのFalcon Sensorを利用しているWindowsデバイスが当該製品のアップデートをしたことでクラッシュし、ブルースクリーンが発生してしまった」 というインシデントです。 様々な解説記事などが出ているため「このくらいは知ってるよ」って方が多いと思いますが、まずはこれくらいの認識から始めていきましょう。
ちなみに、Wikipediaに 「クラウドストライク事件」 として記事がまとめてありましたので、こちらを読まれるのもよいでしょう。
ENの記事の方が詳しく書いてあるので、詳しく知りたい方はこちら
どのような影響があったか？
Microsoftの報告によると、この影響を受けたWindowsデバイスは 約850万台 に及び、ザッと影響の出ていた業界を挙げると
- 航空業界 ：ユナイテッド航空・デルタ航空・アメリカン航空で一時的なグローバルグラウンドストップ。イギリス、アジア圏でも多くの航空会社で全フライトへ影響が出ました。
- 金融機関 ：アメリカ、オーストラリア、フィリピンなど多くの国で提供しているサービスが運用困難な状態になりました。
- メディア ：フィリピンや、イギリスなどのテレビ放送でも影響が出ていた。
- オリンピック ：先日開催されたパリオリンピックでも局所的にですが影響が出ていました。（ユニフォーム配送に関わるシステムに影響が出たらしい）
となり、他にも医療・小売業など多数の業界で影響が出ていました。
Windowsデバイスを使っていて、問題を回避していた航空会社もありましたが、 Windows 3.1とWindows 95を使っていたため問題を受けなかった というのは面白いお話ですね。
CrowdStrike側が負う金銭的な影響としては、まず 株価の急落 があります。
CrowdStrikeの株価が 40%を超える下落 、Microsoftも巻き込まれるように 15%ほどの下落 となりました。
また、この問題で影響を受けた各業界からの損害賠償請求があり、公表されているものでデルタ航空による 5億ドルの損害賠償請求 を求める予定だそうです。
このように非常に広範囲かつ、深刻な影響がたった一つのインシデントで発生したというわけです。
このインシデントは、2024年度の Pwnie Awards（セキュリティ分野における功績/失敗を表彰する賞）で 「Most Epic Fail（最も壮大な失敗）」 に選ばれています。
ちなみに2023年度の同賞は「Transportation Security AdministrationのNo fly list（テロリスト監視リスト）の流出」だったりします。
どのような対応を行ったか？
CrowdStrikeはこのインシデントに対してどのような対応を行ったでしょうか？
時系列にすると以下のようになります。
- 2024/07/19 13:09 ：問題を含んだFalcon Sensorの更新をリリース
- 2024/07/19 14:27 ：問題を認識し、不具合のある更新を修正
- 2024/07/19-20 ：更新してしまったWindowsデバイスの修復方法を公開、ネットワークが利用できるデバイスは自動修復機能を利用した修復を推奨
- 2024/07/20 ：インシデントに対するテクニカルな説明記事を更新（ref: https://www.CrowdStrike.com/blog/falcon-update-for-windows-hosts-technical-details/ ）
以降、問題が収束するまで継続的に様々なパターンでの修復方法を公開していました。
この後説明しますが、問題が分かりやすかったという点を考慮しても１時間半で問題を認識し、修正を行ったというのはかなりのスピード感がありますね。
なぜ起こったか？
2024/02にリリースしたバージョンで 「名前付きパイプやその他のIPCを悪用した攻撃に対する検知」 を実装しました。
Falcon Sensorでは各攻撃に対しての “テンプレータイプ” を用意し、そこへ “チャネルファイル” と呼ばれるテンプレートタイプの沿った設定値の詰まったデータを配布しています。
今回は、この チャネルファイルの内容に問題 がありました。
本来、テンプレートタイプに対しては “21の入力パラメータ” が必要でしたが、チャネルファイルの291では “20の入力パラメータ” しか設定されておりませんでした。
CIにてビルドの検証やテストも各レイヤー用意していたようなのですが、21番目の引数に関してはマッチ基準をワイルドカードにしていたためにすり抜けてしまったようです。
結果、 境界外メモリアクセス が発生し、クラッシュに繋がったというわけです。
原因と結果だけ見てしまうと、 入力値の数が足りなかっただけで数百億円を超える大惨事が起きてしまった 、とも言えますね。
対策
CrowdStrikeはこの問題に対してテストの引数マッチ基準の改善や、テストカバレッジの充実化、追加調査で新たになったテストの不備の修正、セキュリティベンダー数社のレビューなどを施しました。
こちらも後に説明しますが、CrowdStrikeが出している詳細レポートにどのようなことを行ったのか？は書かれています。
インシデントの余波
ここまではインシデントを具に追っていた方なら知っている話かもしれません。
ここからはインシデント自体についてというより、その後の余波についても調べてみます。
AIによる復旧
Cognition AI社が開発している"Devin"が、AWS上の仮想マシンで起こった当該インシデントの復旧に成功したとニュースになっていました。 内容を見ると事前に用意したPlaybookに従って動作していたらしいので、CrowdStrikeが提供した対策記事を読み込ませてPlaybookとし、復旧作業をさせることも出来そうな予感がありますね。
技術分野の寡占による影響
今回の件は技術分野の寡占が引き起こした面があると述べているセキュリティ専門家もおり、多くが依存している場合には（今回で言うとWindows OS）、そこがSPOFとなり強靭性を獲得するには多様性を取り入れる必要性がある。
元Windows開発者による解説
こちらの動画は元Windows開発者である Dave Plummer がCrowdStrikeのインシデントについて解説している動画になります。 Windowsのリングプロテクションの話から、WHQLの話、最後にそれらを踏まえたうえでどう対処するのか？のお話をされていて、非常に勉強になります。（自分はWHQLについて全く知らなかったので・・・）
また、この動画に対するコメントも盛り上がっており、トップコメには 「更新はそれぞれのステージで制御することが可能であったが、今回の元凶となった更新はすべてのステージに対して撒かれた」 と書いてあり、それでこんなに広範囲に影響を与えたのか〜と学びでした。
調べてみると、更新はN・N-1・N-2で最新バージョンか、最新バージョンより一つ前か、最新バージョンより二つ前かのいずれかを選択しインストールするという形のようで、これが今回の更新では N, N-1,N-2の全てに適用された みたいですね。
SREsとしては何ができるんだろう？
こういった大きいインシデントは 「もし自分が中の人でかつSREsだったら何ができるんだろう？」 とシミュレーションしてみるには良い題材かもしれませんね。
幸いにも、インシデントに対する詳細レポートがCrowdStrikeから提出されており、23Pに渡る資料の中には対策・緩和策の詳細が書かれています。
この情報をもとにシミュレーションをより具体的に行えることでしょう。（勿論、ここに書かれていない事情の方が多いとは思いますが・・・）
試しに今回のインシデントでは何ができたのか考えてみます。
テストカバレッジを高める施策
まず、資料の中で 「テストカバレッジが足りていなかった」 ことが問題が起こってしまった原因の一つとして挙げられています。
テストカバレッジを高める施策の第一歩目として可視化を取り入れたり、定期的にテストカバレッジの把握・対応を進める会を設けるなども良さそうですね。
段階的リリースの導入
資料にも書かれていますが、カナリアリリースなどの段階的リリースをキチンとやっていれば今回のような大きな影響範囲にまで広がらなかったので、やはりSREsとしてはやるべきだったと思いますね。
ちなみに今回のCrowsStrike側の対策としては段階的リリースの導入に加え、ラピッドレスポンスコンテンツ（新たな脅威が発見された時に配布される対応データ）を今までは顧客が配信を受けるかどうかコントロールできなかったのですが、細かくコントロールできるようになるそうです。
今後は問題があるコンテンツを配布したとしても、より影響範囲が小さくなりそうですね。
Antifragilityとしての教訓
これはCrowdStrikeも、また利用者側もそうですが、システムに対するAntifragilityを高めるといった意味でも今回の件は良い教訓でした。
Antifragilityは 故障・障害・ストレスなどの結果としてシステム成長が促される といった概念ですが、ある意味カオスエンジニアリングのような今回の事態はシステムにとっての"大きな穴"が浮き彫りになりました。
これによって、各社では「もし〇〇システムが動かなくなったら、こうオペレーションを変える」や、「〇〇システムに冗長性を持たせる」など対応策が考え出されたはずです。（と信じたい
なので今後同じような事態が起きても、ある程度は今回のような混乱は避けられるようにシステム・組織に適応力が付いたことでしょう。
まとめ
ということで、今回は 「あのインシデントってその後どうなったんだろう？」 と気になったので掘ってみました。
こういったポストモーテムをキチンと組織が出してくれて、様々な識者が解説してくれるのは本当に有り難いことですね。
こういう話題になったインシデントを掘ってみるような記事でも大丈夫ですので、ドシドシご寄稿ください〜〜〜〜！！！！