バックドア（コンピュータ）

SobigやMydoomなどの多くのコンピュータワームは、感染したコンピュータ（一般的にはMicrosoft WindowsとMicrosoft Outlookが動作するブロードバンド接続のPC ）にバックドアをインストールします。このようなバックドアは、スパマーが感染したマシンから迷惑メールを送信できるようにするためにインストールされているようです。一方、 2005年末までに数百万枚の音楽CDに密かに仕込まれたSony/BMGルートキットのようなワームは、 DRM対策として、そしてデータ収集エージェントとして機能していました。なぜなら、これらのワームがインストールした2つの密かなプログラムは、いずれも定期的に中央サーバーに接続していたからです。

2003 年 11 月に明らかになったLinux カーネルにバックドアを仕掛ける巧妙な試みでは、リビジョン管理システムを悪用して、小さくて微妙なコード変更が加えられました。^{[ 20 ]}この場合、2 行の変更は関数呼び出し元のroot アクセス権限をチェックして いるように見えましたが、等価性チェックではなく代入を使用していたため、実際にはシステムに権限が付与されていました。この違いは簡単に見落とされ、意図的な攻撃ではなく、偶発的なタイプミスと解釈される可能性さえあります。^{[ 21 ] [ 22 ]}sys_wait4===

2014年1月、Galaxy端末などの一部のSamsung Android製品にバックドアが発見されました。Samsung独自のAndroidバージョンには、端末に保存されているデータへのリモートアクセスを可能にするバックドアが組み込まれています。特に、Samsung IPCプロトコルを使用してモデムとの通信を処理するSamsung Androidソフトウェアは、リモートファイルサーバー（RFS）コマンドと呼ばれる一連のリクエストを実装しており、これによりバックドアのオペレーターはモデムを介して端末のハードディスクやその他のストレージに対してリモートI/O操作を実行できます。モデムはSamsung独自のAndroidソフトウェアを実行しているため、無線によるリモート制御機能を提供している可能性が高く、これを使用してRFSコマンドを発行し、端末のファイルシステムにアクセスできると考えられます。^{[ 23 ]}

バックドアの検出がより困難なのは、ソースコードではなくオブジェクトコードを変更する場合です。オブジェクトコードは機械可読性を目的として設計されているため、人間が読みやすいように作られておらず、検査がはるかに困難です。これらのバックドアは、ディスク上のオブジェクトコードに直接挿入することも、コンパイル、アセンブリリンク、またはロードのいずれかの段階で挿入することもできます。後者の場合、バックドアはディスク上には存在せず、メモリ上にのみ存在します。オブジェクトコードのバックドアは、オブジェクトコードを検査するだけでは検出が困難ですが、長さやチェックサムなどの変更点（差異）を確認するだけで容易に検出できます。また、場合によっては、オブジェクトコードを逆アセンブルすることで検出または分析できます。さらに、オブジェクトコードのバックドアは、（ソースコードが入手可能な場合）信頼できるシステム上でソースコードから再コンパイルするだけで削除できます。

したがって、このようなバックドアが検出を回避するには、バイナリの既存のすべてのコピーを改ざんし、検証チェックサムも改ざんし、再コンパイルを防ぐためにソースコードを利用できないようにする必要があります。あるいは、これらの他のツール（長さチェック、差分、チェックサム、逆アセンブラ）自体を改ざんしてバックドアを隠蔽することもできます。たとえば、改ざんされたバイナリがチェックサムされていることを検知し、実際の値ではなく期待値を返すようにするのです。これらのさらなる改ざんを隠蔽するために、ツール自体も変更を隠蔽する必要があります。たとえば、改ざんされたチェックサムは、自身（または他の改ざんされたツール）がチェックサムされているかどうかを検知し、偽の値を返す必要があります。これは、たった1つの変更を隠蔽するために、システムとツールに大規模な変更が必要になることを意味します。

