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.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.