Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

×

Help jij Tweakers Website van het Jaar te worden?

Tweakers is genomineerd voor beste website 2014 in de categorieŽn Nieuws & Informatie, Community en Vergelijking. Stem nu en maak kans op mooie prijzen!

Door , , reacties: 198, views: 52.331 •
Submitter: soczol

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)

Reactiefilter:-11980195+1148+239+35
Tweakers.net zelf is trouwens op dit moment ook nog steeds kwetsbaar, inclusief de mogelijkheid tot het achterhalen van de prive-sleutel van het SSL-certificaat en andere privegegevens.

[Reactie gewijzigd door kunnen op 8 april 2014 07:51]

Kan je daar wat uitleg bij geven? Wanneer? Hoe? etc ...
http://filippo.io/Heartbleed om te kijken of je site kwetsbaar is
Toch ben ik altijd bang om 'mijn' website adres in te vullen bij een voor mij onbekende website... (Nee, ik zeg niet dat deze site nep is, maar ik weet niet hoe ik dit moet verifiŽren!)

Net als die creditcard-test websites die je dus NOOIT moet bezoeken.
Als je dit niet bij een service wil testen (wat ik me goed voor kan stellen) kan je hier een script downloaden waarmee je het zelf kan testen: http://s3.jspenguin.org/ssltest.py

Niet mijn script, maar kwam het tegen op twitter.
alle geteste sites worden gelogged op http://filippo.io/Heartbleed wat ook te zien is in de code op: https://github.com/FiloSottile/Heartbleed

uiteraard kan ieder willekeurig persoon jouw site daar invullen, dus om je kop in het zand te steken door het niet zelf te willen gebruiken lijkt me een vreemde gedachte
Kan, maar misschien wil ik niet bekend zijn in een log of mijn site wel of niet dit lek bevat voordat ik het gedicht heb? Geen idee wie wat doet met die info.

Ziet het als security by obscurity.
sudo apt-get update + sudo apt-get upgrade doet op iedere linux box de trick. 2 minuten werk om je webservertje weer veilig te maken. Kan me voorstellen dat in de professionele omgeving men e.e.a. niet klakkeloos gaat upgraden, maar voor de hobby'isten een easy fix!
Maar daarmee ben je nog steeds niet veilig:
  • je moet al je certs opnieuw genereren en
  • de processen die een certificaat gebruiken moet herstarten
Aan wat voor services moet ik dan zoal denken voor een gemiddelde LEMP/LAMP stack? Php, nginx/apache, ssh?
Voor de meeste servers ja.
Alles wat een certificaat gebruikt. (dit kan dus ook sshd zijn!)
Als iemand je private key al gestolen heeft, kan hij alsnog je versleutelde communicatie ontsleutelen! Je moet dus ook een nieuwe sleutel aanmaken, dus een re-issue aanvragen bij je ssl-boer, en daarna de oude revoken!
Dat werkt alleen voor debian achtigen, niet voor de andere soorten.
Maar je bent er daarmee nog niet, zoals highmastdon ook al opmerkt
Vreemd. ik tik dat hier in op mijn Archlinux box en ik krijg command not found.

Oh, je bedoelt op elke Debian-based distro ... :)
ELKE ? Houd je zeker geen rekening met de mogelijkheid dat men geen Debian based distro gebruikt ?
http://www.debian.org/doc...-howto/ch-distros.en.html

Ik heb wel wat teweeg gebracht ;), inderdaad niet elke, sorry, sorry 8)7

[Reactie gewijzigd door RatedR op 10 april 2014 10:52]

Niet iedere linux box, "sudo yum update" geldt voor redhat gebaseerde systemen (centOS, fedora etc)
Ik heb een server met de bug, maar als ik de test herhaalde keren doe komt het er de ene keer goed uit, de andere keer niet. Herhaald testen is dus aan te raden.
Eigen server of load balanced omgeving?
Ik lees op die heartbleed test site ook:
"There are load (?) issues causing FALSE NEGATIVES."
Een Nederlandse kloon van het Go-script, zonder "load issues": https://www.hostinginnede...heartbleed-lek-openssl-39
Normaal zou ik zeggen het is github, maak gewoon een clone van de repo:
git clone https://github.com/FiloSottile/Heartbleed heartbleed
cd heartbleed
Maar zie net dat het is gemaakt in Go, niet iedereen weet hoe dat moet of heeft het geinstalleerd.

