English

シーケンス番号攻撃を防ぐ
(Defending Against Sequence Number Attacks)

このメモの位置付け

このメモはインターネットコミュニティに情報を提供するものです。 このメモは、いかなるインターネット標準も定めるものではありません。 このメモの配布に制限はありません。

要旨 English

シーケンス番号スプーフィングに基づくIPスプーフィング攻撃が、 インターネット上の深刻な脅威になってきました。 (CERT Advisory CA-95:01) 数多くある暗号技術による認証が、正攻法の解ではありますが、我々は、 現在の攻撃の潮流に対して非常に本質的なブロックとなるTCP実装についての単純な変更を提案します。

概要と理論 English

1985年にMorris [1]は、 TCP [2]がどんなシーケンス番号を新しいコネクションに使用するかを推測することに基づく攻撃の形態を記述しました。 まとめると、攻撃者は標的に信頼されたホストの口を塞ぎ、 標的に話しかける際に、信頼されたホストの IP アドレスをまねて、 次に最初に使われるシーケンス番号を推測することに基づく3ウェイハンドシェイクを完結させます。 標的への通常のコネクションはシーケンス番号の状態の情報を集めるのに使用されます。 このシーケンス全体が、アドレスに基づく認証と組み合わされて、 攻撃者が標的となるホスト上でコマンドを実行できるようにしてしまいます。

明らかに、 この正統な解決法は暗号技術による認証[3,4]です。 しかし、これが採用されるまでには極めて長い時間を要することでしょう。 それゆえ、多くのサイトではrloginやrshのようなアドレスに基づく認証に依存するプロトコルの使用を制限する必要がありました。 残念ながら「スニッファ攻撃」の蔓延(ネットワーク盗聴(CERT Advisory CA-94:01))は、 通常のTELNET [5]も非常に危険なものにしてしまいました。 それゆえインターネットは、 リモートログインのための安全でセキュアな機構を持たないままとなっています。

我々は、 大部分のシーケンス番号推測攻撃をブロックするTCP実装のシンプルな変更を提案します。 より正確には、このような攻撃は、 悪い野郎が既により荒廃させる攻撃を放つことができる能力をもっている場合においては可能であり続けます。

攻撃の詳細 English

特定のシーケンス番号推測の事例を理解するためには、 TCPがシーケンスを開始するのに使用される3ウェイハンドシェイクに注目しなければなりません[2]。 クライアントマシンAがrshサーバーBに話しかけようとしていると想定します。 これは下記のメッセージを送信します。：

これは、SYN(「同期シーケンス番号」)ビットセットと、 最初のシーケンス番号ISNaをもったパケットを送るということです。

Bは、

と答えます。 自身の最初のシーケンス番号に加えてAのものに対してACKを送信します。 実際の数値ISNaは必ずメッセージ中にあることを覚えておいてください。 Aは下記のように送ることによってハンドシェイクを完結させます。

最初のシーケンス番号は、程度の差はあれ、 ランダムにしようとしています。 より正確には、RFC 793では、32ビットのカウンタが、 4マイクロ秒ごとに1ずつ昇順にインクリメントされることを規定しています。 まさに、バークレー系カーネルは、それを毎秒、 一定値ごとにインクリメントさせ、 各新しいコネクションごとに別の一定値でインクリメントさせます。 それゆえ、あるマシンにコネクションを開くとき、 あなたは非常に強い確信をもってどんなシーケンス番号が、 その次のコネクションに使用されるかを知ることができます。 そして、そこが攻撃されるのです。

攻撃者Xは、まず、実際のコネクションを標的B(例えば、メールのポート、 もしくは各TCPポート)に開きます。 これがISNbを与えます。 それから A を装って、

を送ります。 この"Ax"は、XによってAのふりをして送られたパケットを意味します。

Bの、Xの元のSYN(を名乗るもの)に対する応答は、

