Vraag Heartbleed: wat is het en wat zijn opties om het te verminderen?


Dit is een Canonical Question over het begrijpen en oplossen van het Heartbleed beveiligingsprobleem.

Wat is CVE-2014-0160 AKA 'Heartbleed' precies? Wat is de oorzaak, welke besturingssystemen en versies van OpenSSL zijn kwetsbaar, wat zijn de symptomen, zijn er methoden om een ​​succesvolle exploit te detecteren?

Hoe kan ik controleren of mijn systeem getroffen is? Hoe kan deze kwetsbaarheid worden gemitigeerd? Moet ik me zorgen maken dat mijn sleutels of andere privégegevens zijn aangetast? Aan welke andere bijwerkingen moet ik me bekommeren?


204
2018-04-08 00:26


oorsprong


Mitigatie voor Heartbleed impliceert meer dan alleen nieuwe sleutels. (Link naar mijn antwoord op StackExchange Information Security) - scuzzy-delta
Ik hoor je, maar ik denk dat EEAA dat hieronder behoorlijk uitgebreid heeft behandeld. - MadHatter
Ik ben het ermee eens: het is een geweldig antwoord, maar heartbleed.com doet veel moeite om erop te wijzen dat er verder gaat dan alleen nieuwe sleutelparen, zoals het forceren van wachtwoordwijzigingen en het ongeldig verklaren van sessies. - scuzzy-delta
@ scuzzy-delta - goed punt. Ik heb mijn antwoord op CW nu gemaakt, dus voel je vrij om het met die informatie te bewerken / verbeteren. - EEAA
Beste voorbeeld van wat het is - (niet verrassend) XKCD: xkcd.com/1354 - Wayne Werner


antwoorden:


Eerste, voordat je gaat falen, zorg ervoor dat je begrijpt of deze kwetsbaarheid feitelijk op jou van toepassing is. Als u een server hebt, maar nog nooit toepassingen hebt gehad die TLS gebruiken, is dit geen prioriteit voor u om te herstellen. Als, aan de andere kant, jij ooit gehad Voor TLS geschikte applicaties, nou dan heb je zin in een traktatie. Lees verder:

Wat is CVE-2014-0160 alias "Heartbleed"?

Het is een grote rotzooi, dat is het. In het kort, een op afstand te exploiteren kwetsbaarheid werd ontdekt in OpenSSL-versies 1.0.1 tot 1.0.1f waardoor een aanvaller bepaalde delen van het systeemgeheugen kan lezen. Die onderdelen zijn datgene dat gevoelige gegevens bevat, zoals privésleutels, vooraf gedeelde sleutels, wachtwoorden en zeer waardevolle bedrijfsgegevens, onder andere.

De bug is onafhankelijk ontdekt door Neel Mehta van Google Security (21 maart 2014) en het Finse IT-beveiligingsbedrijf Codenomicon (2 april 2014).

Wat is de oorzaak?

Wel, foutieve code in OpenSSL. Hier is de commit die de kwetsbaarheid heeft geïntroduceerd, en hier is de commit die het beveiligingslek heeft verholpen. De bug verscheen in december 2011 en werd vandaag gepatched, 7 april 2014.

De bug kan ook worden gezien als een symptoom van een groter probleem. De twee gerelateerde problemen zijn (1) welk proces er is om ervoor te zorgen dat errant code niet wordt geïntroduceerd in een codebasis, en (2) waarom zijn de protocollen en uitbreidingen zo complex en moeilijk te testen. Item (1) is een kwestie van beheer en proces met OpenSSL en vele andere projecten. Veel ontwikkelaars weerstaan ​​eenvoudig praktijken zoals code-reviews, analyse en scannen. Item (2) wordt besproken op de TLS WG van de IETF. Zien Heartbleed / protocol complexiteit.

Is de foutieve code kwaadwillig ingevoegd?

Ik zal niet speculeren over de vraag of dit echt een vergissing was of misschien een beetje code die ingeschoten was namens een slechte acteur. De persoon die de code voor OpenSSL heeft ontwikkeld, beweert echter dat deze onbedoeld was. Zien De man die ernstige 'Heartbleed' beveiligingsfout introduceerde, ontkent dat hij het opzettelijk heeft ingevoegd.

Welke besturingssystemen en versies van OpenSSL zijn kwetsbaar?

