Heartbleed: zware vulnerability in OpenSSL 1.0.1 t/m 1.0.1f

[Booster]

OpenSSL 1.0.1 t/m 1.0.1f vulnerable, upgrade asap naar 1.0.1g(+)

Vanavond is bekend gemaakt dat een reeks recente en veelgebruikte OpenSSL-versies een zeer zware vulnerability bevatten, waardoor o.a. memory van de machine uitgelezen kan worden.

Wat is de impact?

Informatie die potentieel door deze bug zou kunnen lekken:

• Private keys
• SSL session keys, session cookies
• Informatie die normaliter door SSL encrypted zou zijn geweest
• Andere informatie uit memory, bv: source code

When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server.

Deze fout zit al in OpenSSL sinds eind 2011:

Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

Mogelijk dat kwaadwillenden al langer op de hoogte waren van dit probleem, en er dus stilletjes misbruik van hebben gemaakt. Er worden bij misbruik geen sporen achtergelaten:

Exploitation of this bug leaves no traces of anything abnormal happening to the logs.

Ben ik vulnerable?

Controleer je OpenSSL-versie

Je kunt dit op (sommige!) systemen zien met:

openssl version -a

Als hierbij geen versie-letter te zien is (maar enkel "OpenSSL 1.0.1"), check dan je package management tool.

Ik heb hier een thread gemaakt om snel te verzamelen hoe dit op andere Linux distributies te zien is:
http://serverfault.com/qu...check-the-openssl-version

Testen op kwetsbaarheid

De website http://filippo.io/Heartbleed/ wordt genoemd als een tool om op de kwetsbaarheid te testen. Het is niet bekend hoe betrouwbaar deze test momenteel is.

Er is ook een Python-script waarmee de kwetsbaarheid vanaf de cli getest kan worden: http://foxitsecurity.file...04/fox_heartbleedtest.zip

Hoe op te lossen?

1. Upgrade je OpenSSL naar 1.0.1g of hoger.
2. Revoke de certificaten die je in gebruik had.
   (lees ook de post van deadinspace over waarom dit heel belangrijk is)
3. Genereer nieuwe certificaten op basis van nieuwe keys.

Patches voor vulnerable versies van o.a. Debian, Ubuntu, FreeBSD en RedHat zijn reeds vrijgegeven. Zie ook onderaan deze post voor enkele verwijzingen.

Check na de upgrade of er nog oude versies van OpenSSL resident zijn:

lsof -n | grep ssl | grep DEL

Wat als je niet kunt upgraden?

Even though the actual code fix may appear trivial, OpenSSL team is the expert in fixing it properly so latest fixed version 1.0.1g or newer should be used. If this is not possible software developers can recompile OpenSSL with the handshake removed from the code by compile time option -DOPENSSL_NO_HEARTBEATS.

Meer informatie

Er is een FAQ opgesteld op http://heartbleed.com/

Samenvatting

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop communications, steal data directly from the services and users and to impersonate services and users.

Hoe werkt de bug, technisch gezien?

Meer uitleg op http://blog.existentializ...enssl-heartbleed-bug.html
En piderman in 'nieuws: Bug OpenSSL maakt onderscheppen privacygevoelige gegevens mogelijk'

Belangrijke linkjes:

FAQ: http://heartbleed.com/
OpenSSL advisory: https://www.openssl.org/news/secadv_20140407.txt

Nieuws/vendor advisories

FoxIT liveblog: http://blog.fox-it.com/20...heartbleed-bug-live-blog/

Debian: http://www.debian.org/security/2014/dsa-2896
Ubuntu: http://www.ubuntu.com/usn/usn-2165-1/
RedHat: https://access.redhat.com/security/cve/CVE-2014-0160

Voor gebruikers van Tor: https://blog.torproject.org/blog/openssl-bug-cve-2014-0160

Bugtrackers o.a.

OpenSSL git commit: http://git.openssl.org/gi...it;a=commitdiff;h=96db902

Debian: https://security-tracker.debian.org/tracker/CVE-2014-0160 en https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743883
Ubuntu: https://launchpad.net/ubu...openssl/1.0.1-4ubuntu5.12
RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1084875
FreeBSD: http://svnweb.freebsd.org...=revision&revision=350548

[ Voor 74% gewijzigd door Booster op 08-04-2014 19:45 ]

[bouvrie]

In de hoop op een snelle oplossing, heb ik een aantal links (waar hopelijk oplossingen/workarounds op gepost worden)

Deze zijn:

• Synology Forum, voor mensen met bijv. een Synology DiskStation
• cPanel forum, voor mensen met een cPanel omgeving...

[ Voor 17% gewijzigd door bouvrie op 08-04-2014 11:37 ]

[Booster]

Ik ben bang dat dit probleem ondanks de aandacht uiteindelijk toch nog aan een hoop beheerders en leken voorbij zal gaan, en daarom mogelijk nog jarenlang tot problemen kan blijven leiden. Denk bv aan gebruikers van Ubuntu 13.04 die de laatste versie uit hun repository hebben, maar daarmee wel vulnerable zijn. Maar ook access points en routers die over SSL beschikbaar zijn en waar nooit naar omgekeken wordt.

En wat te denken van de websites die niet -onmiddelijk- kunnen reageren met een fix? Zij zijn nu al een halve dag vulnerable en ik verwacht dat dat maximaal zal worden uitgebuit door attackers. Alle enigszinds belangrijke websites draaien SSL en zijn daarom een potentieel target voor attackers.

• Wie weet of DigiD vulnerable is/was voor deze attack?

Volgens @CryptoSjon is publeaks.nl o.a. vulnerable (geweest): source

[edit]
Enkele bekende websites die op dit moment nog vulnerable zijn, om een idee te geven van de scope:
• Yahoo (mail.yahoo.com, login.yahoo.com)
• LastPass
• api.dropbox.com
• OpenSSL.org
• FBI
• Stackoverflow
• imgur
• DuckDuckGo

[ Voor 12% gewijzigd door Booster op 08-04-2014 15:48 ]

[_eXistenZ_]

Alle nuttige informatie is te vinden op http://www.heartbleed.nl

[deadinspace]

Booster schreef op dinsdag 08 april 2014 @ 00:36:

Hoe op te lossen?

Upgrade je OpenSSL naar 1.0.1g of hoger én her-genereer al je keys.

Let op; nieuwe keys gebruiken an sich helpt niet. Het enige dat helpt is je oude keys onbruikbaar maken, dat is iets anders. Vooral in de context van x509.

Om HTTPS te nemen: het gevaar is dat iemand via deze kwetsbaarheid je private key van je x509 certificaat heeft buitgemaakt. Je kunt dan wel een nieuw certificaat aanvragen en installeren, maar de aanvaller die je (oude) private key heeft kan met je oude certificaat nog steeds een man-in-the-middle aanval uitvoeren. Je bezoekers zien geen probleem omdat beide certificaten (jouw nieuwe en de oude die de aanvaller gebruikt) allebei geldig zijn.

Het enige dat helpt is je oude certificaat revoken. Uiteraard heb je dan ook een nieuw certificaat nodig, maar het revoken van de oude is wat misbruik tegengaat.

Behalve dat revoken helemaal niet helpt omdat browsers complete apen zijn als het op revocation checks aankomt (meer info: klik, klik). Maargoed, misschien gaan browsers revocation wel beter checken naar aanleiding van dit akkefietje.

Booster schreef op dinsdag 08 april 2014 @ 10:35:
En wat te denken van de websites die niet -onmiddelijk- kunnen reageren met een fix? Zij zijn nu al een halve dag vulnerable ...

Kleine nuance: ze zijn al tot 2 jaar vulnerable

Uiteraard is het nu dringender omdat het publiek is, maar de kwetsbaarheid bestaat al langer. En is mogelijk ook al langer misbruikt.

_eXistenZ_ schreef op dinsdag 08 april 2014 @ 16:12:
Alle nuttige informatie is te vinden op http://www.heartbleed.nl

Link dan naar http://heartbleed.com/, die heeft veel meer informatie en is geen schaamteloze poging om met ads geld te verdienen

[DiedX]

Vanuit Juniper heb ik te horen gekregen dat hun SIRT aan de slag is hiermee. In ieder geval 1 SSL-VPN appliance is vulnerable.

[Booster]

deadinspace schreef op dinsdag 08 april 2014 @ 17:00:
Het enige dat helpt is je oude certificaat revoken. Uiteraard heb je dan ook een nieuw certificaat nodig, maar het revoken van de oude is wat misbruik tegengaat.

