4 ポイント 投稿者 GN⁺ 2026-05-18 | 2件のコメント | WhatsAppで共有
  • セキュリティ研究者 Nightmare-Eclipse がYellowKeyを公開し、BitLockerのフルボリューム暗号化をパスワードなしで回避できると明らかにした
  • YellowKey は、FsTxフォルダーをWindows互換ファイルシステムのUSBドライブにコピーした後、WinREで特定の手順を踏むことで再現できる
  • 手順が完了すると コマンドシェル が開き、BitLockerで保護されたボリュームの参照、コピー、ファイル操作が可能になるという
  • Nightmare-Eclipseは、この回避動作が 公式WinREイメージ でのみ現れるとして、意図的なバックドアの可能性を提起している
  • 影響対象として Windows 11、Server 2022、Server 2025 が挙げられ、Windows 10は影響を受けないと付け加えた

YellowKeyの動作条件

  • セキュリティ研究者 Nightmare-EclipseYellowKey を公開し、BitLockerのフルボリューム暗号化を完全に回避できると明らかにした
  • YellowKeyは、添付された FsTxフォルダー をNTFS、FAT32、exFATなどのWindows互換ファイルシステムでフォーマットされたUSBドライブにコピーすることで再現できる
  • USBドライブがなくても、FsTxファイルを Windows EFIパーティション にコピーし、暗号化されたディスクをシステムから一時的に切り離せば動作する可能性があるという
  • その後、BitLockerで保護されたシステムを再起動して Windows Recovery Environment(WinRE) に入り、特定の入力手順に従う必要がある
  • 手順が正確に完了すると コマンドシェル が表示され、パスワードなしでBitLocker保護ボリュームを参照・コピーしたり、その他のファイル操作を実行できるとされる

バックドア疑惑の根拠

  • Nightmare-Eclipseは、YellowKeyは従来知られていないセキュリティバグとして見るには不自然であり、MicrosoftがBitLockerのデータ保護システムに 正規のバックドア を入れた可能性があると主張している
  • 根拠は、問題を引き起こすコンポーネントが 公式WinREイメージ にしか見つからない点だという
  • 同じコンポーネントは標準のWindowsインストールイメージにも存在するが、実際のシステムで観察されたBitLocker回避動作は現れないと述べている
  • Nightmare-Eclipseは「これが意図的だったという事実以外に説明が思い浮かばない」と述べ、Windows 10は影響を受けず、Windows 11、Server 2022、Server 2025 のみが影響を受けると付け加えた

外部確認と追加公開

  • サードパーティーの研究者らが、Nightmare-EclipseのGitHub資料に記された方法どおりにYellowKeyが動作することを 確認 したと伝えられている
  • Nightmare-Eclipseは、権限昇格が可能とされる2つ目のエクスプロイト GreenPlasma も公開した
  • GreenPlasmaは SYSTEMレベルのアクセス を実現する完全な概念実証コードは公開しておらず、来月のPatch Tuesday前に追加の詳細を公開する可能性を示唆している

緩和策の方向性

  • YellowKeyのバックドア的な動作疑惑への緩和策は比較的単純だとされる
  • セキュリティ専門家は、単一の暗号化システムだけに依存せず、十分に検証された フルディスク暗号化 の代替手段も評価するよう推奨している
  • 例として VeraCrypt が挙げられている

