Apparatuur Juniper en Cisco blijkt vatbaar voor Heartbleed-bug

Netwerkapparatuur van Cisco en Juniper blijkt kwetsbaar voor de Heartbleed-bug in OpenSSL, waarbij clients een deel van het servergeheugen kunnen uitlezen. Ondertussen stelt de ontwikkelaar die de bug waarschijnlijk heeft geïntroduceerd dat het niet om een opzettelijke fout gaat.

Cisco heeft bevestigd dat zestien van zijn routers, switches en ip-telefoons kwetsbaar zijn voor de bug in OpenSSL; van zeker zestig andere producten wordt nog onderzocht of ze kwetsbaar zijn. Ook apparatuur van concurrent Juniper is volgens de Amerikaanse krant The Wall Street Journal kwetsbaar voor de Heartbleed-bug.

Veel websites die kwetsbaar waren hebben de afgelopen dagen OpenSSL-patches uitgerold om zichzelf te beschermen. Beveiligingsonderzoekers raden gebruikers aan om wachtwoorden bij getroffen websites pas te wijzigen als de patch is geïnstalleerd; anders is een wachtwoordwijziging in potentie ook door kwaadwillenden uit te lezen.

Ondertussen stelt de ontwikkelaar die de bug waarschijnlijk heeft geïntroduceerd dat het niet om een opzettelijke fout gaat. Hij noemt de fout 'triviaal', al erkent hij de ernstige impact ervan. "Ik vergat om een variabele die een lengte bevat te valideren", zegt de ontwikkelaar, Robin Segelmann, tegen de Sidney Morning Herald. De fout werd bij het inspecteren van code ook niet opgemerkt.

Ars Technica meldde eerder dat de bug mogelijk twee maanden voor ontdekking door het OpenSSL-team is misbruikt. De Electronic Frontier Foundation vraagt zich af of inlichtingendiensten daar achter zaten. Een van de ip-adressen die zou zijn gebruikt om de bug te misbruiken, zou onderdeel uitmaken van een botnet dat alle gesprekken op FreeNode probeert op te slaan; volgens de EFF is dat niet iets wat een normale internetcrimineel zou doen.

De Heartbleed-bug maakt het mogelijk voor aanvallers om het geheugen van een server met OpenSSL uit te lezen, in chunks van 64 kilobyte. Omdat het interne geheugen wordt uitgelezen, kunnen daarbij onder meer privésleutels worden uitgelezen, evenals ontsleutelde wachtwoorden. Beveiligingsgoeroe Bruce Schneier noemt de kwetsbaarheid 'op de schaal van 1 tot 10 een 11'.

Reacties (55)

Getailleerde uitleg over de bug.

http://www.theregister.co.../09/heartbleed_explained/

En een Jip en Janneke uitleg:
http://xkcd.com/1354/

Op Stack Exchange staat ook een goede uitleg.

Dit artikel is zeker interessant om te lezen.
Het laat zien dat, tenminste op Linux en OS X de bug zeer moeilijk en beperkt te misbruiken is, en Microsoft-servers veelal geen OpenSSL gebruiken.
Hoe het zit met losse apparatuur is natuurlijk een ander verhaal.

Het enige waar ik het mee eens ben in dat artikel is dat het leaken van de private keys eigenlijk niet voorkomt.

Voor de rest heb ik uit eigen tests ondervonden dat er bij de meeste servers die kwetsbaar waren gewoon wel zeer gevoelige informatie gelekt werd, hierbij moet je voornamelijk denken aan username/passwords combinaties, IP adressen van de clients, complete sessie cookies, webmail.

In het geval van Juniper(cisco niet gechecked) was het eigenlijk hetzelfde.
Neem bijvoorbeeld een SSL-VPN verbinding daarvan was ook alle data op te vangen en dan moet je weer denken aan username/passwords en emails.
Om dat mensen nog steeds usernames en passwords voor andere services via de email versturen kun je deze kleine data leak gebruiken om bijvoorbeeld in te breken bij des betreffende bedrijf.

