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

88

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:

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:

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.

Martijn
fuente
2
al menos asegúrese de que la versión de OpenSSL que tiene no sea g debido a la fecha que se muestra
Pato Sáinz
3
Esto funciona en CentOS[root@null~]# openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013
Jacob
1
@ PatoSáinz Lo he comprobado apt-cache policy openssly respondió con: Installed: 1.0.1-4ubuntu5.12que es el 1.0.1g recién lanzado por Ubuntu para 12.04 LTS. Salí y volví a entrar. ¿Hay algo más que pueda hacer para verificar?
Martijn
1
Señalaré, para eso no lo sé, en caso de que sea útil ... Ubuntu 12.04 LTS se envía con OpenSSL 1.0.1 (vainilla).
HopelessN00b
1
Si esa fecha de compilación es precisa, no puede tener un código de "versión versionada" más reciente que 1.0.1e, ya que 1.0.1f salió en 2014 según las notas de versión de OpenSSL 1.0.1 . Las líneas o secciones individuales pueden haber sido respaldadas a su versión de Ubuntu antes de la versión oficial de OpenSSL 1.0.1f, por supuesto. Y la fecha de compilación puede ser menos que completamente útil.
Contraseñas anti-débiles

Respuestas:

66

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.

HopelessN00b
fuente
3
Mi instalación es un Ubuntu 12.04 LTS simple sin nada que haya compilado o descargado de otras fuentes que no sean los repositorios de Ubuntu. Si Ubuntu está distribuyendo OpenSSL con números de versión abreviados, entonces openssl version -ano es un método portátil (al menos no portátil para Ubuntu). Lo comprobé apt-cache policy openssly respondió con: Installed: 1.0.1-4ubuntu5.12que es el 1.0.1g recién lanzado por Ubuntu para 12.04 LTS. Me desconecté y volví a ingresar antes de verificar.
Martijn
19
HopelessN00b, no hay nada dudoso sobre la política de soluciones de backport en lugar de versiones de choque; Es una muy buena manera de garantizar la estabilidad de la plataforma, lo cual es altamente deseable en un entorno de servidor. Como cualquier decisión, tiene consecuencias que los usuarios deben tener en cuenta; pero solo porque rompe la línea de razonamiento " Estoy corriendo foo xyz, por lo tanto soy / no soy vulnerable al último exploit ", eso no lo convierte en algo malo.
MadHatter
10
@towo Los números de versión existen por alguna razón. Si simplemente vamos a tirar los números de la versión aguas arriba por la "empresa", o lo que sea, ¿por qué molestarse con los números de la versión? También podría comenzar a nombrar todas nuestras cosas con aliteraciones. Podemos llamar a las versiones vulnerables de OpenSSL Holy Heartbleed y a las fijas Cunning Coagulant .
HopelessN00b
77
@ HopelessN00b Creo que te encuentras atrapado en la trampa "esto se arregló en la versión XYZ", no siguen los números de versión porque todo lo que se importa a la última versión son correcciones de errores y seguridad. Si añadieron el número de versión, también esperaría la funcionalidad adicional ... "Tengo OpenSSL v XYZ, ¿por qué no tengo ECDHA ???? ..etc". Tiene sentido cuando comprendes que solo son correcciones de errores.
NickW
13
@NickW @Jubal @MadHatter lo que pasa con OpenSSL, sin embargo, es que: After the release of OpenSSL 1.0.0 the versioning scheme changed. Letter releases (e.g. 1.0.1a) can only contain bug and security fixes and no new features.Por lo tanto, no se gana nada abandonando el esquema de versiones ascendente; respaldar las actualizaciones es esencialmente lo mismo que usar la versión actualizada, ya que la actualización solo incluye correcciones de seguridad y errores de todos modos. Lo que hace es confundir las cosas y dejarnos sin forma de verificar de forma portátil la versión de OpenSSL en las distribuciones de Linux.
HopelessN00b
18

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.

