要約

  • Kaminsky型の手法は、標的ドメイン配下の新しい名前を問い合わせさせることで、経路外の推測競争を繰り返した。偽造応答は未完了クエリの条件を当て、正規応答より早く届けばよかった。
  • 2008年の協調パッチはDNSデータを認証していない。予測困難なトランザクションIDと問い合わせごとの送信元ポートを受理境界に加え、そのエントロピーがNATやファイアウォールを越えて残るかを実際の通信で確かめる必要があった。

真偽ではなく、未完了の仕事との一致

再帰リゾルバは通常、署名のないUDPで権威サーバへ問い合わせた。一般的な応答には暗号学的な身分証がない。そこでリゾルバは、到着したパケットが自分の出した質問に対応するかを調べた。

RFC 5452は後に、その境界を列挙した。質問セクションとトランザクションIDが一致し、問い合わせ先と同じ送信元アドレスから、問い合わせに使ったアドレスとポートへ戻ること。通常は、これらを最初に満たした応答が受理される。

経路外の攻撃者はクエリを見られなくても、権威サーバの送信元アドレスを偽り、多数の候補を投げられる。正しい組み合わせを一つ当て、正規パケットに先着すれば、キャッシュは偽データを利用者へ再配布する。ウェブやメールなど、名前解決に依存する経路が変わり得る。

ただし、DNS全体を支配したわけではない。特定のキャッシュが、受理した名前と有効期間について誤った状態を持つ。だから防御面も分けなければならない。再帰を誰に許すか、応答の何を照合するか、どの付随データを権威範囲とみなすか、推測空間をどれほど残すか、署名を検証するかは別の判断である。

失敗しても次の名前でやり直せた

キャッシュ汚染は2008年に発明されたのではない。RFC 3833は2004年にID推測、問い合わせ予測、名前連鎖の脅威を記録していた。ID欄は16ビットしかなく、弱い生成器は実効空間をさらに狭めた。固定UDPポートは新しい未知量を加えない。

Dan Kaminskyが示した実務的な突破口は、既知の弱点を連続試行へ結びつける方法だった。攻撃者は標的ドメインの下に、まだキャッシュされていないランダムなラベルを作る。リゾルバは権威へ新しい問い合わせを送り、偽造応答の群れが正規応答と競う。外れたら別のラベルで次の窓を開く。

使い捨ての名前そのものが獲物とは限らない。偽応答は、関連性やbailiwickの規則が許す範囲で、親の標的に影響する委任情報を入れようとする。価値あるキャッシュ項目のTTLを待つ代わりに、攻撃者がキャッシュミスを製造した。

RFC 5452は、この反復型では実効TTLがほぼゼロになる場合を示す。毎秒7,000個の偽造パケット、送信元ポート一つというモデルでは、およそ7秒で成功確率が50%に達する。これは全環境の攻撃時間ではない。安価に再試行できれば、小さな一回の確率が短時間で実務上の危険になるという計算である。

パッチは受理条件にもう一つの目盛りを置いた

緊急対策は、偽造側が当てる組み合わせを広げた。修正済みリゾルバは一つのUDPポートを使い回さず、問い合わせごとに予測困難な送信元ポートを選び、IDも強く乱数化した。ポートがローカルな追加識別子になった。

RFC 5452の例では、約64,000ポートを使えれば探索空間もその分増える。同じ毎秒7,000パケットの反復モデルで、50%点は約7秒から約116時間へ移る。CERT/CCは原理上およそ16ビットを追加すると説明したが、予約済みや使用中のポートは実際の母数を減らす。

この対策はDNSのパケット形式を変えない。権威サーバは問い合わせが来たポートへ従来どおり返せる。各ベンダーは実装を直し、各運用者は世界共通の切替日を待たずに導入できた。

運用コストはあった。ISCは初期BINDパッチについて、毎秒およそ10,000クエリ以上で目立つ性能影響があり得るとし、最適化したベータ版も用意した。送信元53番だけを許可するファイアウォールは変更が必要で、状態を持つ装置はより多くの変換エントリを消費する。

