ネットワーク WG
Request for Comments: 1948
分類: 情報提供

S. Bellovin
AT&T Research
1996年 5月

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 に話しかけようとしていると想定します。これは下記のメッセージを送信します。:

A->B: SYN, ISNa

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

B は、

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

A->B: ACK(ISNb)

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

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

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

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

B->A: SYN, ISNb', ACK(ISNx)
となります。それについて、全くしらない本物の A に行きます。X は、そのメッセージを見ることはありませんが、
Ax->B: ACK(ISNb')
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] に従ってインクリメントされます。;  しかし、異なる空間における採番に、明らかな関連性はありません。

これを行うための明確なやり方は、死んだコネクションの状態を維持することで、それを行うための最も容易なやり方は、すべてのコネクションの両端とも TIMEWAIT 状態に行くように TCP 状態遷移ダイアグラムを変更することです。これは動作するでしょうが、インテリジェントではなく、ストレージ領域を消費します。まさに、我々は現行の 4 マイクロ秒のタイマー M を使用し、
ISN = M + F(localhost, localport, remotehost, remoteport)
をセットします。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 氏 は、このメモに対して建設的なコメントをしてく れました。

参考文献

[1] R.T. Morris,
"A Weakness in the 4.2BSD UNIX TCP/IP Software",
CSTR 117, 1985年, AT&T Bell Laboratories, Murray Hill, NJ.
 
[2] Postel, J.,
"Transmission Control Protocol",
STD 7, RFC 793, 1981年 9月.
 
[3] Kohl, J., and C. Neuman,
「Kerberos ネットワーク認証サービス (v5) (The Kerberos Network Authentication Service (V5))」,
RFC 1510, 1993年 9月.
 
[4] Atkinson, R.,
「インターネットプロトコルのためのセキュリティアーキテクチャ (Security Architecture for the Internet Protocol)」,
RFC 1825, 1995年 8月.
 
[5] Postel, J., and J. Reynolds,
"Telnet Protocol Specification",
STD 8, RFC 854, 1983年 5月.
 
[6] Jacobson, V., Braden, R., and L. Zhang,
"TCP Extension for High-Speed Paths",
RFC 1885, 1990年10月.
 
[7] G.R. Wright, W. R. Stevens,
"TCP/IP Illustrated, Volume 2",
1995年. Addison-Wesley.
 
[8] S. Bellovin,
"Security Problems in the TCP/IP Protocol Suite",
1989年 4月, Computer Communications Review, vol. 19, no. 2, pp. 32-48.
 
[9] Rivest, R.,
「MD5 メッセージダイジェストアルゴリズム (The MD5 Message-Digest Algorithm)」,
RFC 1321, 1992年 4月.
 
[10] Eastlake, D., Crocker, S., and J. Schiller,
「セキュリティのための乱雑さについての推奨事項(Randomness Recommendations for Security)」,
RFC 1750, 1994年12月.
 
[11] L. Joncheray,
"A Simple Active Attack Against TCP, 1995年, Proc. Fifth Usenix UNIX Security Symposium

著者のアドレス

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.