となります。 それについて、全くしらない本物のAに行きます。 Xは、そのメッセージを見ることはありませんが、

ISNb'の予測された値を使用してを送ることができます。 その推測が正しいとき(通常、正しくなる)、 Bのrshサーバーは、 実際にはXがそのパケットを送っていてもAとの正規のコネクションを持つと考えます。 Xは、このセッションからのアウトプットを見ることができませんが、 程度の差はあれ、いかなるユーザとしてもコマンドを実行することができ、 その場合ゲームオーバーとなり、勝者はXです。

たいしたことはないのですが困難はあります。 AがBのメッセージを見た場合、 Bが送っていない何かにACKを返していることを認識し、 そのコネクションを取り壊すために応答としてRSTパケットを送ります。 これを防ぐ様々なやり方があります。； 最も容易なものは、本物のAがダウンするまで(当然、 おそらく敵対行為の結果として)まで待つことです。 実際にXは、 非常によくある実装のバグを攻略することによってAの口を塞ぐことができます。 ； これは以下に記述されています。

解消法 English

コネクションのための最初のシーケンス番号の選択はランダムではありません。 むしろ、古い状態のパケットが新しい同一のコネクションの実現 [6, Appendix A] において受け入れられる可能性を最小限にするように選択される必要があります。 さらに4.2BSD系のTCPの実装は、 サーバー側の元のコネクションがTIMEWAIT状態 [7, pp. 945] のままにある場合、 そのような再実現を扱うための特別なコードをもっています。 したがって [8] で示唆したようなシンプルなランダマイゼーションでは、うまく動作しません。

しかし重複したパケットや、 それによる最初のシーケンス番号の再実現の制限は、 個々のコネクションごとに固有のものです。 つまり、2つの異なるコネクションのために使用されるシーケンス番号の間には、 構文的であれ、意味的であれ、関連性はありません。 我々はシーケンス番号推測攻撃を、各コネクション(つまり、 各4つの要素 <localhost, localport, remotehost, remoteport>から成る集合)に独立したシーケンス番号空間を与えることによって防ぐことができます。 各空間内で、その最初のシーケンス番号は [2] に従ってインクリメントされます。； しかし、異なる空間における採番に、明らかな関連性はありません。

これを行うための明確なやり方は、 死んだコネクションの状態を維持することで、 それを行うための最も容易なやり方は、 すべてのコネクションの両端ともTIMEWAI 状態に行くようにTCP状態遷移ダイアグラムを変更することです。 これは動作するでしょうが、インテリジェントではなく、 ストレージ領域を消費します。 まさに、我々は現行の4マイクロ秒のタイマーMを使用し、

をセットします。 Fが外部からは計算不能であることが決定的に重要です。 さもなければ、攻撃者は、 なおも他のコネクションに使用される最初のシーケンス番号から、 シーケンス番号を推測できてしまいます。

そこで我々はFが、コネクションidや、 何らかの秘密のデータの暗号技術によるハッシュ関数とすることを示唆いたします。 MD5 [9] は良い選択です。 それは、そのコードが広く入手可能だからです。 秘密のデータは、真の乱数 [10] である場合もあれば、何らかのホスト単位の秘密や、 そのマシンの起動時刻の組み合わせである場合もあります。 起動時刻は、 その秘密が毎回変更されるようにするために含められます。 ホストのIPアドレスやホスト名のような他のデータも、 ハッシュに含まれることがあります。； これは、 ワークステーションのネットワークが同一の秘密なデータを共有することを許すことによって運用管理を楽にする一方、 それらに独立したシーケンス番号空間も与えます。 実際、我々の推奨事項は、これらの要素3つともすべてを使用することです。： ハードウェアが生成しうる限りの乱数と、 運用管理的にインストールされたパスフレーズと、 そのマシンのIPアドレスです。 これは、秘密がどれだけセキュアかに基づいてローカルな選択を許容します。

