Heartbleed: ¿cómo verificar de forma confiable y portátil la versión de OpenSSL?

Estaba buscando una forma confiable y portátil de verificar la versión de OpenSSL en GNU / Linux y otros sistemas, para que los usuarios puedan descubrir fácilmente si deberían actualizar su SSL debido al error Heartbleed.

Pensé que sería fácil, pero rápidamente me encontré con un problema en Ubuntu 12.04 LTS con el último OpenSSL 1.0.1g:

versión openssl -a

Esperaba ver una versión completa, pero en cambio obtuve esto:

OpenSSL 1.0.1 14 de marzo de 2012
construido en: martes 4 de junio 07:26:06 UTC 2013
plataforma: [...]

Para mi desagradable sorpresa, la carta de la versión no se muestra. No f, no g allí, solo "1.0.1" y listo. Las fechas enumeradas tampoco ayudan a descubrir una versión (no) vulnerable.

La diferencia entre 1.0.1 (af) y 1.0.1g es crucial.

Preguntas:

• ¿Cuál es una forma confiable de verificar la versión, preferiblemente la distribución cruzada?
• ¿Por qué no se muestra la letra de la versión en primer lugar? No pude probar esto en otra cosa que no sea Ubuntu 12.04 LTS.

Otros también informan este comportamiento. Algunos ejemplos:

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

Algunas sugerencias (específicas de la distribución) llegan:

• Ubuntu y Debian: apt-cache policy openssly apt-cache policy libssl1.0.0. Compare los números de versión con los paquetes aquí: http://www.ubuntu.com/usn/usn-2165-1/
• Fedora 20: yum info openssl(gracias @znmeb en twitter) yyum info openssl-libs

Comprobando si una versión anterior de OpenSSL sigue siendo residente:

• No es completamente confiable, pero puedes intentarlo lsof -n | grep ssl | grep DEL. Vea Heartbleed: ¿cómo verificar de forma confiable y portátil la versión de OpenSSL? sobre por qué esto puede no funcionar para usted.

Resulta que actualizar el paquete OpenSSL en Ubuntu y Debian no siempre es suficiente. También debe actualizar el paquete libssl1.0.0 y, luego, verificar si lo openssl version -aindica built on: Mon Apr 7 20:33:29 UTC 2014.

Según la fecha que muestra su versión de OpenSSL, parece que está viendo la versión completa que se muestra allí.

Open SSL 1.0.1 fue lanzado el 14 de marzo de 2012 . 1.0.1a fue lanzado el 19 de abril de 2012.

Por lo tanto, voy a seguir adelante y afirmar que esa openssl version -aes la forma correcta, de distribución cruzada para mostrar la versión completa de OpenSSL que está instalada en el sistema. Parece funcionar para todas las distribuciones de Linux a las que tengo acceso, y también es el método sugerido en la documentación de OpenSSL de help.ubuntu.com . Ubuntu LTS 12.04 se envió con Vanilla OpenSSL v1.0.1, que es la versión que se parece a una versión abreviada, debido a que no tiene una carta a continuación.

Dicho esto, parece que hay un error importante en Ubuntu (o cómo empaquetan OpenSSL), ya que openssl version -acontinúa devolviendo la versión original 1.0.1 del 14 de marzo de 2012, independientemente de si OpenSSL se ha actualizado o no a cualquier de las versiones más nuevas. Y, como con la mayoría de las cosas cuando llueve, llueve a cántaros.

Ubuntu no es la única distribución importante en el hábito de actualizar las actualizaciones en OpenSSL (u otros paquetes), en lugar de confiar en las actualizaciones ascendentes y la numeración de versiones que todos reconocen. En el caso de OpenSSL, donde los números de versión de las letras representan solo la corrección de errores y las actualizaciones de seguridad, esto parece casi incomprensible, pero me han informado que esto puede deberse a que el complemento validado por FIPS distribuye las principales distribuciones de Linux empaquetadas con OpenSSL. Debido a los requisitos en torno a la revalidación que se activan debido a cualquier cambio, incluso los cambios que tapan los agujeros de seguridad, está bloqueado en la versión.

Por ejemplo, en Debian, la versión fija muestra un número de versión en 1.0.1e-2+deb7u5lugar de la versión anterior de 1.0.1g.

Como resultado, en este momento, no hay una forma confiable y portátil de verificar las versiones SSL en las distribuciones de Linux , porque todas usan sus propios parches y actualizaciones con diferentes esquemas de numeración de versiones. Tendrá que buscar el número de versión fija para cada distribución diferente de Linux que ejecute, y comparar la versión de OpenSSL instalada con la numeración de versión específica de esa distribución para determinar si sus servidores están ejecutando una versión vulnerable o no.

Si desea algo verdaderamente multiplataforma, verifique la vulnerabilidad en sí en lugar de confiar en los números de versión.