これは問題の消滅ではなく、予測可能な競争を、より複雑なソケットと状態管理へ交換したものだ。交換条件はローカルに測り、調整し、戻すことができる。

エントロピーはNATで縮む

ホストの在庫情報が「修正済み」でも、外から見えるポートが狭い並びに戻ることがある。NAT/PATが送信元ポートを書き換えるためだ。CERT/CCは改善を減らす、または消す可能性を警告し、RFC 5452はポートを直列化・制限する装置を具体的に挙げた。

すべてのNATが悪いという意味ではない。選択を保つ装置も、見かけの変動を別の方向へ変える装置もある。監査すべき値は、リゾルバ内部の選択ではなく、変換後に攻撃者から見える選択肢である。

DNS-OARCは権威側から観測するポートとIDのテストを提供した。特殊な問い合わせを送り、遠端で受信された分布を確認する。バージョン番号から推定するのではなく、OS、ファイアウォール、NATを通った後の挙動を検査できる。

ここにRunning-Code Primacyの実体がある。勧告は設計意図を示し、パッケージ管理はファイルの導入を示す。防御が境界まで届いたことを示すのは、動いている通信だけだ。

同時公開は同時導入ではない

DNS-OARCは、2008年3月31日にMicrosoftの施設でDNSサミットが開かれたと記録する。7月8日、CERT/CCのVU#800113と多数のベンダー更新が公表された。ISCはBINDを、MicrosoftはID、UDPソケット、キャッシュ処理を修正した。

しかし、予定した説明日まで秘密は持たなかった。OARCの時系列では7月21日に事実上漏えいし、23日に動作するコード、24日に別実装が出た。Microsoftは25日、公開知識とコードで脅威が増えたとしつつ、その時点で活動中の攻撃や顧客被害を把握しておらず、試した公開エクスプロイトはMS08-037適用済み環境に効かなかったと述べた。

この観測を「攻撃はなかった」と拡張してはいけない。公開コードは能力を増やした。一社の観測範囲に既知事例がないことは世界の不在証明ではない。一つのテスト成功も全実装と全経路の保証ではない。

KaminskyのBlack Hat発表は8月7日、RFC 5452は2009年1月だった。まず互換性を保つコードが緊急防御を作り、その後で標準文書が照合と予測困難性を共通規則にした。文書は経験を固定したが、7月の更新を配備した主体ではない。

嘘を高価にしても、答えの出所は証明されない

ポート乱数化は経路外偽造の確率を大きく下げた。しかし、受理された無署名データが委任されたゾーン管理者のものだとは証明しない。状態漏えい、縮んだポート集合、十分な試行、あるいは経路上の位置によって前提は変わる。

ISCがDNSSECを根本解と呼びながら、即時全面展開は現実的でないとした理由がここにある。DNSSECは署名と信頼連鎖でデータ起源と完全性を検証する。無署名の競争を勝ちにくくすることとは別の性質だ。

両方は必要になり得る。厳密照合とエントロピーは安い偽造を早く捨て、DNSSECは内容の権限を判定する。どちらの制御も、もう一方の役割を名乗るべきではない。

Heng LuのMinimum Initial Specificationを当てはめるなら、共通層は未完了クエリとの完全照合と必要な予測困難性を定める。一社の乱数生成器、ソケット割当て、配備日程まで世界共通の権力にしない。将来判断はコードを動かす参加者に残り、採用は発表ではなく観測可能な挙動で成立する。

証拠の限界

資料は、多数ベンダーにまたがる露出と攻撃の実用性上昇を裏づける。すべてのリゾルバが同一に脆弱だった、7月8日に一斉更新された、7秒や116時間が普遍値だとは示さない。ポート乱数化は明示された前提で経路外攻撃を難しくしたが、全汚染を消さない。DNSSECの仕様も、実際のリゾルバが検証している証拠ではない。

正確な教訓はこうだ。DNSの信頼は、一部で小さな競争に依存し、多くのシステムがその未知量を無意識に縮めていた。修正は未知量を増やして測定対象にし、真正性を別の配備課題として残した。

出典