Heartbleed：OpenSSLのバージョンを確実かつ移植性のある方法で確認する方法
私は、GNU/Linuxやその他のシステムでOpenSSLのバージョンを確認するための信頼できる移植可能な方法を探していたので、HeartbleedバグのためにユーザーがSSLをアップグレードする必要があるかどうかを簡単に見つけることができます。
簡単だと思いましたが、Ubuntu 12.04 LTSの最新のOpenSSL 1.0.1gですぐに問題が発生しました。
opensslバージョン-a
フルバージョンが表示されると思っていましたが、代わりに次のようになりました。
OpenSSL 1.0.1 2012年3月14日 ビルド：Tue Jun 4 07:26:06 UTC 2013 プラットフォーム：[...]
不愉快なことに、バージョンレターが表示されません。 fもgもありません。「1.0.1」だけです。リストされた日付は、（非）脆弱性のあるバージョンの発見にも役立ちません。
1.0.1（a-f）と1.0.1gの違いは非常に重要です。
質問：
- バージョンを確認する信頼できる方法は何ですか？できればクロスディストリビューション？
- そもそもバージョン文字が表示されないのはなぜですか？ Ubuntu 12.04 LTS以外ではテストできませんでした。
他の人もこの動作を報告しています。いくつかの例：
- https://Twitter.com/orblivion/status/45332303495522304
- https://Twitter.com/axiomsofchoice/status/453309436816535554
一部の（ディストリビューション固有の）提案は次のとおりです。
- UbuntuとDebian：
apt-cache policy opensslおよびapt-cache policy libssl1.0.0。ここでバージョン番号をパッケージと比較します： http://www.ubuntu.com/usn/usn-2165-1/ - Fedora 20：
yum info openssl（Twitterの@znmebに感謝）およびyum info openssl-libs
古いバージョンのOpenSSLがまだ常駐しているかどうかの確認：
- 完全に信頼できるわけではありませんが、
lsof -n | grep ssl | grep DELを試すことができます。これが機能しない理由については、 Heartbleed：OpenSSLバージョンを確実かつ移植性のある方法で確認する方法 を参照してください。
UbuntuとDebianでOpenSSLパッケージを更新するだけでは必ずしも十分ではないことがわかりました。また、libssl1.0.0パッケージを更新し、openssl version -aがbuilt on: Mon Apr 7 20:33:29 UTC 2014を示しているかどうかを確認してください。
OpenSSLのバージョンによって表示される日付に基づいて、そこに表示されている完全なバージョンを見ているようです。
Open SSL 1.0.1は2012年3月14日にリリースされました 。 1.0.1aは2012年4月19日にリリースされました。
したがって、私は先に進み、openssl version -aがシステムにインストールされているOpenSSLの完全バージョンを表示する適切なクロスディストリビューションの方法であることを断言します。これは、私がアクセスできるすべてのLinuxディストリビューションで機能するようです。 help.ubuntu.com OpenSSLのドキュメントでも提案されている方法です 。 Ubuntu LTS 12.04には、Vanilla OpenSSL v1.0.1が同梱されています。これは、それに続く文字がないため、省略バージョンのように見えるバージョンです。
そうは言っても、Ubuntu（またはOpenSSLのパッケージ方法）にmajorバグがあるようで、openssl version -aは引き続き元の1.0.1バージョンを返しますOpenSSLが新しいバージョンにアップグレードされたかどうかに関係なく、2012年3月14日から。そして、雨が降るとほとんどのことと同様に、それは注ぐ。
Ubuntuは、アップデートをOpenSSL（または他のパッケージ）にバックポートする習慣における唯一の主要なディストリビューションではなく、誰もが認識しているアップストリームのアップデートとバージョン番号付けに依存するよりも評価が高いです。文字バージョン番号がバグ修正とセキュリティ更新のみを表すOpenSSLの場合、これはほとんど理解できないようですが、これは FIPS-validated プラグインの主要なLinuxディストリビューションが原因である可能性があると通知されましたOpenSSLでパッケージ化されて出荷されます。変更によってトリガーされる再検証に関する要件のため、セキュリティホールを埋める変更であっても、バージョンがロックされます。
たとえば、Debianでは、修正されたバージョンには、アップストリームバージョンの1.0.1e-2+deb7u5ではなく、1.0.1gのバージョン番号が表示されます。
その結果、現時点では、Linuxディストリビューション全体でSSLバージョンを確認するための信頼できる移植可能な方法はありません、それらはすべて、異なるバージョン番号付けスキームで独自のバックポートされたパッチと更新を使用するためです。実行するLinuxの各ディストリビューションの固定バージョン番号を検索し、インストールされているOpenSSLバージョンをそのディストリビューションの特定のバージョン番号と照合して、サーバーが脆弱なバージョンを実行しているかどうかを判断する必要があります。
本当にクロスプラットフォームなものが必要な場合は、バージョン番号に依存するのではなく、脆弱性自体をチェックしてください。
脆弱であることがわかっているバージョン番号を報告するコードがあるかもしれませんが、実際のコードは脆弱ではありません。そして、その逆-静かに脆弱なコード-はさらに悪化する可能性があります！
OpenSSLやOpenSSHなどのオープンソース製品をバンドルする多くのベンダーは、APIの安定性と予測可能性を維持するために、緊急の修正を古いバージョンのコードに選択的に改良します。これは特に、「長期リリース」およびアプライアンスプラットフォームに当てはまります。
ただし、これをサイレントに（独自のバージョン文字列サフィックスを追加せずに）行うベンダーは、脆弱性スキャナー（およびユーザーを混乱させる）で誤検知をトリガーするリスクを負います。したがって、これを透過的かつ検証可能にするために、一部のベンダーは独自の文字列をメジャーパッケージバージョンに追加しています。 Debian（OpenSSL）とFreeBSD（OpenSSHではVersionAddendum sshd_configディレクティブを使用）の両方がこれを行うことがあります。
これを行わないベンダーは、他のプログラムがバージョン番号をチェックする多くの直接的および間接的な方法による破損の可能性を最小限にするために、おそらくそうしています。
したがって、次のようになります。
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.4 LTS"
$ openssl version
OpenSSL 1.0.1 14 Mar 2012
... パッチが適用されています ：
$ dpkg -l openssl | grep openssl
ii openssl 1.0.1-4ubuntu5.12 [truncated]
$ ls -la `which openssl`
-rwxr-xr-x 1 root root 513208 Apr 7 12:37 /usr/bin/openssl
$ md5sum /usr/bin/openssl
ea2a858ab594905beb8088c7c2b84748 /usr/bin/openssl
このようなことをしていると、バージョン番号を信用しない方がいいです
残念ながら、私はこれを行うためのクロスプラットフォームの方法があるかわかりません。 ブログの投稿で説明しているように 、OpenSSLのバージョンは、固定バージョンにアップグレードした後、Ubuntu 12.04 REMAINS 1.0.1に表示されます。
Ubuntu 12.04の場合のみ、以下がすべて当てはまる場合は、更新されているかどうかを確認できます。
dpkg -s openssl | grep Versionはバージョン1.0.1-4ubuntu5.12以降を示します。dpkg -s libssl1.0.0 | grep Versionはバージョン1.0.1-4ubuntu5.12以降を示します。openssl version -aは、2014年4月7日以降の「ビルドオン」日付を示しています。
追加情報を提供してくれた@dannyに感謝します。
次のことを試してみてください。 sshがリンクされているcryptoライブラリからすべての文字列を抽出します。複数行の出力を生成しますが、必要に応じて1行に変換できます。
ldd `which ssh` | awk '/\// { print $3 }' | grep crypto | xargs strings | grep OpenSSL
作り出す
OpenSSLDie
DSA_OpenSSL
...
MD4 part of OpenSSL 1.0.1f 6 Jan 2014
MD5 part of OpenSSL 1.0.1f 6 Jan 2014
...
etc
例えば出現する前のGentoo
[ebuild U ] dev-libs/openssl-1.0.1f [1.0.1c] USE="bindist (sse2) tls-heartbeat%* zlib -gmp -kerberos -rfc3779 -static-libs {-test} -Vanilla" 4,404 kB
上記のコマンドの結果は
...
OpenSSL 1.0.1c 10 May 2012
後
...
OpenSSL 1.0.1f 6 Jan 2014
痛い、まだない。
これらのスクリプトのいずれかがすべてのサービスをテストしますか、それとも [〜＃〜] https [〜＃〜] のみをテストしますか？ [〜＃〜] afaik [〜＃〜] 、 PostgreSQL は脆弱ですが、それは野生の攻撃が表面化するまでの噂にすぎません。
使用できる metasploit スクリプトがあります。
https://github.com/rapid7/metasploit-framework/commit/dd69a9e5dd321915e07d8e3dc8fe60d3c54f551a
これを入力するか（ GnuWin32 OpenSSLバイナリバージョン1.0.1.6でテスト済み、2014-01-14付）、またはこの下のコメントにあるスクリプトを使用します。より正確でシンプルです！
s_client -connect a23-75-248-141.deploy.static.akamaitechnologies.com:443 -debug -state
タイプBに接続すると、脆弱なホストに表示され、接続が解除されることはありません。
B
HEARTBEATING
write to 0x801c17160 [0x801cbc003] (66 bytes => 66 (0x42))
0000 - 18 03 03 00 3d 8f 6f 3c-52 11 83 20 9c a2 c0 49 ....=.o 5 (0x5))
0000 - 18 03 03 00 3d ....=
read from 0x801c17160 [0x801cb7008] (61 bytes => 61 (0x3D))
0000 - 05 4d f5 c0 db 96 d1 f5-c7 07 e5 17 1f 3b 48 34 .M...........;H4
0010 - 6e 11 9d ba 10 0c 3a 34-eb 7b a5 7c c4 b6 c0 c0 n.....:4.{.|....
0020 - b0 75 0e fe b7 fa 9e 04-e9 4e 4a 7d 51 d3 11 1f .u.......NJ}Q...
0030 - e2 23 16 77 cb a6 e1 8e-77 84 2b f8 7f .#.w....w.+..
read R BLOCK
これに似たハートビート応答が得られます。
パッチが適用されたホストでは、以下のような応答が表示され、接続が切断されます。
Bを入力してください
HEARTBEATING
write to 0x801818160 [0x8019d5803] (101 bytes => 101 (0x65))
0000 - 18 03 03 00 60 9c a3 1e-fc 3b 3f 1f 0e 3a fe 4c ....`....;?..:.L
0010 - a9 33 08 cc 3d 43 54 75-44 7d 2c 7b f3 47 b9 56 .3..=CTuD},{.G.V
0020 - 89 37 c1 43 1c 80 7b 87-66 ff cb 55 5f 8d 1a 95 .7.C..{.f..U_...
0030 - 1b 4c 65 14 21 a1 95 ac-7a 70 79 fc cc a0 cf 51 .Le.!...zpy....Q
0040 - 0f 7e c5 56 14 c8 37 c1-40 0b b8 cb 43 96 8a e6 [email protected]...
0050 - 21 42 64 58 62 15 fb 51-82 e6 7f ef 21 1b 6f 87 !BdXb..Q....!.o.
0060 - b9 c2 04 c8 47 ....G
ソース：
これらのツールもあります：
最新のOpenSSL OpenSSL 1.0.1jにアップグレードすることをお勧めします。
http://blog.vincosolution.com/2014/10/upgrade-openssl-1-0-1j-debianubuntu.html
私は devcentralのこのスクリプト を見つけました：
openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe
example.comを、確認するサーバーの名前またはIPアドレスに置き換えます。
サーバーに問題がない場合は"safe"を返し、問題がある場合は"server extension "heartbeat" (id=15)"を返します。
これはバージョン番号には依存しませんが、問題の原因となるサーバーエクステンションのリストに基づいているため、ライブラリのバージョンの悪用の影響を受けません。
openssl s_clientを実行しているマシンmustこれが機能するためには、OpenSSL 1.0.1以降を使用している必要があります。
Ubuntuの場合：
aptitude show libssl1.0.0 | grep Version
そして http://www.ubuntu.com/usn/usn-2165-1/ と比較してください。再起動後（!!!）、http://possible.lv/tools/hbで確認できます。