2件のコメント

 
GN⁺ 2026-05-19
Lobste.rsの意見
  • 記事の文言だと パスワードベース保護 まで回避するようにも読めるが、そうではない気がする
    このバックドアは WinRE がドライブをアンロックする必要があることで動作するとされており(以前の投稿)、ドライブがパスワードで保護されているなら、そのパスワードを入力しなければならないはず
    おそらく実際の対象は、TPM だけを信頼してディスク暗号化パスワードを使わない 透過的 BitLocker である可能性が高い。すでに完全な Windows が起動していて暗号鍵がメモリ上にあり、ログイン画面だけがログインを妨げている状態なので、見たまま安全ではない
    すでに Windows の内部に入っている状態なので攻撃面は非常に広く、OP のいう「bugdoor」以外にも、ログイン画面の回避を可能にしたバグは複数あった。また、TPM バスをスニッフィングしたり、コールドブート攻撃でメモリから鍵を取り出したりもできる
    もちろん依然として懸念すべきではあるが、BitLocker の推奨利用方法はどうもこちららしく、一般ユーザーはディスク暗号化に実際のパスワードを使わない場合のリスクを十分に案内されていない。ただ、この脆弱性が当てはまるのは、もともと根本的に安全ではない形で BitLocker を使っていた場合だけで、既存の攻撃を少しやりやすくするにすぎないと思う
    もちろん、WinRE がパスワードで暗号化されたドライブまで魔法のように開けられるなら話は別だが、もしそうなら何年も前に誰かが気付いていたはずだ
    • https://deadeclipse666.blogspot.com/2026/05/…
      「次に、いいえ、TPM+PIN も助けにはなりません。この問題は依然として悪用可能です。私も『TPM+PIN 環境でも動くだろうか?』と自分に問い、その答えはイエスです。ただし PoC は公開しません。すでに公開されている内容だけでも十分に悪質だと思うからです」
  • 一次ソース: https://github.com/Nightmare-Eclipse/YellowKey
  • TrueCrypt が非常に怪しい形で消え、その代わりに BitLocker を使うよう勧められたときから、何かあるのは明らかに見えた
    別の言い方をすれば、Paul Le Roux が麻薬と暗殺の犯罪で逮捕され、当局に協力し始めたその瞬間から、TrueCrypt のユーザーは バックドア入りソフトウェア へ誘導されたことになる
    • TrueCrypt は 2014 年に終了しており、このバックドアは Windows 11 で登場した
      Wikipedia ベースでは Le Roux は 2012 年に逮捕されているので、そのタイムラインは合っていないように見える
    • 私の理解では、TrueCrypt は E4M を基にしていたが、Paul Le Roux は TrueCrypt そのものには関与していない。なぜ TrueCrypt ユーザーが彼の勧告に従うのか?
    • 当時の TrueCrypt の勧告がどれだけ怪しく見えたかは覚えている。2014 年には HN でも話題になっていた
      https://news.ycombinator.com/item?id=7812133
  • 鍵が自動的にクラウドへバックアップされるなら、わざわざ意図的なバックドアを仕込むより、そこから 回復キー を簡単に取得すればいいのではないかと思う
    • 企業環境で BitLocker を使う人や、Microsoft アカウントなしで 使う人もいるかもしれない
      ますますもっともらしくなる陰謀論の帽子をかぶるなら、クラウドの鍵への要求は記録に残る可能性があり、司法上の承認も必要になるかもしれない
  • これがいつ サイレントパッチ されたのか、タイムラインはあるのか?
    4 月末ごろ、Windows 更新を入れた後に PIN で BitLocker ボリュームをまったく復号できなくなった。回復コードは動いたが、PIN を何度再設定しても誤りだと言われ続けた
    結局原因は分からず、Windows を再インストールした。かなり腹立たしいバグだったし、妙な偶然でもある
  • 単に「誰かが 重大な主張 X をした」と書いて、それを記事のように見せることはできない
    私がどこかに ECDSA にバックドアがあると投稿したからといって、クリック稼ぎの場所以外ならそれをニュース記事にはしないだろう
    • このスレッドの別の箇所に実際の PoC へのリンクがある。BitLocker の「面白い」部分を回避できていないとしても、それ自体かなり注目に値すると思う
      ある程度、意図的なバックドアだと疑うのもそれほど無理のある飛躍ではないが、それは推測だ
      証拠がない部分は、PIN を別途設定した BitLocker も回避できると主張している点だ。これは記事には出ていなかった
      この人は Windows 脆弱性の発見でかなり良い実績があるようなので、PoC がなくても注目に値する主張だと思う
  • これって本当に誰にとっても驚きなのか?
    • Microsoft が何かに バックドアを入れていなかった と分かったら、むしろ本当に驚くと思う
      言うまでもないが、盗難から守る必要のあるものを Windows に置いてはいけない。Windows で銀行業務、投資、納税、メール、ホスティング、買い物、私的なことをしてはいけない
      Windows は (i) ゲームと (ii) Windows 向けビルドにだけ使うべきだ
 