その秘密は、 生きているマシン上では簡単には変えられないことを覚えておいてください。 そのようにすることによって、 再実現されるコネクションに使用される最初のシーケンス番号を変更することになります。； 安全を維持するためには、 死んだコネクション状態が維持されるか、そのような変更後、 最大2セグメントのライフタイム間、 静粛な時間が観測されなければなりません。

よくある TCP のバグ English

前の方で述べたように、シーケンス番号推測を使用する攻撃者は、 最初に信頼されたマシンの「口を塞ぐ」必要があります。 数多くの戦略がありえますが、 これまで検知された大部分の攻撃は実装のバグに依拠するものです。

コネクションを張るためのSYNパケットが受け取られたとき、 受信システムは、SYN-RCVD状態において新しいTCBを作ります。 資源の過剰消費を避けるために4.2BSD系のシステムはコネクションごとに、 その状態において限られた数のTCBだけを許容します。 この制限に到達したら、 以降の新しいコネクションのためのSYNパケットは捨てられます。； クライアントは、必要に応じてそれらを再転送することが想定されています。

パケットが受け取られたとき、最初にやらなければならないことは、 そのコネクションのためのTCBを検索することです。 TCBが見つからない場合、そのカーネルは、 すべてのクライアントからのコネクションを受け入れるためにサーバによって使われている「ワイルドカード」TCBを検索します。 残念ながら多くのカーネルにおいて、このコードは、 最初のSYNパケットにだけではなく、 すべてのやって来るパケットによって呼び出されます。 SYN-RCVDキューがワイルドカードTCBでいっぱいの場合、 たとえそれらがSYNパケットでなくても、 そのホストとポート番号を指しているすべての新しいパケットが捨てられます。

それからホストの口を塞ぐために攻撃者は、 実在しないマシンの別のポート番号から相当数のSYNパケットをそのrloginポートに送ります。 これはSYN-RCVDキューを溢れさせ、そのSYN+ACKパケットが対抗して返されます。 標的上の攻撃は、信頼されたマシン上のrlogin ポートから来たように見えます。 応答(標的からのSYN+ACK)は、 キュー満杯状態にあるパケットとして知覚され、 黙ってドロップされます。 キュー満杯コードが、正規のオープン要求においては、 まともにはありえないはずのACKビットについてチェックされれば、 これを避けることができます。 それがある場合、RSTが応答として送られる必要があります。

セキュリティについての考慮事項 English

良いシーケンス番号は、 暗号技術による認証の代わりになるものではありません。 いいところ、それらは一時しのぎの手段です。

コネクションの最初のメッセージを観察することができる盗聴者は、 そのシーケンス番号の状態を判断することができ、また、 そのコネクションになりすますことによってシーケンス番号推測攻撃をしかけることができる可能性があります。 しかし、そのような盗聴者は、既存のコネクション [11] もハイジャックすることができるので、 増大する脅威は大きくはありません。 それでもなお、偽のコネクションと実際のコネクションの間隔は、 程度の差こそあれ、在ることにはかわりないないので、 攻撃者がそのようなパケットをキャプチャできないようにすることが重要です。 それらを見せてしまう典型的な攻撃には、盗聴と [8] で検討した様々なルーティング攻撃の両方があります。

乱数が唯一の秘密の元として使用されている場合、 それらは、[10] にある推奨事項に沿って選択されなければなりません。

謝辞 English

Matt Blaze氏とJim Ellis氏が、このRFCについて、 いくつかの決定的なアイディアを出してくれました。 Frank Kastenholz氏は、 このメモに対して建設的なコメントをしてくれました。

参考文献

著者のアドレス

Steven M. Bellovin
AT&T Research
600 Mountain Avenue
Murray Hill, NJ 07974

電話： (908) 582-5886
EMail： smb＠research.att.com

翻訳者のアドレス

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

EMail： miyakawa＠ipa.go.jp

Copyright (C) The Internet Society (1996). All Rights Reserved.