True. Zie update

Behalve dat revoken helemaal niet helpt omdat browsers complete apen zijn als het op revocation checks aankomt [...]

Agreed. Maar laten we niet vergeten dat we in "revoking certificates doesn’t really work" het "revoking" best weg kunnen laten. Het hele certificatensysteem zoals we het nu kennen is ruk en flawed.

Overigens is men in ieder geval bij Mozilla wel bezig met wat verbeteringen: https://wiki.mozilla.org/CA:ImprovingRevocation - een aantal zaken zitten al in recente Fx versies.

Kleine nuance: ze zijn al tot 2 jaar vulnerable

Natuurlijk, maar de impact zal nu nog heel veel groter worden. Voorheen mogelijk al bekend en misbruikt, maar nu kan iedereen, overal, en altijd, even kijken of er wat info lekt.

[ Voor 16% gewijzigd door Booster op 08-04-2014 18:02 ]

[deadinspace]

Booster schreef op dinsdag 08 april 2014 @ 17:54:
Agreed. Maar laten we niet vergeten dat we in "revoking certificates doesn’t really work" het "revoking" best weg kunnen laten. Het hele certificatensysteem zoals we het nu kennen is ruk en flawed.

Heh. Daar moet ik het helaas hartgrondig mee eens zijn

Overigens is men in ieder geval bij Mozilla wel bezig met wat verbeteringen: https://wiki.mozilla.org/CA:ImprovingRevocation - een aantal zaken zitten al in recente Fx versies.

Ah, dat is altijd mooi om te horen.

In één van de links die ik eerder gaf staat trouwens nog wel een interessante strategie voor revocation: Gebruik subcertificaten met een korte geldigheidsduur (bv 1 dag) die je automatisch genereert en installeert. Misbruik is dan maximaal 1 dag mogelijk, geen CRL e.d. nodig.

Nogal bewerkelijk om op te zetten, maar voor iets als dit was het bijzonder effectief geweest.

[Biersteker]

Dat dit nog niet door yahoo is gefixed is eigenlijk schandalig:


Damn, foxit doet het niet veel beter. Waarom zou je blurren als je filenames gokbaar zijn.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 38% gewijzigd door Biersteker op 08-04-2014 18:24 ]

[wootah]

Ik heb inmiddels mijn eigen server op ubuntu 12.04 gepatched. Helaas geeft de check nog steeds terug dat mijn server vulnerable is
Zelfs na een herstart van het systeem is het er niet beter op geworden.
Toen had ik maar apart openssl van deze launchpad geïnstalleerd: https://launchpad.net/~ge...ve/openssl-heartbleed-fix zelfde verhaal

Iemand een idee waarom hij nog steeds als vulnerable bestempeld word? Of moet ik eerst nieuwe certificaten gaan aanvragen en de oude revoken voordat die status verdwijnt?

trouwens, je kan hier ook testen of je site vatbaar is: https://www.ssllabs.com/ssltest/index.html
ssllabs is toch altijd wel betrouwbaar met dat soort dingen

[ Voor 13% gewijzigd door wootah op 08-04-2014 18:37 ]

[Bastien]

Heb hetzelfde met een installatie op Debian Wheezy. Volgens Debian moet het met de gebruikte versie nu opgelost zijn maar de sites blijven inderdaad aangeven dat de servers vulnerable zijn. Weet niet of de sites kunnen zien welke versie er gebruikt wordt, Debian loopt nog op 1.0.1e-2+deb7u6 maar is wel gepatched. Als alleen daar naar gekeken wordt is het een beetje knullig.

En anders hebben we nog een uitdaging vanavond.

[Booster]

Er kunnen een paar dingen aan de hand zijn:

1. Na de nieuwe installatie van OpenSSL zijn de diensten die gebruik maken van die library nog niet opnieuw opgestart.
   
   Dan gebruiken ze een versie van OpenSSL die nog in het geheugen staat. Herstart in ieder geval die diensten. Je kunt dan denken aan Apache, Postfix, Exim, etc.
   
   Soms zijn oude versies van OpenSSL te detecteren met:
   

   lsof -n | grep ssl | grep DEL

2. Sommige websites waarmee op de kwetsbaarheid getest kan worden, hebben het erg druk, en soms ontstaan hierdoor false positives, of false negatives. Je kunt dan beter een lokaal scriptje gebruiken om mee te testen, zoals deze: http://foxitsecurity.file...04/fox_heartbleedtest.zip

Intussen heeft iemand een uitgebreide test gedaan van bekende websites, en een aardig lijstje is nog vulnerable. Een belangrijk deel heeft intussen gepatched, of was sowieso niet vulnerable. Linkje:
https://github.com/musalb...t/blob/master/top1000.txt

Onder websites die kwetsbaar zijn, behoren ook nog:
flickr.com
okcupid.com
wetransfer.com

[ Voor 20% gewijzigd door Booster op 08-04-2014 19:53 ]

[deadinspace]

wootah schreef op dinsdag 08 april 2014 @ 18:34:
Ik heb inmiddels mijn eigen server op ubuntu 12.04 gepatched. Helaas geeft de check nog steeds terug dat mijn server vulnerable is

Welke service? Apache?

Wat is je exacte versie van libssl1.0.0 (dpkg -l)?

Iemand een idee waarom hij nog steeds als vulnerable bestempeld word? Of moet ik eerst nieuwe certificaten gaan aanvragen en de oude revoken voordat die status verdwijnt?

Nee, certificaten vervangen en revoken is niet nodig om dit gat te dichten. (Het is wel nodig om misbruik van gelekte keys tegen te gaan)

Bastien schreef op dinsdag 08 april 2014 @ 18:46:
Heb hetzelfde met een installatie op Debian Wheezy. Volgens Debian moet het met de gebruikte versie nu opgelost zijn maar de sites blijven inderdaad aangeven dat de servers vulnerable zijn. Weet niet of de sites kunnen zien welke versie er gebruikt wordt, Debian loopt nog op 1.0.1e-2+deb7u6 maar is wel gepatched. Als alleen daar naar gekeken wordt is het een beetje knullig.

Voorzover ik weet test http://filippo.io/Heartbleed/ of je daadwerkelijk vulnerable bent, en kijkt die niet naar de versies. 1.0.1e-2+deb7u6 zou voorzover ik weet goed moeten zijn.

Voor jou dezelfde vragen trouwens: welke service, en wat is je libssl1.0.0 versie?

[Bastien]

Uiteindelijk, gezien de diverse mogelijkheden (apache, postfix etc.) de servers maar even een reboot gegeven. Nu werkt de check wel goed, althans geen Heartbleed melding meer. Dank voor de reacties.

[wootah]

deadinspace schreef op dinsdag 08 april 2014 @ 19:49:

Welke service? Apache?

Wat is je exacte versie van libssl1.0.0 (dpkg -l)?

Ja ik gebruik apache2

alle libssl pakketten:

code:

ii  libssl-dev                                    1.0.1g-1ppa1~precise1             Secure Sockets Layer toolkit - development files
ii  libssl-doc                                    1.0.1g-1ppa1~precise1             Secure Sockets Layer toolkit - development documentation
ii  libssl0.9.8:i386                              0.9.8o-7ubuntu3.1                 SSL shared libraries
ii  libssl1.0.0                                   1.0.1g-1ppa1~precise1             Secure Sockets Layer toolkit - shared libraries
ii  libssl1.0.0:i386                              1.0.1g-1ppa1~precise1             Secure Sockets Layer toolkit - shared libraries

Zoals ik al zei: ik heb nu de pakketten van https://launchpad.net/~ge...ve/openssl-heartbleed-fix gepakt, omdat de standaard update 1.0.1-4ubuntu5.12 (http://www.ubuntu.com/usn/usn-2165-1/) niet bleek te werken.

apache is op dit moment de versie 2.2.22-1ubuntu1.5

ik heb mijn gehele server al een paar keer gereboot, dus t kan niet zijn dat een applicatie nog de oude openssl libraries gebruikt.

edit:
net ook even handmatig de desbetreffende libraries van mijn server af gegooid en opnieuw via apt-get binnen gehaald. Dan krijg ik idd te zien dat een aantal servers nog een oude library gebruiken. Vervolgens weer gereboot: same difference.

edit 2:
wat dieper graven:

code:

$ lsof -n | grep ssl | grep .so
apache2   5409     www-data  mem       REG              253,1  2100904      41140 /usr/lib/apache2/modules/mod_ssl_with_npn.so

hmm...