Ik heb het al eerder vermeld in een andere post en heb met verschillende bedrijven ook contact gehad over deze bug, en bij sommige was er gewoon de mogelijkheid om complete email conversaties uit te lezen (via Juniper)

Mac OS X gebruikt gewoon OpenSSL 0.9.8, de bug zit enkel in 1.0.1. Mac OS X is dus niet kwetsbaar voor deze bug...

Daarentegen; we hebben wel al onze CentOS servers mogen updaten na de update naar 6.5, want die nam v1.0.1 mee.

Sterker nog, OS X en iOS maken uberhaupt geen gebruik van OpenSSL. Apple raadt developers ook af om OpenSSL te gebruiken omdat ze de API te instabiel vinden.

Er wordt inderdaad een oudere, niet kwetsbare, versie van OpenSSL meegeleverd maar dat is waarschijnlijk voornamelijk om het porten van sommige applicaties van Unix en Linux makkelijker te maken.* Er wordt normaal gesproken geen gebruik van gemaakt. Developers gebruiken normaal gesproken de eigen encryptie libraries van het OS.

* Voor mensen die Mac Ports gebruiken om naar OS X te porten en die bang zijn dat ze wel een kwetsbare versie hebben geinstalleerd, met: 'sudo port upgrade openssl' is hij zo geupdate naar een niet-kwetsbare versie.

[Reactie gewijzigd door Maurits van Baerle op 11 april 2014 11:07]

OS X was dan niet kwetsbaar voor Heartbleed, ze hebben net al hun eigen ernstige SSL bug voor de kiezen gehad:
http://www.macworld.com/a...about-apples-ssl-bug.html

Als deze man gelijkt heeft, dan is alle ophef dus voor niks. Ik werk in een IBM-callcenter en krijg vaak telefoontjes over Heartblead, zelfs tech-leken weten ervan. En dan blijkt het ongefundeerde angst te zijn?

Toevallig kreeg ik gisteren wel een spam-SMS (wie doet dat nou?), en dan bekruipt je toch het gevoel dat al je gegevens op straat liggen. Dit artikel stelt me weer gerust!

Als deze man gelijkt heeft, dan is alle ophef dus voor niks.

Dat is niet geheel waar. Dat de kans op misbruik klein is, betekend niet dat het risico er niet meer is. Als het wel succesvol misbruikt wordt, zou dat betekenen dat iemand zonder pardoen je private keys kan krijgen. Wat als gevolg heeft dat een certificaat te misbruiken is en man-in-the-middle attacks heel makkelijk zijn. De ophef is dus zeker terecht.

windows servers zelf bevatten geen openssl. maar applicaties / utilities die er op draaien is een heel ander verhaal. een vlugge quickscan op mijn eigen windows 7 laptop:
- avast virusscanner 2014.9.0.2016: 1.01e ( vulnerable )
- intel proset networkcard software: 1.00b ( niet vulnerable )
- x-win32 2010: 0.98k ( niet vulnerable )
- any video converter: 1.01c ( vulnerable )
- openvpn 2.3.2, heb ik net ge-update naar 2.3.3, maar bevatte ook een vulnerable openssl lib

dit zijn alleen de met die software meegeleverde dll's. mogelijkerwijs is er ook nog software waarin deze libraries statisch zijn gelinkt. mag wel niet, maar wil niet zeggen dat het niet gebeurt.

De programma's die je opnoemt zijn echter client-side programma's, ze gebruiken OpenSSL dus om verbinding te kunnen maken met een SSL server.
Ik denk niet da 1 van deze programma's zelf een server opzet.
Het enige risico dat je dan misschien hebt is als je met een server verbind waarop een virus staat. Op dat moment zou de betreffende server het geheugen van de betreffende app kunnen lezen.
Het lezen van het geheugen door een virusscanner gebruikt lijkt me hoogstens te kunnen onthullen welke bestanden er op je computer staan, en eventueel een registratie van de virusscanner.
Het geheugen van een video-converter zal al helemaal niets boeiends bevatten voor een aanvaller.
OpenVPN zou dan eventueel nog een klein risico kunnen zijn indien wanneer het certificaat van de server waarmee je connect niet gecontrolleerd word.

