CrowdStrike CSAgent.sysクラッシュ原因の初期詳細
(twitter.com/patrickwardle)- 世界中のWindowsクラッシュは、CrowdStrike CSAgent.sys が誤ったメモリアドレスを参照するフローによって発生したと初期分析されている
- 問題の命令は
mov r9d, [r8]で、R8にはポインタ配列からインデックスで取り出した マップされていないアドレス が入っていた C-00000291-...xxx.sysファイル群はカーネルドライバではなく、CSAgent.sys が読む難読化データに見え、CrowdStrike はこれを Channel Files 構成ファイルだと確認した- CrowdStrike は
C-00000291-が ロジックエラー を引き起こし、OSクラッシュにつながったと明らかにし、Channel File 内の null byte が原因だという推定は否定した - 今回の配布はバージョン更新ではなく コンテンツ更新 として扱われ、一部クライアントの staging 制御を迂回した事例があり、crash report が原因分析の核心的な手がかりとなった
CSAgent.sysクラッシュの流れ
- 初期分析は CrowdStrike の CSAgent.sys をリバースし、単一の crash dump をもとに進めた静的分析である
- Windows システムや VM なしで資料を共有し、追加調査を依頼していた状態だった
- CSAgent.sys は VirusTotal に上がっていたファイルを基準に分析された: VirusTotal サンプル
- クラッシュ地点は
mov r9d, [r8]命令であるR8はマップされていないアドレスだった- この値は
RAXにあるポインタ配列からRDXインデックス (0x14 * 0x8) で取得したアドレスである
C-00000291-...32.sysのような他の.sysファイルは、実際のドライバではなく 難読化データ のように見えた- CSAgent.sys がこれらのファイルを参照または読み込んでいる状況があった
- ファイルを削除するとクラッシュが解消する状況のため、ファイル内容が CSAgent.sys クラッシュに影響した可能性が提起された
- デバッグすればより簡単に確認できるとも付け加えられていた
- 共有された
.zipには複数の CSAgent.sys バージョン、IDB、複数のC-....sysファイルが含まれていた- 最新ファイルの一つには “fix” が含まれているようだという説明があった
- 共有リンク: Google Drive zip
Channel FilesとCrowdStrikeの確認内容
- Kevin Beaumont は、問題を引き起こした
.sysファイルは channel update files であり、不正な形式が上位の CS ドライバをクラッシュさせたと記した- リンク: Kevin Beaumont の投稿
- CrowdStrike の技術説明は、初期分析と同じ方向性を確認している
C-...sysファイルはカーネルドライバではなく、Channel Files という構成ファイルであるC-00000291-がロジックエラーを誘発し、その結果 CSAgent.sys を通じて OS クラッシュが発生した- リンク: CrowdStrike 技術説明
- 一部では空の
0x0Channel File が原因だと推定したが、CrowdStrike は問題が Channel File 内の null byte と関連していないと否定した- Malware Utkonos は、ファイルが
0xaaaaaaaaで始まるべきだというチェックを指摘している: 関連投稿
- Malware Utkonos は、ファイルが
- Channel update は、一部クライアントの staging 制御 を迂回して配布されたことが確認された
- 一部の IT 担当者は CrowdStrike ポリシーで最新バージョンを無視するよう設定していたが、今回の更新はバージョン更新ではなく コンテンツ更新 だったため迂回されたと確認している
- 関連投稿: ResetEra スレッド
- CrowdStrike の特許でも channel files という表現が複数回登場する
- 例として US11822515B2 と US11645397B2 が挙げられている
- 検索語は
channel file assignee:(Crowdstrike, Inc.)
crash reportとmacOS System Extensionsの手がかり
- crash report は CrowdStrike クラッシュを理解する手段であり、macOS の別の 0day を明らかにするのにも使われた
- 関連する Black Hat 発表タイトルは “The Hidden Treasure of Crash Reports?” である
- リンク: Black Hat 発表ページ
- Apple が 3rd-party kext を廃止し、ユーザーモードの System Extensions へ移行した点は肯定的に評価されている
- ただし、この移行過程で kernel panic、権限昇格、セキュリティツールのアンロード問題があったと記されている
- macOS でユーザーモード System Extensions をサポートするカーネルコードにはバグが多く、ユーザーモードへ移行したセキュリティツールが Apple の中核 kext で広範な kernel panic を引き起こした事例があった
- core macOS System Extension フレームワークの権限昇格問題として CVE-2019-8805 が言及されている
- System Extensions の処理欠陥により、非特権コードやマルウェアがセキュリティツールのアンロードを引き起こせる可能性がある
- 例として、最新の macOS でも信頼された System Extension として動作するファイアウォール LuLu を終了させられると記されている
- このバグは LuLu のみに該当する問題ではない
1件のコメント
Hacker Newsの意見
「BSODを引き起こすコンテンツ更新で、削除すれば解決する」という話を見た瞬間、壊れたバイナリデータと不適切に書かれたパーサーの組み合わせだろう、と100ポンド賭けてもいいと思った
この10年ほどかなり真剣にコンピューティングに取り組んできて、サイバーセキュリティはまったくやっていないが、ほぼすべてのCVE・クラッシュ・バグ・性能低下・苦痛は、バイナリデータを機械が読めるデータ構造に戻すデシリアライズの過程から生まれると思っている
人間のプログラマーがエッジケースを見落とし、命令型言語がそれを許してしまうからだ。展開アルゴリズム、フォントアウトラインリーダー、画像・動画・音声パーサー、ゲームデータパーサー、XML/HTMLパーサー、OpenSSLの証明書・署名・キーパーサー、今回のCrowdStrike EDRのコンテンツパーサーまで、全部含まれる
2つ目の仮説まで考えるなら、さらに50ポンド上乗せしてもいい
破損ファイルが内部テストを通過したか、内部テストがなかったかで、更新適用タイミングに関する個別設定も無視されたようだ。さらに世界中に同時配布して被害を限定できず、そもそもファイル破損がなぜ起きたのかもまだ分からない
信頼できないデータのデシリアライズ（CWE-502）は15位で、1位は境界外書き込み（CWE-787）、4位は解放後使用（CWE-416）だった。2019年から毎回リストに入っている弱点はhttps://cwe.mitre.org/top25/archive/2023/2023_stubborn_weaknesses.htmlにまとめられている
ちなみに情報セキュリティ分野で30年以上働いている
逆に20年前に使っていたSchemeの派生は関数型だったが、すべてのケースを網羅したかは検査しなかったし、Haskellのghcも数年前はその検査がデフォルトで有効ではなかった。今は変わったかどうか分からない
何人かのIT担当者がCSのポリシーを最新バージョン無視に設定していたにもかかわらず、これは「バージョン更新」ではなく「コンテンツ更新」なので迂回されたと確認している。コンテンツ更新がクライアントを壊し得るなら、ステージング制御やポリシーを迂回できてはならない
CSのようなルートキットベースのエンドポイント監視ソフトウェアが本当に必要かは別として、この分野をより倫理的な標準へ移すには、オープンソースの代替が強力になり得る
中核ツールがオープンソースなら、正確に何をしているかが透明で、バックドアや深刻なバグがないかを一般の人々が監査できる。一方で、セキュリティチームがマルウェアシグネチャを供給する方式は、依然としてビジネスモデルになり得る
ユーザーの立場からすると、オープンソースの監視ルートキットがよりよくテスト・開発されているとか、自分の利益を考慮していると安心することはできない。問題は監視ソフトウェアというカテゴリー全体だ。存在すべきではない。こういうものを使う会社はセキュリティを理解しておらず、従業員を信頼しておらず、働きやすい場所でもない
Googleのすべてのクライアント端末に入っている
こうしたツールは高度な脅威に対して不可欠な保護を提供し、実際に検出する。Windows端末が含まれるテストなら、EDRがないと私の仕事は90%楽になる
OpenEDRのようなオープンソースEDRもあるが、古く、テレメトリの品質が悪い: https://github.com/ComodoSecurity/openedr。GitHub上の各種概念実証コードを寄せ集めて運用向けEDRを作るのは非現実的で危険だ
EDRセンサー自体が攻撃対象になる。攻撃者にとってはたいていEDRが唯一の障害なので、オープンソース化すると、悪意あるコード提供で開発を遅らせたり脆弱性を仕込んだりするリスクが大きくなる。セキュリティセンサー開発は、相手が誰なのか確信できない非常に敵対的な環境だ
実際にはむしろ逆に近い。Elastic Securityの検出ルールのように、オープンソースのマルウェアヒューリスティックルールは存在する: https://github.com/elastic/detection-rules。Elasticもカーネルドライバーを含むEDRを提供しており、経験上、回避するのは比較的難しい。WindowsでドライバーなしのEDRを作れば、私の仕事はもっと楽になる
EDRセンサーはすでにセキュリティ研究者や攻撃者に「監査」されている。弱点を見つけるためにリバースエンジニアリングとデバッグが継続的に行われている。EDRがカーネルモードのシェルコードをそのまま受け取って実行するレベルの問題を見つけたら、当然公開するだろう
単純なハッシュ照合プログラムよりはるかに複雑だ
テスト配布でなぜ検出できなかったのか理解しにくい。外部に配布したときだけ問題が起きるようにした差分が何だったのか気になる。
配布前にテストしなかったとは信じがたく、企業側もサードパーティ製コンポーネントを配布する前にテスト環境を持つべき。開発中にパッケージをインストールして失敗したり問題を起こしたりすることはよくあるが、本番環境にテストなしでそのまま入れるのがよいと考える人はいない。このケースがなぜ違うのか分からない。
パイプライン1では、ソフトウェアコード更新を重要な変更と見なし、非本番環境とカナリーテストを経て新しい「バージョン」をグローバルに配布していたのだろう。
パイプライン2では、コンテンツ／チャネル更新を別扱いしていた可能性がある。この経路では新しいマルウェアシグネチャのようなものだけを配布するため、新しいファイルは標準形式のデータファイルであり、「実行」されず読み取られるだけだと仮定していたのだろう。
このパイプライン自体は当初テストされ、十分に動作すると判断されていたはずだが、生成されたデータファイルの完全性を検証したり、より重要なことに、現在使われている最新バージョンのソフトウェアに配布したときにエラーなく動作するか確認したりするテスト段階がなかったのだろう。
毎日チャネルファイルを読むエージェントソフトウェアは、パイプライン1で、考え得るあらゆるデータファイルサイズと模擬コンテンツについて「徹底的に」テストされていたはずだ。もちろん、不正なデータファイルはエラーとして拒否すべきだったが。
今回の正確なシナリオは、2つ目の経路にある壊れたパイプラインが特殊な形の不正なデータファイルを作り、その特定のケースがソフトウェアバージョンの開発・テスト・配布パイプラインで想定もテストもされていなかった、という可能性がある。
これが正しければ教訓は明らかだ。「データ」専用の配布であっても、パイプラインがどれほど標準化され安定していても、大規模配布前のテストは必須だ。コストと遅延は増えるが、受け入れなければならない。そもそも人々が「セキュリティ」ソフトウェアにお金を払うのと似た話だ。
企業顧客も同様に、新しい配布物をIT環境の非本番領域でテストするか、本番フリート全体に許可する前にカナリー配布を設けるべきだ。
ある会社がエンドポイントセキュリティとネットワーク異常検知に参入しようとしたとき、複数の見込み顧客がさまざまなCVE種別と深刻度について4時間SLAを要求していた。つまり、24時間365日のオンコールのセキュリティエンジニアと、4時間未満での定義作成・配布が必要であり、その4時間内に対象の100%へ配布可能でなければならないという意味だった。
ゼロデイについて高品質な定義を4時間以内に作成して配布するのも難しく、テストパイプラインを通すのはさらに難しく、実際にカバーする新しいテストを書くなど言うまでもない。その分野ではそれが「普通」と見なされていたので、すぐに諦めた。CSもここで同じように仕事をしていたとしても驚かない。
それでもひどい話だが、もし何のテストもなくリリースしたのなら、本当に衝撃的なレベルの怠慢だ。
理解できないのは、はるかに技術的ではないが、より重要な部分だ。なぜ影響範囲がこれほど大きかったのか分からない。
もっと重要度の低いサービスでも、自動モニタリングとロールバックを用意し、はるかにゆっくり配布したことがある。まず顧客トラフィックのないベータに配布し、問題がなければフリートのごく一部に配布したうえで、更新を受け取るホストの割合をゆっくり増やしていく。
この方式なら問題は即座に止まっていたはずで、これが一般的な慣行だと思っていた。
新しいウイルスを認識した時点では、すでに野生で広がっているので、一分一秒が重要になる。1日遅らせた結果、サーバーが20時間前に侵害されていたと知るような状況は望まない。
潜在的に壊れる変更は望まなくても、最新のウイルス検知ルールは引き続き欲しい、という期待があったのだろう。見落とされたエッジケースは、テストされていない設定が既存コードを壊す状況だ。
出典は純粋な推測なので、ニュース記事で引用しないこと。
この問題を避ける、あるいは少なくとも発生リスクを減らす方法はいくらでもあったが、いつものように利益が人より優先された。
今回の事態で Microsoft の役割がほとんど議論されていないのは驚きです。Microsoft は直接クラッシュを引き起こしたバグの責任者ではありませんが、Windows がこのような状況にしなやかに耐えられるようにするインセンティブ、つまり利益と競争が不足した環境を作ってきました
Microsoft はワークステーション・コンピューティング領域で事実上の独占的地位にあり、今ではインフラに近い存在なので、製品のセキュリティ・信頼性・機能を保証する注意義務があります
競争がないため、Microsoft は Windows の革新から手を引いており、その一部は今回の障害を防げたかもしれません。たとえば CrowdStrike は macOS と Linux ではユーザー空間で動作しますが、Windows は CrowdStrike がユーザー空間で動作するための機能を提供できないのでしょうか？
アプリケーションのサンドボックス化の革新によって、CrowdStrike が要求するレベルの制御権の必要性を減らすこともできたのではないでしょうか？
Microsoft は世界のコンピューティングインフラの鍵を、事実上競争なしに握っており、監督もほとんど受けていません。Windows はかつて Microsoft の売上の 80% 以上を占めていましたが、今では 10% 程度まで下がっています
民間企業が利益を追求すること自体は問題ありませんが、その製品が病院・航空会社・重要インフラの運用に不可欠であるなら、収益性を高めるために AI アシスタントや広告だけに注力するわけにはいきません
Microsoft は消費者に対する注意義務を果たせておらず、CrowdStrike はその症状だと思います。政府はデスクトップワークスペース市場の競争を真剣に促進するか、さもなければ Microsoft Windows 製品を規制すべきです
Windows の売上比率が下がったことの利点の一つは、MS がもはや Windows を触れてはならない聖域として抱え込み続けない可能性がある点です
CrowdStrike を直接使っておらず、私の知る限り自分のシステムにインストールしたこともありません。最後の会社の機器には似たものが動いていたようなので、間違っていたら訂正してください
CS ドライバは先にインストールされ、削除できず、おそらくリモートモニターが検知し、署名済みドライバなので改変も難しくしようと相当な努力が払われているようです
ところがそのドライバが、エンドユーザーが任意に削除できる 署名されていないデータファイルを読み込むのでしょうか？ こうしたファイルをエンドユーザーが任意に追加して、ドライバに本来してはいけない形で動作させることもできるのでしょうか？
悪意ある攻撃者が悪性のデータファイルを使ってさらに別の大規模障害を起こしたり、さらに悪いことにカーネル権限を得たりするのを、何が防いでいるのか気になります
別のオペレーティングシステムでファイルシステムをマウントしなければできませんが、通常は BitLocker がそれを防ぎます
CrowdStrike の顧客には、こうしたアップデートが配信されることについて発言権があるのでしょうか。それとも、CrowdStrike が企業内のすべてのマシンに対して 完全なリモートコード実行を持つことを、そのまま受け入れているのでしょうか
少なくとも認証局や暗号化関係の人たちは、こういうものを自分たちのシステムから外しておけることを望むでしょう
CrowdStrike がその部分を自動化していること自体が製品の核心です
もしかするとそれを見ることはできないかもしれません。私たち自身がその何百万人の一人かもしれないからです
この「チャネルファイル」が CS ドライバによって署名・検証されているのか、知っている人がいるのか気になります。そうでないなら、ring 0 ルートキットにつながる大きな穴のように見えます
チャネルファイルをインストールするには権限が必要でしょうが、いったん可能になれば、システムのはるか深い場所に潜むことができます。チャネルファイルがセグメンテーションフォルトを起こせるなら、おそらくもっと多くのこともできるはずです
それほど高い権限で動作するものに入るすべての入力は、少なくとも完全性チェックを受けるべきです。これは基本です。単にチャネルファイルを削除できるという事実は、改ざん防止メカニズムすらないことを示唆しています