Bug OpenSSL maakt onderscheppen privacygevoelige gegevens mogelijk

Hackers hebben mogelijk betalingsgegevens en andere vertrouwelijke info van veel internetters kunnen onderscheppen door een kritieke bug in OpenSSL. De bug zit in software die naar schatting door een meerderheid van de websites op internet wordt gebruikt.

De bug, die bekendstaat onder de namen Heartbleed en CVE-2014-0160 en die al twee jaar in OpenSSL zit, maakt het mogelijk om van buitenaf het interne geheugen van een webserver uit te lezen en daardoor private keys en ontsleutelde data te zien zonder enig spoor achter te laten. OpenSSL heeft de bug bevestigd.

Omdat de bug het mogelijk maakt om ontsleutelde data uit te lezen en gegevens te onderscheppen, is het mogelijk dat kwaadwillenden sessies op sites met privacygevoelige gegevens hebben onderschept. Onder meer iDeal gebruikt OpenSSL voor het genereren van private keys, net als naar schatting meer dan de helft van de webservers die online zijn, waaronder veel diensten die een login vereisen.

De bug zit in de 'heartbeat'-extensie van TLS, waar de software een 'bounds check' zou moeten doen om te kijken of een actie mag worden uitgevoerd. Een aanval met deze bug laat geen enkel spoor achter volgens de onderzoekers, waardoor niemand kan achterhalen of kwaadwillenden deze kwetsbaarheid de afgelopen twee jaar actief hebben misbruikt.

De getroffen versies zijn OpenSSL 1.0.1 en 1.0.2; gebruikers zouden moeten upgraden naar 1.0.1g of 1.0.2beta2, waarin een fix zit voor deze bug. Mensen achter het Tor-project, die een sterke focus hebben op anonimiteit en beveiliging, waarschuwen dat 'als je sterke anonimiteit of privacy nodig hebt op internet, je misschien een paar dagen van het internet wil wegblijven'.

Update 08:48: In dit artikel stond aanvankelijk dat wellicht de sites van grote Nederlandse banken zouden zijn getroffen, maar daar zijn geen nadere aanwijzingen voor gevonden. Een site van een Italiaanse ontwikkelaar waarmee hij claimt te checken of sites kwetsbaar zijn claimt dat in elk geval ING Bank en Rabobank veilig zijn. Diezelfde site beoordeelt Tweakers als 'kwetsbaar'.

Reacties (198)

[RedPixel]

Dit is wel een serieus ernstige bug, die er al te lang in zit!

Merk op dat dit vrijwel iedere webserver van de afgelopen twee jaar kwetsbaar heeft gemaakt! De private key kan geraadpleegd worden, en daardoor kan alle onderschepte data ingezien worden! Dat houdt ook opgeslagen historische data in.

Aan alle systeembeheerders:
Het updaten van openSSL en herstarten van servers is niet voldoende! Je moet óók een nieuw certificaat maken bij je ssl-boer, én de oude revoken! (In die volgorde)

[airell]

Merk op dat dit vrijwel iedere webserver van de afgelopen twee jaar kwetsbaar heeft gemaakt!

Nou... áls de webserver van (deze versie) OpenSSL libraries gebruik maakt natuurlijk... IIS en OHS gebruiken naar mijn weten geen OpenSSL.

[RedPixel]

Klopt, Apache en nginx wél, en die zijn toch al goed voor meer dan twee-derde van het internet. Moet je ze natuurlijk wel gebruiken in combinatie met een OpenSSL versie tussen 1.0.1 en 1.0.1f. Maar dat zijn nogal veel distributies. Meer info op de gelinkte website.

[Reactie gewijzigd door RedPixel op 25 juli 2024 05:22]

[Yzord]

Vreemd, mijn webserver bestaat uit Apache en OpenSSL en heb er ook ssl's op installed, maar de mijne is niet vulnerable. Terwijl ik toch niet geupdatet ben naar de laatste versies (ik wacht altijd op een nog nieuwere versie alvorens ik update). Dus schijnbaar is het niet alleen maar als je Apache en OpenSSL hebt.