edit 3:
de oplossing, blijkbaar.
Geen idee wat mod_ssl_with_npn.so precies doet, maar nu heb ik de normale mod ssl gepakt.
mod_ssl_with_npn komt via het mod spdy pakket binnen, je hebt het persé nodig als je van google's spdy gebruik wilt maken.

in file /etc/apache2/mods-enabled/ssl.load

code:

#LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl_with_npn.so
LoadModule ssl_module /usr/lib/apache2/modules/mod_ssl.so

en nu is ie not affected na een restart

[ Voor 25% gewijzigd door wootah op 08-04-2014 20:50 ]

[HarmoniousVibe]

Wat is me afvraag is het volgende:

- Is sshd ook affected? Zo ja, in hoeverre? Blijft dit beperkt tot de host keys die wellicht zijn gecompromitteerd of kun je middels sshd ook memory dumps uitlezen?

- Is de client software ook in gevaar? Bijvoorbeeld alle browsers die libssl (van OpenSSL) gebruiken? Zou je mensen naar een website kunnen leiden die vervolgens middels deze bug de 'heartbeat info' de andere kant op kunnen sturen om zo als server een chunk uit het geheugen van de client uit kunnen lezen? Volgens heartbleed.com is dat wel zo:

Furthermore you might have client side software on your computer that could expose the data from your computer if you connect to compromised services.

[wootah]

HarmoniousVibe schreef op dinsdag 08 april 2014 @ 20:36:
Wat is me afvraag is het volgende:

- Is sshd ook affected? Zo ja, in hoeverre? Blijft dit beperkt tot de host keys die wellicht zijn gecompromitteerd of kun je middels sshd ook memory dumps uitlezen?

- Is de client software ook in gevaar? Bijvoorbeeld alle browsers die libssl (van OpenSSL) gebruiken? Zou je mensen naar een website kunnen leiden die vervolgens middels deze bug de 'heartbeat info' de andere kant op kunnen sturen om zo als server een chunk uit het geheugen van de client uit kunnen lezen? Volgens heartbleed.com is dat wel zo:


[...]

Alle applicaties die van die openssl versies gebruik maken zijn kwetsbaar

client software is ook gevoelig idd. Ik moet dus ook ff een andere openvpn op mijn pc's zetten. Iets met polarssl, zoals de openvpn android app ook gebruikt.
dropbear (ssh server) gebruikt trouwens ook polarssl standaard volgens mij.

[CrashOne]

Op Twitter had ik de volgende discussie:

https://twitter.com/Byte_Internet/status/453547262409707520

Byte claimt dat ze de certificaten niet hoeven te vervangen omdat er geen aanwijzingen zijn dat er misbruik is gemaakt. Ik ben van mening dat je de certificaten zeker moet vervangen omdat er geen aanwijzingen hoeven te zijn. Is hier een eenduidig antwoord op te geven?

[Nvidiot]

Hoe hadden ze gedacht misbruik te detecteren? 't is niet alsof Apache crasht of dat er iets in je access / error logs terecht komt als iemand dit lek misbruikt. Voor zover ik begrijp krijg je een random blok van 64k geheugen terug, dus je moet een beetje geluk hebben om echt interessante gegevens te vinden, maar zoals 't screenshot van yahoo hierboven al aantoont, het kan zeker wel link zijn. Daar komt nog bij dat dit lek al een behoorlijke tijd in de code zit, en wie zegt dat de NSA of anderen hier niet al lang misbruik van maken?

[HarmoniousVibe]

Ik betwijfel het ten zeerste; tenzij Byte op TCP/netwerkniveau connecties monitort is er géén aanwijzing dat er memory is uitgelezen met daarin gevoelige informatie (zij het de private keys of usernames/wachtwoorden e.d.). Heel dit ding is pre-auth en gebeurt als root, dus het is niet zo dat je zomaar even je nginx/apache logs door kunt greppen en als je daarin niks vindt (wat je nooit zult vinden), dan vervolgens kunt concluderen dat er geen misbruik is gemaakt.

[CrashOne]

Dat dacht ik dus al, vond de reactie ook vreemd voor een tech partij.

[Orion84]

HarmoniousVibe schreef op dinsdag 08 april 2014 @ 20:36:
Wat is me afvraag is het volgende:

- Is sshd ook affected? Zo ja, in hoeverre? Blijft dit beperkt tot de host keys die wellicht zijn gecompromitteerd of kun je middels sshd ook memory dumps uitlezen?

[...]

Lijkt met niet. Het is een bug in de implementatie van het SSL protocol, en dat gebruikt een ssh server niet (hoogstens zal die sshd wellicht gebruik maken van bepaalde cryptoroutines uit de openssl library).

[flux_w42]

Ergens wel grappig hoe enkele regels code de helft van 't internet op stelten kan zetten :-)

Dit is de originele bug (deel van de code)

C:

unsigned int payload;
unsigned int padding = 16; /* Use minimum padding */
/* Read type and payload length first */
hbtype = *p++;
n2s(p, payload);
pl = p;
/* Knip ... */

/* ... knip */
buffer = OPENSSL_malloc(1 + 2 + payload + padding);

En een deel van de fix :-)

C:

unsigned int payload;
unsigned int padding = 16; /* Use minimum padding */
/* Read type and payload length first */
if (1 + 2 + 16 > s->s3->rrec.length)
  return 0; /* silently discard */
hbtype = *p++;
n2s(p, payload);
pl = p;
/* Knip ... */

/* ... knip */
buffer = OPENSSL_malloc(1 + 2 + payload + padding);

De volledige code van de bug en fix is hier te vinden.

[ Voor 8% gewijzigd door flux_w42 op 09-04-2014 01:36 ]

[jordy-maes]

Voor iedereen met een Synology NAS: http://ukdl.synology.com/...pdate/update_pack/4458-2/

Ik heb deze patch gedownload en ik draai nu openSSL g

"I've already downloaded this patch for my DS211 and DS212J and when I type 'openssl version' I see OpenSSL 1.0.1g-fips 7 Apr 2014"

[XzeroD]

Mijn server bleek kwetsbaar te zijn, inmiddels ligt de update er over heen.
Op mijn server draait een website volledig op https, dit certificaat is ergens anders ingekocht. Moeten ik nu deze certificaten laten revoken en deze opnieuw aanvragen of is dit in mijn geval onnodig ?

Certificaat wordt alleen gebruikt voor https dus niet voor ssh of iets dergelijks.

[Orion84]

Dat ligt er aan of je het risico wilt nemen dat in de tussentijd je private key door iemand is opgevist. Als je dat risico acceptable acht, dan zou je kunnen besluiten om je die moeite te besparen.

[XzeroD]

Orion84 schreef op woensdag 09 april 2014 @ 14:50:
Dat ligt er aan of je het risico wilt nemen dat in de tussentijd je private key door iemand is opgevist. Als je dat risico acceptable acht, dan zou je kunnen besluiten om je die moeite te besparen.

De private key wordt in het geheugen geladen ?

[Orion84]

Ja, hoe wilde je hem anders gebruiken om inkomende berichten te ontsleutelen?

Er zijn op verschillende sites claims geplaatst dat mensen daadwerkelijk key materiaal hebben weten op te vissen. Ik heb er alleen nog geen bewijs van gezien, zoals bijvoorbeeld wel van die Yahoo passwords.

[XzeroD]

Orion84 schreef op woensdag 09 april 2014 @ 14:55:
Ja, hoe wilde je hem anders gebruiken om inkomende berichten te ontsleutelen?

Er zijn op verschillende sites claims geplaatst dat mensen daadwerkelijk key materiaal hebben weten op te vissen. Ik heb er alleen nog geen bewijs van gezien, zoals bijvoorbeeld wel van die Yahoo passwords.

Ah heel erg bedankt, ik weet genoeg en ga maar voor de zekerheid alles revoken.

[Maranello]

XzeroD schreef op woensdag 09 april 2014 @ 14:44:
Op mijn server draait een website volledig op https, dit certificaat is ergens anders ingekocht. Moeten ik nu deze certificaten laten revoken en deze opnieuw aanvragen of is dit in mijn geval onnodig ?

Afhankelijk van de certificaat verstrekker kan je een "reissue" van je certificaat doen. Voorwaarde is dat je hem met exact dezelfde gegevens moet aanmaken, wel nieuwe key natuurlijk. Dit kan dan vaak ook kostenloos . Even in de FAQ kijken van waar je certificaat vandaan komt.

[XzeroD]

Maranello schreef op woensdag 09 april 2014 @ 14:58:
[...]

