CVE-2020-10136～IP-in-IPに脆弱性…
久しぶりに個人的なツボにはまる脆弱性が…
CVE-2020-10136の脆弱性概要
詳しくは以下のJVNの記事を見てください。
要は「IP over IPを実現する規格の1つで、悪用される脆弱性があるからね」というもの。
この脆弱性を悪用すると、何ができるのか？
脆弱なIP-in-IPを使えるところを経由して、好きなところにIPパケットを送りつけることができます。いわば「IPパケットプロキシ」のような感じです。
IP-in-IPは、以下のRFCに記述されています。
TCPコネクションが必要など、戻りパケットが必須な攻撃を仕掛けるためには、少しアタマを使う必要がありますし、DDoSのように「大量にあちこちからパケットを送りつける用途」には若干効率が落ちる可能性はありますが*1、単にパケット送りつけられればいいという話であれば、これは非常に有用な脆弱性になります。
対策のサマリ
該当するJVN（http://jvn.jp/ta/JVNTA90492923/index.html）にも記述はありますので、そちらをご覧いただきたいですが、個人的にはそれも含めて以下の3つのいずれかになる、と考えています。
以下、上記のような結論に至った経緯を説明します。
IP-in-IPの通常利用と悪用のイメージ
以下に、通常の利用イメージ（あくまでイメージｗ）を示します。
普通ならば、Normal Userが、IP-in-IPサービスを経由して、任意の（Normal Userが通信したい）ホストにIPパケットを送りつけます。
詳細は省略しますが、通常はNormal Userとの間で、IP-in-IPを利用したトンネルを開設していると考えられるので、戻ってきたIPパケットは、宛先IPアドレスがNormal Userのものであれば、またIP-in-IPを使ってNormal Userに送り届けられます。
ところが、通常のIP-in-IPの規格を見ると、以下のようなことも可能そうです…。
そして、今回の脆弱性は、どうもこういうことが出来てしまう、というように読めます。
ポイントは、Normal UserもAttacker（攻撃者）も、フォーマットが正しいパケットさえ送っていれば、カプセル化を解除の上IP-in-IP serviceを提供するコンピュータ上での処理が走る、ということです。
攻撃者が送りつけたいIP packet2とIP packet3は、送信元IPアドレスに何が入ってるかわからないですが、IPパケットを送りつけるだけで成立する攻撃を仕掛けたいのであれば、これだけで事足ります。
JVNで挙げられている対策～送信元を限定した遮断は「役に立たない」
今回、該当するJVN（http://jvn.jp/ta/JVNTA90492923/index.html）には、以下の4つの対策が記述されています。
- アップデートする
- IP-in-IP を無効化する
- PoC を確認する
- 侵入検知システムでフィルタリングする
この中で、1のアップデートについてはよくわからない*2ですが、2についてはすべてのIP-in-IPを遮断・無効にする対策であり、使わずにすむのであれば、それが一番いいと思っています。
なお、よく言われる「送信元を限定する」対策は、今回の場合は役に立ちません。理由は後述します。
3は確認のための手段なので、有用といえば有用ですが、それで何かの対策になるか？は怪しいです。3を実施して、影響あるとなったら1,2,4のいずれかを実施する、というのが正しいでしょう。
4は「検知する」だけであり、これだけで遮断はできません。
送信元限定が対策にならない理由～IPはステートレス＆IP-in-IPは認証レス
送信元限定が対策にならない理由は2つ。
- IPプロトコルはステートレスである
- IP-in-IPに認証の仕組みがない
IPプロトコルがステートレスであり、かつIP-in-IPそのものには認証のしくみがないため、別の認証手段が必要となります。実際、RFC2003（RFC 2003 - IP Encapsulation within IP）でも、Authentication Header（RFC 1826 - IP Authentication Header）について言及されています。
じゃあ対策は？～IPsecを使うこと。でもこの時点で、IP-in-IPいらなくね？
ここまで読んでくれた人はもう理解したと思いますが、安全にIP-in-IPを使うためには、IP-in-IPパケットの送信元が正当であることを確認出来る必要があります。今、IPパケット単位でこのようなことを実現できるポピュラーな技術はIPsecです。実際、前述のAuthentication Header（RFC 1826 - IP Authentication Header）も、IPsecを実現する1つの形態です（パケット認証のみを行うモード）。今はだいたいESPだけで暗号化＋認証いけてしまうのですが、AHのような認証だけ行うというのも今回の場合は有効である、ということです。
もっとも、ここまでやっておいて、IP-in-IP + AHとするくらいならば、IPsecトンネルモード使えばいいんじゃないか？と思うのはオレだけではないはずです。
むすび～IP-in-IPを使うならばベンダの修正を適用 or AHを併用する or 他の選択肢を採用できないか？を考えよう
今回の脆弱性は、いろいろとステートレスの意味を考えさせられるものでした。
とりあえず「不正なIP-in-IP通信を検知できる」というところでしのいで（問題は、しのいだところで不正なパケット送付を防止できるわけではないこと）、ベンダ製装置を使用しているのであれば、修正を適用する、もしくはIPsec AHを使う、もしくは別の手段に乗り換えるかというくらいしかないです。