[TvdW]

openssl 0.9.8 is niet kwetsbaar

[paradoXical]

Gelukkig de versie die ik draai

[Xieoxer]

Ik probeer het te begrijpen, maar als ik het goed begrijp kan een hacker zonder toegang in het systeem de private key opvragen van je SSL? Dit komt omdat de private key in de memory zit?

[RedPixel]

Exact.

[BlackOwl]

En dat lokaal geheugen van die webserver is toegankelijk door een bug in openssl?
Of komt alleen het feit dat die private key in dat geheugen staat door de bug en heeft het kunnen uitlezen van het geheugen een compleet andere oorzaak?

[Armin]

De client kan het gehele virtuele geheugen dat toegankelijk is voor de webserver uitlezen. De bug is 'enkel' het kunnen uitlezen van het geheugen van de server-applicatie.

Het is immers het virtuele geheugen, en niet het fysieke geheugen. Immers intern in de server zijn ook nog afschermingen tussen applicaties/processen. Ofwel een hacker kan de websserver-applicatie zijn geheugen in blokjes van 64kB uitlezen, maar niet het geheugen van een andere appliciatie op diezelfde server,

Wat in dat geheugen van die webserver staat zal verschillen. Een van de dingen die er vaak in staat is de private key. Soms echter nog veel meer, en veel gevaarlijke informatie. Immers als het een bank-webserver is gaat er wellicht andere informatie door die server die tijdelijk in het geheugenblijft hangen. En bij een webshop wellicht credit card informatie. Etc.

Soms gelukkig ook niet, want er zijn ook nog beveiligingen mogelijk die het gevaar kleiner maken. Als bijvoorbeeld de authenticatie-server los staat van de content-server, is enkel de authenicatie-server vatbaar en 'enkel' de key uit te lezen. En ook daar kan een server extra beveiliging hebben intern.

Enkel de admin's van die webservers kunnen met zekerheid zeggen (en dan wellicht enkel met hulp van de makers van de webserver software), hoe groot het gevaar is.

[Lennie]

Ja, of eigenlijk: er is een kans dat dat gebeurt. Wat het geheugen dat gelekt wordt kan ook andere informatie bevatten die wel of niet interresant is voor de ontvangende partij.

[Cobalt]

Kostbaar grapje als iedereen die openssl draait een nieuw certificaat moet aanvragen.

[RedPixel]

Iedereen die een kwetsbare versie draait of heeft gedraaid en zijn private key/certificaat belangrijk genoeg vindt.

[freaky]

Uren technisch wel. Meeste CA's doen gratis een reissue echter.

[Yggdrasil]

Bij de meeste CA's kun je gratis een vervanging aanvragen, dat dan dezelfde verloopdatum heeft als het origineel.

Helaas is het wel arbeidsintensief want je moet alle stappen doorlopen die bij een nieuw certificaat horen, incl. de verificatiemail. Als je certificaten voor veel klanten moet vervangen is dat vervelend want moeilijk te automatiseren.

[hackerhater]

Vertel ons wat -_-'
Hier gaat ons vrije weekend voor alle clients op onze servers weer veilig zijn.

[Ergomane]

Die actie is mogelijk nog onvoldoende. Afhankelijk van de applicatie kan er allerlei cleartext request & response data zijn onderschept. Denk daarbij aan sessie IDs, wachtwoorden, en als de PHP interpreter in het webserver proces draait ook interne API sleutels en tokens.

De consequenties van het lekken van die data dient ook te worden onderzocht, waarna maatregelen genomen moeten worden.

Gezien het feit dat mijn oude Tweakers sessie nog steeds actief is, lijkt me dat de staf van tweakers hier nog over aan het nadenken is.

[erikloman]

Aanvallers kunnen met deze bug de private keys van de SSL certificaten stelen.

Gebruikers van OpenSSL (het zit in nogal wat software) moeten hun SSL certificate revoken en reissuen. Maar voordat je dat doet: eerst de OpenSSL software patchen.

Meer info hier:
https://medium.com/p/715b2260813d

[SunnieNL]