Zoals hierboven vermeld, elk besturingssysteem dat gebruikt of een toepassing die is gekoppeld aan OpenSSL 1.0.1 tot en met 1.0.1f.

Wat zijn de symptomen, zijn er methoden om een ​​succesvolle exploit op te sporen?

Dit is het enge deel. Voor zover wij weten, is er geen bekende manier om vast te stellen of dit beveiligingslek al dan niet is misbruikt. Het is theoretisch mogelijk dat binnenkort IDS-handtekeningen worden vrijgegeven die deze exploit kunnen detecteren, maar vanaf dit moment zijn deze niet beschikbaar.

Er zijn aanwijzingen dat Heartbleed al in november 2013 actief in het wild werd uitgebuit. Zie de EVF's Wild at Heart: waren Intelligence Agencies met Heartbleed in november 2013? En Bloomberg meldt dat de NSA de exploit had bewapend kort nadat de kwetsbaarheid was geïntroduceerd. Zien NSA zegt al jaren Heartbleed Bug voor intelligentie te gebruiken. De US Intelligence Community ontkent echter de beweringen van Bloomberg. Zien IC OP HET VERSLAG.

Hoe kan ik controleren of mijn systeem getroffen is?

Als je bent OpenSSL aan het onderhouden op je systeem, dan kun je gewoon uitgeven openssl version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Als de distributie houdt OpenSSL aan, dan kunt u waarschijnlijk de versie van OpenSSL niet bepalen vanwege backpatching met openssl opdracht of de pakketinformatie (bijvoorbeeld apt-get, dpkg, yum of rpm). Het back-patchingproces dat door de meeste (alle?) Distributies wordt gebruikt, gebruikt alleen het basisversienummer (bijvoorbeeld "1.0.1e"); en doet niet omvatten een effectieve beveiligingsversie (bijvoorbeeld "1.0.1g").

Er is een open vraag over Super User om de effectieve beveiligingsversie voor OpenSSL en andere pakketten te bepalen wanneer pakketten worden backpatched. Helaas zijn er geen bruikbare antwoorden (anders dan de website van de distro controleren). Zien Bepaal de effectieve beveiligingsversie wanneer u wordt geconfronteerd met backpatching?.

Als vuistregel: als je ooit een van de betreffende versies hebt geïnstalleerd en ooit programma's of services hebt uitgevoerd die zijn gekoppeld aan OpenSSL voor TLS-ondersteuning, ben je kwetsbaar.

Waar kan ik een programma vinden om op de kwetsbaarheid te testen?

Enkele uren na de Heartbleed-aankondiging hadden verschillende mensen op het internet public-toegankelijke webapplicaties gepubliceerd die zogenaamd zouden kunnen worden gebruikt om een ​​server te controleren op de aanwezigheid van dit beveiligingslek. Vanaf dit schrijven heb ik er nog geen beoordeeld, dus ik zal hun applicaties niet verder publiceren. Ze zijn relatief eenvoudig te vinden met behulp van uw favoriete zoekmachine.

Hoe wordt deze kwetsbaarheid verzacht?

Upgrade naar een niet-kwetsbare versie en herstel of herbeveilig kwetsbare gegevens. Zoals opgemerkt op de heartbleed site, zijn de juiste reactiestappen in grote lijnen:

  1. Patch kwetsbare systemen.
  2. Nieuwe privésleutels opnieuw genereren.
  3. Dien nieuwe CSR in bij uw CA.
  4. Vraag een nieuw ondertekend certificaat aan en installeer het.
  5. Ongeldige sessiesleutels en cookies
  6. Reset wachtwoorden en gedeelde geheimen
  7. Oude certificaten intrekken.

Zie voor een meer gedetailleerde analyse en antwoord Wat moet een website-exploitant doen met de Heartbleed OpenSSL-exploit?op de Security Stack Exchange.

Moet ik me zorgen maken dat mijn sleutels of andere privégegevens zijn geweest   aangetast? Aan welke andere bijwerkingen moet ik me bekommeren?

Absoluut. Systeembeheerders moeten dit doen uitgaan van dat hun servers die kwetsbare OpenSSL-versies hebben gebruikt, inderdaad in gevaar zijn en dienovereenkomstig reageren.

