Pregunta Heartbleed: ¿cómo comprobar de forma fiable y portátil la versión de OpenSSL?


Estaba buscando una forma confiable y portátil para 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 su lugar obtuve esto:

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

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

La diferencia entre 1.0.1 (a-f) y 1.0.1g es crucial.

Preguntas:

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

Otros están reportando este comportamiento también. Algunos ejemplos:

Algunas sugerencias (distro-específicas) rodando en:

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

Comprobando si una versión anterior de OpenSSL todavía es 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, a continuación, comprobar si openssl version -a indica built on: Mon Apr 7 20:33:29 UTC 2014.


86
2018-04-07 23:51


origen


Al menos asegúrese de que la versión de OpenSSL que tiene no es g debido a la fecha que muestra - Pato Sáinz
Esto funciona en CentOS. [root@null~]# openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 - Jacob
@ PatoSáinz lo he comprobado apt-cache policy openssl y respondió con: Installed: 1.0.1-4ubuntu5.12 que es el 1.0.1g recién lanzado por Ubuntu para 12.04 LTS. Me desconecté y volví a entrar. ¿Hay algo más que pueda hacer para verificar? - Martijn
Señalaré, por lo que no sé, en caso de que sea útil ... Ubuntu 12.04 LTS se incluye con OpenSSL 1.0.1 (vainilla). - HopelessN00b
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 por Las notas de la versión de OpenSSL 1.0.1. Las líneas o secciones individuales pueden haber sido portadas a su versión de Ubuntu antes de la versión oficial de OpenSSL 1.0.1f, por supuesto. Y la fecha de construcción puede ser menos que completamente útil. - Anti-weakpasswords


Respuestas:


Según la fecha mostrada por su versión de OpenSSL, parece que usted son viendo la versión completa mostrada 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.

Entonces, voy a seguir adelante y afirmar que openssl version -a es la forma correcta y de distribución cruzada de 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 es el método sugerido en la documentación de ayuda.ubuntu.com de OpenSSL, también. Ubuntu LTS 12.04 se envió con el OpenSSL v1.0.1 de vainilla, que es la versión que parece una versión abreviada, debido a que no tiene una letra que la siga.

Dicho esto, parece que hay una mayor error en Ubuntu (o cómo empaquetan OpenSSL), en eso openssl version -a continúa devolviendo la versión original 1.0.1 desde el 14 de marzo de 2012, independientemente de si OpenSSL se ha actualizado o no a alguna de las versiones más nuevas. Y, como con la mayoría de las cosas cuando llueve, vierte.

Ubuntu no es la única distribución principal en el hábito de realizar backporting de actualizaciones en OpenSSL (u otros paquetes), más que confiar en las actualizaciones 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 correcciones de errores y actualizaciones de seguridad, esto parece casi incomprensible, pero se me ha informado que esto puede deberse a FIPS validado plugin principales distribuciones de Linux enviadas con OpenSSL. Debido a los requisitos relacionados con la revalidación que se desencadena debido a cualquier cambio, incluso los cambios que taponan los agujeros de seguridad, está bloqueado por versión.

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

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


67
2018-04-08 00:05



Mi instalación es un simple Ubuntu 12.04 LTS sin nada que yo 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 -a no es un método portátil (al menos no portátil a Ubuntu). He comprobado apt-cache policy openssl y respondió con: Installed: 1.0.1-4ubuntu5.12 que es el 1.0.1g recién lanzado por Ubuntu para 12.04 LTS. Me desconecté y volví a entrar antes de verificar. - Martijn
HopelessN00b, no hay nada dudoso acerca de la política de arreglos de backporting en lugar de las versiones topográficas; es una muy buena manera de garantizar la estabilidad de la plataforma, lo cual es altamente deseable en un entorno de servidor. Como toda decisión, tiene consecuencias, que los usuarios deben conocer; pero solo porque rompe el "Estoy ejecutando foo x.y.z, por lo tanto no soy vulnerable al último exploit"línea de razonamiento, eso no hace que sea una mala cosa. - MadHatter
@towo Los números de versión existen por una razón. Si solo vamos a tirar los números de las versiones anteriores por la ventana porque "enterprisey", o lo que sea, ¿para qué molestarse con los números de las versiones? También puedo comenzar a nombrar todas nuestras cosas con aliteraciones. Podemos llamar a las versiones vulnerables de OpenSSL. Holy Heartbleed y los fijos Coagulante Astuto. - HopelessN00b
@ HopelessN00b Creo que está atrapado en la trampa "esto se arregló en la versión X.Y.Z", no siguen los números de versión porque todo lo que se está importando a la última versión son errores y soluciones de seguridad. Si superaran el número de versión, también esperaría la funcionalidad adicional ... "Tengo OpenSSL v X.Y.Z, ¿por qué no tengo ECDHA ???? ..etc". Tiene sentido cuando entiendes que solo son correcciones de errores. - NickW
@NickW @Jubal @MadHatter la cosa 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; Backporting las actualizaciones es esencialmente lo mismo que usar la versión actualizada, ya que la actualización solo incluye la seguridad y la corrección de errores de todos modos. Lo que sí hace es confundir las cosas y dejarnos sin ninguna forma de verificar de manera portátil la versión de OpenSSL en las distribuciones de Linux. - HopelessN00b


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

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

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

