Solución 1:
Según la fecha que muestra su versión de OpenSSL, parece que es viendo la versión completa que se muestra allí.
Open SSL 1.0.1 se lanzó el 14 de marzo de 2012. 1.0.1a se lanzó el 19 de abril de 2012.
Entonces, voy a seguir adelante y afirmar que openssl version -a es la forma correcta entre distribuciones 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 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 parece una versión abreviada, debido a que no tiene una letra a continuación.
Habiendo dicho eso, parece que hay un principal error en Ubuntu (o cómo empaquetan OpenSSL), en ese openssl version -a continúa devolviendo la versión 1.0.1 original desde el 14 de marzo de 2012, independientemente de si OpenSSL se actualizó o no a alguna de las versiones más nuevas. Y, como ocurre con la mayoría de las cosas, cuando llueve, llueve a cántaros.
Ubuntu no es la única distribución importante que tiene la costumbre de respaldar actualizaciones en OpenSSL (u otros paquetes), más que confiar en las actualizaciones anteriores y la numeración de versiones que todos reconocen. En el caso de OpenSSL, donde los números de versión de letras representan solo correcciones de errores y actualizaciones de seguridad, esto parece casi incomprensible, pero me han informado que esto puede deberse al complemento validado por FIPS que las principales distribuciones de Linux envían empaquetado con OpenSSL. Debido a los requisitos relacionados con la revalidación que se activan debido a cualquier cambio, incluso los cambios que tapan 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 original de 1.0.1g .
Como resultado, en este momento, no existe una forma portátil y confiable de comprobar las versiones de SSL en las distribuciones de Linux. , porque todos usan sus propios parches y actualizaciones retroportados 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 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.
Solución 2:
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 informe un número de versión que se sabe que es vulnerable, pero el código real no es vulnerable . ¡Y lo contrario, código silenciosamente vulnerable, podría ser incluso 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 del código para mantener la estabilidad y la previsibilidad de la API. Esto es especialmente cierto para las plataformas de "versión a largo plazo" y dispositivos.
Pero los proveedores que hacen esto en silencio (sin agregar su propio sufijo de cadena de versión) corren el riesgo de generar falsos positivos en los escáneres de vulnerabilidades (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. Tanto Debian (OpenSSL) como FreeBSD (en OpenSSH, a través de VersionAddendum directiva sshd_config) a veces hacen esto.
Los proveedores que no hacen esto probablemente lo hacen 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 cosas como esta en juego, es mejor que no confíes en el número de versión.
Solución 3:
Desafortunadamente, no estoy seguro de que hay una forma multiplataforma de hacer esto. Como analizo en una publicación de blog, la versión de OpenSSL que se muestra en Ubuntu 12.04 PERMANECE 1.0.1 después de actualizar a una versión fija.
SOLO para Ubuntu 12.04, puede saber si ha sido actualizado si todo lo siguiente es cierto:
dpkg -s openssl | grep Versionmuestra la versión 1.0.1-4ubuntu5.12 o posterior.dpkg -s libssl1.0.0 | grep Versionmuestra la versión 1.0.1-4ubuntu5.12 o posterior.openssl version -amuestra una fecha de "incorporación" del 7 de abril de 2014 o posterior.
Gracias a @danny por la información adicional.
Solución 4:
Pruebe lo siguiente. Extraerá todas las cadenas de crypto biblioteca contra la que está vinculado ssh. Produce más de una línea de salida, pero si es necesario se puede convertir 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
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
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 hay g.
Solución 5:
¿Alguno de estos scripts prueba todos los servicios o solo prueban HTTPS? AFAIK, PostgreSQL es vulnerable, pero eso es solo un rumor hasta que surge un ataque salvaje.
Hay un script de 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 2014-01-14), 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 será desconectado:
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 será desconectado:
Introduzca 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:
- Entrada de blog Cómo comprobar si su OpenSSL funciona
También están estas herramientas:
-
https://github.com/titanous/heartbleeder
-
http://filippo.io/Heartbleed/
-
https://github.com/musalbas/heartbleed-masstest