ROBOT (Return Of Bleichenbacher's Oracle Threat) 対応

セキュリティの専門家ではありません。情報漏えいの危険性のある脆弱性に関することなので参考程度に見ていただくようにお願いします(記載した情報の正しさ、対処の判断などについて自己責任でお願いします)
自分でも分かっていないこと多いので、内容についてご指摘いただけると助かります。
あと、うちはこう考えた！こう判断した！こう対応してる！みたいの超うれしいです
内容について不定期に補足・修正する予定です

ソース

参考になるサイト

ITmedia
http://www.itmedia.co.jp/enterprise/articles/1712/14/news061.html

ZDNet
https://japan.zdnet.com/article/35111951/

内容

ソースのgoogle翻訳+多少誤訳修正
(前半部分だけ)

脆弱性
ROBOTは、TLSサーバーの秘密鍵でRSAの復号化と署名操作を実行できる19年前の脆弱性の復活です。
1998年にDaniel Bleichenbacherは、PKCS＃1 v1.5パッディングのエラーのためにSSLサーバーによって提供されたエラーメッセージが適応的に選択された暗号文攻撃を許可したことを発見しました。この攻撃は、RSA暗号化で使用されるTLSの機密性を完全に破棄します。
我々は、いくつかのわずかなバリエーションを使用することによって、今日のインターネットでは多くのHTTPSホストに対してこの脆弱性を使用できることを発見しました。

どれくらい悪い？
脆弱で、RSA暗号鍵交換のみをサポートするホストにとっては、かなり悪いことです。これは、攻撃者が受動的にトラフィックを記録し、後でそれを解読できることを意味します。
通常は転送秘密を使用するが脆弱なRSA暗号化キー交換をサポートしているホストでは、攻撃者が攻撃を実行する速度に依存します。サーバーの偽装や中間攻撃の可能性はありますが、それはより困難です。

影響を受けるのは誰ですか？
F5、Citrix、およびCiscoを含む少なくとも7つのベンダーの脆弱な実装を識別しました。 （現在のパッチの状態は以下の通りです。）
FacebookやPaypalなど、インターネット上で最も人気のあるウェブページが影響を受けました。合計で、Alexaによってランク付けされた上位100個のドメインのうち27個に脆弱なサブドメインが見つかりました。
上記のテストを使用して、パブリックHTTPSサーバーをテストすることができます。脆弱なホストをスキャンするためのPythonツールも公開しました。
複数のベンダーが修正を保留しており、現時点では名前が付けられません。パッチが入手可能になると、次の表が更新されます。
※表を省略
MatrixSSLとJSSEは古い脆弱性ですが、脆弱なホストがまだ存在するため、MatrixSSLとJSSEを追加しました。

該当する場合どうすれば良いですか?
修正プログラムを提供する製品を使用している場合は、もちろん更新プログラムをインストールする必要があります。しかし、私たちは何か他のことをお勧めします：

RSA暗号化を無効にする！
ROBOTは、RSA暗号化を使用するTLS暗号モードにのみ影響します。現代のTLS接続のほとんどは、楕円曲線ディフィーヘルマン鍵交換を使用しており、署名のためだけにRSAが必要です。私たちは、RSA暗号化モードが非常に危険であると信じており、唯一の安全な方法はそれらを無効にすることです。これらのモードにはリスクを伴うことは別として、前方の秘密がありません。
RSA暗号化を無効にすると、TLS_RSAで始まるすべての暗号を意味します。 RSA署名を使用する暗号は含まれておらず、名前にDHEまたはECDHEが含まれています。これらの暗号は私たちの攻撃の影響を受けません。
予備データに基づいて、RSA暗号化モードを無効にする互換性コストは比較的低いとも考えています。 Cloudflareは、接続の約1％がRSA暗号化モードを使用していることを私たちと共有しました。著者の1人が運用するHTTPSサーバーでこれらのモードを無効にすると、大きな問題は生じませんでした。
...

チェックツールを実行する

ROBOT研究チームの公開してるツールを試してみる

その1. HTTPSパブリックサーバ用のテストツール

インターネット上のHTTPSのサイトの場合にチェックできる
入力欄にFQDNを入力して、Test Serverをクリックする
(https://とかは必要ない。あとアプリケーション(コンテキスト)名はつけられない。あくまでホスト名とドメイン名のみ)

クリックするとこの画面になる。テストには数分くらい時間がかかるときがある。2回目以降は早い。
(安易に本番環境や社外のサイトに実行しないようにしましょう)

こんな感じで結果が出る

This host is not vulnerable. と表示されれば問題なしと判断できる
"しかしながらRSAはまだ許可されてますよ"の警告つきだけど。
自社運用のサイトを管理者に許可得ていくつか実行してみたけど、問題が見つかるケースがありませんでした(問題あるとどう表示されるのかちょっと見てみたい気はしますが^^ 黄色いところが赤く表示されると勝手に想像)
robot.orgでFacebookとかいくつかのサイトがひっかかったと書いてるのはこのツールと同じようなことを実行したのかも?

その2. 脆弱なホストをスキャンするための「Python」ツール

実行元の環境はUbuntu17.04
Windows10+Vagarantでインストールしました(インストール試したときの記事もQiitaにあるので参考にしていただければ。でも特に設定とかはしてなくてほんとにVagrant試すために入れただけです)
Vagramt試すためだけに立てたけど直近で立派に活用の機会が来ようとは・・

インストール

apt-get install python-pip python-dev
apt-get install python3-pip python3-dev
apt-get install python3-gmpy2
pip3 install robot-detect

ヘルプ

robot-detect
usage: robot-detect [-h] [-p int] [-t TIMEOUT] [-q] [--gcm | --cbc] [--csv]
                    host
robot-detect: error: the following arguments are required: host

適当なテストサーバに実行
(これはUbuntuから対象サーバにつながればいいので、イントラのサーバに対しても実行できます)

robot-detect <テストサーバ>
Scanning host <テストサーバ> ip <IP> port 443
RSA N: 0xcf212766462a1202591338be2bb620a3531ee8004f06715b290a11f2ddd8520e73ccf1a9a9025305970475c1bcb331c9215ea0e8e7ba8247dd417079e7325c75f1ec9fb5f822bbf0cfe904cae84efe9e9006c364313ef9c82105a2ba39a82a42ffeba3db88880faasd9f876a9sd8fa6fcaacb0a832d29d81dff1878ba21812b33501d3d4b86e473ec0fd33c12e1d4b5e83fd09ed95ddabae50e2da45f022d0a61c005f7eade85caccc3b7ebc20f0c03af009b08f82c289bdf936ed31f9ab1396c51be66078756afddcfd015fdf82a49f5d08adaca6628929c0862275edfce745d5093e4e39a9c06ce06e43803ae00931fe1ab291d1ab02cbdb78539d5865315
RSA e: 0x10001
Modulus size: 2048 bits, 256 bytes
Identical results (TLS alert 20 of length 7), retrying with changed messageflow
Identical results (Timeout waiting for alert), no working oracle found
NOT VULNERABLE!

NOT VULNERABLE!って出力されればOKなんだと思います
"oracle found"に業務でOracle利用してるので反応してしまうんですけど、脆弱性の名前がパディングオラクルアタックとか、英語でOracleは神託的というような意味で使われていて、Oracle社の製品のことをさしてるわけではなさそうです。
こちらもイントラのいくつかのサーバ(Apache+mod_SSL)に実行してみたり、AWSのELBでTLSを設定しているサーバに実行してみたりしましたが、問題は見つかりませんでした。
あと、ssllaboというサイトがあって、こちらでいろいろなクライアントからテスト対象のサイトにアクセスしたときに利用される暗号プロトコルスイートが確認できます。

その3. サポートされてる暗号プロトコルスイートと各種クライアントとの通信で利用されるプロトコルのチェックツール

https://www.ssllabs.com

※インターネットアクセスできるHTTPSのサイトだけです
右上のTest your server をクリック
Hostname:にFQDNを入力して、submitをクリックします
こんな感じで処理待ちになります

しばらくすると(パーセンテージが上がると)少しずつ情報が表示され(先頭の方はサイトの証明書の情報とか)・・
わたしが試してるサイトではランクAで表示されました
今回の脆弱性に関して、Aの右隣のグラフの、Key Exchangeのスコアも気になります(これがどうなのかは分かりませんが)

今回見たいのは、Handshake Simulationの項目になります

私見ですが、この各クライアントの種類の一番右にFSと書いてあるものはROBOTの影響を受ける可能性は小さく、No FSと書いてあるものが危険と判断しました。
FS=Forward secrecy。もしバレても大丈夫!(通信を傍受されて保存されて復号を試みられても破られる可能性が低くなる実装)ということです。今回の場合は、鍵交換するときの暗号プロトコルにECDHEを利用していれば、ECDHEは通信の暗号化をする鍵を一時的に生成してすぐ破棄する暗号プロトコルのようで、鍵交換にRSAを直接利用していれば、悪意のある第3者に通信が傍受されたときに復号される危険があるが、ECDHEで鍵交換していれば、復号を試みるための情報はすでに消失済みとなるので復号される危険性が減る、というようなものです。

No FSとなっているものを見ていくと、Android 2x, Windows XPのIE8, Java6, OpenSSL0.98 ですね(メジャーver部分をひろってます)
ただ、他のサイトもいくつか見たところ、Windows Phone8, 8.1もNo FSとなっているもがありました。
いずれもメーカーのサポート切れの古いクライアントで、新しいverのクライアントやブラウザを利用していれば問題なさそうです。
あとここで書いてるJavaとかOpeeSSLは、サーバ側ではなくクライアントとしてHTTPSサーバに通信したときのものだと思います。
Java6で代々動いているツールとか、ものもちよく大事にずっと使ってるAndroid 2xのスマホからインターネットアクセスすると、ROBOT攻撃受ける可能性がありそうと思います。

総合して私なりの解釈

• 要するにクライアント<->サーバ間の鍵交換に、ECDHEが利用されていれば影響を受ける可能性が低い
  • 通信を盗み取られたとしても暗号解読用の鍵が破棄されてしまっているので
• 厳密にはTLSの通信を洗い出して大丈夫か確認が必要だと思いますので、そこの対応方針が迷いどころかと思います
  • robot.orgよりネットワーク製品などで問題が見つかっているということなので、厳密にはTLS使ってるネットワーク機器の洗い出しとパッチ情報のチェックなどが必要かなと。あと、TLSっていろんなところに使われてるので以下のような通信経路の考慮も必要かと・・
  • クラウド上のグループウェア/メールサーバ(G Suite, Office365など), クラウド上のID製品(SAML製品, Azure ActiveDirectoryなど)、インターネットアクセス可能なルーターやロードバランサー、リバースプロキシサーバなど。あとインターネットVPN・・・??(これ思いついたときにちょっと怖くなりました)

他に参考にしたサイト

いっぱいありますが出元がちゃんとしたところでこれがおすすめです

SSL/TLS 暗号設定ガイドライン
https://www.ipa.go.jp/files/000045645.pdf

その他

JVN https://jvn.jp/vu/JVNVU92438713/ みると各メーカーが「対応済み」とか書いてるけどRSAオフっちゃってるのかな・・古いクライアントからつなぐと影響受けるんじゃないかと思うけどサポート切れのばかりだし切り捨て??