よくある質問| エリアビイジャパン株式会社 / /

よくある質問

607100 off-path TCP脆弱性(CVE-2016-5696)が報告されていますが、SWANStorに影響はありますか

off-path TCP脆弱性(CVE-2016-5696)はRFC 5961で提言されたTCPのセッションハッキングを低減させる方式ですが、Linuxにおけるその実装に問題が有り、比較的簡単な方法でTCPのセッションハッキングが可能となるという問題で、カリフォルニア大学リバーサイド校のYue Cao氏らによって報告されたものです。


TCPハッキングとは、悪意のある第三者が、通信中のTCPの送受信IPとポート番号、有効なセッション番号を指定したパケットに悪意のあるコードを入れて送りつけ、システムをクラッキングするというものです。


RFC 5961以前の実装では、悪意のある第三者が通信中のTCPの送受信IPとポート番号、有効な範囲内にあるセッション番号を指定したTCPパケット(TCP SYN)を送るだけでそのTCP通信を終了させてしまうことができていました。これを改良したRFC 5961では、TCP SYNを送ってTCP通信を終了させたい場合は決められたセッション番号が送られた場合のみとし、それ以外は”Challenge Ack”を返して正しいTCP SYNまたはTCP RSTを送るように促すようにして、第三者による介入リスクを下げようと試みたのです。ただ、仕様では通信中のTCPセッションに対してTCP SYNを受け取った場合、無条件で”Challenge Ack”を返すことになっていて、DoS攻撃のようにTCP SYNを大量に受け取った場合にいちいち”Challenge Ack”を返していてはリソースの浪費につながりかねないため、1秒間に返す”Challenge Ack”の数をシステムで決めていて、今いくつ返しているかというカウンター値を保持して管理するという実装になっているのですが、それが別の問題を発生させてしまったというのが今回の問題となります。


この問題について更に話を進める前にSWANStorへの影響についてですが、SSLで暗号化されたSWANStorの通信では、この問題の影響はほとんどありません。


悪意のある第三者がTCPハッキングに成功しても、データの中身が見れるわけではなく悪意のあるコードを送りつけることができるだけですが、そのコードはSSL通信に対して意味のあるものではあり得ず、またSSL通信ではTCPとは別のセッション番号で暗号通信を管理していて、その番号は上記の方法ではハッキングできないので、結局送られてきた悪意のあるコードは、受信側で無視され廃棄されてしまいます。


そこで、以下の記事はSWANStorシステム以外の一般的なケース、例えばHTTP/Telnet/FTPなど、TCPの上で暗号化していない通信を行っている場合への本問題の影響と対処法についての内容となります。


上記のとおり、悪意のある第三者は、通信中のTCPの送受信IPとポート番号、有効なセッション番号を指定したパケットに悪意のあるコードを入れて送りつけ、システムをクラッキングしようとするのですが、そのために、TCPの送受信IPとポート番号、有効なセッション番号といった情報が必要となります。RFC 5961が実装されたシステムでは、例えばTCPの送受信IPとポート番号が現在通信中のものとマッチしていれば、”Challenge Ack”が応答されカウンター値が一つ減ります。”Challenge Ack”はパケットに指定した”送信者IP”に返され、悪意のある第三者には応答されませんが、現在のLinuxカーネルの実装ではカウンター値がシステムに1個となっているため、悪意のある第三者が個別のTCPセッションを張っておき、TCP SYNを送って返ってくる”Challenge Ack”を観察することで、攻撃ターゲットが攻撃パケットに対して”Challenge Ack”を送ったか送らなかったかを判断することができ、つまり悪意のある第三者が最初に送った、攻撃パケットのTCPの送受信IPとポート番号が、現在通信中のものとマッチしているのかどうかを知ることができるのです。同じようなやり方で、有効なセッション番号も探索が可能となります。


この問題はRedHat 6以上に影響があるようです。RedHat 5以前あるいはWindowsやMacOSXなどではRFC 5961を実装していないため影響がありません。また、ご利用のLinuxカーネルによってはRFC 5961をバックポートしている場合があり、RedHat 5以前と同じバージョンのカーネルでも実際には影響している可能性もあるようです。


影響しているかどうかについては次のコマンドで確認することができます。


sysctl -a | egrep net.ipv4.tcp_challenge_ack_limit

これで

net.ipv4.tcp_challenge_ack_limit = 100

のように表示される場合、ご利用のシステムはCVE-2016-5696の影響を受ける可能性があります。このパラメータの100という数値がデフォルト値となっています。


対処法については、カーネルのアップデートが望ましいですが、その場合にはシステムの再起動が必要となります。


また、上記攻撃手法について「返ってくる”Challenge Ack”を観察することで、攻撃ターゲットが攻撃パケットに対して”Challenge Ack”を送ったか送らなかったかを判断する」について、net.ipv4.tcp_challenge_ack_limitが100と小さい数値なので、攻撃ターゲットに対して100個の攻撃パケットを送りつければ、悪意のある第三者が引き続き送るTCP SYNに対し、本来返されるべき”Challenge Ack”が返ってこないことを観察するだけで攻撃の正しさを判断できてしまうので、この値をものすごく大きな値に設定しなおすことで、簡単には攻撃の成否を判断できないようにするという対処法もあります。

net.ipv4.tcp_challenge_ack_limit = 999999999

を、RedHat 6あるいはその互換OSであれば/etc/sysctl.confの最後の行に追加し、RedHat 7 あるいはその互換OSであれば/etc/sysctl.d/にcve-2016-5696.confとして保管します。

その上でsysctl –systemで設定を反映させます。


なお、上記の対処法を具体的に実施されるばあい、各自の責任において行ってください。









Updated on 12月 4, 2023