Kort nadat de kwetsbaarheid was onthuld, bood Cloudfare een uitdaging om te zien of de persoonlijke sleutel van een server in de praktijk kon worden hersteld. De uitdaging werd onafhankelijk gewonnen door Fedor Indutny en Ilkka Mattila. Zien De Heartbleed-uitdaging.

Waar kan ik meer informatie vinden?

Link dump, voor wie op zoek is naar meer details:


Een vrij gedetailleerde tijdlijn van de onthullingsgebeurtenissen is te vinden op Heartbleed disclosure tijdlijn: wie wist wat en wanneer.


Als je een programmeur bent en geïnteresseerd bent in verschillende programmeertrucs zoals het detecteren van een Heartbleed-aanval via OpenSSL's msg_cb callback, zie dan OpenSSL's Beveiligingsadvies 2014047.


118
2018-04-08 04:23



+1 voor SHUT. DOWN. JOUW. Servers. * - Als u IETS doet waar SSL echt belangrijk is, schakelt u het uit totdat u het probleem hebt opgelost. Vergeet ook niet om nieuwe certificaten te installeren (met nieuwe sleutels) nadat u uw servers hebt gepatcht - het opnieuw gebruiken van uw oude sleutels (die mogelijk in gevaar zijn gebracht) verslaat het hele doel van het patchen van de kwetsbaarheid ... - voretaq7
OOK - herstart alle services die linken naar OpenSSL-bibliotheken. Het upgraden van OpenSSL zonder je daemons opnieuw op te starten is zo goed als helemaal niet upgraden. - EEAA
Inderdaad - na elke belangrijke patch (zoals OpenSSL), beschouw ik het als een goede regel om de machine gewoon opnieuw op te starten om ervoor te zorgen dat u niets mist. - voretaq7
Een van de testers is open source: github.com/FiloSottile/Heartbleed - Riking
@EEAA, "sluit uw servers af" betekent niet dat u aan de macht moet trekken. Dit betekent dat de apache afgesloten moet worden (of opnieuw geconfigureerd moet worden om ssl / tls uit te schakelen), of welke service dan ook die de servering uitvoert. - psusi


Een eenvoudige uitleg van de bug, door XKCD:

XKCD 1354


42
2018-04-08 07:28





Ubuntu 12.04, 12.10 en 13.10

Ubuntu heeft uitgegeven USN-2165-1, waarin staat dat bijgewerkte pakketten nu beschikbaar zijn in de archieven. Voer de volgende twee opdrachten uit om de fix te pakken.

sudo apt-get update
sudo apt-get upgrade

Ubuntu 14.04

Ik heb een Debian-pakket met de nieuwe release (1.0.1g) geüpload naar een PPA die ik voor dit doel heb ingesteld. Met deze drie opdrachten wordt mijn PPA aan uw systeem toegevoegd, wordt de lijst met beschikbare pakketten bijgewerkt en wordt alles bijgewerkt:

sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade

Opmerking: de PPA biedt ook pakketten voor Ubuntu 12.04 en 13.10, voor het geval u liever de nieuwe versie (1.0.1g) gebruikt in plaats van alleen de gepatchte versies in de archieven te gebruiken.

Ubuntu 10.04

Dit is een LTS-versie, de serverversie wordt nog steeds ondersteund en ontvangt beveiligingsupdates. Maar de harteloze kwetsbaarheid had geen invloed op het openssl-pakket van een standaardinstallatie van ubuntu 10.04, omdat de versie lager is dan 1.0.1.

De desktopversie heeft het einde van de levensduur bereikt en moet worden bijgewerkt / opnieuw geïnstalleerd.

Ubuntu 13.04 en andere verouderde versies

Ubuntu 13.04 had een zeer korte ondersteuningscyclus die je misschien niet verwacht. Het heeft het einde van het leven al bereikt en ontvangt geen beveiligingsupdates meer. Het zou lang moeten zijn opgewaardeerd. Als nog steeds iemand het gebruikt, upgrade dan nu vanaf nul of het kan niet-destructief worden opgewaardeerd naar 13.10 volgens deze eenvoudige procedure: http://www.tecmint.com/upgrade-ubuntu-13-04-raring-ringtail-to-ubuntu-13-10-saucy-salamander/ Na de upgrade ontvangt het systeem de heartbleed patch van 13.10.

Voor alle andere verouderde ubuntu-versies betekent het feitelijk dat een nieuwe installatie noodzakelijk is.

Controleer of de patch is toegepast