オブジェクトコードは元のソースコードを再コンパイル（再アセンブル、再リンク）することで再生成できるため、ソースコードを変更せずに永続的なオブジェクトコードバックドアを作成するには、コンパイラ自体を乗っ取る必要があります。つまり、攻撃対象のプログラムをコンパイルしていることを検出したときに、バックドアを挿入するようにするのです。あるいは、アセンブラ、リンカ、ローダを乗っ取ることもできます。これはコンパイラを乗っ取る必要があるため、コンパイラを再コンパイルしてバックドア挿入コードを削除することで修正できます。しかし、この防御策は、コンパイラにソースメタバックドアを仕込むことで覆すことができます。コンパイラが自身をコンパイルしていることを検出したときに、このメタバックドアジェネレータと、攻撃対象の元のプログラムの元のバックドアジェネレータを挿入するように仕向けるのです。この後、ソースメタバックドアを削除し、改ざんされたコンパイラ実行ファイルを使用して元のソースからコンパイラを再コンパイルすれば、バックドアが起動します。この攻撃は、1974 年の Karger と Schell の論文^{[ 24 ]}に遡り、1984 年の Thompson の「信頼を信頼することについての考察」というタイトルの記事^{[ 25 ]}で広く知られるようになりました。そのため、一般的には「信頼を信頼する」攻撃として知られています。同様の攻撃は、オペレーティングシステムなどのシステムの下位レベルを標的にすることができ、システムの起動プロセス中に挿入することができます。これらも 1974 年に Karger と Schell によって言及されており、現在ではブートセクタウイルスの形で存在しています。^{[ 24 ] [ 26 ]}

従来のバックドアは対称バックドアです。バックドアを見つけた人は誰でもそれを使用できます。非対称バックドアの概念は、Adam Young とMoti YungによってProceedings of Advances in Cryptology – Crypto '96で導入されました。非対称バックドアは、バックドアの完全な実装が公開されたとしても (たとえば、公開、リバースエンジニアリングによる発見と開示など)、それを仕掛けた攻撃者のみが使用できます。また、ブラックボックスクエリの下で非対称バックドアの存在を検出することは計算上困難です。この種の攻撃はクレプトグラフィーと呼ばれ、ソフトウェア、ハードウェア (たとえば、スマートカード)、またはその両方の組み合わせで実行できます。非対称バックドアの理論は、現在暗号ウイルス学と呼ばれるより大きな分野の一部です。特に、NSA はDual EC DRBG標準にクレプトグラフィーバックドアを挿入しました。^{[ 8 ] [ 27 ] [ 28 ]}

RSA鍵生成には実験的な非対称バックドアが存在する。YoungとYungによって設計されたこのOpenSSL RSAバックドアは、ねじれた楕円曲線ペアを利用しており、公開されている。^{[ 29 ]}

大規模言語モデルにおけるモデルポイズニングとは、トレーニングまたはファインチューニングの過程で悪意のあるデータを導入し、標準入力ではモデルが正常に動作するものの、特定のバックドアトリガーが現れると悪意のある動作をアクティブにするようにすることです。最近の研究では、SIMPLE、COVERT、TROJANPUZZLEという3つの攻撃が紹介されました。これらは主に、マルチトークンペイロードや文脈外のトリガーを埋め込むことでコード生成モデルをポイズニングすることに焦点を当てています。 ^{[ 30 ]}これらの攻撃は、特定のトリガー条件が満たされるまで隠れたままの巧妙なポイズニングによって、大規模な基盤モデルでさえも悪用される可能性があることを示しています。

これらのバックドア攻撃はトレーニングパイプラインを標的とするため、推論中の敵対的サンプルに焦点を当てた従来の防御策の多くを回避します。たとえば、COVERT と TROJANPUZZLE は、ファインチューニングデータセット内の汚染されたサンプルが、通常の検証手順では検出されずに静的解析を回避できることを示しています。 ^{[ 30 ]}オープンソースまたはクラウドソーシングのデータセットでは、信頼できる中央レビュープロセスなしに悪意のある貢献が更新パイプラインに紛れ込む可能性があるため、リスクはさらに高くなります。これにより、トリガーがアクティブになるまで、つまりモデルがデプロイされてからかなり後になるまで、開発者が攻撃を検出することが困難になります。