Van server-software hangt het af van het gebruikte programma op de server wat er te rapen is.
Software die voor elke request een nieuw proces start is nauwelijks te misbruiken, in het geheugen staat dan immers enkel jou eigen request.
Als hetzelfde proces meerdere requests afhandelt kan er inderdaad misbruik gemaakt worden.

interessante vise maar zit wel vol met dubieuze aannames. Deze bijv:

Since there has been no massive compromise at any vulnerable sites, we can safely assume that nobody was using the exploit.

Als de NSA en dergelijke gebruik maakten van deze backdoor ( al dan niet bewust aangebracht) dan hebben ze geen enkel belang bij massive compomising. Ze zullen dit stil en voor eigen gebruik houden. Inmiddels blijkt uit onderzoek van de FSS dat er sterke aanwijzingen zijn dat de toegang reeds misbruikt is!
Kortom, leuke insteek maar eigenlijk alweer achterhaald door onderzoek.

"Beveiligingsonderzoekers raden gebruikers aan om wachtwoorden bij getroffen websites pas te wijzigen als de patch is geïntalleerd; anders is een wachtwoordwijziging in potentie ook door kwaadwillenden uit te lezen."

Na patchen is een wachtwoordwijziging in potentie ook door kwaadwillenden uit te lezen. Hiervoor moet wel voor het patchen door kwaadwillenden de private key moeten zijn bemachtigd. Misschien niet zo'n grote kans, maar in het ernstigste geval heeft de server al meer dan 2 jaar een kwetsbare versie van OpenSSL, dus better safe than sorry. De servereigenaren moeten hun private keys en certificaten revoken en nieuwe uitgeven, wat nu ook massaal gedaan wordt. Dit kan echter langer duren dan het patchen en dus is het verstandig om voor het wijzigen van het wachtwoord eerst naar uitgiftedatum van het certificaat te kijken.
Yahoo bijv. is een mooi voorbeeld, die hadden al snel gepatched, maar de nieuwe certificaten lieten even op zicht wachten. Het revoken is namelijk het werk van de Certificate Authority, en bovendien hebben die het op het moment natuurlijk extra druk. Bovendien zullen grote klanten als Yahoo waarschijnlijk sneller worden geholpen dan de wat kleineren.

Er zijn nu dus nu in 1 klap miljoenen certificaten blacklisted, hoe gaan clients dat in vredesnaam bijhouden?

Totdat deze certs verlopen zijn is het hele SSL/TLS systeem nu praktisch onbruikbaar, of zie ik dit nu verkeerd?

[Reactie gewijzigd door Dreamvoid op 11 april 2014 13:57]

De certificaten worden niet geblacklist zoals bijv. bij het Diginotar debacle. Wanneer ze ingetrokken zijn kunnen browsers iig met OCSP en CRL zien dat een certificaat ingetrokken is.
In Google Chrome staat OCSP standaard uit en bijna alle browsers geven standaard geen waarschuwing als de OCSP server geen reactie geeft, ook omdat die bijvoorbeeld plat is gelegd door kwaadwillenden.
In de meeste browsers kan je dit in de opties aanpassen.

Ik las trouwens net dat sommigen sites al nieuwe certificaten hebben e.d. maar in intrekken door CA's een week kan duren. In die tijd zou een aanvaller in theorie een Man in the Middle attack kunnen doen met het oude certificaat.

OCSP? CRL?

Hoe ik er momenteel tegenaan kijk is het probleem veel groter dan men nu overziet.

wachtwoorden op netwerkapparatuur zijn uit te lezen wat in potentie betekent dat een volledig inzicht in de topologie is verkregen of de topologie en instellingen gewijzigd. Bijvoorbeeld met het doel op een MItM waarbij het doel is om de datastroom op te vangen.

Doordat public private keys (welke vaak automatisch tussen nodes worden uitgewisseld) in theorie zijn gecompromitteerd ontstaaT de situatie dat de encrypte data op door public/private keys gebaseerde verbindingen kan worden decrypt. Ook met terugwerkende kracht.