In wezen rennen openssl version -a en zorg ervoor dat de builddatum 7 april 2014 of later is, maar zie meer hier.

reboot

De beste manier om ervoor te zorgen dat alle services die afhankelijk zijn van OpenSSL opnieuw worden opgestart, is reboot.


36
2018-04-08 10:37



Ik kan niet spreken voor andere versies, maar er lijkt een patch beschikbaar voor precieze (12.04). Hoewel ik niet met zekerheid kan zeggen dat dit de kwetsbaarheid herstelt, werd het tenminste gecompileerd na de relevante commit (Mon Apr 7 20:31:55 UTC 2014). - Calrion
@ Calmion: een patch voor OpenSSL of de Debian-verpakking voor OpenSSL? OpenSSL is al gerepareerd en er is een nieuwe release uitgegeven. - Nathan Osman
wat gebeurt er met bestaande verbindingen terwijl openssl wordt bijgewerkt? zullen ze worden gedropt? - pdeva
Dat hangt af van welke webserver u gebruikt en hoe u werkt. Dat gezegd hebbende, zou ik me geen zorgen maken over het laten vallen van bestaande verbindingen omdat ze de kwetsbare versie gebruiken. - Nathan Osman
14.04 heeft sindsdien een patch ontvangen. - Seth


RedHat 6.5 en CentOS 6.5

Deze zijn kwetsbaar. RedHat's erratum RHSA-2014-0376 zegt dat er patched-bibliotheken beschikbaar zijn en dat iedereen die wordt beïnvloed zo snel mogelijk moet upgraden.

Op het moment van schrijven had CentOS nog geen vaste versie, maar Karanbir Singh's bericht aan CentOS-kondigen aan zegt dat ze een bijgewerkte versie van openssl hebben geproduceerd (openssl-1.0.1e-16.el6_5.4.0.1, let op de laatste vier cijfers die belangrijk zijn) waarop de te gebruiken TLS-opdracht is uitgeschakeld en die veilig kan worden toegepast omdat deze door een vaste versie zal worden overschreven wanneer deze uiteindelijk wordt vrijgegeven.

De tijdelijk gefixeerde versie lijkt nog niet op alle mirrors te zijn terechtgekomen, maar bevindt zich in de hoofdrepository http://mirror.centos.org/centos/6/updates/x86_64/Packages/ (en op dezelfde manier voor i686).

Bewerk: zoals Iain zegt, lijkt er nu een volledig gepatchte versie voor C6.5 te zijn, en deze lijkt in een haast door de spiegels te zijn geduwd. Een rechte yum update heb het voor mijn servers; haar openssl-1.0.1e-16.el6_5.7.

Versies van RH6 en C6 voor 6.5

Deze zijn niet kwetsbaar. Volgens dit advies van Red Hat,

Dit probleem had geen invloed op de versies van openssl zoals geleverd bij Rood   Hat Enterprise Linux 5 en Red Hat Enterprise Linux 6.4 en eerder.

Karanbir Singh's bericht aan CentOS-kondigen aan is even duidelijk over versiebeheer:

Eerder vandaag, werden we bewust gemaakt van een ernstige   probleem in openssl zoals verzonden in CentOS-6.5


14
2018-04-08 13:07



is het niet lists.centos.org/pipermail/centos-announce/2014-April/... de release van de fix? - Iain


Debian Wheezy

Debian heeft problemen veroorzaakt DSA-2896-1 en gepatchte bibliotheken zijn beschikbaar Hier. Een shellscript is beschikbaar Hier.

1. Patch

Apt-get repository is bijgewerkt, dus nu zijn gepatchte bibliotheken beschikbaar via apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

Als alternatief (niet aanbevolen) kunnen de pakketten handmatig worden geüpgraded:

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

2. Start de server / services opnieuw op

Voor de beste beveiliging start u de hele server opnieuw op of als de server niet offline kan zijn, start u de benodigde services opnieuw op.

3. Controleer de OpenSSL-versie

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries

13
2018-04-08 11:23