Pero los proveedores 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 hacer esto transparente y verificable, algunos proveedores añaden sus propias cadenas a la versión principal del paquete. Tanto Debian (OpenSSL) como FreeBSD (en OpenSSH, a través de VersionAddendum directiva sshd_config) a veces hace esto.

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

Así que 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

... aunque 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 cosas como esta en juego, estarás mejor si No confíe en el número de versión.


18
2018-04-08 20:52



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


Por desgracia, no estoy seguro de que hay es Una forma multiplataforma de hacer esto. Como discuto 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 se ha actualizado si todo lo que se muestra a continuación es verdadero:

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

Gracias a @danny por la información adicional.


14
2018-04-08 03:15



Ok, en ese caso debo agregar esa versión del paquete 1.0.1-4ubuntu5.12 es SOLO para Ubuntu 12.04 LTS. Si estás en Ubuntu 12.10 deberías ver al menos la versión 1.0.1c-3ubuntu2.7y si estás 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
Lamentablemente esto es insuficiente. Tú debe también actualizar libssl1.0.0 explícitamente en ubuntu. Si ve una fecha de creación antes del 7 de abril de 2014, incluso si openssl tiene una versión correcta (1.0.1-4ubuntu5.12 para Ubuntu 12.04) es probable que sigas siendo vulnerable. - danny
@danny Me acabas de ahorrar mucho trabajo. Estaba tratando de averiguar por qué la fecha de construcción era correcta en unos 12.04 sistemas e incorrecta en otros. Eres un salvavidas! - Schof
openssl version -a Es posible que no necesite la fecha de compilación del 7 de abril, ya que la solución se está cargando en versiones anteriores. - Patrick James McDougle


Prueba lo siguiente. Extraerá todas las cuerdas de la crypto biblioteca que ssh está vinculada contra. Produce más de una línea de salida, pero si es necesario se puede convertir en 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

p.ej. 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

los resultados del comando anterior en

...
OpenSSL 1.0.1c 10 May 2012

después

...
OpenSSL 1.0.1f 6 Jan 2014

Auch, todavía no g.


4
2018-04-08 14:45



Pensé que estabas muy cerca de proporcionar una buena solución, pero desafortunadamente esto no funciona para la biblioteca criptográfica 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 openssl version -a hace. ¡Este es un truco que puede funcionar en otros casos! - Martijn
@Martijn Bueno, eso es desafortunado, pero funciona en ubuntu 12.10. Es extraño que se identifique mal en 12.04. ¿Hay múltiples libs? ¿Es posible que ssh no use la más actualizada? - waTeim
No he podido encontrar ningún otro binario de openssl o bibliotecas criptográficas. Otros sugieren que la diferencia es que, en 12.04 LTS, Ubuntu está realizando una copia de respaldo de los cambios a 1.0.1 sin aumentar la versión. Mientras que 12.10 no es un LTS, Ubuntu usa la última versión allí en lugar de un backport. - Martijn


¿Alguno de estos scripts prueba todos los servicios, o solo prueba HTTPS? hasta donde se, PostgreSQL es vulnerable, pero eso es solo un rumor hasta que surge un ataque salvaje.

Hay un metasploit Guión 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 2014-01-14), o simplemente use el script en el comentario debajo de este. ¡Es más preciso y más sencillo!

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 que se parece a esta.

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

Entrar 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:

También hay estas herramientas:


2
2018-04-09 11:43





Para Ubuntu puedes usar:

aptitude show libssl1.0.0 | grep Version

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


0
2018-04-08 11:14





Será mejor que actualices a OpenSSL OpenSSL 1.0.1j.

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


0
2017-10-19 01:57





encontré este script en devcentral:

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

Reemplazar example.com con 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 se basa en el número de versión, sino en la lista de la extensión del servidor que causa el problema, por lo que debe ser inmune a los chanchullos de la versión de la biblioteca.

La maquina que estas ejecutando openssl s_client en debe estar usando OpenSSL 1.0.1 o posterior para que esto funcione.


0
2018-04-08 09:12



Útil, pero no le dice si tiene una versión con la extensión y la solución. - mattdm
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
ADVERTENCIA IMPORTANTE - La máquina que está ejecutando. openssl s_client en DEBE estar utilizando 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 REPORTARÁ "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