Es posible que tenga un código que informa un número de versión que se sabe que es vulnerable, pero el código real no es vulnerable . Y lo contrario, un código silenciosamente vulnerable, ¡podría ser aún peor!

Muchos proveedores que agrupan productos de código abierto como OpenSSL y OpenSSH actualizarán selectivamente las correcciones urgentes a una versión anterior de código, para mantener la estabilidad y la previsibilidad de la API. Esto es especialmente cierto para "lanzamiento a largo plazo" y plataformas de dispositivos.

Pero los vendedores que hacen esto en silencio (sin agregar su propio sufijo de cadena de versión) corren el riesgo de desencadenar falsos positivos en los escáneres de vulnerabilidad (y confundir a los usuarios). Entonces, para que esto sea transparente y verificable, algunos proveedores agregan sus propias cadenas a la versión principal del paquete. Debian (OpenSSL) y FreeBSD (en OpenSSH, a través de la VersionAddendumdirectiva sshd_config) a veces hacen esto.

Los proveedores que no hacen esto probablemente lo estén haciendo para minimizar la posibilidad de rotura debido a las muchas formas directas e indirectas en que otros programas verifican los números de versión.

Entonces puede verse así:

$ 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

... a pesar de que ha sido parcheado :

$ 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

Con este tipo de cosas en juego, es mejor que no confíes en el número de versión.

Por desgracia, no estoy seguro de que es una forma de plataforma cruzada de hacer esto. Como discutí en una publicación de blog , la versión de OpenSSL mostrada en Ubuntu 12.04 REMAINS 1.0.1 después de actualizar a una versión fija.

SOLO para Ubuntu 12.04, puede saber si ha sido actualizado si se cumple todo lo siguiente:

1. dpkg -s openssl | grep Version muestra la versión 1.0.1-4ubuntu5.12 o posterior.
2. dpkg -s libssl1.0.0 | grep Version muestra la versión 1.0.1-4ubuntu5.12 o posterior.
3. openssl version -a muestra una fecha "incorporada" del 7 de abril de 2014 o posterior.

Gracias a @danny por la información adicional.

Prueba lo siguiente. Extraerá todas las cadenas de la biblioteca de cifrado con las que ssh está vinculado. Produce más de una línea de salida, pero si es necesario podría convertirse a 1 línea.

ldd `which ssh` | awk '/\// { print $3 }' | grep crypto | xargs strings  | grep OpenSSL

produce

OpenSSLDie
DSA_OpenSSL
...
MD4 part of OpenSSL 1.0.1f 6 Jan 2014 
MD5 part of OpenSSL 1.0.1f 6 Jan 2014
... 
etc

por ejemplo, en Gentoo antes de emerger

[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

el comando anterior da como resultado

...
OpenSSL 1.0.1c 10 May 2012

después

...
OpenSSL 1.0.1f 6 Jan 2014

Ay, todavía no g.

¿Alguno de estos scripts prueba todos los servicios o solo prueba HTTPS ? AFAIK , PostgreSQL es vulnerable, pero eso es solo un rumor hasta que surge un ataque en la naturaleza.

Hay un script metasploit disponible para su uso.

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

Puede escribir esto (probado con GnuWin32 OpenSSL versión binaria 1.0.1.6, con fecha 14/01/2014), o simplemente usar el script en el comentario debajo de este. ¡Es más preciso y más simple!

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

Una vez conectado, escriba B y verá en un host vulnerable y no se desconectará:

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

Obtendrá una respuesta de latido similar a esta.

En un host parcheado, verá una respuesta similar a la siguiente y se desconectará:

Ingrese 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   .~.V..7.@...C...
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

Fuente:

• Publicación de blog Cómo probar si su corazón de OpenSSL sangra

También hay estas herramientas:

• https://github.com/titanous/heartbleeder

• http://filippo.io/Heartbleed/

• https://github.com/musalbas/heartbleed-masstest

Para Ubuntu puedes usar:

aptitude show libssl1.0.0 | grep Version

Y compare con http://www.ubuntu.com/usn/usn-2165-1/ . Después de reiniciar (!!!) puede consultar con http://possible.lv/tools/hb.

Será mejor que actualice a la última versión de OpenSSL OpenSSL 1.0.1j.

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

Encontré este script en devcentral :

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

Reemplace example.comcon el nombre o la dirección IP del servidor que desea verificar.

Volverá "safe"si su servidor está bien o "server extension "heartbeat" (id=15)"si no.

Esto no depende del número de versión, sino de enumerar la extensión del servidor que causa el problema, por lo que debería ser inmune a las travesuras de la versión de la biblioteca.

La máquina está ejecutando openssl s_clienten debe ser el uso de OpenSSL 1.0.1 o posterior para que esto funcione.