Hoofdwachtwoord wachtwoordmanagers uit geheugen te halen
Het hoofdwachtwoord van wachtwoordmanagers is in bepaalde gevallen uit het geheugen van de pc te halen, zo hebben onderzoekers van Independent Security Evaluators aangetoond. Een aanvaller die hier misbruik van wil maken moet toegang tot de computer hebben, bijvoorbeeld via malware of fysiek.
Volgens de onderzoekers en de aanbieders van wachtwoordmanagers vormt het probleem dan ook een klein risico voor gebruikers. Voor het onderzoek werd er gekeken naar de wachtwoordmanagers 1Password 7, 1Password 4, Dashlane, KeePass en LastPass op Windows 10. De onderzoekers wilden weten of er informatie van de wachtwoordmanagers uit het geheugen kan worden gehaald als de wachtwoordmanagers nog niet zijn gestart, zijn gestart en ontgrendeld en zijn gestart, maar de gebruiker vervolgens is uitgelogd.
Bij geen van de wachtwoordmanagers is het mogelijk om informatie uit het geheugen te stelen als de programma's nog niet zijn gestart. In de ontgrendelde staat konden de onderzoekers het hoofdwachtwoord en andere geheimen die in de wachtwoordmanagers waren opgeslagen uit het geheugen halen. Iets wat volgens de onderzoekers waarschijnlijk wordt veroorzaakt door geheugenlekken.
Tegenover de Washington Post laat LastPass weten dat het deze week met een update komt. Dashlane zou ook aan een oplossing werken. KeePass en 1Password bestempelden het als een bekende beperking van Windows en een acceptabel risico. Ook de onderzoekers stellen dat zelfs wanneer de wachtwoordmanagers alles goed zouden doen, een aanvaller nog steeds via een keylogger of "clipboard sniffing" toegang tot wachtwoorden kan krijgen, aangezien de wachtwoordmanagers hier geen bescherming tegen bieden.
De meeste talen hebben zoiets als een Secure String welke er voor zorgt dat het NIET in het geheugen gelekt wordt. Maar ja, dan moeten developers meer gaan nadenken. Goed om te zien dat enkelen daar toch voor kiezen en zich niet achter een "Windows beperking" verschuilen.
Voorbeeld:
DLL Hijacking kan gebruikt worden door een persoon op dezelfde pc maar met een ander user account.
DLL Planting via een SMB share, bijvoorbeeld bij openen van een bepaalde bestandsextensie, verlegt de grens al naar het LAN.
DCOM/COM/ActiveX kunnen in sommige gevallen vanaf het internet de gewenste impact hebben.
Je weet dat als je je laptop 'encrypted' hebt dat 'dichtklappen met wachtwoord' niet voldoende is?
Encryptie heeft pas zin bij volledige uitschakeling van je laptop (of hibernate (geheugen op schijf en ram leeg))
De kans is klein dat zowel KeepassX en KeepassXC onder Linux deze kwetsbaarheid hebben. Zover ik weet draait Keepass (versie 2 dan) op .NET, en ik heb vernomen (weet niet of dit ook klopt, dus ik kan niet aan enige fact-check doen!) KeepassX en KeepassXC hebben geen afhankelijkheden van Mono (de open implementatie van .NET), en is het minder waarschijnlijk dat ditzelfde trucje uit te halen is onder Linux.
In theorie zou dan betekenen dat:
1. Alle applicaties die .NET (onder Windows) of Mono (onder Linux) nodig hebben mogelijk deze kwetsbaarheid bevatten
2. Keepass versie 1 in dat geval niet getroffen is door deze kwetsbaarheid omdat het niet afhankelijk is van .NET
Uiteindelijk is alle software te compromitteren. Net als dat elke kluisdeur te openen is. Dat is de werkelijkheid van alledag. Het enige dat je kunt doen is het risico afwegen van hetgeen je doet met je software. Ik zal bijvoorbeeld nooit en te nimmer voor een wachtwoordmanager kiezen die alles in de cloud flikkert. Mijn wachtwoorden zitten in een .kdbx-bestand (gebruik zelf ook KeepassX en KeepassXC (allebei dus)), en dit bestand zit netjes "opgesloten" in een VeraCrypt-container. Dat voorkomt uiteraard niet dat mijn hoofdwachtwoord in het geheugen geladen wordt, maar het zorgt wel voor een extra veiligheidslaag. Dus ook al zou de kwetsbaarheid ook in KeepassX en KeepassXC zitten, dan hebben ze er nog weinig aan omdat ze ook door die Veracrypt barrière heen moeten breken. En fysiek achter mijn computer moeten zitten, óf malware moeten fabriceren die onder Linux werkt. En dàt wordt dan wel een lastig verhaal om de boel te kraken....
Trouwens: Hoi L4. ;)
De kans is klein dat zowel KeepassX en KeepassXC onder Linux deze kwetsbaarheid hebben. Zover ik weet draait Keepass (versie 2 dan) op .NET, en ik heb vernomen (weet niet of dit ook klopt, dus ik kan niet aan enige fact-check doen!) KeepassX en KeepassXC hebben geen afhankelijkheden van Mono (de open implementatie van .NET), en is het minder waarschijnlijk dat ditzelfde trucje uit te halen is onder Linux.
In theorie zou dan betekenen dat:
1. Alle applicaties die .NET (onder Windows) of Mono (onder Linux) nodig hebben mogelijk deze kwetsbaarheid bevatten
2. Keepass versie 1 in dat geval niet getroffen is door deze kwetsbaarheid omdat het niet afhankelijk is van .NET
Uiteindelijk is alle software te compromitteren. Net als dat elke kluisdeur te openen is. Dat is de werkelijkheid van alledag. Het enige dat je kunt doen is het risico afwegen van hetgeen je doet met je software. Ik zal bijvoorbeeld nooit en te nimmer voor een wachtwoordmanager kiezen die alles in de cloud flikkert. Mijn wachtwoorden zitten in een .kdbx-bestand (gebruik zelf ook KeepassX en KeepassXC (allebei dus)), en dit bestand zit netjes "opgesloten" in een VeraCrypt-container. Dat voorkomt uiteraard niet dat mijn hoofdwachtwoord in het geheugen geladen wordt, maar het zorgt wel voor een extra veiligheidslaag. Dus ook al zou de kwetsbaarheid ook in KeepassX en KeepassXC zitten, dan hebben ze er nog weinig aan omdat ze ook door die Veracrypt barrière heen moeten breken. En fysiek achter mijn computer moeten zitten, óf malware moeten fabriceren die onder Linux werkt. En dàt wordt dan wel een lastig verhaal om de boel te kraken....
Trouwens: Hoi L4. ;)
Hoi Unix4 ;-)
Ik gebruik geen software die afhankelijk is van mono op Manjaro. Ik draai wel KeePassXC portable op Windows 10 Enterprise van de baas. Verwacht ook geen problemen maar ik was gewoon nieuwsgierig en ook verbaasd dat KeePassXC niet meegenomen was in de test.
En ik ben lekker weer terug als Linux4 want ik laat me niet wegjagen en zal altijd mijn persoonlijke mening over alles laten horen. Nog bedankt voor je support vorige week, je was de enige...
Heb je het actief dan zal ergens die informatie er moeten zijn.
Aangezien memory het snelste werkt kun jet daar verwachten.
Niets nieuws elk systeem werkt zo.
Het wordt erger als je wel automatische processing eist maar geen veilige geïsoleerde opslag hebt. Hardcore users password certificaten het werkt en is snel te leveren.
Moet je bekend voorkomen met iot en shodan.
Heb je het actief dan zal ergens die informatie er moeten zijn.
Aangezien memory het snelste werkt kun jet daar verwachten.
Niets nieuws elk systeem werkt zo.
Het wordt erger als je wel automatische processing eist maar geen veilige geïsoleerde opslag hebt. Hardcore users password certificaten het werkt en is snel te leveren.
Moet je bekend voorkomen met iot en shodan.
Mee eens, alleen de laatste zin slaat weer helemaal nergens op. Bizar hoe je weer eens geheel off-topic IoT bij een probleem over password managers betrekt.
Ah, je zegt het zelf: je gebruikt geen Mono. KeepassX en KeepassXC zijn allebei gelukkig niet op een applicatieframework gebouwd en werken volledig zelfstandig. Dat verkleint het risico op veiligheidsissues wel. Al moet er altijd in het achterhoofd gehouden worden dat er ergens heus nog wel een verborgen issue te vinden is.
Nog bedankt voor je support vorige week, je was de enige...
Bijvoorbeeld Lastpass in combinatie met Authenticator?
Gr,
CCINL
Bijvoorbeeld LastPass in combinatie met Authenticator? Is dat veilig?
Gr,
CCINL
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?