Vraag Heartbleed: hoe controleer je op betrouwbare en draagbare wijze de OpenSSL-versie?


Ik was op zoek naar een betrouwbare en draagbare manier om de OpenSSL-versie op GNU / Linux en andere systemen te controleren, zodat gebruikers gemakkelijk kunnen ontdekken of ze hun SSL moeten upgraden vanwege de Heartbleed-bug.

Ik dacht dat het gemakkelijk zou zijn, maar ik kwam snel een probleem tegen op Ubuntu 12.04 LTS met de nieuwste OpenSSL 1.0.1g:

openssl-versie -a

Ik verwachtte een volledige versie te zien, maar in plaats daarvan kreeg ik dit:

OpenSSL 1.0.1 14 maart 2012
gebouwd op: di 4 juni 07:26:06 UTC 2013
platform: [...]

Tot mijn onaangename verrassing verschijnt de versletter niet. Geen f, nee g daar, gewoon "1.0.1" en dat is alles. De vermelde datums helpen ook niet bij het vinden van een (niet-) kwetsbare versie.

Het verschil tussen 1.0.1 (a-f) en 1.0.1g is cruciaal.

vragen:

  • Wat is een betrouwbare manier om de versie te controleren, bij voorkeur cross-distro?
  • Waarom wordt de versie letter niet weergegeven? Ik kon dit op niets anders testen dan Ubuntu 12.04 LTS.

Anderen melden dit gedrag ook. Een paar voorbeelden:

Sommige (distro-specifieke) suggesties rollen in:

  • Ubuntu en Debian: apt-cache policy openssl en apt-cache policy libssl1.0.0. Vergelijk hier de versienummers met de pakketten: http://www.ubuntu.com/usn/usn-2165-1/
  • Fedora 20: yum info openssl (bedankt @znmeb op twitter) en yum info openssl-libs

Controleren of een oudere versie van OpenSSL nog aanwezig is:

Het blijkt dat het updaten van het OpenSSL-pakket op Ubuntu en Debian niet altijd voldoende is. U moet ook het libssl1.0.0-pakket bijwerken en vervolgens controleren of openssl version -a duidt op built on: Mon Apr 7 20:33:29 UTC 2014.


86
2018-04-07 23:51


oorsprong


Zorg er in ieder geval voor dat de OpenSSL-versie die je hebt is niet g vanwege de datum die wordt weergegeven - Pato Sáinz
Dit werkt op CentOS [root@null~]# openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 - Jacob
@ PatoSáinz Ik heb het nagevraagd apt-cache policy openssl en het reageerde met: Installed: 1.0.1-4ubuntu5.12 dat is de 1.0.1g die zojuist door Ubuntu is uitgebracht voor 12.04 LTS. Ik ben uitgelogd en weer terug. Kan ik nog iets doen om te verifiëren? - Martijn
Ik zal erop wijzen, voor dat dat niet weet, voor het geval het nuttig is ... Ubuntu 12.04 LTS verzonden met OpenSSL 1.0.1 (vanille). - HopelessN00b
Als die builddatum correct is, kunt u de "release versioned" -code niet recenter hebben dan 1.0.1e, aangezien 1.0.1f uitkwam in 2014 per de OpenSSL 1.0.1 release-opmerkingen. Afzonderlijke regels of secties zijn mogelijk teruggezet naar je Ubuntu-versie voorafgaand aan de officiële OpenSSL 1.0.1f-release. En de bouwdatum is misschien minder dan compleet nuttig. - Anti-weakpasswords


antwoorden:


Op basis van de datum die wordt weergegeven door uw versie van OpenSSL, lijkt het u zijn zien dat de volledige versie daar wordt weergegeven.

Open SSL 1.0.1 werd vrijgegeven op 14 maart 2012. 1.0.1a werd vrijgegeven op 19 april 2012.

Dus ik ga door en beweer dat openssl version -a is de juiste, cross-distro manier om de volledige versie van OpenSSL weer te geven die op het systeem is geïnstalleerd. Het lijkt te werken voor alle Linux-distributies waartoe ik toegang heb, en is de voorgestelde methode in de help.ubuntu.com OpenSSL-documentatie. Ubuntu LTS 12.04 wordt geleverd met vanilla OpenSSL v1.0.1, de versie die lijkt op een verkorte versie, omdat er geen letter achter staat.

Dat gezegd hebbende, lijkt het erop dat er een is groot bug in Ubuntu (of hoe ze OpenSSL verpakken), daarin openssl version -a blijft de oorspronkelijke 1.0.1-versie terugzenden vanaf 14 maart 2012, ongeacht of OpenSSL is geüpgraded naar een van de nieuwere versies. En, zoals met de meeste dingen als het regent, giet het.

Ubuntu is niet de enige grote distro in de gewoonte om back-ups van updates in OpenSSL (of andere pakketten) te maken, meer dan te vertrouwen op de stroomopwaartse updates en versienummering die iedereen herkent. In het geval van OpenSSL, waar de letterversienummers alleen bugfixes en beveiligingsupdates vertegenwoordigen, lijkt dit bijna onbegrijpelijk, maar ik ben geïnformeerd dat dit mogelijk komt door de FIPS-gevalideerde plug-in major Linux distro's verpakt met OpenSSL. Vanwege de vereisten voor revalidatie die veroorzaakt worden door een wijziging, zelfs wijzigingen die beveiligingsgaten dichten, is deze versie-geblokkeerd.

Op Debian geeft de vaste versie bijvoorbeeld een versienummer weer van 1.0.1e-2+deb7u5 in plaats van de upstream-versie van 1.0.1g.

Als gevolg hiervan, op dit moment er is geen betrouwbare, draagbare manier om SSL-versies te controleren binnen Linux-distributies, omdat ze allemaal hun eigen backported patches en updates gebruiken met verschillende versienummers. U moet het vaste versienummer opzoeken voor elke verschillende distributie van Linux die u uitvoert en de geïnstalleerde OpenSSL-versie controleren aan de hand van de versienummering van die distributie om te bepalen of uw servers een kwetsbare versie gebruiken of niet.


67
2018-04-08 00:05



Mijn installatie is een eenvoudige Ubuntu 12.04 LTS zonder iets dat ik zelf heb gecompileerd of gedownload van andere bronnen dan de Ubuntu-repositories. Als Ubuntu OpenSSL met verkorte versienummers distribueert, dan openssl version -a is geen draagbare methode (in ieder geval niet overdraagbaar aan Ubuntu). ik heb het nagekeken apt-cache policy openssl en het reageerde met: Installed: 1.0.1-4ubuntu5.12 dat is de 1.0.1g die zojuist door Ubuntu is uitgebracht voor 12.04 LTS. Ik heb me afgemeld en opnieuw aangemeld voordat ik kon controleren. - Martijn
HopeloosN00b, er is niets dubieus aan het beleid van backporting-fixes in plaats van het stoten van versies; het is een zeer goede manier om platformstabiliteit te garanderen, wat zeer wenselijk is in een serveromgeving. Zoals elke beslissing heeft dit consequenties, waarvan gebruikers op de hoogte moeten zijn; maar gewoon omdat het de "Ik voer foo x.y.z uit en daarom ben / ben ik niet kwetsbaar voor de nieuwste exploit"redenering, dat maakt het niet slecht. - MadHatter
@towo Versienummers bestaan ​​om een ​​reden. Als we de stroomopwaartse versienummers gewoon uit het venster gooien omdat 'enterprisey', of wat dan ook, waarom zou je überhaupt moeite doen met versienummers? Kan net zo goed beginnen met al onze dingen te benoemen met alliteraties. We kunnen de kwetsbare OpenSSL-versies bellen Heilige Heartbleed en de vaste Sluwe stollingsmiddel. - HopelessN00b
@ HopelessN00b Ik denk dat je verstrikt raakt in de valstrik "dit was opgelost in versie X.Y.Z", ze volgen niet de versienummers omdat alles dat wordt geïmporteerd in de nieuwste versie bug- en beveiligingsoplossingen zijn. Als ze het versienummer hadden gestoten, zou je ook de extra functionaliteit verwachten. "Ik heb OpenSSL v X.Y.Z, waarom heb ik ECDHA ???? ..etc" niet. Het is logisch als u begrijpt dat het alleen bugfixes zijn. - NickW
@NickW @Jubal @MadHatter het ding met OpenSSL, is echter dat: 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. Er wordt dus niets gewonnen door het stroomopwaartse versiebeheerschema achterwege te laten; backporting van de updates is in wezen hetzelfde als het gebruik van de bijgewerkte versie, omdat de update sowieso alleen beveiligings- en bugfixes bevat. Wat het wel doet, is dingen verwarren en ons op geen enkele manier de mogelijkheid geven om de OpenSSL-versie op een overdraagbare manier over Linux-distributies te controleren. - HopelessN00b


Als je iets echt cross-platform wilt, controleer voor de kwetsbaarheid zelf in plaats van te vertrouwen op versienummers. 

U hebt mogelijk code die een versienummer meldt dat bekend staat als kwetsbaar, maar de eigenlijke code is niet kwetsbaar. En de omgekeerd - in stilte kwetsbare code - zou nog erger kunnen zijn!

Veel leveranciers die open-source producten bundelen zoals OpenSSL en OpenSSH zullen selectief urgente fixes achteraf inbouwen in een oudere versie van de code om de stabiliteit en voorspelbaarheid van de API te behouden. Dit geldt met name voor platforms voor "langdurige release" en apparatuur.

Maar leveranciers die dit stil doen (zonder hun eigen achtervoegsel voor de string toe te voegen) lopen het risico van het activeren van valse positieven in kwetsbaarhedenscanners (en verwarrende gebruikers). Dus om dit transparant en verifieerbaar te maken, voegen sommige leveranciers hun eigen strings toe aan de belangrijkste pakketversie. Zowel Debian (OpenSSL) als FreeBSD (in OpenSSH, via de VersionAddendum sshd_config richtlijn) soms dit doen.

Leveranciers die dit niet doen, doen dit waarschijnlijk om de kans op breuk te minimaliseren vanwege de vele directe en indirecte manieren waarop andere programma's versienummers controleren.

Dus het kan er zo uit zien:

$ 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

... Hoewel het is gepatcht:

$ 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

Met dingen als deze in het spel, ben je beter af als je vertrouw het versienummer niet.


18
2018-04-08 20:52



Het is duidelijk dat het controleren van versies niet zo eenvoudig en transparant is als ik hoopte. Het controleren van de kwetsbaarheid is platformonafhankelijk, maar ook moeilijker om te doen: je moet een betrouwbare PoC of test hebben die handig is voor de specifieke kwetsbare softwareservice die je gebruikt. In dit geval is het allemaal begonnen met een PoC voor Apache en Nginx. Wat als ik op dat moment alleen SMTP met SSL zou gebruiken en ik wilde controleren of ik kwetsbaar ben? Uiteindelijk zullen we testen hebben voor de meeste diensten, maar het kan een tijdje duren. - Martijn
Martijn, dat is een goed punt. Wanneer een test niet beschikbaar is, zijn secundaire methoden (zoals het opsporen van de controlesom voor de betreffende binaire bestanden op uw doelsystemen) minder optimaal, maar zijn ze misschien goed genoeg om de klus te klaren ... en gaan dan verder met de volgende brand. :-) - Royce Williams


Helaas ben ik daar niet zeker van is een platformonafhankelijke manier om dit te doen. Zoals ik in een blogpost bespreek, de versie van OpenSSL weergegeven op Ubuntu 12.04 REMAINS 1.0.1 na het upgraden naar een vaste versie.

ALLEEN voor Ubuntu 12.04 kunt u zien of u bent bijgewerkt als alle onderstaande punten waar zijn:

  1. dpkg -s openssl | grep Versiontoont versie 1.0.1-4ubuntu5.12 of later.
  2. dpkg -s libssl1.0.0 | grep Versiontoont versie 1.0.1-4ubuntu5.12 of later.
  3. openssl version -a toont een "ingebouwde" datum van 7 april 2014 of later.

Bedankt aan @danny voor de extra info.


14
2018-04-08 03:15



Ok, in dat geval moet ik die pakketversie toevoegen 1.0.1-4ubuntu5.12 is ALLEEN voor Ubuntu 12.04 LTS. Als je op Ubuntu 12.10 zit, zou je tenminste de versie moeten zien 1.0.1c-3ubuntu2.7en als je op 13.10 zit, zou het op zijn minst versie moeten zijn 1.0.1e-3ubuntu1.2, volgens de bron: ubuntu.com/usn/usn-2165-1 - Martijn
Dit is helaas onvoldoende. U moet ook upgraden libssl1.0.0 expliciet op ubuntu. Als u vóór 7 april 2014 een ingebouwde datum ziet, zelfs als openssl de juiste versie is (1.0.1-4ubuntu5.12 voor Ubuntu 12.04) bent u waarschijnlijk nog steeds kwetsbaar. - danny
@danny Je hebt me zo veel werk zojuist opgeslagen. Ik probeerde te achterhalen waarom de build-datum op sommige 12.04-systemen klopte en verkeerd was voor anderen. Je bent een redder in nood! - Schof
openssl version -a heeft misschien niet de builddatum van 7 april nodig, omdat de fix naar de oudere releases wordt teruggestuurd. - Patrick James McDougle


Probeer het volgende eens. Het haalt alle snaren uit de crypto bibliotheek waarnaar ssh is gelinkt. Het produceert meer dan één regel output, maar kan indien nodig worden geconverteerd naar 1 regel.

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

produceert

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

bijv. op Gentoo voordat je tevoorschijn komt

[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

de bovenstaande opdracht resulteert in

...
OpenSSL 1.0.1c 10 May 2012

na

...
OpenSSL 1.0.1f 6 Jan 2014

Ouch, nog steeds geen g.


4
2018-04-08 14:45



Ik dacht dat je heel dicht bij het bieden van een goede oplossing was, maar helaas werkt dit niet voor de cryptobibliotheek op Ubuntu 12.04 LTS. Het toont alle reeksen met versie [...] part of OpenSSL 1.0.1 14 Mar 2012, op dezelfde manier als openssl version -a doet. Dit is een truc die misschien in andere gevallen werkt! - Martijn
@Martijn Nou dat is jammer, maar het werkt wel op ubuntu 12.10. Vreemd dat het zichzelf verkeerd zou identificeren op 12.04. Zijn er meerdere libs? Is het mogelijk dat ssh niet de meest actuele gebruikt? - waTeim
Ik kon geen andere openssl-binaries of cryptobibliotheken vinden. Er wordt door anderen gesuggereerd dat het verschil is dat Ubuntu op 12.04 LTS de wijzigingen naar 1.0.1 back-porteert zonder de versie te verhogen. Hoewel 12.10 geen LTS is en dus gebruikt Ubuntu de nieuwste versie daar in plaats van een backport. - Martijn


Voer een van deze scripts uit om alle services te testen, of testen ze alleen HTTPS? zo ver ik weet, PostgreSQL is kwetsbaar, maar dat is slechts een gerucht totdat een aanval in het wild opduikt.

Er is een Metasploit script beschikbaar voor gebruik.

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

Je kunt dit typen (getest met GnuWin32 OpenSSL binaire versie 1.0.1.6, gedateerd 2014-01-14), of gebruik het script alleen in de opmerking hieronder. Het is nauwkeuriger en eenvoudiger!

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

Nadat u verbinding hebt gemaakt met type B, ziet u een kwetsbare host en wordt de verbinding niet verbroken:

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

U krijgt een hartslagreactie die op deze lijkt.

Op een gepatchte host ziet u een reactie zoals hieronder en wordt de verbinding verbroken:

Voer B in

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

Bron:

Er zijn ook deze hulpmiddelen:


2
2018-04-09 11:43





Voor Ubuntu kunt u gebruiken:

aptitude show libssl1.0.0 | grep Version

En vergelijk met http://www.ubuntu.com/usn/usn-2165-1/. Na een herstart (!!!) kun je checken met http://possible.lv/tools/hb.


0
2018-04-08 11:14





U kunt beter upgraden naar de nieuwste OpenSSL OpenSSL 1.0.1j.

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


0
2017-10-19 01:57





ik vond dit script in devcentraal:

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

Vervangen example.com met de naam of het IP-adres van de server die u wilt controleren.

Zal terugkeren "safe" als je server in orde is of "server extension "heartbeat" (id=15)" als niet.

Dit is niet afhankelijk van het versienummer, maar van de vermelding van de serverextensie die het probleem veroorzaakt, dus het zou immuun moeten zijn voor de shenanigans van de bibliotheekversie.

De machine die u gebruikt openssl s_client op moet OpenSSL 1.0.1 of later gebruiken om dit te laten werken.


0
2018-04-08 09:12



Handig, maar vertelt u niet of u een versie met extensie hebt en de oplossing. - mattdm
Dit is inderdaad een goede manier om te controleren op de kwetsbaarheid en is wat sommige scripts doen. Het vereist geen SSH-toegang. - Stefan Lasiewski
BIG SCARY BELANGRIJKE WAARSCHUWING - De machine die u gebruikt openssl s_client op MOET OpenSSL 1.0.1 of later gebruiken om dit te laten werken. Als u deze opdracht uitvoert op een computer met 0.9.8 of 1.0.0 HET ZULT ALTIJD "Veilig" RAPPEN, zelfs voor kwetsbare servers. - voretaq7
Vreemd. Ik stel een versie van OpenSSL in werking die vermoedelijk door deze fout wordt beïnvloed, maar die reeks verschijnt niet in de uitvoer ... - Michael
@StefanLasiewski Ik heb mijn antwoord bijgewerkt en het gedeelte "need ssh" verwijderd - egarcia