Afhankelijk van de certificaat verstrekker kan je een "reissue" van je certificaat doen. Voorwaarde is dat je hem met exact dezelfde gegevens moet aanmaken, wel nieuwe key natuurlijk. Dit kan dan vaak ook kostenloos . Even in de FAQ kijken van waar je certificaat vandaan komt.

Is een "reissue" niet het zelfde als de oude revoken en nieuwe laten aanmaken ?
Al gevonden, thanks!

[deadinspace]

Bastien schreef op dinsdag 08 april 2014 @ 19:54:
Uiteindelijk, gezien de diverse mogelijkheden (apache, postfix etc.) de servers maar even een reboot gegeven. Nu werkt de check wel goed, althans geen Heartbleed melding meer. Dank voor de reacties.

Ahja, de services in kwestie moeten ook herstart worden. Voorzover ik begrepen heb doet 1.0.1e-2+deb7u6 dat ook, 1.0.1e-2+deb7u5 (welke de vulnerability fixt) niet. Maar dat kan ik niet 100% bevestigen.

Een reboot is een makkelijke manier om hier zeker van te zijn idd

wootah schreef op dinsdag 08 april 2014 @ 20:06:
[...]

Zoals ik al zei: ik heb nu de pakketten van https://launchpad.net/~ge...ve/openssl-heartbleed-fix gepakt, omdat de standaard update 1.0.1-4ubuntu5.12 (http://www.ubuntu.com/usn/usn-2165-1/) niet bleek te werken.

Om eerlijk te zijn zou ik niet snel een PPA pakken voor zoiets.

mod_ssl_with_npn komt via het mod spdy pakket binnen, je hebt het persé nodig als je van google's spdy gebruik wilt maken.

Dat is interessant. Waar komt die mod spdy precies vandaan, hoe heb je dat geinstalleerd?
Kun je eens de output van

ldd /usr/lib/apache2/modules/mod_ssl_with_npn.so
dpkg -S /usr/lib/apache2/modules/mod_ssl_with_npn.so

geven?

HarmoniousVibe schreef op dinsdag 08 april 2014 @ 20:36:
Wat is me afvraag is het volgende:

- Is sshd ook affected? Zo ja, in hoeverre? Blijft dit beperkt tot de host keys die wellicht zijn gecompromitteerd of kun je middels sshd ook memory dumps uitlezen?

Bij heartbleed kunnen keys gecomprommiteerd zijn doordat memory uit te lezen is. Die twee zijn voor heartbleed onlosmakelijk verbonden.

Maar, voorzover ik kan nagaan, is OpenSSH niet vatbaar voor dit probleem. OpenSSH gebruikt namelijk het SSH protocol, niet TLS. En heartbleed is een bug in OpenSSL's TLS implementatie.

Dat is ook te zien aan het feit dat sshd wel tegen libcrypto (core crypto stuff) linkt, maar niet tegen libssl (SSL/TLS support).

% ldd =sshd | egrep '(libcrypto|libssl)'
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fbf630f6000)

Is de client software ook in gevaar?

Ja.

CrashOne schreef op dinsdag 08 april 2014 @ 20:58:
Byte claimt dat ze de certificaten niet hoeven te vervangen omdat er geen aanwijzingen zijn dat er misbruik is gemaakt. Ik ben van mening dat je de certificaten zeker moet vervangen omdat er geen aanwijzingen hoeven te zijn. Is hier een eenduidig antwoord op te geven?

Je hebt gelijk, er kan misbruik van het lek zijn gemaakt zonder dat je daar enige aanwijzing voor hebt.

Of de kans daarop groot is, en of je de certificaten moet revoken is een afweging die ze kunnen maken. Maar ze moeten er dan wel eerlijk over zijn dat het een afweging is, een kansberekening

Orion84 schreef op dinsdag 08 april 2014 @ 22:26:
Lijkt met niet. Het is een bug in de implementatie van het SSL protocol, en dat gebruikt een ssh server niet (hoogstens zal die sshd wellicht gebruik maken van bepaalde cryptoroutines uit de openssl library).

Dat ja

XzeroD schreef op woensdag 09 april 2014 @ 14:44:
Mijn server bleek kwetsbaar te zijn, inmiddels ligt de update er over heen.
Op mijn server draait een website volledig op https, dit certificaat is ergens anders ingekocht. Moeten ik nu deze certificaten laten revoken en deze opnieuw aanvragen of is dit in mijn geval onnodig ?

Het is mogelijk dat de private key van je certificaat gelekt is via de heartbleed bug voordat je geupdate had. Als je dus zeker wil zijn, dan moet je revoken en opnieuw aanvragen.

Maranello schreef op woensdag 09 april 2014 @ 14:58:
Afhankelijk van de certificaat verstrekker kan je een "reissue" van je certificaat doen. Voorwaarde is dat je hem met exact dezelfde gegevens moet aanmaken, wel nieuwe key natuurlijk. Dit kan dan vaak ook kostenloos . Even in de FAQ kijken van waar je certificaat vandaan komt.

Let wel op dat die reissue dan ook het oude certificaat revoked, anders schiet je er niks mee op

[XzeroD]

Bedankt iedereen!
Inmiddels worden alle SSL certificaten vervangen door een re-issue, revoken word na navraag niet automatisch gedaan maar op verzoek omdat het er zoveel zijn.

[Booster]

CrashOne schreef op dinsdag 08 april 2014 @ 21:20:
Dat dacht ik dus al, vond de reactie ook vreemd voor een tech partij.

Valt me tegen van Byte. Volgensmij moeten zij beter weten. Gisteren zijn er pas in de loop van de dag Snort detectiesignatures voor Heartbleed bekend geworden. Tot dat moment was detectie van misbruik niet mogelijk. Dus tenzij Byte al op de hoogte was van deze exploit is het voor hen niet mogelijk om vast te stellen of er wel of geen misbruik van is gemaakt.

De vraag die ik ze zou stellen is:

Als er wel misbruik was gemaakt van deze kwetsbaarheid, hoe hadden jullie dat dan gedetecteerd?

Zijn er hier klanten van Mijndomein? Zoja, hebben jullie iets van communicatie ontvangen over wat zij doen naar aanleiding van Heartbleed? Zij zijn een van de grotere webhosters van Nederland, en bij een aantal pakketten bieden ze SSL aan.

Ik heb Mijndomein gisteren geinformeerd over hun webmail op mail.mijndomein.nl die kwetsbaar bleek te zijn. Gedurende die periode was het prima mogelijk om fragmenten van via de webmail gelezen berichten in te zien.

Het gat bij Mijndomein is na mijn melding rond 16:20 gedicht, maar volgensmij is het certificaat niet revoked en opnieuw gegenereerd, ondanks dat ik daar wel op gewezen heb. (Issued on 27-3-2013 / Validity not before 27-3-2013 15:40:24)

Nxs/IS Group heeft een tweet verzonden met deze link: http://isstatus.nl/?p=193
Misschien interessant om eens te inventariseren hoe NL-providers gereageerd hebben op Heartbleed.

[AtleX]

Booster schreef op woensdag 09 april 2014 @ 16:31:
Misschien interessant om eens te inventariseren hoe NL-providers gereageerd hebben op Heartbleed.

Eén van mijn providers, een oud werkgever, is nog steeds kwetsbaar. Maarja, met een certificaat uit het jaar kruik en een minstens net zo oude PHP is dat ook niet heel verwonderlijk. Deze bug is een minder grote zorg dan de zwaar verouderde software die ze draaien. Gelukkig doen ze voor mij niets anders dan DNS en een simpele webpagina hosten.

Mijn Nederlandse VPS provider, PC Extreme, is volgens SSL Labs op iig hun control panel niet kwetsbaar en verder zou ik het niet weten. Ik heb wel een mail gehad, dinsdag al, over deze bug met upgrade-instructies. Daarmee waren ze net te laat, want ik had 's ochtends mijn enige kwetsbare server al gepatched en die is niet eens bij hun gehost.

Die kwetsbare server had trouwens een certificaat met Forward Secrecy, dus de potentiele impact is relatief klein geloof ik. Toch heb ik het certificaat daarvan vervangen en de oude gerevoked, voor wat dat laatste waard is. Daarnaast had ik nog twee 1024-bits certificaten, eentje voor communicatie tussen servers binnen een eigen fysiek netwerk en eentje voor een monitoringtool. Beiden heb ik zojuist vervangen door 2048-bits certificaten met FS. De overige certificaten die ik heb zijn al wel 2048-bits maar nog zonder FS, die ga ik vanavond ook maar meteen vervangen aangezien ik nu toch bezig ben. Die zijn nooit kwetsbaar geweest voor zover ik kan zien, maar dit is een mooi moment om weer eens een stapje omhoog te gaan qua security.