Waarom is IIS niet vatbaar voor de bug. Dacht dat die ook OpenSSL gebruikt, maar blijkbaar niet?

[edit] Al gevonden. Gewoon niet goed gelezen. Het is een bug in de OpenSSL library. Geeft maar weer aan dat opensource niet altijd leidt tot snellere bugfix, gezien hij er al 2 jaar in zit.

[Reactie gewijzigd door SunnieNL op 25 juli 2024 05:22]

[JAVE]

Niet zozeer de bugfix, maar het sneller vinden is het idee.
Helaas is veel open source software zo complex dat er niet veel mensen zijn die voor de lol de code gaan doorspitten, waardoor het sneller opmerken van bugs niet werkt.

Het sneller fixen van bugs werkt wel; als de bug eenmaal gevonden is gaan ze niet wachten tot de eerstvolgende service pack om er wat aan te doen...

[YopY]

Het is maar zeer de vraag of je echt veel vindt door code door te spitten, ook als je nagaat dat er al genoeg ogen naar gekeken hebben (de auteur, de reviewer, degenen die het uiteindelijk in de core moeten plaatsen, security researchers, etc)

[Lennie]

Als je denkt dat het makkelijk is om dit soort bugs uberhaubt te vinden, dan is dat een illusie.

Neem nu Microsoft als voorbeeld, toch duidelijk een bedrijf die zich bezig houd met het maken van closed source software.

Sinds Windows 95 heeft Microsoft een nieuwe TCP/IP stack. Met Windows 95 kon je een bluescreen maken door het sturen van het juiste ping pakket. De bekende Ping of Death.

Sinds Vista hadden ze een nieuwe TCP/IP stack. Wat denk je dat er gebeurde met een nieuwe TCP/IP stack van Windows Vista ? Weer een Ping of Death bug. En dat is nadat men een heel nieuw regieme had ingevoerd met betere geuatomatiseerde security checks en betere security reviews.

Nog gekker, Windows heeft ook een RPC over SMB, dat zit er al in sinds Windows 95, misschien zelfs wel Windows for Workgroups 3.11. Wanneer denk je dat de nieuweste security bug (er zijn er natuurlijk meerdere geweest) is gevonden in die code ? In 2013.

Dus hoe lang heeft die bug in Windows bestaan, het is zeker niet onmogelijk dat deze code er al in zit sinds Windows NT 3.5 of Windows NT 4.0.

Dat is ook nog eens heeel veel jaren nadat men hun nieuwe process in heeft gevoerd.

Terwijl dat nu juist 1 van de weinige dingen is die standaard altijd open staat in op een Windows Server, maakt niet uit wat de firewall instelling zijn. Lijkt mij toch iets waar ze als eerste naar gekeken hebben en mogelijk nadat ze geleerd hebben beter te reviewen, opnieuw naar gekeken hebben.

[JAVE]

We hebben het niet over de Linux kernel, maar over OpenSSL.
Ik weet niet hoe hun procedure is, maar ik weet wel dat reviews nog wel eens overgeslagen worden.

Daarentegen had ik wel verwacht dat encryptie-gerelateerde programma's uitgebreid gechecked zouden worden door diverse security bedrijven.

[ShadyNetworker]

Die verwachting is leuk, maar "diverse security bedrijven" vragen er gewoon geld voor, en niet zo een beetje ook.
Daarnaast is het natuurlijk altijd de vraag of je zo een "professionele" audit kunt vertrouwen.

[kwikstaart]

Red Hat, IBM, Facebook, Oracle, Google - allemaal bedrijven voor wie dat geld niet zo belangrijk is, of die makkelijk een paar mensen op zo'n project kunnen zetten. En dat doen ze ook.

[halofreak1990]

Nou ja. Je zou toch verwachten dat bij dit soort security-critical libraries er regelmatig een security-audit plaatsvindt.

[Lennie]

Dat is precies wat hier nu gebeurt is en daar uit is gekomen dat de OpenSSL code van een 2012 toch een bug bevatte.

[goarilla]

Is dit een vrucht van de security audit die gepland was na meneer Snowden z'n uitlatingen over NIST curves en NSA's ECDSA backdoor ?