Zelfs na een patch kan decryptie plaatsvinden van de opgevangen data sessie en als de automatische handshake van public/private keys plaatsvindt (binnen de encrypte tunnel) kan ook deze nieuwe handshake worden gecompromitteerd. Wat betekent dat de hacker alsnog alle data kan blijven lezen!

Patchen is pas het begin, vervolgens moeten verbindingen met public/private key algoritmen, waar een men in the middle op enigerlei manier mogelijk is, down gebracht worden om vervolgens een nieuwe handshake te laten plaatsvinden.


Zoals ik het zie houdt dit in dat je in principe je netwerk volledig van de buitenwereld moet afsluiten vervolgens alles intern opnieuw moet patchen en uitwisselen en daarna pas de connectiviteit met de buitenwereld kanactiveren.
Bedenk eens hoeveel switches routers etc van een enkele organisatie in verbinding staan met een netwerk van een andere organisatie... (Ook de wanprovider en de access laag zijn potentieel gevaarlijke ander netwerken.)

http://tools.cisco.com/se...co-sa-20140409-heartbleed

naast juniper en cisco zijn ook Aruba networks wlan en identity services oplossing en Alcatel-Lucent (Aruba OEM) geraakt door heartbleed. Alcatel-Lucent heeft geen reactie op data en carrier producten gegeven. Alcatel voice oplossingen zijn naar het lijkt veilig.

Beveiligingsgoeroe Bruce Schneier noemt de kwetsbaarheid 'op de schaal van 1 tot 10 een 11'.

Dit is nou een voorbeeld van het niet controleren of een variabele wel binnen zijn boundaries blijft.

De Sonicwall SRA Appliance (SSL VPN) is er ook vatbaar voor.
Sonicwall heeft gisteren een fix uitgebracht om de bug te repareren.

http://www.sonicwall.com/...esponse_Vulnerability.pdf

Sonicwall Intrusion Prevention pakte bij mij de bug niet op. Dus zeker zaak om daar niet blind op te vertrouwen!

[Reactie gewijzigd door Acmosa op 11 april 2014 08:16]

https://www.mysonicwall.c...ts.aspx?ev=article&id=668

Alleen als Intrusion Prevention niet is geactiveerd:

Dell SonicWALL firewalls with activated Intrusion Prevention protect customers' servers against this attack with the following signatures by testing the bytes in the heartbeat packet against the limits that are outside the normal bounds.

Sonicwall Intrusion Prevention pakte bij mij de bug niet op. Dus zeker zaak om daar niet blind op te vertrouwen!

Zo ook de Sophos UTM, zie http://blogs.sophos.com/2...vulnerability-heartbleed/

Het feit dat HP hier niet wordt genoemd betekend dat deze apparatuur er niet kwetsbaar voor is? Lijkt mij toch van niet.. Misschien omdat zij het nog niet officieel naar buiten hebben gebracht.

Edit: uitgebreid met McAfee & Citrix.
Edit2: Lees de links vooral, en niet mijn korte (vast foute) samenvatting!

HP:
http://h17007.www1.hp.com...artbleedVulnerability.pdf

At this time, we have completed investigations on the vast majority of HP
Networking hardware and software platforms and packages. We have
determined the products we have investigated are not vulnerable due to
either using a version of OpenSSL that is not vulnerable or are not using
OpenSSL:
 Data Center, Campus & Branch switches and routers
 Unified and MSM wireless controllers and access points
 Intelligent Management Center (IMC)
 TippingPoint IPS, NGFW, SMS
 VAN SDN Controller*

===============================

McAfee:
https://kc.mcafee.com/cor...x?page=content&id=SB10071

See specific versions affected in the patch table below.

NGFW – Next Generation Firewall (Stonesoft)
MFE – McAfee Firewall Enterprise
SIEM – McAfee Enterprise Security Manager (Nitro)
MWG – McAfee Web Gateway
MSME - McAfee Security for Microsoft Exchange
Others to be announced as more information is available

===============================

Citrix:
http://support.citrix.com/article/CTX140605