Als u updates ontvangt van wheezy/security dan zal je goed zijn met apt-get update && apt-get upgrade. Of gebruik een interactieve pakketbeheerder om alleen de pakketten bij te werken openssl, libssl1.0.0, libssl1.0.0-dbg en libssl-dev (zoals geïnstalleerd op uw systeem). - α CVn
apt-get gebruiken lost het probleem niet voor mij op - nog steeds OpenSSL 1.0.1e 11 februari 2013 tonend - user568829
Bedankt @ michael-kjorling, het was niet beschikbaar toen ik dit deed, maar het is de veiligste en meest correcte manier om te upgraden. - jacksoncage
@ user568829 na het toepassen van de patch openssl versie zal nog steeds verschijnen OpenSSL 1.0.1e 11 Feb 2013 aangezien de patch 1.0.1e-2 wordt genoemd. U kunt contact opnemen met dpkg -l openssl en het zou versie moeten tonen 1.0.1e-2+deb7u6 - jacksoncage
Ik zou willen voorstellen de host te herstarten na het updaten van OpenSSL, niet omdat het strikt noodzakelijk is, maar uit gemoedsrust dat ten minste alles dat de OpenSSL-bibliotheken dynamisch laadt de nieuwe versie gebruikt. (Statisch gekoppeld is een andere zaak.) Dat gezegd hebbende, erken ik dat sommige servers niet eenvoudig opnieuw kunnen worden opgestart in alle situaties waarin een herstart van de service acceptabel kan zijn. - α CVn


Ik wil erop wijzen dat privésleutels niet de enige items zijn die als aangetast moeten worden beschouwd. De bug heeft het potentieel om te lekken ieder geheugen dat in dezelfde adresruimte loopt (d.w.z. hetzelfde proces) als OpenSSL. Daarom, als u een serverproces uitvoert waarbij een kwetsbare versie van OpenSSL statisch of dynamisch is gekoppeld, alle informatie die dat proces ooit heeft verwerkt, inclusief wachtwoorden, creditcardnummers en andere persoonlijke gegevens, moet als mogelijk aangetast worden beschouwd.


9
2018-04-08 20:23





FreeBSD 10.0 of openssl van havens

De Beveiligingsteam van FreeBSD heeft een advies uitgebracht met betrekking tot CVE-2014-0160 (ook bekend als "Heartbleed") en: FreeBSD-SA-14: 06.openssl

  1. FreeBSD updaten

    • FreeBSD updaten via een binaire patch

      Systemen met een Uitgegeven versie van FreeBSD op de i386 of amd64 platforms kunnen worden bijgewerkt via het hulpprogramma freebsd-update (8):

      # freebsd-update fetch
      # freebsd-update install
      
    • FreeBSD updaten vanuit de bronnen

      1. Download de relevante patch van de onderstaande locatie en verifieer de losse PGP-handtekening met behulp van uw PGP-hulpprogramma.

        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
        # gpg --verify openssl-10.patch.asc
        
      2. Voer de volgende opdrachten uit als root:

        # cd /usr/src
        # patch < /path/to/patch
        
      3. Hercompileer het besturingssysteem

        gebruik makend van buildworld en installworld zoals beschreven in de FreeBSD handboek.

  2. Werk het openssl poort met minimale versie 1.0.1_10

  3. Start alle daemons opnieuw op met behulp van de bibliotheek of start het systeem opnieuw op

  4. Doe alsof uw systeem is aangetast, voer al uw SSL-sleutels en / of certificaten en potentieel gelekte informatie opnieuw uit (zie EEAA meer algemeen antwoord).

FreeBSD 9.x en FreeBSD 8.x

Deze systemen zijn niet kwetsbaar naar de heartbleed standaard probleem, als een beroep op oudere 0.9.x-versie van de openssl bibliotheek, tenzij je hebt geïnstalleerd openssl  van de havens (zie boven).

Als deze systemen niet kwetsbaar zijn voor de heartbleed probleem is, is het misschien verstandig om uw systeem eerder te upgraden als gevolg van een ander systeem lokaal kwetsbaarheid (zie FreeBSD-SA-14: 06.openssl en het gedeelte "FreeBSD 10.0" boven):

Een lokale aanvaller kan een ondertekeningsproces opsporen en mogelijk herstellen   de ondertekeningssleutel ervan. [CVE-2014-0076]

Notitie:

Het origineel heartbleed advieslijsten die FreeBSD 8.4 en 9.1 als potentieel kwetsbaar beschouwen. Dit is niet waar vanwege het ontbreken van Heartbeat-extensie (standaard FreeBSD openssl-bibliotheek die versie 0.9.x is).


9
2018-04-11 08:03