[hackerhater]

Zou me persoonlijk niks verwonderen.

[Kenhas]

Ik zie het eerder als niet leiden tot het sneller vinden van een bug. Maar volgens mij is de bugfix er toch snel gekomen

[unglaublich]

Nog erger, bij closed-source weet je niet eens of er bugs in zitten. Security by obscurity of misschien gewoon met opzet. Bad practice dus.

[Niemand_Anders]

De bug zit inderdaad al twee jaar in de OpenSSL library, maar dat betekend niet dat de bug al twee jaar bekend is. Hoeveel bugs (exploits) gevonden in Windows 8.x blijken ook niet in Windows 7 of zelfs XP te zitten?

[Armin]

Waarom is IIS niet vatbaar voor de bug. Dacht dat die ook OpenSSL gebruikt, maar blijkbaar niet?


Microsoft gebruikt - uiteraard - de eigen SChannel bibliotheek.
SChannel juist de historische grote concurent van OpenSSL.

[Anoniem: 578672]

@SunnieNL
Tja met zulke logica krijg ik ook altijd gelijk

Een vals dillema en bewijs vanuit ontoegankelijkheid.

[The Zep Man]

Aanvallers kunnen met deze bug de private keys van de SSL certificaten stelen.

En zie ook hier een reden om server-side private keys op te slaan in een hardware security module.

[Lizard]

Dat helpt m.i. ook niet? Aangezien ze het geheugen waar de private key staat kunnen uitlezen. Dus niet de locatie op de disk. De webserver zal tijdens normaal gebruik de private key gewoon in het geheugen hebben staan.

[Goderic]

Dat heb je niet met een hardware security module, anders zou die nogal nutteloos zijn. De key zin in je hardware en komt er nooit ofte nimmer uit, zelfs als je de hardware fysiek in handen hebt kun je niet aan de key geraken (tenzij er natuurlijk bugs in zitten of je de NSA bent met een supergeavanceerd lab).

[purrple]

dat is nogal wat dan.. en als ik het artikel mag geloven, dan kan je als eindgebruiker eigenlijk nog niks doen ook. Zolang een site dit niet patched, heeft het eigenlijk ook geen nut om je wachtwoord te wijzigen

[piderman]

Hoe de bug ongeveer werkt:

OpenSSL ondersteunt een "heartbeat" functie waarbij je wat loze data kan sturen en de server stuurt deze dan terug, om de verbinding open te houden. Je geeft daarbij aan hoeveel data je opstuurt. Dit wordt/werd echter niet gecontroleerd tegen hoeveel data je daadwerkelijk opstuurt.

Je kunt dus tegen de server zeggen "ik ga 64k aan data sturen", vervolgens slechts 1 byte sturen, en de server stuurt je vervolgens wel 64k aan data terug: die ene byte, plus de 64k (min 1 byte) die erachteraan kwamen in het geheugen. Dit is dus willekeurige data in het geheugen van de server!

Omdat OpenSSL zijn eigen data meestal bij elkaar heeft staan is er dus ook een hoge kans dat bij de willekeurige data private keys zitten, maar het kunnen net zo goed email adressen en wachtwoorden zijn. Een flink serieuze bug dus.

[robvanwijk]

Puur uit nieuwsgierigheid: waarom stuur je überhaupt data; een leeg pakketje houdt de verbinding toch ook open?

[EnnaN]

Goeie vraag an sich, maar het gaat er volgens mij niet om dat je een 'verbinding open houdt', het gaat er om dat je je "orginele pakketje" terug gaat krijgen. Ass je liegt over de size dan krijg je dus meer (buffer overread) terug.

Ik neem aan -maar dat kon ik zo snel niet vinden- dat je een valide pakketje moet sturen, en dat een pakketje zonder payload al eerder tegen wordt gehouden. Dat zou sowieso een invalid request zijn.

Met een aanwezige, maar kleine, payload stuur je voor zover ik weet een prima valide request, alleen de metadata (hoe groot die payload is) klopt niet: met alle geheugen-'uitlees'-gevolgen van dien.