Dus in dit geval is het Python script waarschijnlijk handiger.
Je kunt em bekijken op Github he ;)
En wie zegt dat de code die in github staat, dezelfde is als die op die site draait?
Dan draai je em zelf even, opgelost.
Eh, als je daar bang voor bent moet je wellicht geen site hebben?
Een site is op internet voor iedereen te bereiken, dus... Als iemand echt kwaad wil zijn er veel makkelijkere methodes om sites te indexeren. Daar hoef je echt niet zoiets voor op te gaan zetten.
Wel als je als hacker net achter dit issue bent gekomen en er snel misbruik van wilt maken. Dan kan je via deze site zeer snel achter alle sites komen die dit lek bevatten!

Mensen geven je hun lekken (alleen heartbleed hopelijk) aan op een silveren dienblad!
Aan de andere kant hebben diegenen die hun site testen het waarschijnlijk ook kort daarna gefixed, dus moet je er heel snel bij zijn.
Credit card website's geef je daadwerkelijk geheime informatie, namelijk je credit card nummer. Een website URL is niet echt geheim ofzo ;)
Een aantal overheidsites zijn ook kwetsbaar. Zou even niet meer inloggen met DigiD!
Digid staat op zichzelf, ook als je via een andere site inlogt, en digid.nl is niet kwetsbaar volgens de tool.
Misschien zou Tweakers een rondje willen doen bij de banken om uit te vinden hoe ze hiermee omgaan?
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
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 :/
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 8 april 2014 08:24]

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...
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)
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.
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.
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.
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.
Nou ja. Je zou toch verwachten dat bij dit soort security-critical libraries er regelmatig een security-audit plaatsvindt.
Dat is precies wat hier nu gebeurt is en daar uit is gekomen dat de OpenSSL code van een 2012 toch een bug bevatte.
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 ?
Zou me persoonlijk niks verwonderen.
Ik zie het eerder als niet leiden tot het sneller vinden van een bug. Maar volgens mij is de bugfix er toch snel gekomen
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.
@SunnieNL
Tja met zulke logica krijg ik ook altijd gelijk ;)

Een vals dillema en bewijs vanuit ontoegankelijkheid.
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?
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.
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.
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.
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).
Ach... en dus worden door banken allerlei eisen aan de gebruikers gesteld zodat de banken bij fraude evt. de schade niet hoeven te vergoeden, maar zelf hebben ze het ook niet 100% voor elkaar?
Ik snap je niet helemaal.
Waar staat dat ze het niet 100% voor elkaar hebben?
  • Er is een bug gevonden in OpenSSL.
  • Er is een patch voor gemaakt.
  • De ING en Rabobank zijn veilig.
Trouwens, de eisen die aan een consument gesteld worden zijn niet heel vreemd of exotisch.
En hun betaalautomaten draaien nog op Windows XP. :-)
Daar deze niet blind op het internet aangesloten lijken te zijn zou dit geen groot probleem op mogen leveren.

Ook verwacht ik (hoewel ik het niet zeker weet) dat deze wel eens XP Embedded zouden kunnen draaien. Deze versie van XP heeft een houdbaarheidsdatum van 12-1-2016 (link)
Dat zou ik zo even niet te snel aannemen. Ik heb gewerkt aan een systeem bij de overheid die een security audit kreeg en management en de IT afdeling gaven aan dat belangrijke systemen voor de infrastructuur niet bij het internet konden. Maar de praktijk wat toch even anders, wat ik toen heb aangetoond.