Royce Williams
fuente
Está claro que verificar versiones no es tan fácil y transparente como esperaba que fuera. Verificar la vulnerabilidad es multiplataforma, pero también es más difícil de hacer: debe tener un PoC confiable o una prueba práctica para el servicio de software vulnerable particular que está ejecutando. En este caso, todo comenzó con un PoC para Apache y nginx. ¿Qué sucede si solo estaba usando SMTP con SSL en ese momento y quería verificar si soy vulnerable? Eventualmente tendremos pruebas para la mayoría de los servicios, pero puede llevar un tiempo.
Martijn
Martijn, ese es un punto justo. Cuando no hay una prueba disponible, los métodos secundarios (como rastrear la suma de comprobación para los archivos binarios afectados en sus sistemas de destino) son menos óptimos, pero podrían ser lo suficientemente buenos como para hacer el trabajo ... y luego pasar al siguiente disparo. :-)
Royce Williams
14

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.

Schof
fuente
2
Ok, en ese caso debo agregar que la versión del paquete 1.0.1-4ubuntu5.12es SOLO para Ubuntu 12.04 LTS. Si está en Ubuntu 12.10, debería ver al menos la versión 1.0.1c-3ubuntu2.7y si está en 13.10, entonces debería ser al menos la versión 1.0.1e-3ubuntu1.2, según la fuente: ubuntu.com/usn/usn-2165-1
Martijn
1
Esto es lamentablemente insuficiente. También debe actualizar libssl1.0.0explícitamente en ubuntu. Si está viendo una fecha de construcción anterior al 7 de abril de 2014, incluso si openssl es la versión correcta ( 1.0.1-4ubuntu5.12para Ubuntu 12.04), probablemente todavía sea vulnerable.
danny
@danny Me acabas de salvar TANTO trabajo. Estaba tratando de descubrir por qué la fecha de compilación era correcta en algunos sistemas 12.04 e incorrecta en otros. Eres un salvavidas!
Schof
openssl version -aes posible que no necesite la fecha de compilación del 7 de abril, ya que la solución se está actualizando a las versiones anteriores.
Patrick James McDougle
4

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.

WaTeim
fuente
3
Pensé que estabas muy cerca de proporcionar una buena solución, pero desafortunadamente esto no funciona para la biblioteca de cifrado en Ubuntu 12.04 LTS. Muestra todas las cadenas con versión [...] part of OpenSSL 1.0.1 14 Mar 2012, de la misma manera que lo openssl version -ahace. ¡Sin embargo, este es un truco que puede funcionar en otros casos!
Martijn
@Martijn Bueno, eso es lamentable, pero funciona en ubuntu 12.10. Es extraño que se identifique erróneamente en 12.04. ¿Hay múltiples libs? ¿Es posible ssh no utiliza el más actualizado?
waTeim
No pude encontrar otros binarios de openssl o bibliotecas de cifrado. Otros sugieren que la diferencia es que, en 12.04 LTS, Ubuntu está respaldando los cambios a 1.0.1 sin actualizar la versión. Si bien 12.10 no es un LTS, Ubuntu usa la última versión allí en lugar de un backport.
Martijn
2

¿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   [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

Fuente:

También hay estas herramientas:

Justin Goldberg
fuente
0

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.

Rufinus
fuente
0

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.

egarcia
fuente
44
Útil, pero no te dice si tienes una versión con la extensión y la corrección .
mattdm
1
De hecho, esta es una buena manera de verificar la vulnerabilidad y es lo que hacen algunos scripts. En realidad no requiere acceso SSH.
Stefan Lasiewski
8
ADVERTENCIA IMPORTANTE : la máquina en la que está ejecutandoopenssl s_clientDEBE utilizar OpenSSL 1.0.1 o posterior para que esto funcione. Si ejecuta este comando en una máquina con 0.9.8 o 1.0.0, SIEMPRE INFORMARÁ "Seguro", incluso para servidores vulnerables .
voretaq7
Impar. Estoy ejecutando una versión de OpenSSL que supuestamente se ve afectada por este error, pero esa cadena no aparece en la salida ...
Michael
@StefanLasiewski Actualicé mi respuesta y eliminé la parte "need ssh"
egarcia