[robvanwijk]

Wat jij beschrijft is waar het precies fout gaat en hoe de bug werkt. Maar het beantwoord niet de vraag waarom ik mijn "originele pakketje" (nou ja, strikt genomen is het niet exact hetzelfde pakketje, maar het bevat dezelfde payload data) terug zou willen krijgen.

Als ik iets terug krijg (desnoods een leeg pakketje) dan weet ik dat de server nog up is, dat de verbinding nog werkt en (impliciet) dat eventuele time-outs gereset zijn. Het is me echter nog steeds niet duidelijk waar die payload goed voor zou moeten zijn...?

[EnnaN]

Ah, zo, ik dacht dat je nog een extra byte aan data wou kunnen krijgen door het request te doen zonder de payload

Het lullige antwoord zou zijn: je moet een payload omdat het in de RFC staat, maar daar hebben we niet zoveel aan.

ALs ik deze link goed begrijp is het een effect van de ondersteuning van DTLS, maar daar weet ik niet zoveel van, dus het begrijpen hiervan laat ik als een excersize to the reader ;P

https://news.ycombinator.com/item?id=7558227

[Booster]

Update je je OpenSSL package op Ubuntu en Debian, let dan goed op: het versienummer van OpenSSL die je kunt nakijken met

openssl version -a

geeft niet persee "1.0.1g" weer. De uitleg: http://serverfault.com/qu...check-the-openssl-version

Samenvatting: het versienummer kan afwijken omdat Ubuntu en Debian changes vaak backporten naar een oude versie, en daarbij wordt het versienummer niet verhoogd.

[Reactie gewijzigd door Booster op 25 juli 2024 05:22]

[m4ikel]

Voor volk op CentOS zoals ik:

So the official update is now out. Details below copied from the CentOS-Announce mailing list.

If you run `rpm -q openssl` and it reports version 1.0.1e and less than 1.0.1e-16.el6_5.4.0.1 then you are currently vulnerable to this problem. If it reports 1.0.1e-16.el6_5.4.0.1.centos then you have the temporary version issued before Redhat issued their official fix. If you have 1.0.1e-16.el6_5.7 or higher then you have the official fixed version. If you are not running the fixed version then you should update as soon as possible by running `yum update`. If no newer version is offered then you might try running `yum clean metadata` then retry. If nothing shows up still then you may need to wait for your current mirror to catch up and replicate the update.

https://www.centos.org/forums/viewtopic.php?f=9&t=45814

[Reactie gewijzigd door m4ikel op 25 juli 2024 05:22]

[raphidae]

Wat ik mis is het feit dat dit ook OMGEKEERD werkt.

Als je een client app hebt die gelinkt is met OpenSSL 1.0.1/2 dan kan een kwaadwillende server ook het geheugen uitlezen van de client. Dat is niet OS specifiek,

Dus het gaat dan om je TrueCrypt/Bitlocker keys, passwords, gevoelige data. Als je iets met OpenSSL draait (wat kan zonder dat je het weet) dan kan potentieel alles wat de laatste 2 jaar (en iig de laatste week) in het geheugen van je computer heeft gezeten in handen van derden terecht zijn gekomen...

[f.v.b]

Onder Linux kan je niet zomaar en willekeurig stuk geheugen adresseren. Je krijgt een Segmentation Violation zodra je buiten je eigen adresruimte een stuk geheugen probeert uit te lezen.

Of heb je een link voor me waar je bewering onderbouwd wordt? Ik heb me niet helemaal ingelezen in het originele probleem.

[Radiant]

Dan kan je nog steeds in de eigen adresruimte gaan zitten lezen, waar bij browsers met wachtwoordsystemen enzo genoeg leuks mee uit te halen is.

[Armin]

Nee, de 'eigen' adresruimte is die van het process, niet de client.

Browsers hebben vaak expliciet segmentatie in verschillende processen als bescherming tegen drive-by aanvallen. Internet Explorer heeft dat al sinds IE 7, en in IE 10+ zelfs tot nieuwe hoogten gebracht indien draaiende op Windows 8. De renderer draait dan in een apart en optioneel zelfs gesandboxed process.