[ Voor 5% gewijzigd door AtleX op 10-04-2014 09:27 ]

[Booster]

Dat is dan weer een van de positievere kanten van dit hele verhaal; dat iedereen even kan nagaan of er nog iets te verbeteren is aan de veiligheid van de machine. Het FS/PFS verhaal is nu erg hip. Ik ben zelf niet heel goed op de hoogte van de mogelijkheden daarmee, dus dat moet ik nog even goed nalezen en dan binnenkort maar eens implementeren.

Van de servers die ik beheer was er 1 die een vulnerable versie van OpenSSL geinstalleerd had. Deze machine bood echter alleen SSH/rsync-toegang, en geen services die TLS ondersteunen. Die is in de uren na bekendmaking gepatched.

Overige machines gebruiken momenteel nog de 10.04 LTS, en daarin zit een versie van OpenSSL < 1.0.1. Wel getest op deze kwetsbaarheid en geen problemen gevonden. Het traject om te upgraden naar 12.04 is onderweg maar heeft nog even tijd nodig. Daar kunnen we dan wel meteen overstappen op 1.0.1g.

[chickpoint]

Booster schreef op woensdag 09 april 2014 @ 16:31:
[...]

Zijn er hier klanten van Mijndomein? Zoja, hebben jullie iets van communicatie ontvangen over wat zij doen naar aanleiding van Heartbleed? Zij zijn een van de grotere webhosters van Nederland, en bij een aantal pakketten bieden ze SSL aan.

[...]

Ik heb een hostingpakket bij Mijndomein (weliswaar zonder SSL dat loopt voor mij via startcom) maar er is echt 0,0 communicatie over heartbleed. Geen mail, geen bericht in het controlpanel en niet eens een berichtje onder het nieuws tab blad. Als ik kijk bij de webmail zie ik inderdaad nog het certificaat uit 2013.

Dus ze hebben goede hoop dat er niks gelekt is en dat niemand gaat klagen?

[Booster]

Interessant artikel over de marketing van Heartbleed: http://www.kalzumeus.com/...ommunity-about-marketing/

@chickpoint: ik denk dat het nog niet helemaal is doorgedrongen bij ze, of wellicht dat een marketing/PR-departement heeft besloten het niet naar buiten te brengen.

Het grootste risico bij Mijndomein is dat er gebruikersnamen en wachtwoorden zijn gelekt waarmee ingelogd kon worden op de webmail, én dat er gevoelige data is gelekt die in de e-mails stonden die bekeken zijn via de webmail. Daar kunnen ook gebruikersnamen en wachtwoorden bij zitten, of andere gegevens.

De kans dat er private keys gestolen zijn lijkt vooralsnog vrij klein, maar ach; even een certificaat revoken en opnieuw ingeven is denk ik een kleine moeite.

Ergo; providers moeten echt een bijzonder goed excuus hebben om niet die stappen te verrichten.

[ Voor 9% gewijzigd door Booster op 10-04-2014 12:17 ]

[eborn]

Booster schreef op donderdag 10 april 2014 @ 12:17:
De kans dat er private keys gestolen zijn lijkt vooralsnog vrij klein, maar ach; even een certificaat revoken en opnieuw ingeven is denk ik een kleine moeite.

Ergo; providers moeten echt een bijzonder goed excuus hebben om niet die stappen te verrichten.

Hangt wel een beetje van de SSL certificaat af. Volgens mij kun je overal (al dan niet gratis) een reissue aanvragen, maar een aantal boeren doen niet aan het revoken van SSL certificaten. Bijv. goedkopere partijen als RapidSSL of Comodo.

[Firesphere]

ik weet niet of'ie hier al is gepost, maar Mashable heeft een mooi overzichtje van waar je je wachtwoorden moet wijzigen:
http://mashable.com/2014/...ed-bug-websites-affected/

[deadinspace]

chickpoint schreef op donderdag 10 april 2014 @ 11:53:
Ik heb een hostingpakket bij Mijndomein (weliswaar zonder SSL dat loopt voor mij via startcom)

SSL loopt via startcom? Dat lijkt me erg sterk

[stuffer]

Ik kreeg gister van Xolphin een email met de waarschuwing dat mijn webserver kwetsbaar was.