Het is zelfs zoiets simpels dat beheerders ergens een eigen proxy servertje hebben staan om zo updates voor software of backupjes over te hevelen. Of dat een paar ip's in een segment wel rechten hebben om het internet op te gaan "voor als de beheerder in die iprange zit om te kunnen werken".

Ik zeg niet dat het daarmee ook gelijk openstaat maar er hoeft maar een klein foutje gemaakt te worden of een slim virus te zijn wat bepaalde proxy poorten scant en daar gaat je security beleid.
In het orginele bericht (dus voor de update) stond dat de Nederlandse banken gebruik zouden maken van de getroffen versie van OpenSSL (dus niet geupdated waren).
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)
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?
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?
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.
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.
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.
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 wwwhizz op 8 april 2014 08:44]

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.
openssl 0.9.8 is niet kwetsbaar
Gelukkig de versie die ik draai ;)
Kostbaar grapje als iedereen die openssl draait een nieuw certificaat moet aanvragen.
Iedereen die een kwetsbare versie draait of heeft gedraaid en zijn private key/certificaat belangrijk genoeg vindt.
Uren technisch wel. Meeste CA's doen gratis een reissue echter.
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.
Vertel ons wat -_-'
Hier gaat ons vrije weekend voor alle clients op onze servers weer veilig zijn.
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.
Waar staat vermeldt dat de grote banken OpenSSL gebruiken??

De bug is ernstig, maar betreft alleen (voor zover ik weet) OpenSSL. Ik neem aan dat de meeste banken voor hun (naar buiten gerichte) SSL afhandeling dedicated hardware crypto boxen gebruiken.
De bug die al twee jaar in TLS1.2/heartbeat zit.. Mooi op tijd opgemerkt dan. Heeft het ook niet zo'n zin om 'een paar dagen van internet weg te blijven', want de kans dat dit gat de afgelopen twee jaar gebruikt is, is natuurlijk vrij groot. Met andere woorden; het kwaad is al geschied.
Dat de bug er al twee jaar in zit betekent niet dat deze al 2 jaar ontdekt is.
Niet ontdekt door wie? Het zal niet de eerste keer zijn dat een lek al een tijd actief misbruikt wordt voor het publiekelijk bekend wordt dat er Łberhaupt een lek is..
Bugs kun je pas oplossen wanneer je weet dat ze erin zitten.
Dat een cybercrimineel dat niet meldt is evident :+
Dat is duidelijk uiteraard, waar ik op doelde is dat misbruik van dit lek al enige tijd aan de gang kan zijn, dus dat het ook niet zoveel zin heeft om iemand te adviseren zich een paar dagen niet op internet te laten zien.
Met deze bekendmaking zijn echter wel meteen heel veel meer mensen op de hoogte van de bug, en zijn er daarmee ook meer die gaan pogen om er misbruik van te maken. De kans dat er daadwerkelijk misbruik van gemaakt wordt (en kan worden) is dus de komende dagen, wanneer wel al iedereen er van weet maar nog lang niet overal het probleem gerepareerd is.
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?
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 8 april 2014 08:43]

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!
Ik zie bij Triodos not affected, blijkbaar al gefixed.
idd... en tweakers.net is nu ook niet meer affected.
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.
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!
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
ťn een SSL-certivicaat uitgeven (reissue), en de oude opschorten (revoke)!
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 8 april 2014 09:40]

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 :X
Dat is niet waar, SSH gebruikt de code waar deze bug in zit niet.
Oeps, je hebt inderdaad gelijk. Ik had blijkbaar nog niet genoeg koffie op |:(
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 8 april 2014 22:05]

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 9 april 2014 17:57]

** never mind **
Bedenk me net dat je niet buiten je eigen ram kan komen.
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.
Klopt helemaal!
Rabobank heeft hun bankieren.rabobank.nl online banking omgeving inmiddels gepatched.
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 (!).
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>
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.
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.
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...
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)
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.
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.
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.
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.
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.
Het CVE nummer dat wordt vermeld is onjuist, het juiste nummer is: CVE-2014-0160.

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneAsus

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013