[SlaadjeBla]

En firmware voor apparaten. Routers, smart TV's. En die worden niet vaak ge-update.
DD-WRT bevat bijvoorbeeld ook een kwetsbare OpenSSL versie (1.0.1e)

[Marcks]

Niet alle versies van DD-WRT zijn kwetsbaar, veel gebruiken immers nog een oudere OpenSSL. Het gaat om buildnummers van ongeveer 19000 tot en met 23882. Omdat de gangbare commands als 'openssl version' niet altijd lekker werken op zo'n minimaal systeem kun je voor de zekerheid het versienummer van libssl.so controleren in /usr/lib.

[Armin]

Dus het gaat dan om je TrueCrypt/Bitlocker keys, passwords, gevoelige data

NEE!

Het kan het geheugen van de client-process uitlezen, niet de hele client.

Aangezien de client in een sandbox draait zal de schade heel beperkt zijn. Op Chrome heeft elke tab bijvoorbeeld zijn eigen process. Bij Internet Explorer draait de zaak zelfs in een extra app-chamber als je enhanced protected mode aan hebt staan.

[RedPixel]

Hier kun je testen of je kwetsbaar bent: http://filippo.io/Heartbleed/#tweakers.net

Overigens:

• tweakers.net IS VULNERABLE.
• rabobank.nl seems not affected
• abnamro.nl seems not affected!
• snsbank.nl seems not affected!
• ing.nl seems not affected!
• asnbank.nl seems not affected!

Hebben de banken geüpdate of waren ze niet kwetsbaar?

[Maurits van Baerle]

Ik denk dat je voor de zekerheid de echte banking portal moet controleren en niet de algemene voorpagina. Ik kan me zomaar voorstellen dat www.ing.nl op andere machines en andere server software draait (en misschien wel op een hele andere lokatie) dan de feitelijke banking portal mijn.ing.nl.

Misschien niet, misschien wel, voor de zekerheid moet je hem dus de volledige url voeren en niet de voorpagina.

[Lennie]

Dat is goed gedacht. Dat is namelijk ook zo.

Nog mooier, het IP-adres van www.ing.nl wijst naar Akamai, dus die website draait niet eens bij hun (!).

[freaky]

Zou me persoonlijk ook meer zorgen maken om mijn.ing.nl dan ing.nl of www.ing.nl, maar ieder z'n ding.

~ $ dig +short ing.nl www.ing.nl mijn.ing.nl
172.229.199.37
www.ing.nl.edgekey.net.
e7225.ksd.akamaiedge.net.
2.21.7.37
145.221.194.139

freaky@flaptoppy ~ $ whois 145.221.194.139

<stripped>

inetnum: 145.221.0.0 - 145.221.255.255
netname: NL-ING-GROUP
descr: ING Groep
descr: Amsterdam
country: NL
admin-c: CA3305-RIPE
tech-c: CA3305-RIPE
tech-c: MVDV48-RIPE
tech-c: ROBR1-RIPE
status: ASSIGNED PI
mnt-by: ING-MNT
source: RIPE # Filtered

<lost more stripped>

[Armin]

Top 100 sites die kwestbaar zijn:

https://github.com/musalb...t/blob/master/top1000.txt

Uiteraard is de lijst aan verandering onderhevigd aangezien iedereen druk aan het pacthen is (hoop ik).

Schade blijkt overigens wel mee te vallen. Er werd in eerste instantie iets geroepen van potentieel 2/3 van het web, maar dat blijkt dus te hoog. Hier een betere schatting:

http://news.netcraft.com/...le-to-heartbleed-bug.html

17% van de websites ...

Het verschil is hierom: However, not all of these servers are running an HTTPS service, nor are they all running vulnerable versions of OpenSSL with heartbeats enabled.

[Spykie]

Klopt helemaal!
Rabobank heeft hun bankieren.rabobank.nl online banking omgeving inmiddels gepatched.

[[Yellow]]

