Heartbleed:如何可靠和便携地检查OpenSSL版本?

我正在寻找一种可靠和便携的方式来检查GNU / Linux和其他系统上的OpenSSL版本,因此用户可以很容易地发现是否应该升级他们的SSL,因为Heartbleed错误。

我认为这很容易,但是我很快在最新的OpenSSL 1.0.1g的Ubuntu 12.04 LTS上遇到了一个问题:

  openssl版本-a 

我期待看到一个完整的版本,但是我得到了这个:

  OpenSSL 1.0.1 2012年3月14日
build立于:2013年6月4日星期二07:26:06 UTC
平台:[...] 

令我不愉快的惊喜,版本信不显示。 不,没有,只是“1.0.1”就是这样。 列出的date也无助于发现(非)易受攻击的版本。

1.0.1(af)和1.0.1g之间的差异是至关重要的。

问题:

  • 什么是可靠的方式来检查版本,最好是跨发行版?
  • 为什么不把版本信件放在首位? 除了Ubuntu 12.04 LTS,我无法testing这个。

其他人也报告这种行为。 几个例子:

  • https://twitter.com/orblivion/status/453323034955223040
  • https://twitter.com/axiomsofchoice/status/453309436816535554

一些(特定于发行版)的build议正在滚动:

  • Ubuntu和Debian: apt-cache policy opensslapt-cache policy libssl1.0.0 。 比较版本号与这里的包: http : //www.ubuntu.com/usn/usn-2165-1/
  • Fedora 20: yum info openssl (感谢@ znmeb在twitter上)和yum info openssl-libs

检查旧版本的OpenSSL是否仍驻留:

  • 这不是完全可靠的,但你可以试试lsof -n | grep ssl | grep DEL lsof -n | grep ssl | grep DEL lsof -n | grep ssl | grep DEL 。 见Heartbleed:如何可靠和便携地检查OpenSSL版本? 为什么这可能不适合你。

事实certificate,在Ubuntu和Debian上更新OpenSSL包并不总是足够的。 你还应该更新libssl1.0.0包,然后 – 然后检查是否openssl version -a指示built on: Mon Apr 7 20:33:29 UTC 2014

根据您的OpenSSL版本显示的date,似乎您看到显示的完整版本。

Open SSL 1.0.1于2012年3月14日发布 。 1.0.1a于2012年4月19日发布。

因此,我将继续并声明openssl version -a是一种正确的,跨发行版的方式来显示安装在系统上的完整版本的OpenSSL。 它似乎适用于我可以访问的所有Linux发行版,并且也是help.ubuntu.com OpenSSL文档中build议的方法 。 Ubuntu LTS 12.04附带了vanilla OpenSSL v1.0.1,这个版本看起来像一个缩写版本,因为它后面没有一个字母。

话虽如此,似乎在Ubuntu中有一个重大的 bug(或者它们如何打包OpenSSL),在openssl version -a ,无论OpenSSL是否具有自2012年3月14日起继续返回原来的1.0.1版本已升级到任何新版本。 和下雨时的大部分事情一样,

Ubuntu并不是将更新反向移植到OpenSSL(或其他软件包)中的唯一主要发行版,而是依赖每个人都认可的上游更新和版本编号。 在OpenSSL的情况下,字母版本号只代表错误修复和安全更新,这似乎几乎不可理解,但我被告知这可能是因为经过FIPSvalidation的主要Linux发行版与OpenSSL打包在一起。 由于任何更改都会触发重新validation的要求,即使插入安全漏洞的更改也是版本locking的。

例如,在Debian上,固定版本显示版本号为1.0.1e-2+deb7u5而不是上游版本1.0.1g

因此, 目前还没有可靠的,可移植的方法来检查Linux发行版中的SSL版本 ,因为它们都使用自己的backport补丁,并使用不同的版本编号scheme进行更新。 您将不得不为每个不同的Linux发行版查找固定的版本号,并根据该发行版的特定版本号检查已安装的OpenSSL版本,以确定您的服务器是否运行易受攻击的版本。

如果你想要一个真正跨平台的东西, 检查这个漏洞本身,而不是依靠版本号。

您可能拥有报告已知易受攻击版本号的代码但实际的代码不易受到攻击 。 而反向 – 无声的脆弱的代码 – 可能会更糟!

许多捆绑OpenSSL和OpenSSH等开放源代码产品的供应商会select性地将紧急修复程序改为旧版代码,以保持API的稳定性和可预测性。 对于“长期版本”和设备平台尤其如此。

但是那些静静地执行此操作的供应商(不添加自己的版本string后缀)会在漏洞扫描器中引发误报(以及令用户困惑)的风险。 所以为了使这个透明和可validation,一些供应商将自己的string附加到主要的软件包版本。 Debian(OpenSSL)和FreeBSD(在OpenSSH中,通过VersionAddendum sshd_config指令)有时会这样做。

不这样做的供应商可能是这样做的,以尽量减less由于其他程序检查版本号的多种直接和间接方式而导致破坏的可能性。

所以它可以看起来像这样:

 $ 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,如果以下所有情况都属实,则可以判断是否已更新:

  1. dpkg -s openssl | grep Version dpkg -s openssl | grep Version显示版本1.0.1-4ubuntu5.12或更高版本。
  2. dpkg -s libssl1.0.0 | grep Version dpkg -s libssl1.0.0 | grep Version显示版本1.0.1-4ubuntu5.12或更高版本。
  3. openssl version -a显示2014年4月7日或更晚的“build立”date。

感谢@danny获取更多信息。

请尝试以下方法。 它将从ssh链接的encryption库中提取所有string。 它生成多行输出,但如果需要可以转换为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 

哎哟,还没有克。

是否有这些脚本testing所有服务,还是只testingHTTPS ? AFAIK , PostgreSQL是脆弱的,但这只是一个传闻,直到一个野​​外攻击表面。

有一个metasploit脚本可供使用。

 https://github.com/rapid7/metasploit-framework/commit/dd69a9e5dd321915e07d8e3dc8fe60d3c54f551a 

你可以input这个(使用GnuWin32 OpenSSL二进制版本1.0.1.6进行testing,date是2014-01-14),或者在下面的注释中使用脚本。 这更准确,更简单!

 s_client -connect a23-75-248-141.deploy.static.akamaitechnologies.com:443 -debug -state 

一旦连接typesB,你会看到一个脆弱的主机,你不会被断开连接:

 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 

你会得到一个类似于这个的心跳响应。

在已修补的主机上,您将看到类似于下面的回复,您将被断开连接:

inputB

 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},{.GV 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 

资源:

  • 博客文章如何testing您的OpenSSL是否stream血

还有这些工具:

对于Ubuntu,您可以使用:

 aptitude show libssl1.0.0 | grep Version 

并与http://www.ubuntu.com/usn/usn-2165-1/比较。 重新启动(!!!)后,您可以检查http://possible.lv/tools/hb

你最好升级到最新的OpenSSL OpenSSL 1.0.1j。

http://blog.vincosolution.com/2014/10/upgrade-openssl-1-0-1j-debianubuntu.html

我在devcentral中find了这个脚本 :

 openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe 

example.comreplace为您要检查的服务器的名称或IP地址。

如果你的服务器没有问题,或者"server extension "heartbeat" (id=15)"将返回"safe"

这不依赖于版本号,而是列出导致问题的服务器扩展,所以它应该对库版本shenanigans免疫。

运行openssl s_client的机器必须使用OpenSSL 1.0.1或更高版本才能运行。