Citrix XenMobile App Controller versions 2.9 and 2.10 are vulnerable.
{ rest is niet vulnerable }
Citrix Web Interface: Web Interface makes use of the TLS functionality provided by the underlying web server. Citrix customers are advised to verify that any deployed web servers used to host Web Interface are not vulnerable to this issue. Web Interface can also use a built-in TLS library to make outgoing TLS connections, this library is not vulnerable to CVE-2014-0160.

[Reactie gewijzigd door Triblade_8472 op 11 april 2014 16:12]

Hey perfect Triblade, thanks.

Nu is het zo dat mijn organisatie dus veelal HP gebruikt op netwerk gebied. Ze hebben dan weliswaar de dans ontsprongen wat betreft deze exploit (in grote lijnen) maar Ik zie toch liever Cisco op netwerk gebied .

Het kan zijn dat HP een andere SSL library gebruikt. De bug zit alleen in OpenSSL. Maar ik zou wachten op een officiële erkenning/ontkenning.

Omdat de lengte van een enkele variabele niet gevalideerd wordt is dit allemaal mogelijk? Je zou denken dat er toch iets meer beveiliging in zit...

Zelfs je vergissen door een enkel of juist een dubbel = teken te gebruiken - lees je ook zo overheen - zou een dergelijke situatie kunnen opleveren. De impact ligt niet altijd voor de hand.

Het erge is, als je weet dat er ergens zo'n foutje zit, dan kun je zomaar een dag bezig zijn om dat foutje op te sporen. Wat heb je vandaag gedaan? Ehm, 1 karakter verwijderd uit de broncode - kun je beter niet zo op je factuur zetten.

Tja, welkom in de wondere wereld van software. De meeste bugs worden veroorzaakt door de kleinste foutjes.

En zo ga je van de een op de andere dag de geschiedenis in als de maker van een van de grootste bugs ooit xD. Staat wel leuk op je CV.

Volgens Theo de Raadt (OpenBSD / OpenSSH) is het niet alleen de programmeur, maar hoe het OpenSSL project "Is being run by an unresponsible team":

http://article.gmane.org/gmane.os.openbsd.misc/211963

Als openssl zo slecht geschreven is zijn er ook goede alternatieven voor Linux?

OpenSSL is niet slecht geschreven, er is gewoon een bug in gekomen en ja die had een hele grote impact. Kan gebeuren en het gebeurt wel vaker helaas. Laatst bij Apple ook grote kwetsbaarheden, etc. Shit happens.

Deze bug gaat wel wat verder dan 'shit happens', het betekent dat de test procedures in het OpenSSL project niet deugen. Een beetje static analysis tool had zo'n ontbrekende range check direct eruit gepakt - IMO valt het OpenSSL wel degelijk wat te verwijten, ook al kan je niet verwachten dat ze foutloos coden, een beetje fatsoenlijk testen is niet teveel gevraagd.

Maar goed, in principe is het gratis en open source, en hadden we allemaal zelf die bug moeten vinden. Dat blijft altijd het lastige met het hele OSS gebeuren - iedereen en niemand is aansprakelijk of verantwoordelijk, de gebruikers zelf worden geacht om bugs te zoeken en herstellen. Laten we hopen dat de grote jongens (Google, Yahoo, Cisco, Juniper) die nu met de gebakken peren zitten in de toekomst wat meer gaan bijdragen aan OpenSSL.

[Reactie gewijzigd door Dreamvoid op 11 april 2014 14:34]

Een beetje static analysis tool had zo'n ontbrekende range check direct eruit gepakt

Dat is helaas niet waar. Coverity Scan staat hoog aangeschreven, maar slaagde er niet in dit te vinden. Dat is wel meer dan "een beetje" static analysis. Dat wil overigens niet zeggen dat het onmogelijk is deze bug op te sporen met static analysis, noch dat de OpenSSL code bijzonder goed in elkaar zit, want Coverity vind wel genoeg andere defects. Meer informatie hier.

Niet per se. Het is er doorheen geslipt, en ja dat heeft een enorme impact nu: maar wat ik wilde zeggen is dat dit overal gebeurd... Daarom gaf ik ook het Apple voorbeeld, dat was ook echt een belachelijk trieste fout en is ook nog doorgekomen... Vandaar: shit happens.

polarssl?