Debian stable gebruikt geen openSSL 1.0.1 maar de oudere 0.9.8k die niet kwetsbaar is voor deze aanval (alléén de 1.0.1 branch is kwetsbaar, rest niet).

Ik ga ervan uit dat de systeembeheerders van banken het advies opvolgen om alleen de stable edities te gebruiken. Goed advies blijkt nu maar weer eens!

[JPDeckers]

Ahums, Debian OLDstable gebuikte de 0.9.8 branch. Stable (wheezy) bevat altijd al 1.0.1

[stable:~] cat /etc/debian_version && openssl version
7.4
OpenSSL 1.0.1e 11 Feb 2013

vs

[oldstable:~] cat /etc/debian_version && openssl version
6.0.9
OpenSSL 0.9.8o 01 Jun 2010

Dus.. Alleens stable gebruiken is nu juist kwetsbaar.

PS: na upgraden ook je services herstarten die de oude libs gebruiken.
lsof -n | grep ssl | grep DEL om te vinden welke dat waren

[RedPixel]

én een SSL-certivicaat uitgeven (reissue), en de oude opschorten (revoke)!

[airell]

Ik denk dat de banken geen webservers hebben staan die de OpenSSL libaries gebruiken voor hun SSL verbindingen. OpenSSL 1.0.1g is pas sinds gisteren uit. Ik denk niet dat de webserver leveranciers deze al ingebakken hebben én dat de banken die jij noemt die ook al hebben doorgevoerd.

[Reactie gewijzigd door airell op 25 juli 2024 05:22]

[abeker]

Of ze gebruiken een oudere versie waar deze lek nog niet in zat

In ieder geval lijken de meeste websites van de Nederlandse banken niet getroffen. De enige bank die ik tegen ben gekomen die wel kwetsbaar is, is Triodos. Het bankieren via bankieren.triodos.nl wordt weliswaar niet getroffen door deze bug, maar triodos.nl zelf is wel kwetsbaar. Bij het openen van een nieuwe rekening zou dus oa je BSN achterhaald kunnen worden!

[rvvliet]

Ik zie bij Triodos not affected, blijkbaar al gefixed.

[abeker]

idd... en tweakers.net is nu ook niet meer affected.

[Armin]

Of ze gebruiken een oudere versie waar deze lek nog niet in zat

Of ze gebruikten geen OpenSSL, maar een concurerend SSL/TLS pakket.

Of ze hadden deze optionele OpenSSL feature uit staan.

Of ze hebben een speciale aangepaste versie.

Uberhaupt draaien banken zelden een standaard configuratie voor hun internet-verkeer.

[databeestje]

Ik kreeg net op www.rabobank.nl wel een Vulnerable met content.

Het lijkt erop dat 1 van de webservers uit de pool van de loadbalancer misschien niet bijgewerkt is. Wellicht een nieuwe(re) server in de pool.

[RoestVrijStaal]

Neemt niet weg dat je alsnog vatbaar bent als je SSH-daemon van je server de OpenSSL-library gebruikt.
En dat doen de meesten die standaard op de populaire distro's worden geïnstalleerd

[Overv]

Dat is niet waar, SSH gebruikt de code waar deze bug in zit niet.

[RoestVrijStaal]

Oeps, je hebt inderdaad gelijk. Ik had blijkbaar nog niet genoeg koffie op

[RoestVrijStaal]

Kleine kanttekening hier.

Doe eens

apt-cache show libssl1.0.0

of

apt-cache rdepends libssl1.0.0

Zoals je ziet heeft OpenSSH blijkbaar OpenSSL als dependency.

Ik vond het vanochtend al zo raar dat libssl1.0.0 op een server van een klant stond geïnstalleerd. Een kwartier geleden begreep ik waarom.

Dus ja, over het algemeen is SSH veilig. MAAR niet als je openssh-server en/of openssh-client voor je SSH verbindingen gebruikt.

Edit: gnagnagna Tweakers.net heeft geen [code]-tag.

[Reactie gewijzigd door RoestVrijStaal op 25 juli 2024 05:22]

[Overv]