Lees hierboven dat het niet standaard is dat dat gebeurt maar heb wel naar de support engineer een bedankje gestuurd (mede nadat hij me de fix voor de synology's vertelde)

[geez]

Heeft er iemand informatie over OpenVPN in combinatie met deze bug? Ik heb de nodige upgrades al uitgevoerd op de servers en het certificaat voor webservices vervangen maar m.i. zou OpenVPN ook kwetsbaar geweest moeten zijn? Ik neem aan dat ik daarvoor ook alle certificaten (minus CA?) opnieuw moet genereren?

Natuurlijk heb ik OpenVPN al uitgezet voor de gelegenheid

[ Voor 9% gewijzigd door geez op 10-04-2014 17:39 ]

[Rukapul]

flux_w42 schreef op woensdag 09 april 2014 @ 01:20:

C:

if (1 + 2 + 16 > s->s3->rrec.length)
  return 0; /* silently discard */

Die fix is wederom om te huilen net zoals de hele openssl codebase om te huilen is. Er zit geen spatje kwaliteit aan die hele code. Unmaintainable en unusable.

3 magic numbers, 2 pointer operaties, een magic return code en een stille return. Het valt nog net mee dat de functie zelf niet honderden regels lang is met vele tab-niveaus en vele functiecalls (wat dan meestal macro's blijken te zijn) zoals in openssl gebruikelijk

Over het afgelopen decennium heb ik een aantal maal met de code, en de devs op de mailinglijst, te maken gehad en het is gewoon drama. Volgens mij wordt een flink deel van de code base door een halve man en een paardekop onderhouden waarbij de halve man liever academisch hobbiet dan software engineert.

[ Voor 4% gewijzigd door Rukapul op 10-04-2014 17:18 ]

[chickpoint]

deadinspace schreef op donderdag 10 april 2014 @ 12:55:
[...]

SSL loopt via startcom? Dat lijkt me erg sterk

Ik doelde op, dat ik mijn certificaat bij startcom heb lopen en niet via Mijndomein.

[deadinspace]

chickpoint schreef op donderdag 10 april 2014 @ 18:57:
[...]


Ik doelde op, dat ik mijn certificaat bij startcom heb lopen en niet via Mijndomein.

Ja precies. En als mijndomein kwetsbaar was voor Heartbleed, dan bestaat de kans dat de private keys van je certificaten gelekt zijn. Dat je certificaten bij Startcom vandaan komen maakt daarvoor niet uit

[Compizfox]

Nou, eigenlijk wel. Want Startcom/StartSSL weigert certificaten gratis te revoken. Een erg slechte zet nu de private keys van het halve internet misschien compromised zijn.

Bij Mozilla loopt er een hele discussie of ze misschien StartSSL moeten distrusten als CA en de CA root uit de truststore moeten halen.

[Firesphere]

Compizfox schreef op vrijdag 11 april 2014 @ 00:42:
Nou, eigenlijk wel. Want Startcom/StartSSL weigert certificaten gratis te revoken. Een erg slechte zet nu de private keys van het halve internet misschien compromised zijn.

Bij Mozilla loopt er een hele discussie of ze misschien StartSSL moeten distrusten als CA en de CA root uit de truststore moeten halen.

Jaaa, nee, niet helemaal het probleem.
Het probleem is vooral dat door hun keuze om niet direct alle certificaten te revoken en opnieuw uit te brengen, ze het hele concept van SSL, namelijk SECURE socket layer, ondermijnen. Omdat het "secure" gedeelte niet meer secure te noemen is.

Het is hetzelfde als dat elke voordeur in Nederland te openen blijkt met 1 loper-sleutel. En dat alle slotenleveranciers hun sloten gratis laten vervangen.
Op 1 na.

(kuch, ik kijk nu naar AXA met hun SL7/SL9 sloten trouwens "Ja, nee, ehm, we hebben een extra nieuw en veilig slot nu, dus koop die maar!")

[arie_papa]

Ah, net ff Raspbian upgrade uitgevoerd, openssh-client/server, openssl, ssh stonden allemaal ter nominatie op te upgraden. Daarna de versie van openssl gecheckt, wat blijkt: OpenSSL 1.0.1e Feb 2013 . Idem met 2 Xbian installs.

Deze link heeft de oplossing voor Raspbian. Xbian ik heb ik nog niet aangedurft. Iemand daar al ervaring mee?

http://raspberrypi.stacke...pdate-openssl-on-raspbian

Upgrade werkt zonder problemen in inmiddels zit mijn RPi'tje op 1.0.1g

[Nullius]

Als ik het goed begrijp, is misbruik enkel mogelijk door een mitm attack vóór het patchen?

De kans dat veiligheidsdiensten er misbruik van hebben gemaakt is reëel, vooral op de bekendere sites.
De kans dat één of andere Chinees een Nederlands/Belgisch Gmail account gehackt heeft, is gering.
De kans dat één of andere Chinees überhaupt al geïnteresseerd was in het verkeer tussen m'n laptop en NAS, is zeer klein. Dat hij/zij dan ook nog eens de (toegang tot de) resources had om een mitm attack bij mij uit te voeren, is minimaal?

Met andere woorden: Als de modale burger zijn paswoorden verandert en z'n software upgrade maar het certificaat voor z'n thuisservertje niet revoked, is de kans minimaal dat ie het slachtoffer is/wordt?

[Orion84]

Je hoeft geen MitM te zijn om heartbleed te misbruiken (hoogstens als je de client wilt aanvallen). Zo lang je verbinding kan maken met een server, kan je die server aanvallen.

Het is een fluitje van een cent om een script / botnet in elkaar te draaien dat automatisch het internet afstruint naar systemen waar op bekende poorten (443, SSL VPN poorten, etc.) een kwetsbare openssl draait, om daar vervolgens een aanval op uit te voeren.

Het enige wat het directe risico wat beperkt, is dat het niet bepaald triviaal is om de opgeviste blokjes geheugen aan elkaar te puzzelen en daar de interessante info uit te plukken. Het is niet zo dat je gericht bepaalde specifieke info kan uitlezen. Waardoor ik geneigd ben te zeggen dat als het al actief misbruikt is, dat vooral voor gerichte aanvallen zal zijn geweest waar uiteindelijk de menselijke aanvaller zelf een deel van dat puzzelwerk doet.

Als er daadwerkelijk een eenvoudige, goed geautomatiseerde aanval voor ontwikkeld zou zijn in de afgelopen 2 jaar, dan zouden we denk ik al veel meer (wellicht lastig verklaarbare) voorbeelden hebben gezien van de gevolgen daar van.

[deadinspace]

skinlee78 schreef op vrijdag 11 april 2014 @ 09:56:
Ah, net ff Raspbian upgrade uitgevoerd, openssh-client/server, openssl, ssh stonden allemaal ter nominatie op te upgraden. Daarna de versie van openssl gecheckt, wat blijkt: OpenSSL 1.0.1e Feb 2013 . Idem met 2 Xbian installs.

Debian backport security fixes naar de versie in het repository, en dat zal voor Debian-afgeleiden niet anders zijn. Dus afhankelijk van de details kan die 1.0.1e wel degelijk gefixt zijn.

Upgrade werkt zonder problemen in inmiddels zit mijn RPi'tje op 1.0.1g

Hoe heb je precies geupgrade? Als je dat fout aanpakt dan ontvang je voortaan juist geen security updates meer en ga je er dus juist op achteruit...

[arie_papa]

deadinspace schreef op vrijdag 11 april 2014 @ 11:04:

Hoe heb je precies geupgrade? Als je dat fout aanpakt dan ontvang je voortaan juist geen security updates meer en ga je er dus juist op achteruit...

Check even de link die ik in mijn bericht gezet heb. Daar staat precies in wat ik uitgevoerd heb. Voor zover ik kan beoordelen zou dit geen invloed moeten hebben op overige updates. Of beoordeel ik dat fout?

[leuk_he]

Orion84 schreef op vrijdag 11 april 2014 @ 10:37:
Als er daadwerkelijk een eenvoudige, goed geautomatiseerde aanval voor ontwikkeld zou zijn in de afgelopen 2 jaar, dan zouden we denk ik al veel meer (wellicht lastig verklaarbare) voorbeelden hebben gezien van de gevolgen daar van.

Hoe? Als je via een fake wifispot een goede MITM attack doet, dan ben je je er wellicht van bewust dat je met een verkeerd netwerk hebt verbonden. Als je dan 2 maanden later ondekt dat je wachtwoord gelekt is, is niet meer te achterhalen of dat via een MITM is gegaan, of dat de site gelekt heeft, of dat er een trojan op op jouw laptop terecht is gekomen. Je zou het alleen op plaatsen tegenkomen waar een MITM mogelijk is, zonder een MITM is het al niet mogelijk zinvol.

Zeker omdat het geen sporen achterlaat.

Nu is het niet meer te achterhalen, want zoveel mensen kennen deze bug nu, dus je zult deze attack vaak in logs terugvinden(als het gelogd kon worden..wordt waarschijnlijk in signatures toegevoegd, maar kunnen dat soort intrusion prevention producten wel in SSL sessies kijken?) .

[deadinspace]

skinlee78 schreef op vrijdag 11 april 2014 @ 11:17:
[...]


Check even de link die ik in mijn bericht gezet heb. Daar staat precies in wat ik uitgevoerd heb. Voor zover ik kan beoordelen zou dit geen invloed moeten hebben op overige updates. Of beoordeel ik dat fout?

Er staan (zoals bij de meeste SE topics) meerdere oplossingen, dus ik weet niet zeker welke stappen je precies gevolgd hebt

[roeleboel]

Firesphere schreef op vrijdag 11 april 2014 @ 00:49:
[...]

Jaaa, nee, niet helemaal het probleem.
Het probleem is vooral dat door hun keuze om niet direct alle certificaten te revoken en opnieuw uit te brengen, ze het hele concept van SSL, namelijk SECURE socket layer, ondermijnen. Omdat het "secure" gedeelte niet meer secure te noemen is.

Asjeblieft niet nee! Ik heb een hoop certificaten die niet via openssl gebruikt worden, waarvoor dus geen enkele reden is om die te vervangen.
Het is niet omdat veel mensen brakke software gebruiken dat iedereen er maar onder moet lijden...

StartSSL heeft ook geen idee op wat voor software jij je certificaat gebruikt, dus het is echt niet aan hun om zomaar alles te revoken!

[arie_papa]

deadinspace schreef op vrijdag 11 april 2014 @ 11:56:
[...]

Er staan (zoals bij de meeste SE topics) meerdere oplossingen, dus ik weet niet zeker welke stappen je precies gevolgd hebt

Ok, excuses. Onderstaande uitleg heb ik uitgevoerd.

code:

*Here is how to selectively upgrade certain packages using jessie repository, without completely 
breaking wheezy, and will install the latest g version

Add the following two lines into /etc/apt/sources.list

deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi
deb http://archive.raspbian.org/raspbian jessie main contrib non-free rpi

You then edit the file /etc/apt/preferences (create the file if doesn't exist) to tell apt in which repositories 
it should look to do an update. We put jessie on a low priorty so that when you use apt-get update it 
will ignore jessie and use wheezy repo instead. This is important for the step after this one.

Package: *
Pin: release n=wheezy
Pin-Priority: 900

Package: *
Pin: release n=jessie
Pin-Priority: 300

Package: *
Pin: release o=Raspbian
Pin-Priority: -10

Now, at your free will you can tell apt to use jessie instead.

apt-get -t jessie install openssl libssl1.0.0 openssh-client openssh-server ssh

(make sure you run apt-get update before running the above command)

[Compizfox]

Firesphere schreef op vrijdag 11 april 2014 @ 00:49:
[...]

Jaaa, nee, niet helemaal het probleem.
Het probleem is vooral dat door hun keuze om niet direct alle certificaten te revoken en opnieuw uit te brengen, ze het hele concept van SSL, namelijk SECURE socket layer, ondermijnen. Omdat het "secure" gedeelte niet meer secure te noemen is.

Het is hetzelfde als dat elke voordeur in Nederland te openen blijkt met 1 loper-sleutel. En dat alle slotenleveranciers hun sloten gratis laten vervangen.
Op 1 na.

(kuch, ik kijk nu naar AXA met hun SL7/SL9 sloten trouwens "Ja, nee, ehm, we hebben een extra nieuw en veilig slot nu, dus koop die maar!")

True, dat is ook precies wat ik bedoelde. Wordt ook goed uitgelegd in dat topic op Mozilla.com, vandaar dat ik die ook linkte.

[Orion84]

leuk_he schreef op vrijdag 11 april 2014 @ 11:52:
[...]


Hoe? Als je via een fake wifispot een goede MITM attack doet, dan ben je je er wellicht van bewust dat je met een verkeerd netwerk hebt verbonden. Als je dan 2 maanden later ondekt dat je wachtwoord gelekt is, is niet meer te achterhalen of dat via een MITM is gegaan, of dat de site gelekt heeft, of dat er een trojan op op jouw laptop terecht is gekomen. Je zou het alleen op plaatsen tegenkomen waar een MITM mogelijk is, zonder een MITM is het al niet mogelijk zinvol.

Zeker omdat het geen sporen achterlaat.

Ik kan me niet herinneren dat er in de laatste twee jaar ergens een keer een hause is geweest van grote botnets / lekken / breaches waarvoor geen verklaring was (en waarvoor de verklaring dus mogelijk in deze onbekende vulnerability zou kunnen liggen).

Zeker de kans dat dergelijke aanvalstechnieken beschikbaar waren voor de gemiddelde hacker die zich bekommert om clients op wifi hotspots, zonder dat de vulnerability uitlekt lijkt me verwaarloosbaar.

Vandaar mijn opvatting dat als er misbruik van is gemaakt in de afgelopen jaren, dat voornamelijk zal zijn door de beter georganiseerde soorten aanvallers, die zich voornamelijk bezig houden met gerichte aanvallen. Waarmee het risico voor jan met de pet die een VPN / SSL verbinding opzet naar zijn NAS me niet levensgroot lijkt.

Maar al met al staat dat natuurlijk wel redelijk bol van aannames en is het aan ieder voor zich om de beslissing te nemen of je het zekere voor het onzekere wil nemen.

Nu is het niet meer te achterhalen, want zoveel mensen kennen deze bug nu, dus je zult deze attack vaak in logs terugvinden(als het gelogd kon worden..wordt waarschijnlijk in signatures toegevoegd, maar kunnen dat soort intrusion prevention producten wel in SSL sessies kijken?) .

Er zijn al IDS signatures voor in elk geval. Onder andere fox-it heeft Snort signatures gepubliceerd. Wat voor trucs je uit moet halen om je IDS dergelijke pakketjes te laten lezen durf ik niet te zeggen.

[Jester-NL]

Compizfox schreef op vrijdag 11 april 2014 @ 00:42:
Nou, eigenlijk wel. Want Startcom/StartSSL weigert certificaten gratis te revoken. Een erg slechte zet nu de private keys van het halve internet misschien compromised zijn.

Ik zie bij de opties van StarSSL niet dat ze aanbieden om een certificaat te replacen.
En als ik dan naar de prijs van een certificaat bij hen kijk, en wat andere CA's vragen (en bieden) dan kan ik eigenlijk alleen maar iets mompelen over 'goedkoop en duurkoop en zo'
Let wel, ik praat het niet goed. Ik snap echter ook wel iets van businessmodel en de prijszetting.

[.Peter.]

geez schreef op donderdag 10 april 2014 @ 16:56:
Heeft er iemand informatie over OpenVPN in combinatie met deze bug? Ik heb de nodige upgrades al uitgevoerd op de servers en het certificaat voor webservices vervangen maar m.i. zou OpenVPN ook kwetsbaar geweest moeten zijn? Ik neem aan dat ik daarvoor ook alle certificaten (minus CA?) opnieuw moet genereren?

Natuurlijk heb ik OpenVPN al uitgezet voor de gelegenheid

OpenVPN is ook kwetsbaar geweest als jouw installatie een getroffen openssl versie gebruikt. Zie: https://community.openvpn.net/openvpn/wiki/heartbleed. Voor de zekerheid dus nieuwe keys genereren en dus ook certificaten.

Over StartSSL, ik meende dat ze iets van 25 USD vroegen voor revocation. Dit om te voorkomen dat mensen lulkraak gratis certificaten maken en vervolgens revocen waardoor hun CRL enorm groeit. Het schijnt dat sommigen hun Class 2 certificaat gratis vervangen hadden. Mijn (in)directe ervaring met StartSSL is nog best positief, mijn broertje heeft zijn code signing certificate gratis vervangen om een foutief emailadres te corrigeren.

Overigens moeten mensen niet vergeten dat clients (dus ook webftps clients, webcrawlers, OpenID consumers, ...) ook kwetsbaar zijn. Ik heb een client PoC geschreven, te vinden op https://github.com/Lekensteyn/pacemaker

[deadinspace]

skinlee78 schreef op vrijdag 11 april 2014 @ 12:42:
Ok, excuses. Onderstaande uitleg heb ik uitgevoerd.

[snip]

Ahja, als ik pinning goed begrijp dan heb je op die manier voortaan de openssh en de openssl uit Jessie (testing). Dus ook met updates. Dat kan je compatibility-problemen op gaan leveren als die versie te nieuw wordt voor de software die er gebruik van maakt. Ik zou testing en stable mengen afraden tenzij je er echt een goede reden voor hebt.

Op de SE pagina die je linkte staat trouwens ook:

As of 09/04/2014 the main wheezy repository uses the patched version 1.0.1e-2+deb7u5 and as commented, you can get it like this:

Dus er zijn wel updates voor wheezy. En aangezien je zelf al aangaf dat je updates binnenkreeg had je waarschijnlijk de gefixte versies, en heb je je zelf met de stappen daarna alleen maar een nadeel bezorgd.

[Firesphere]

https://www.cloudflarechallenge.com

[Bananenplant]

Is er al een overzicht van Nederlandse sites? Ik heb maar een vracht mails gestuurd, beetje jammer dat bedrijven niet wat proactiever communiceren hierover ...

Edit: bol.com en Ziggo zeggen in elk geval dat ze er niet door getroffen zijn.

[ Voor 20% gewijzigd door Bananenplant op 13-04-2014 16:48 ]

[GlowMouse]

Bananenplant schreef op zondag 13 april 2014 @ 13:57:
Edit: bol.com en Ziggo zeggen in elk geval dat ze er niet door getroffen zijn.

Wat bedoelen ze daar precies mee? Ziggo draait aardig wat services die van SSL gebruikmaken (https, imap, pop3, smtp). Zijn die nooit vatbaar geweest, zijn ze 'tijdig' gepatcht, of zijn er geen sporen van misbruik gevonden?

[HarmoniousVibe]

GlowMouse schreef op zondag 13 april 2014 @ 21:51:
[...]

Wat bedoelen ze daar precies mee? Ziggo draait aardig wat services die van SSL gebruikmaken (https, imap, pop3, smtp). Zijn die nooit vatbaar geweest, zijn ze 'tijdig' gepatcht, of zijn er geen sporen van misbruik gevonden?

Daar bedoelen ze waarschijnlijk simpwelweg mee dat ze nooit een vulnerable versie hebben gedraaid. Dat is niet ondenkbaar, aangezien de conservatievere distro's (en dat is niet ongebruikelijk op grote productie-omgevingen) nog openssl-0.9.8 draaien.

[JJ Le Funk]

Bananenplant schreef op zondag 13 april 2014 @ 13:57:
Is er al een overzicht van Nederlandse sites? Ik heb maar een vracht mails gestuurd, beetje jammer dat bedrijven niet wat proactiever communiceren hierover ...

Edit: bol.com en Ziggo zeggen in elk geval dat ze er niet door getroffen zijn.

hosting van bol gebeurt door een toko genaamd schubergphilis. deze hoster laat zich er niet over uit maar heeft vermoedelijk als een dolle een patch uitgerold gezien ze vrij goed betaald worden voor maximale SLA-dinges.

[alt-92]

.Peter. schreef op vrijdag 11 april 2014 @ 14:56:
Voor de zekerheid dus nieuwe keys genereren en dus ook certificaten.

Zou toch wat zijn als blijkt dat een aantal CAs compromised zijn en dat die nieuwe PK's buitgemaakt worden....

/alu-hoed modus

[Orion84]

Ja, want je stuurt je private key op naar de CA?

Niet dus. Je private key blijft veilig op je eigen (als het goed is reeds gepatchte) systeem. Alleen de public key gaat in de vorm van een CSR richting CA voor ondertekening. En dat ondertekenen middels de private key van de CA gebeurt als het goed is in een HSM, niet in een proces op de webserver.

[ Voor 3% gewijzigd door Orion84 op 13-04-2014 23:03 ]

[Compizfox]

HarmoniousVibe schreef op zondag 13 april 2014 @ 21:58:
[...]

Daar bedoelen ze waarschijnlijk simpwelweg mee dat ze nooit een vulnerable versie hebben gedraaid. Dat is niet ondenkbaar, aangezien de conservatievere distro's (en dat is niet ongebruikelijk op grote productie-omgevingen) nog openssl-0.9.8 draaien.

Of ze draaien überhaupt geen OpenSSL. Er zijn nog andere SSL/TLS-implementaties, zoals GnuTLS en PolarSSL.

Als je een Microsoft-server gebruikt draai je ook geen OpenSSL; zo te zien gebruik IIS SChannel van Microsoft.

[Sando]

Ik snap de kwetsbaarheid, maar ik snap de ernst niet helemaal.
Als je inlogt op een website wordt toch vaak alleen een hash onthouden van je wachtwoord? En bij success een sessie à la oAuth ofzo, en die werkt niet als je het betreffende cookie gewoon naar een andere computer kopiëert.

Goed, een site die met mijn creditcard werkt, zover kan ik nog meedenken. Maar wie wil me even uitleggen hoe bijvoorbeeld mijn Dropbox app, waarvoor ik al sinds mensenheugenis niet hoef in te loggen, zorgt voor een probleem?

(Niet boos worden als dit een domme vraag is. Oprecht nieuwschierig. )

Er is nu (voor clients) ook de Chromebleed extensie. Hij wordt her en der aangeraden. Maar bij dit soort zaken weet ik nooit of het handig is, of dat een een slimme zet is om een en ander in kaart te kunnen brengen.

[Orion84]

Het ligt heel erg aan de manier waarop je precies authenticeert tegen een webapplicatie. Voor sommige applicaties werkt dat met challenge response via javascript, of via een externe authenticatie dienst met oAuth tokens. Maar heel veel webapplicaties werken simpel weg met:
https://app.com/login.php?user=redsandro&pass=$ecr3t

Dergelijke URL requests, komen gewoon plaintext in het geheugen van de webserver terecht. Zie bijvoorbeeld het voorbeeld van Yahoo dat eerder in dit topic genoemd is.

Als er in het geheugen van de webserver alleen een eenmalige response / token te vinden is die niet door de aanvaller gebruikt kan worden om mee in te loggen, dan is de impact inderdaad beperkt. Al kan het nog steeds zo zijn dat er gevoelige data uit het geheugen van de server wordt gevist waarmee een aanvaller toegang kan krijgen tot de server of sleutelmateriaal in handen krijgt waarmee een perfecte man in the middle aanval kan worden uitgevoerd.

[_JGC_]

HarmoniousVibe schreef op zondag 13 april 2014 @ 21:58:
[...]

Daar bedoelen ze waarschijnlijk simpwelweg mee dat ze nooit een vulnerable versie hebben gedraaid. Dat is niet ondenkbaar, aangezien de conservatievere distro's (en dat is niet ongebruikelijk op grote productie-omgevingen) nog openssl-0.9.8 draaien.

Hier ook vnml OpenSSL 0.9.8, ben nog te lui geweest om van Debian oldstable naar stable te upgraden. Alleen 1 klant getroffen, die heeft nu nieuwe certificaten nadat ze behalve de servers ook hun Sonicwall VPN konden patchen na een paar dagen.

Wat OpenVPN betreft, ik gebruik bij alle OpenVPN setups een tls-auth key bestandje, zonder de juiste key komt OpenVPN niet tot het uitvoeren van de exploit, dus als je tls-auth gebruikt ben je op zich veilig, ook met een ongepatchte OpenSSL.

[Orion84]

_JGC_ schreef op dinsdag 15 april 2014 @ 13:19:
[...]
Wat OpenVPN betreft, ik gebruik bij alle OpenVPN setups een tls-auth key bestandje, zonder de juiste key komt OpenVPN niet tot het uitvoeren van de exploit, dus als je tls-auth gebruikt ben je op zich veilig, ook met een ongepatchte OpenSSL.

Ik dacht dat de heartbeats al tijdens de handshake gestuurd konden worden? Of haal ik nu dingen door elkaar?

[_JGC_]

Orion84 schreef op dinsdag 15 april 2014 @ 13:21:
[...]

Ik dacht dat de heartbeats al tijdens de handshake gestuurd konden worden? Of haal ik nu dingen door elkaar?

OpenVPN doet de TLS handshake die nodig is voor heartbleed pas nadat de tls-auth key gecontroleerd is. Uiteraard ben je alsnog de klos als een van je clients met die key gaat zitten rommelen, maar vanbuitenaf heb je er geen last van.
Zie onderaan: https://community.openvpn.net/openvpn/wiki/heartbleed

[Sando]

@Orion84 thanks voor de uitleg. Er zijn dus gewoon erg veel variabelen en voorwaarden waardoor je gelekt zou kunnen zijn, maar onder de streep is de kans dermate klein dat niemand van de grotere sites het nodig vond om mij per email aan te raden daadwerkelijk mijn wachtwoord te veranderen?

Want los van Tweakers en wat andere nerdsites hoor ik er gewoon helemaal niks over.

Anyway, aluhoedjemode, ik ben benieuwd of de commit die de exploit mogelijk maakte ook door een Chinees of Rus of NSA is gedaan.

[ResuCigam]

Sando schreef op dinsdag 15 april 2014 @ 13:29:
Anyway, aluhoedjemode, ik ben benieuwd of de commit die de exploit mogelijk maakte ook door een Chinees of Rus of NSA is gedaan.

Volgens de persoon in kwestie Robin Seggelmann was het een 'foutje'. Je kunt er onder andere hier en hier wat over lezen.

[bvanaerde]

We hebben in onze Google Apps omgeving alerting aanstaan (suspicous activity), die ons meldt wanneer er een login is gebeurd vanuit een "vreemde" locatie. We controleerden dit ook elke maal samen met de werknemers. Tot nu toe was dit altijd doordat de persoon op vakantie was, en van daaruit met de GSM/Tablet de mails even checkte.

Ik zou verwachten dat - wanneer onze paswoorden zijn onderschept - we dit wel hadden gemerkt via deze alerting. Niet bij het onderscheppen van de paswoorden, maar wel bij het gebruik hiervan.

Of ben ik nu iets te naïef?

[Bananenplant]

- Ik zag van de week dat bol.com een nieuw certificaat heeft. Ik heb daar dus maar mijn wachtwoord even gewijzigd.
- Ik ben gebeld door iemand van DigiD naar aanleiding van een vraag die ik had gesteld. De persoon vertelde dat alles gepatcht was. Toen ik vroeg of ze de certificaten ook hadden vervangen wist-ie dat niet. Als ik digid.nl test bij SSL Labs staat er iig geen nieuw certificaat.

Ik vind dat wel vervelend, dat je halve antwoorden op je vragen krijgt en er vervolgens wel acties zijn uitgevoerd die impliceren dat ze kwetsbaar waren. Zeker bij DigiD kunnen ze toch een bericht op de site zetten met dat duidelijk maakt wat er is ondernomen aan acties en waarom dat afdoende wordt geacht ?

[Sando]

bvanaerde schreef op dinsdag 15 april 2014 @ 13:59:
Ik zou verwachten dat - wanneer onze paswoorden zijn onderschept - we dit wel hadden gemerkt via deze alerting. Niet bij het onderscheppen van de paswoorden, maar wel bij het gebruik hiervan.

Stel dat een handjevol hackers honderdduizenden heartbeats hebben opgevist. Dan sta je op een dikke vette lijst, het zou maaaaanden kunnen duren voordat 'ze' jouw gegevens eens gebruiken.

[airell]

Bastien schreef op dinsdag 08 april 2014 @ 18:46:
Heb hetzelfde met een installatie op Debian Wheezy. Volgens Debian moet het met de gebruikte versie nu opgelost zijn maar de sites blijven inderdaad aangeven dat de servers vulnerable zijn. Weet niet of de sites kunnen zien welke versie er gebruikt wordt, Debian loopt nog op 1.0.1e-2+deb7u6 maar is wel gepatched. Als alleen daar naar gekeken wordt is het een beetje knullig.

Ja, inderdaad.

Hetzelfde is bij Red Hat / Oracle Linux. In de laatste 1.0.1e versie zit een backport van 1.0.1g:

“Version openssl-1.0.1e-16.el6_5.7 included a fix backported from openssl-1.0.1g“.
https://access.redhat.com/site/solutions/781793

Alleen kijken naar 1.0.1e is niet genoeg. Package versies en OpenSSL versies kunnen uiteenlopen.