TCPシーケンス番号予測攻撃とは、TCPのシーケンス番号を予測することで成立する攻撃手法の一つである。ハッキング、サイバーテロ(サイバー攻撃)の一つ。
TCPシーケンス番号
TCPでは、フロー制御にスライディングウィンドウを用いており、そのスライディング管理にシーケンス番号を用いている。例えば、1000オクテットのデータを3パケット送信すると、以下のような通信内容となる。
1000オクテットのデータを3パケット送信した場合
項番 |
送信側 |
向き |
受信側 |
備考
|
送信 データ長 |
シーケンス 番号 |
ACK番号
|
1
|
1000 |
0 |
→ |
|
|
2
|
|
← |
1000 |
1000バイト受信済みであることを示す肯定応答が返される
|
3
|
1000 |
1000 |
→ |
|
項番1において1000バイト送信済みであるため、シーケンス番号は1000となる
|
4
|
|
← |
2000 |
トータル2000バイト受信済みであることを示す肯定応答が返される
|
5
|
1000 |
2000 |
→ |
|
項番1と3において2000バイト送信済みであるため、シーケンス番号は2000となる
|
6
|
|
← |
3000 |
トータル3000バイト受信済みであることを示す肯定応答が返される
|
実際にはスライディングウィンドウの影響を受けるため、項番3の送信は項番2のACK応答が返ってくる前に送信されると考えられる。また、受信側の都合で途中までしか受信されなかった場合はACK番号が1000単位未満の値が返されることもある。しかし、これらの事情はここでの主題とは外れる話であるため割愛する。
上表は理解のために簡素化して記しているが、実際にはシーケンス番号は0から始まるのではなく、適当な番号から始まり、以降のパケットにおいても第1パケットのシーケンス番号だけ加算された値が用いられる。この事情は、上表の「シーケンス番号」だけでなく「ACK番号」についても同様である。つまり、上の表を、実際の送受信パケット内で用いられるもので表記すると、以下のようになる。
1000オクテットのデータを3パケット送信した場合(実際版)
項番 |
送信側 |
向き |
受信側 |
備考
|
送信 データ長 |
シーケンス 番号 |
ACK番号
|
1
|
1000 |
990000 |
→ |
|
|
2
|
|
← |
991000 |
991000の手前までを受信済みであることを示す肯定応答が返される
|
3
|
1000 |
991000 |
→ |
|
項番1において1000バイト送信済みであるため、シーケンス番号は990000+1000=991000となる
|
4
|
|
← |
992000
|
5
|
1000 |
992000 |
→ |
|
|
6
|
|
← |
993000
|
この加算値、つまり、セッションの第1パケットに含まれるシーケンス番号は、イニシャルシーケンス番号(ISNと略される)と呼ばれている。上表がセッション確立開始時点からのパケットであれば、990000がイニシャルシーケンス番号となる。
なお、シーケンス番号が取りうる範囲は32ビットで示される数値に限られる。上限に達した場合は0からサイクリックに使用されることになる。
攻撃
上記のように、TCP通信では相手のシーケンス番号を自身のACK番号として応答する必要がある。そのため、項番1のパケットを受信しない第三者には、項番1に含まれるイニシャルシーケンス番号が不明であり、項番2のパケットを偽装することはできない。同じセグメント内にある端末であればLANアナライザ等によるパケット監視によって知ることも可能であるが、ソース・ルーティングなどと組み合わせてセッション確立を偽装する目的を考えると現実的でない。しかし、イニシャルシーケンス番号を予測することが可能であれば、項番2の肯定応答を偽装することが可能となる。また、それ以降に送られてくるパケット(のサイズ)が予測可能であれば、項番4や項番6にあたるパケットへの肯定応答も可能である。
もし、攻略対象システムに「認証なしにアクセス可能な、信頼関係にある端末」が設定されており、「IPスプーフィングやソースルーティング等によって、その信頼関係にある端末からの通信であることを偽装可能」であり、「シーケンス番号を予測可能」であれば、攻略対象システムに対して侵入可能となる。そして、ケビン・ミトニックによってそのような侵入事件が発生したことはよく知られている[1]。
IP通信を行なう初期の製品においては、シーケンス番号を予測可能なケースがあった。TCPについて記されているRFC793では、イニシャルシーケンス番号の決定方法も合わせて記されている。ここで示されている方法は、4マイクロ秒ごとに加算される32ビットクロックを用いるというものである。このように、イニシャルシーケンス番号が端末稼働時間に依存する場合、試しにセッション確立を複数回試み、時間経過と各セッション確立に対する応答(拒否応答でも構わない)に含まれるシーケンス番号の増加傾向を確認することで充分予測可能となる。
防御
この問題は古くより指摘されており、CERT/CCからもCA-1995-01[2]が指摘されていた。この当時の対策としては、疑似乱数生成器(PRNG)を使用するというものであった。
しかしその後、なおも予測可能であるとする警告がCERT/CCからCA-2001-09[3]として指摘されることとなった。これは、統計的手法により疑似乱数生成器を用いたイニシャルシーケンス番号をかなり狭い範囲に絞り込むことが可能であるというものであった。
昨今の製品においては、RFC1948[4]で示される対策が既に施されていると考えられる。
脚注
関連項目
外部リンク