Nee, je hebt me verkeerd begrepen. Er zijn misschien wel applicaties als openssh-server die OpenSSL gebruiken, maar het deel van de library dat deze bug bevatte (TLS) gebruiken ze niet. Zo gebruikt bijvoorbeeld ook Chrome op Android OpenSSL, maar met de heartbeat functionaliteit uit, en was daardoor ook niet kwetsbaar.

[Reactie gewijzigd door Overv op 25 juli 2024 05:22]

[hackerhater]

** never mind **
Bedenk me net dat je niet buiten je eigen ram kan komen.

[MadEgg]

Leuke reclame, maar maakt Hiawatha dan geen gebruik van OpenSSL?

edit:

Ik zie net dat Hiawatha sinds versie 8.0 overgestapt is van OpenSSL naar PolarSSL dus dan zullen ze inderdaad buiten schot blijven. Wellicht leuk om zoiets te vermelden in plaats van puur de reclameslogan die jij neerzette.

[Reactie gewijzigd door MadEgg op 25 juli 2024 05:22]

[_eXistenZ_]

Voor degenen die Debian stable draaien (7.4): zojuist krijg ik een hotfix binnen voor openSSL en libssl via apt-get (1.0.1e-2+deb7u4 wordt vervangen voor 1.0.1e-2+deb7u5 met daarin de fix)

Ook Ubuntu 13.10, 12.10 en 12.04 zijn getroffen!

Dus: sudo apt-get update && sudo apt-get upgrade!

The following packages will be upgraded:
libssl1.0.0 openssl
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,957 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://security.debian.org/ wheezy/updates/main libssl1.0.0 amd64 1.0.1e-2+deb7u5 [1,257 kB]
Get:2 http://security.debian.org/ wheezy/updates/main openssl amd64 1.0.1e-2+deb7u5 [700 kB]

[Reactie gewijzigd door _eXistenZ_ op 25 juli 2024 05:22]

[JointFillah]

Ubuntu 12.04 (TLS) is niet getroffen want draait nog een versie uit 2012

Let op: Ubuntu 12.04 LTS is _wel_ getroffen!
Hoewel openssl version suggereert dat de oude versie draait, bevatten de ubuntu packages veel nieuwere code.

Zie http://www.ubuntu.com/usn/usn-2165-1/

en ook Reactie van Booster

[Reactie gewijzigd door JointFillah op 25 juli 2024 05:22]

[_eXistenZ_]

Ah ja, ik zie em, pas m'n originele bericht aan.

[Reactie gewijzigd door _eXistenZ_ op 25 juli 2024 05:22]

[DennusB]

Er is een script beschikbaar om de output te zien : http://s3.jspenguin.org/ssltest.py ! Hier mee krijg je dus die geheugen dump te zien.
Best bizar, je ziet echt alles langskomen!

[Henk Poley]

Is er ook al ergens een test script op client software te checken?

[freaky]

hexedit /dev/mem

is makkelijker/sneller en waarschijnlijk vollediger - of /dev/kmem afhankelijk van je wensen.

[Eloy]

Huh? Dat is voor je eigen RAM. Met het Python script lees je het geheugen van de server uit. En daar heb ik bij een bepaald bedrijf uit de USA met een paars logo al wat login pogingen voorbij zien komen.

[hackerhater]

Mensen opletten !
Bij de updates heb ik ook updates van OpenSSH-Server gezien. Waarschijnlijk gebruikten ze dezelfde lib!
Hou er rekening mee dat je wellicht je ssh-sleutels moet revoken.

[brutus]

Die zag ik idd ook Ubuntu Server 12.04.4 LTS, echter dat lijkt meer toeval :
* SECURITY UPDATE: failure to check SSHFP records if server presents a
certificate
- debian/patches/CVE-2014-2653.patch: fix logic in sshconnect.c.
- CVE-2014-2653

Dat heeft voor zover ik kan inschatten geen betrekking op de openssl bug:
* SECURITY UPDATE: memory disclosure in TLS heartbeat extension
- debian/patches/CVE-2014-0160.patch: use correct lengths in
ssl/d1_both.c, ssl/t1_lib.c.
- CVE-2014-0160