大規模な言語モデルにバックドアを仕掛けることの影響は、コード生成や特定のトリガーが作動した際の機密情報の漏洩の可能性といった分野で重大です。研究者たちは、モデルポイズニングによって、無害な入力に対しては高いパフォーマンスを維持しながら、大規模なデータセットでトレーニングされたモデルの動作を操作できることを示しました。^{[ 30 ]}これらのリスクは、さまざまなコンテキストにわたる、より厳密なデータセット監査、トリガーテスト、およびモデル出力の継続的な監視の必要性を浮き彫りにしています。

トンプソンのバージョンは公式には世に出回らなかった。しかし、BBNに配布されたバージョンがあり、バックドアの使用が少なくとも1回記録されたと考えられている。^{[注3 ]}その後数年間、そのようなバックドアに関する逸話的な報告が散見される。

2009年8月、Sophos Labsはこの種の攻撃を発見しました。W32/Induc-Aウイルスは、 Windowsプログラミング言語であるDelphiのプログラムコンパイラに感染しました。このウイルスは、新しいDelphiプログラムのコンパイルに独自のコードを挿入し、ソフトウェアプログラマーの知らないうちに多くのシステムに感染して拡散することを可能にしました。ウイルスはDelphiのインストールを探し、標準ライブラリの一部であるSysConst.pasファイルを変更してコンパイルします。その後、そのDelphiのインストールでコンパイルされたすべてのプログラムにウイルスが含まれることになります。独自のトロイの木馬を構築して拡散する攻撃は、特に発見が困難です。その結果、多くのソフトウェアベンダーが感染した実行ファイルを気づかずにリリースし、誤検出を主張することもありました。結局のところ、実行ファイルは改ざんされておらず、コンパイラが改ざんされていたのです。Induc-Aウイルスは、発見される少なくとも1年前から拡散していたと考えられています。^{[注4 ]}

2015年には、Xcodeの悪意のあるコピーであるXcodeGhostも同様の攻撃を行い、中国の十数社のソフトウェア会社のiOSアプリを感染させた。世界中で4,000のアプリが影響を受けたことが判明した。これは開発ツール自体を感染させるわけではないため、真のThompsonトロイの木馬ではなかったが、ツールチェーンの汚染が大きな損害を引き起こす可能性があることを証明した。^{[ 36 ]}

システムがバックドアやトロイの木馬（Trusting Trustコンパイラなど）によって侵害されると、「正当な」ユーザーがシステムの制御を取り戻すのは非常に困難になります。通常は、クリーンなシステムを再構築し、データ（実行ファイルは除く）を転送する必要があります。しかし、Trusting Trustスキームにはいくつかの実用的な弱点が指摘されています。例えば、十分な動機を持つユーザーであれば、信頼できないコンパイラを使用する前に、そのマシンコードを入念にレビューすることができます。前述のように、逆アセンブラを改ざんするなど、トロイの木馬を隠蔽する方法はありますが、逆アセンブラをゼロから作成するなど、その防御策に対抗する方法もあります。

信頼攻撃に対抗する一般的な方法として、異なるコンパイラとテスト対象コンパイラのソースコードが挙げられます。この方法では、異なるコンパイラとテスト対象コンパイラのソースコードが必要です。両方のコンパイラでコンパイルされたソースコードは、2つの異なるステージ1コンパイラを生成しますが、動作は同じであるはずです。したがって、同じソースコードを両方のステージ1コンパイラでコンパイルすると、2つの同一のステージ2コンパイラが生成されます。いくつかの仮定の下で、後者の比較によって、テスト対象コンパイラのソースコードと実行可能ファイルが一致することが保証されるという形式的な証明が与えられています。この方法は、著者がGCCスイート（v. 3.0.4）のCコンパイラにトロイの木馬が含まれていないことを検証するために、異なるコンパイラとしてicc （v. 11.0）を使用して適用しました。 ^{[ 32 ]}

実際には、このような高度な攻撃は稀であること、またプログラムが通常バイナリ形式で配布されることから、侵入検知や分析といった極めて特殊な状況を除き、エンドユーザーがこのような検証を行うことはありません。バックドア（コンパイラのバックドアを含む）の削除は、通常、クリーンなシステムを再構築することで行われます。しかし、このような高度な検証は、侵害されたシステムを配布していないことを確認するため、また、このような攻撃が現実的な懸念事項となる高セキュリティ環境においては、オペレーティングシステムベンダーにとって重要な意味を持ちます。