GN⁺ 2026-05-18
Hacker News の意見
  • この脆弱性を発見した研究者 Nightmare-Eclipse の投稿を見ると、ほぼ1週間前から続いていたように見える
    2026年5月12日火曜日には「今回は脆弱性が2つある [YellowKey] [GreenPlasma] [...] 次のパッチチューズデーで Microsoft は大きな驚きを受けることになる」と書き、5月13日水曜日には「一連の経緯をすべて公開できるようになれば、人々は自分の激しい反応がかなり理にかなっていたと分かるだろうし、Microsoft にとってもまったく見栄えのいい話にはならない」と書いていた
    投稿者のブログ: https://deadeclipse666.blogspot.com/
    2026年3月の最初の投稿には「誰かが我々の合意を破り、自分は一文無しになって家も失った。彼らはこうなると分かっていながら自分を裏切った。これは自分の決断ではなく、彼らの決断だ」といった内容がある
    これをどう受け止めるべきかは分からないが、内部者が事実上「リーク」しているようにも聞こえるし、他の人たちも結果を再現できているようだ

    • 内部者というよりは、Microsoft と 脆弱性開示プロセス を進めている途中で、何らかの理由で腹を立てて公開してしまったように読める
    • HN ではすでに何度も議論されていて、たとえばここ: https://news.ycombinator.com/item?id=48130519
      これがバックドアかどうかは、結局のところ普段から「バグかバックドアか」をどう見るかにかかっており、技術メディアが好むような「Microsoft やらかす、BitLocker がハックされる」といった単純な話ではない
      核心は Windows Recovery Environment WinRE の NTFS トランザクションログ再生機能にあるバグで、外部ボリュームの NTFS トランザクションログを読み取り、それをマウントされたファイルシステムに適用できてしまう。これによって攻撃者は WinRE 認証を回避できる
      PIN やパスワードのない BitLocker では、どんな認証回避でもディスク暗号化の回避になる。ブートローダーがすでにディスクをアンシールしているからであり、この構造的な「欠陥」は同じ設定の Linux にもある。たとえば Ubuntu インストーラーで比較的最近追加された Hardware Disk Encryption のチェックボックスを使う場合も同様だ
      追加の証拠がない限り、NTFS トランザクションログの問題が仕込まれたバックドアなのか、単なる実装上のバグなのかは、エクスプロイト開発でよくある陰謀論をどこまで信じるか次第だ。個人的にはもっともらしいバグに見えるし、起動時アンシールの弱点はよく知られていて明白なので、これを世界を揺るがす暴露だとは思わないが、興味深いバグではある
    • 実際に何があって、なぜこの人がこんなふうに M$ を暴露 することになったのか、ブログ記事を早く読みたい
  • よりよくまとまった説明: https://infosec.exchange/@wdormann/116565129854382214
    公開されたエクスプロイトは PIN を使う BitLocker には影響しない。PIN がなければ BitLocker はそもそも安全ではない
    元の投稿者は PIN があっても動作するエクスプロイトを持っていると主張しているが、まだその証拠は出していない

    • 会社では PIN を必須にしているのか? さらに重要なのは、会社が金を払っている サイバー保険会社 が PIN を要求しているのか?
      BitLocker に PIN を必須にしている会社は見たことがない
    • BitLocker には PIN の一段上もあり、起動時にだけ使うキーを入れた USB スティック を使える。データがデバイスに保存されないので、この攻撃には安全そうだ
    • PIN 版の主張が本当だと仮定すると、なぜ PIN 版ではなく弱い役に立たない版を公開したのかは興味深い。いくつか考えはあるが、どれも根拠はない
  • 出典: https://infosec.exchange/@wdormann/116565129854382214
    「一般的な WinRE セッションには X:\Windows\System32 ディレクトリがあり、その中に winpeshl.ini ファイルがある」
    「しかし YellowKey エクスプロイトでは、USB ドライブ上の Transactional NTFS の断片によって、別のドライブの winpeshl.ini ファイルを削除できるように見える」
    興味深い。この環境にはあまり詳しくないが、単純にファイルハンドルを作成または受け渡してしまう問題なのだろうか? だとしたら、なぜ WinRE の再起動中にキー入力が必要なのだろう?
    パッチ適用がどの程度可能なのかも気になる。無数の WinRE USB ドライブには手を入れられないはずなので、BitLocker 側でアクセス権を更新できるのだろうか? 復号/再暗号化が必要になるのだろうか? 今後さらに多くの情報が出てきそうだ

    • 抜けている点は、なぜ WinRE が権限を持つのかということだ。Windows は TPM に復号鍵 を保存し、回復キーがなくても WinRE がディスクを復号できるようにしている
      そのため、この攻撃では Ubuntu ライブ CD のようなものではなく WinRE が必要になる
      また、既存の WinRE USB ドライブをすべてパッチする必要はない。Secure Boot の署名を失効させれば TPM 検証を通れなくなり、その結果どのディスクも復号できなくなる
  • 「セキュリティ専門家は一般に、単一の暗号化システムに依存せず、VeraCrypt のような十分に検証された フルディスク暗号化 の代替手段を評価するよう勧めている」
    もし FDE にバックドアを入れたのなら、人々に Windows 自体の利用をやめて Linux を使えと言うほうがもっと筋が通る
    FDE にバックドアを入れたのなら、OS 自体にもバックドアが1つしかないとは考えないだろう。プロプライエタリソフトウェアはまったく信用すべきではないし、きちんと監査されていないオープンソースも信用すべきではない

    • Microsoft 製品はたいてい使わないが、自分のコンピューターでも VeraCrypt は使わないだろう
    • あるいはオープンソースの VeraCrypt のようなものを使えばいい
  • これは BitLocker 専用の問題というより、ログイン回避 に近く見える。PIN なしで TPM に依存すると自動的に復号される
    通常は攻撃者がログイン画面を突破できないので問題ないはずだが、このエクスプロイトは回復環境で制限のないシェルを得る方法を示しているようだ
    研究者は PIN も回避する方法があると主張しているが、まだ公開していない

    • 開示プロセスで報奨金が出なかったので、金を払う誰かに売るほうが得だと考えたのかもしれない
  • セキュリティ専門家が「Microsoft 製品のセキュリティ」という役割を断り始めるのはいつになるのだろう? 自分はもうその段階に来ている
    Microsoft 製品のセキュリティは、MS の狂った技術的負債と強欲の次の波でまた崩壊するまで続く忙しい仕事にすぎない。今やバックドアまである

    • それは「セキュリティ」の役割ではなく コンプライアンスの役割 だ。ほとんどの企業顧客が本当に気にしているのはそれだけだ
      すべてのコンプライアンス規則を満たし、MS の影響を受けた「ベストプラクティス」に従っているので、何が起きても自分の責任ではないと言えるようになる
    • iOS もデフォルトではエンドツーエンド暗号化されていない iCloud バックアップを作成するため、捜査機関がチャットやブラウザ履歴などを要求できる。Signal は例外的に除外されている
      E2E 暗号化バックアップのために ADP を有効化することはできるが、会話相手が有効化していない可能性が高いため、大して役に立たないかもしれない
      Microsoft を擁護したいわけではなく、こうした企業はどこも PRISM の一部だったという話だ
    • 企業市場ではこれで稼げる金が多すぎるので、面倒だからという理由だけで人々が仕事を断り始めるとは思えない
    • 「今やバックドアまで」だって? 「今や」?
      昔、ある Windows NT のバージョンが誤ってデバッグシンボルを有効にしたまま出荷されたとき、Microsoft が「予備キー」だと主張していたキー名がなぜ ..._NSAKEY だったのかについて話そうか
      たった一度、本当にたった一度だけ Windows がデバッグシンボルを有効にしたまま出荷されたのに、よりによって暗号鍵の名前が「NSAKEY」だった
      もちろん、国家の不正にずっと目をつぶってきた人たちは、それが完全に普通のことだと言い、当時 Microsoft が苦心して作った「バックドアではない」という言い訳をそのまま繰り返すだろう
  • エクスプロイトをもう少し掘ってみると、これは TPM 専用モードの BitLocker を狙っている。つまり事前ブート認証のようなものはない
    Secure Boot がブートチェーンを検証すると、TPM が自動的に暗号鍵を渡す。物理アクセスがあれば大きな違いはない
    エクスプロイト入りの USB で起動して緊急シェルを得るにせよ、5ドルのマイクロコントローラーを買ってマザーボードの特定ピンに半田付けし、TPM キーをスニッフィングするにせよ可能だ
    Microsoft は全体として安全でないものを売りながら、それをフルディスク暗号化として売っている。USB メモリにエクスプロイトを入れてシェルを取り、ファイルを漁ってコピーできるような人なら、マイクロコントローラーを買って YouTube の半田付け動画を見ながら真似することもできる
    だから問題は「エクスプロイト」そのものではなく、Microsoft が売っている 偽りの安心感

    • 「ブート可能なスティックで緊急シェルに入る」という方法はできない。TPM は「承認された」OS で起動するときにだけ鍵を渡し、具体的には暗号鍵がバインドされた PCR 状態 が一致していなければならない
      5ドルのマイクロコントローラーで特定ピンに半田付けして TPM キーをスニッフィングできるのは dTPM の場合だけだ。fTPM はこれに脆弱ではなく、dTPM よりはるかに広く使われている
    • Ubuntu も数バージョン前に TPM ベースの FDE を導入した。そのときも同じことを考えて使わないことにした
      起動時にパスフレーズを入力するのはすでに筋肉の記憶になっていて、信頼できるシンプルなセキュリティを与えてくれる
      マザーボードがなくてもデータを復旧できる
      日常用途では、evil maid 攻撃を防ぐために Secure Boot+TPM+パスフレーズを組み合わせたスロットを使い、バックアップ用のパスフレーズスロットをもう1つ持つようなハイブリッドなら悪くないかもしれない
    • TPM+PIN エクスプロイトもあると主張してはいるが、信頼できるかどうかはまだ分からない
      https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
    • Linux LUKS もまったく同じやり方で設定できる
      これは BitLocker への攻撃というより Secure Boot チェーン への攻撃に見える
      PIN なしのアンロックに価値があるのは、脅威モデルがディスク廃棄、ディスク取り外し、TPM とディスクの分離程度に限定される場合だ
      デバイスを複数人が定期的に使うなら、PIN 入力は不便または不可能なことがある。そのため、アクセス検証制御を信頼された OS コンポーネントに委ねる構成になる
    • 非常に深刻なバグではあるが、BitLocker は確かにフルディスク暗号化だ。ただし認証回避が可能なだけだ
  • 「TrueCrypt の使用は安全ではなく、未修正のセキュリティ問題が含まれている可能性がある」という文言を覚えている人はいる? ;)

    • TrueCrypt/VeraCrypt を思い出す。おそらくより安全な暗号化ソリューションである可能性が高い。今回の件の後では、確かにより安全に見える