Re: Gnupg key en OpenSSL problemen
On 04/09/2014 12:10 PM, Paul van der Vlis wrote:
Hoi,
> Zijn gnupg keys die zijn aangemaakt op Wheezy vulnerable m.b.t. de
> openssl bug?
>
> Volgens mij gebruikt gnupg geen openssl of tls, maar ik hoor het graag
> als jullie daar anders over denken.
De beste informatie die ik over heartbleed kon vinden was dit:
http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/
Over de impact:
- met heartbleed krijgt een aanvaller een *willekeurig* blok van 64K uit
het geheugen van de server
- de aanvaller kan niet sturen welk blok 'ie ontvangt
- de aanvaller kan de aanval onbeperkt herhalen
Met andere woorden: in potentie kan *ALLES* wat in het geheugen van de
server zit/zat gecompromitteerd zijn. Dat kunnen read/write caches zijn
van gegevens op de disk, actieve sessies, sleutels van welke soort dan
ook, ontsleutelde data, wachtwoorden die op dat moment gecheckt worden,
wat dan ook. Op het internet zijn inmiddels scripts te vinden die
blokjes geheugen doorzoeken naar specifiek zaken als (sessie)cookies.
Ik weet niet hoe groot de impact in de praktijk is. Het blijft namelijk
ook toevalszaak: de gegevens die een aanvaller zoekt, moeten maar net op
dat moment in het geheugen zitten en dat blok geheugen moet dan maar
niet het blok zijn dat de aanvaller ontvangt. Als een aanvaller
specifiek naar 1 blok data op zoek is, dan is de kans om precies dat ene
blok te krijgen op een server met 8GB aan geheugen De kans om precies
het juiste blok data te krijgen kleiner dan 0,001%. Oftewel: je moet
tienduizenden requests sturen en gigabytes aan data ontvangen voordat je
een redelijke kans begint te krijgen om het blokje dat je zoekt te
ontvangen.
Een andere strategie voor een aanvaller is een aantal blokjes opvragen
en dan kijken wat daar toevallig in zit. Je hebt een redelijke kans dat
er wel wat vertrouwelijks in zit. Dat maakt het opvragen veel
makkelijker maar de analyse van de ontvangen gegevens veel moeilijker:
je moet goed weten waar je naar moet zoeken en in staat zijn om
bijvoorbeeld het geheugen dat een database gebruikt te 'decoderen'. Op
wat laaghangend fruit na, verwacht ik dat deze aanvalsroute alleen
bruikbaar is voor aanvallers die er hooggeschoold personeel voor langere
tijd aan kunnen en willen zetten.
Maar niets garandeert je dat je meest geheime data niet al (al dan niet
toevallig) gelicht is door een aanvaller.
Om aan de veilige kant te zitten zou ik alle gegevens vervangen die,
indien ze uitgelekt zijn, later nog de veiligheid in gevaar kunnen
brengen. Denk dan aan:
- Secret keys van welke soort dan ook (ssl, ssh, GPG)
- Ongehashte wachtwoorden
- Tokens van langdurige gebruikerssessies (voor zover die niet gehasht
zijn op de server)
Ik vind het nog wel een vraag of je de wachtwoorden die op de machine
gehasht worden (bijvoorbeeld van lokale accounts of van websites) moet
vervangen: ze kunnen op het moment dat ze ingevoerd zijn en verwerkt
werden gelekt zijn. Maar zo een wachtwoord vinden zou echt een flink
'lucky shot' zijn.
Voor andere zaken die al uitgelekt zouden zijn geldt: jammer, maar niets
meer aan te doen.
groet,
Winfried
Reply to: