Soluzione 1:
In base alla data visualizzata dalla tua versione di OpenSSL, sembra che tu sia di vedendo la versione completa visualizzata lì.
Open SSL 1.0.1 è stato rilasciato il 14 marzo 2012. 1.0.1a è stato rilasciato il 19 aprile 2012.
Quindi, vado avanti e affermo che openssl version -a è il modo corretto e cross-distro per visualizzare la versione completa di OpenSSL installata nel sistema. Sembra funzionare per tutte le distribuzioni Linux a cui ho accesso, ed è anche il metodo suggerito nella documentazione OpenSSL di help.ubuntu.com. Ubuntu LTS 12.04 è stato fornito con Vanilla OpenSSL v1.0.1, che è la versione che sembra una versione abbreviata, poiché non è seguita da una lettera.
Detto questo, sembra che ci sia un maggiore bug in Ubuntu (o come pacchettizzano OpenSSL), in quel openssl version -a continua a restituire la versione originale 1.0.1 dal 14 marzo 2012, indipendentemente dal fatto che OpenSSL sia stato aggiornato o meno a una delle versioni più recenti. E, come con la maggior parte delle cose quando piove, diluvia.
Ubuntu non è l'unica grande distribuzione con l'abitudine di eseguire il backport degli aggiornamenti in OpenSSL (o altri pacchetti), piuttosto che fare affidamento sugli aggiornamenti a monte e sulla numerazione delle versioni che tutti riconoscono. Nel caso di OpenSSL, dove i numeri di versione delle lettere rappresentano solo correzioni di bug e aggiornamenti di sicurezza, questo sembra quasi incomprensibile, ma sono stato informato che ciò potrebbe essere dovuto al plug-in convalidato FIPS che le principali distribuzioni Linux vengono fornite con OpenSSL. A causa dei requisiti relativi alla riconvalida che si attivano a causa di qualsiasi modifica, anche modifiche che colmano falle di sicurezza, è bloccato dalla versione.
Ad esempio, su Debian, la versione corretta mostra un numero di versione 1.0.1e-2+deb7u5 invece della versione originale di 1.0.1g .
Di conseguenza, al momento, non esiste un modo affidabile e portatile per controllare le versioni SSL nelle distribuzioni Linux , perché tutti usano le proprie patch e aggiornamenti backported con diversi schemi di numerazione delle versioni. Dovrai cercare il numero di versione fisso per ogni diversa distribuzione di Linux che esegui e confrontare la versione OpenSSL installata con la numerazione di versione specifica di quella distribuzione per determinare se i tuoi server eseguono o meno una versione vulnerabile.
Soluzione 2:
Se vuoi qualcosa di veramente multipiattaforma, controlla la vulnerabilità stessa piuttosto che fare affidamento sui numeri di versione.
Potresti avere un codice che riporta un numero di versione noto per essere vulnerabile, ma il codice effettivo non è vulnerabile . E il contrario -- codice silenziosamente vulnerabile -- potrebbe essere anche peggio!
Molti fornitori che raggruppano prodotti open source come OpenSSL e OpenSSH eseguiranno il retrofit selettivo di correzioni urgenti a una versione precedente del codice, al fine di mantenere la stabilità e la prevedibilità dell'API. Ciò è particolarmente vero per le "rilasci a lungo termine" e le piattaforme di appliance.
Ma i fornitori che lo fanno in silenzio (senza aggiungere il proprio suffisso della stringa di versione) corrono il rischio di attivare falsi positivi negli scanner di vulnerabilità (e confondere gli utenti). Quindi, per renderlo trasparente e verificabile, alcuni fornitori aggiungono le proprie stringhe alla versione principale del pacchetto. Sia Debian (OpenSSL) che FreeBSD (in OpenSSH, tramite il VersionAddendum direttiva sshd_config) a volte lo fanno.
I fornitori che non lo fanno probabilmente lo fanno per ridurre al minimo la possibilità di rottura a causa dei molti modi diretti e indiretti con cui altri programmi controllano i numeri di versione.
Quindi può assomigliare a questo:
$ 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
... anche se è stato corretto:
$ 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 cose come questa in gioco, stai meglio se non ti fidi del numero di versione.
Soluzione 3:
Sfortunatamente, non sono sicuro che esista un modo multipiattaforma per farlo. Come ho discusso in un post sul blog, la versione di OpenSSL visualizzata su Ubuntu 12.04 RIMANE 1.0.1 dopo l'aggiornamento a una versione corretta.
SOLO per Ubuntu 12.04, puoi sapere se sei stato aggiornato se tutte le seguenti condizioni sono vere:
dpkg -s openssl | grep Versionmostra la versione 1.0.1-4ubuntu5.12 o successiva.dpkg -s libssl1.0.0 | grep Versionmostra la versione 1.0.1-4ubuntu5.12 o successiva.openssl version -amostra una data "costruita il" 7 aprile 2014 o successiva.
Grazie a @danny per le informazioni aggiuntive.
Soluzione 4:
Prova quanto segue. Estrarrà tutte le stringhe dalla crypto libreria a cui è collegato ssh. Produce più di una riga di output, ma se necessario può essere convertita in 1 riga.
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
per esempio. su Gentoo prima di emerge
[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
il comando precedente risulta in
...
OpenSSL 1.0.1c 10 May 2012
dopo
...
OpenSSL 1.0.1f 6 Jan 2014
Ahi, ancora niente g.
Soluzione 5:
Qualcuno di questi script testa tutti i servizi o testa solo HTTPS? AFAIK, PostgreSQL è vulnerabile, ma questa è solo una voce finché non emerge un attacco in-the-wild.
C'è uno script metasploit disponibile per l'uso.
https://github.com/rapid7/metasploit-framework/commit/dd69a9e5dd321915e07d8e3dc8fe60d3c54f551a
Puoi digitare questo (testato con GnuWin32 OpenSSL binario versione 1.0.1.6, datato 2014-01-14), o semplicemente usare lo script nel commento sotto questo. È più preciso e più semplice!
s_client -connect a23-75-248-141.deploy.static.akamaitechnologies.com:443 -debug -state
Una volta connesso, digita B e vedrai su un host vulnerabile e non verrai disconnesso:
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
Riceverai una risposta del battito cardiaco simile a questa.
Su un host con patch, vedrai una risposta simile alla seguente e verrai disconnesso:
Inserisci 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
Fonte:
- Blog post Come testare se il tuo cuore OpenSSL sanguina
Ci sono anche questi strumenti:
-
https://github.com/titanous/heartbleeder
-
http://filippo.io/Heartbleed/
-
https://github.com/musalbas/heartbleed-masstest