Kwetsbaarheid in wachtwoordmanager KeePass, oplossing volgt in juni

Door een kwetsbaarheid in wachtwoordbeheerder KeePass is het voor aanvallers mogelijk om het hoofdwachtwoord van gebruikers in plaintext op te halen. De ontwikkelaar werkt aan een oplossing, al verschijnt deze pas ten vroegste in juni.

Beveiligingsonderzoeker 'vdohney' publiceerde een proof-of-concept voor de kwetsbaarheid op GitHub. De kwetsbaarheid, die gevolgd kan worden via CVE-2023-3278, kan met deze tool worden uitgebuit. Aanvallers die toegang hebben tot de pc van een gebruiker kunnen een geheugendump uitvoeren om het hoofdwachtwoord grotendeels in plaintext weer te geven, zelfs als de database vergrendeld is of het programma is afgesloten. De eerste of eerste twee tekens van het wachtwoord ontbreken, maar kunnen worden geraden om het hele wachtwoord te achterhalen.

Naar verluidt zijn alle bestaande versies van KeePass 2.x getroffen door de kwetsbaarheid. Een oplossing volgt in versie 2.54, die in juni wordt verwacht. Bleeping Computer waarschuwt dat het hoofdwachtwoord ook na de release van de nieuwe versie mogelijk nog achterhaald kan worden, omdat de bestanden in het geheugen worden opgeslagen. Gebruikers moeten voor de zekerheid mogelijk het besturingssysteem van hun pc opnieuw installeren en bestaande gegevens overschrijven.

KeePass is een gratis, opensource wachtwoordmanager. Eerder dit jaar was er ook al sprake van een kwetsbaarheid in KeePass, zo waarschuwde het Nederlandse Cyber Security Centrum. In eerste instantie wilde de ontwikkelaar het lek niet dichten, maar uiteindelijk is dit toch gebeurd.

Reacties (229)

[Anoniem: 111246]

Een pc-reinstall is enigsinds overdreven...
Wanneer je het item leest, staat er dat je je swap & hybernation file moet deleten (+ eventuele memory.dmp), etc.
En dat daarbij het advies is om de sectoren op je HDD te overschrijven zodat data recovery lastiger wordt. Dat hoeft echt niet door een re-install...

Daarbij... Wanneer je je disk ge-encrypteerd hebt (met bijv. Bitlocker) kun je data recovery sowieso al vergeten wanneer je de decryption key niet hebt. Je mag toch hopen dat een Password database op een encrypted disk wordt opgeslagen...

[Reactie gewijzigd door Anoniem: 111246 op 22 juli 2024 22:47]

[m_snel]

Ja je niet gewoon je ww aanpassen lijkt me veel makkelijker.

[Dominobit]

Hahaha, dat dat niet in de tekst staat. Geniaal .

[vliegendekat]

Ja je niet gewoon je ww aanpassen lijkt me veel makkelijker.

Wel eerst even updaten als de oplossing er is.
Tot die tijd blijft het lastig.

Maar als de update die dit oplost er is, dan is het inderdaad veel verstandiger om gewoon het wachtwoord aan te passen.

[Clemens123]

Het gaat er om waar je OS van draait (dus waar de swap / hybernation wordt opgeslagen), niet waar je passwoord database opgeslagen is.

[Anoniem: 111246]

Bitlocker encryptie gebeurd inmiddels standaard bij Windows 11 (onder bepaalde condities).
Bij mij is iig alles encrypted.

Ref:
https://www.pcworld.com/a...ight-be-a-good-thing.html

[Reactie gewijzigd door Anoniem: 111246 op 22 juli 2024 22:47]

[asing]

Bitlocker is in deze een beetje een wassen neus. Ja, de data op de schijf is versleuteld. Deze wordt echter direct door het systeem zelf ontsleuteld met behulp van de TPM chip. Een aanval gaat op Windows niet tegen de encryptie maar tegen het OS.

LUKS/DM-Crypt doet het anders, daar moet je bij het opstarten een wachtwoord ingeven om je volume te ontgrandelen. Dat is een stuk lastiger dan een volledig geboot OS.

Nu kan je bij Bitlocker ook gaan voor een code om het volume te ontsleutelen maar dat is niet zo gebruikersvriendelijk. Linux kan sinds kort ook overweg met de TPM chip dus je zou ervoor kunnen kiezen om die hele code achterwege te laten.

Moraal van het verhaal : Bitlocker gaat je in dit geval niet redden.

[closefuture]

Bitlocker is in deze een beetje een wassen neus. Ja, de data op de schijf is versleuteld. Deze wordt echter direct door het systeem zelf ontsleuteld met behulp van de TPM chip.

Wassenneus is FUD. Je kunt bijvoorbeeld niet even een Linux of Windows PE USB stick booten en dan op de Windows partitie rondneuzen. De TPM zal enkel werken met de Windows installatie op de HDD (dankzij measured boot [1]). Dus als je iemands notebook gestolen hebt zul je een gebruikers account van de Windows installatie moeten kraken. Dat is best lastig als een ander OS booten dus geen optie is.

[1] https://www.anoopcnair.co...ng-windows-measured-boot/

[Reactie gewijzigd door closefuture op 22 juli 2024 22:47]

[asing]

Je hebt duidelijk het punt gemist. Het feit dat Windows zo is ingericht dat de disk automatisch ontsleuteld wordt en Windows start is de kwetsbaarheid. In het geval van een pincode dien je de versleuteling te kraken. De attack surface van de versleuteling is zeer klein. Als je OS doorstart wordt je attack surface ineens het OS en niet de versleuteling an sich.

De hamvraag die volgt is natuurlijk : is het OS kwetsbaar? Kan je erin komen? Als ik in mijn werk zie hoeveel kritieke fouten er maandelijks worden opgelost, dan zou het zomaar kunnen. Het kon in ieder geval op deze manier. Of je trekt de code zo van de TPM chip zelf. Want BitLocker gaat in plain text. Ik heb IC ontwerpen op de hogeschool gehad dus dit zou mij wel lukken. Dan is er ook nog de Rubber Ducky en daarnaast zijn er vast nog onbekende methodes.

Het probleem is simpel : de attack surface is te groot. Implementatiefouten worden gemaakt en de insteek is "het moet voor de gebruiker zo makkelijk mogelijk zijn". Je kan er heel makkelijk een fort Knox van maken door Bitlocker een pin code te laten vragen maar dat wordt bijna nooit gedaan.

Het enige wat men nu doet is het moeilijker maken. Zo moeilijk dat velen zullen afhaken.

[closefuture]

Je hebt duidelijk het punt gemist.

Er zit nogal een forse nuance verschil tussen iets een "wassenneus" noemen en dat een oplossing een groter aanvalsoppervlak heeft.

Je kan er heel makkelijk een fort Knox van maken door Bitlocker een pin code te laten vragen maar dat wordt bijna nooit gedaan.

Als we jouw lijn volgen en custom IC's e.d. als een valide aanvals vector beschouwen dan kan je dus nooit een fort knox maken van een TPM. Er zijn namelijk plenty kwetsbaarheden in de meeste TPM implementaties waarmee je de key eruit kunt halen. Ongeacht of je een PIN erop gezet hebt.

Dan is het enkele wat "geen wassenneus is" disk encryptie met een goede lange passphrase (die via een PBKDF een sleutel oplevert) omdat dan de key zich dan niet op de PC bevind (en dan valt er niks te stelen). Of je een externe key gebruiken zoals een Yubikey en die uit je PC trekken als je wegloopt van je PC.

[Reactie gewijzigd door closefuture op 22 juli 2024 22:47]

[asing]

Het doel van encryptie (Bitlocker, Luks, Veracrypt) is om de inhoud van de schijf versleuteld te houden voor onbevoegden. Zowel Luks als Veracrypt voldoen hieraan. Eerst je ontsleutelwachtwoord en anders kom je niet verder. Luks staat 3 pogingen toe, daarna mag je opnieuw opstarten. Veracrypt doet ongeveer hetzelfde.

Beiden doen dus precies wat ze beloven. De attack surface is zeer klein en brute forcen kan ook erg lang gaan duren.

De implementatie van Bitlocker zit iets anders in elkaar. Microsoft wil dat het allemaal zo makkelijk mogelijk wordt en een pin code bij het opstarten is het tegenovergestelde van makkelijk. Dus het ding start zonder pin code en vervolgens is alle data op de disk ontsleuteld. De sleutel zit namelijk vast gesoldeerd op het moederbord. Daarna hoef je alleen Windows zelf maar te verslaan en je bent binnen. De encryptie was al verslagen toen de machine startte.

De oplossing is in dit geval een pin code bovenop de TPM, maar die moet je apart aanzetten en dat kan alleen met Windows 11 Pro of hoger. De Home editie kan de schijf wel versleutelen maar heeft een uitgeklede versie van Bitlocker en kent volgens mij geen pin code.

"versleuteld" is in dit geval de wassen neus. Het is namelijk niet meer versleuteld als je de machine aanzet.

[Cerberus_tm]

Wordt bij Bitlocker de hele schijf al ontsleuteld voordat je het wachtwoord voor je Windows-gebruiker hebt ingegeven?

[PD2JK]

Correct, het ontsleutelen gebeurt door de bootloader op een kleine onversleutelde systeempartitie die nog vóór de versleutelde Windows partitie zit.

[Sandor_Clegane]

Anders is het lastig booten niet?

[Cyberpuppy]

Op zich correct wat je schrijft. Echter bij Windows kom je enkel bij het loginscherm. Dan moet je eerst maar eens zien een gebruiker/wachtwoord te raden. Want in dit scherm kun je niet zomaar een ander proces of iets starten. Wordt dus nogal lastig vooropgesteld natuurlijk dat de gebruiker een beetje zinnig wachtwoord heeft gebruikt. Daarnaast begint Windows ook moeilijk te doen na een aantal mislukte inlogpogingen. Dan duurt het echt wel even voor je nog eens mag proberen.

Vanuit beveiliging benader ik het meestal anders. Iemand die een pc/laptop steelt is meestal niet uit op de data maar op de hardware. Die gaat niet heel veel moeite doen om schijven en wachtwoorden te decrypten. Een hacker zal meestal geen toegang hebben tot het fysieke device en dus zie ik het beschreven probleem dat ook op te lossen is met een simpele reboot. Veel succes om remote de hele schijf te gaan dumpen en daarin op zoek te gaan naar restjes van een opgeslagen wachtwoord.

[Saven]

Wat en onzin dit. Bitlocker is absoluut geen wassen neus. Tenzij je inderdaad geen toegangsode vereist

Ontsleutelen is helemaal niet onvriendelijk(er) op Windows (dan Linux bijv. en werkt in de basis hetzelfde) Dat kan met een PIN of password en geef je alleen bij boot even snel in. Er zit een retry limit op waardoor je zelfs met een PIN van van 6 cijfers erg veilig zit en er maar een kans van zo'n 1 op 32.000 is dat je die goed gokt. Niks aan het handje dus.

[asing]

Het probleem is die pin code (of toegangscode zoals jij heb denk ik noemt). Die zal bijna niemand aanzetten. Althans, ik ken niemand. Je voelt je dus veilig want je bestanden zijn versleuteld. Maar zodra je je PC aanzet en tegen je login aan kijkt niet meer.

Het is als een enorm intimiderend hangslot maar het wordt geopend zodra je de machine start. Dat noem ik een wassen neus.

[eitjeappeltje]

Het login-scherm is toch nog steeds bescherming tegen ongewenste datatoegang? Het gaat er volgens mij vooral om dat als je de SSD uit de computer haalt en aan een andere computer hangt je er dan niks mee kan. Je hebt de originele installatie nodig met dus het wachtwoord daarvan om de data te ontsluiten voor jou als eindgebruiker.

[campr112]

Alleen is het zo dat er veel mogelijkheden zijn om in te breken op een draaiend OS.

[Saven]

Volgens mij valt dat wel mee. Je kunt niet met een usb booten en dan het password aanpassen ofzo, want die schijf is dan nog encrypted. Je kunt dus ook niet Utilman hernoemen naar cmd ofzo; los van dat vrijwel geen enkele installatie die toegankelijkheidsopties op het loginscherm geactiveerd heeft

Alleen als je genoeg skills hebt voor een cold boot attack en dat daadwerkelijk weet te gebruiken, heb je daar wat aan. Maar op het moment dat iemand met zoveel kennis het heeft voorzien op jouw data/apparaat, zou ik me om hele andere dingen druk maken

[Cyberpuppy]

Als de gebruiker is ingelogd dan wel ja, maar vanaf enkel het loginscherm is het toch al een heel stuk lastiger. Daar zul je toch eerst langs moeten voordat je iets kunt gaan ondernemen

[trisje]

sorry maar geef u eens aan hoe u de disk zou kunnen uitlezen nadat men de computer heeft opgestart. Als men remote probeerd. heeft men een paswoord nodig, als Men met een usb stick opstart loop men tegen bitlocker key aan. en wat is het verschil tussen een pincode van bitlocker mocht men die aan zetten en de code van andere versleutel programma's. Als u nu is bitlocker zou kraken, dan kan u het een wasseneus noemen, voorals nog is het een prima methode om de gegevens te beschermen.

[asing]

Als de computer is opgestart wordt Windows zelf het attack surface. En in het verleden bleek het niet onmogelijk om via het login scherm in Windows te komen zonder het wachtwoord van de gebruiker te kennen. Die lekken zullen allemaal gedicht zijn maar het kan maar zo dat er nog een paar in zitten die wij nog niet kennen. Dat heten zero-days en de betere zijn echt geld waard.

Een pincode helpt omdat je die eerst moet raden voor het OS start. Dat is vele malen moeilijker dan het OS aanvallen.

[trisje]

hoeveel van die lekken zijn er in de afgelopen 30 jaar van windows en andere besturing systemen geweest ? en hoeveel verwacht je de komende jaar te vnden ? Het is een nul issue voor de meeste van ons. jouw uitspraak is een wasse neus.

[OruBLMsFrl]

Meerdere computers privé zo zelf gedaan, als ook op de bedrijfslaptop wordt Bitlocker pre-boot pin gepushed. Duidelijk andere werelden. Begrijp het wel hoor, is allemaal optioneel en nergens krijg je dit aanbevolen vanuit Microsoft zelf in het OS, dus het zal vrij weinig toegepast worden tot je in het enterprise segment komt.

Die bitlocker pre-boot PIN is met al dan niet local group policy, bovendien alfanumeriek toegestaan te maken, tot een maximum van 20 karakters kun je dan als je die optie activeert. Blijven allemaal extra opties, maar het werkt wel goed en veilig als je die toepast. Veel NAS systemen zelfde overigens, daar bij iig QNAP heb je ook vinkjes van 'remember encryption key'. Lekker uit laten staan, zo vaak reboot die niet, en bij diefstal ben je daar extreem blij mee, dat je die vinkjes lekker uit hebt laten staan inderdaad

[Clemens123]

Bij mijn weten gebeurt dat standaard niet

[mjl]

Klopt. Bij installatie zal je dan ook de recovery key moeten opslaan (doe ik dan uiteindelijk weer in KeePass).

[R4gnax]

Hopelijk niet op hetzelfde systeem, dan.
Want dan heb je een kip-ei situatie gemaakt.

[mjl]

De database staat in de cloud, dus ik kan altijd ergens bij de keys

[supersnathan94]

Nog steeds niet?

Man man man. Heeft windows eindelijk een serieus goede feature voor beveiliging van in store data staat het niet default aan.

Apple heeft nu al 20 jaar filevault en nu al 10 jaar FV2 wat default full disk encryption doet. Dat is opt out in de install-wizard, maar staat default aan.

Zal maar snel gaan kijken of ik het onder windows 11 nu aan heb staan, want dat is wel verdraaid handig.

[Clevergyno]

Gebeurt helemaal niet standaard

[Carlos0_0]

Gebeurt standaard als je een Microsoft account gebruikt staat er, heb jij offline acciun5 gemaakt dan niet.

If you haven’t noticed BitLocker on your new computer it may be because, well, you skipped creating a Microsoft account and used a local account. If you did that, BitLocker is not turned on.

[supersnathan94]

Why?

Dat maakt echt zero sense.

Weer een deterrent om local accounts aan te maken zeker.

[GoBieN-Be]

Omdat met een Microsoft Account de recovery key online opgeslagen wordt in je account.
Zomaar bitlocker aanzetten zonder dat de recovery key ergens veilig opgeslagen is, lijkt mij geen goed idee.

[supersnathan94]

Daar heeft bitlocker normaal een hele procedure voor die er dan voor zorgt dat je het uitprint of extern opslaat. Kan dus prima. Doet macOS ook.

[batjes]

Kan toch ook prima, het is nog steeds mogelijk om met een lokaal account bitlocker te gebruiken. Het staat alleen niet standaard aan.

[Metalfreak]

En jij als Tweaker bent je ervan bewust dat je het ook daadwerkelijk uitprint of extern opslaat, de gemiddelde gebruiker denkt "het zal wel, VOLGENDE!" en heeft vervolgens nooit meer toegang tot die key.

[supersnathan94]

Mwah. MacOS laat je niet doorgaan zonder dat je het spulletje geprint hebt of elders hebt opgeslagen. Ook voor 2FA enablen op icloud account MOET je een printje hebben gemaakt.

Aan de andere kant heb ik ook echt nog nooit die recovery key nodig gehad, maar ik gebruik m’n accounts ook dagelijks dus dat wachtwoord vergeet ik niet even zomaar.

Het enige nadeel is dataloss bij overlijden. Digitaal nalatenschap is nog steeds iets waar ik wat op wil vinden.

[asing]

Ik heb een dual boot systeem met Linux en Windows. Linux is mijn daily driver en als het echt niet anders kan pak ik Windows erbij. Linux heeft Luks, en ik vond het wel een goed idee om ook Windows te voorzien van Bitlocker. Dat gedaan, en de code opgeslagen op mijn NAS. Ja ik heb een local account op Windows.

Anyway, iedere keer als ik Windows wilde starten of nodig had was het ding die code weer vergeten. Geen idee waarom, maar ik kon iedere keer die code opvissen uit mijn NAS en zo kon ik verder. Bij elke reboot in Windows ging het dan weer goed tot ik het OS weer een tijd niet gebruikte.

Dus het is zeker handig om die code ergens op te slaan.

[Metalfreak]

Dat snap ik en ik heb ook ergens een blaadje in een klapper met de Bitlocker code. Maar een "gemiddelde gebruiker" heeft nooit dergelijke scenario's als jij beschrijft en weet zelfs niet eens wat Bitlocker überhaupt is, dat kun je ze vandaag 10x vertellen, morgen zijn ze het weer vergeten. De gemiddelde gebruiker wil gewoon dat het werkt zonder over dergelijke zaken na te denken. De spijt komt meestal ergens na de zonde, maar zij zijn ook niet bezig met "wat als" scenario's.

[Carlos0_0]

Je kan het nog steeds gebruiken met local accounts, doe geniet installaties.
Even gpedit eventueel instelling wijzigen, en bitlocker openen vanuit start menu en de gewenste optie kiezen.

[eitjeappeltje]

Ik heb hier een local account en Bitlocker stond toch echt gewoon automatisch aan.

[Carlos0_0]

Zal wel weer een bug zijn geweest als bitlocker Automatisch kwam

https://nl.hardware.info/...oorzaakt-flinke-problemen

Net zoals in de laatste patch updates schijnbaar ook veel problemen weer zitten, of elke versie upgrade weer voor printer problemen etc zorgt 😂.

[Clevergyno]

Ah dat verklaart het ja. Local account zal het altijd blijven hier

[SebasFM]

Is het aanzienlijk aanpassen van je master wachtwoord zodra de bugfix uit is, ook een optie om niet je hele swap/hybernation file te slopen? Wil niet straks meerdere Windows servers om zeep helpen.

[Bliksem B]

Je mag toch hopen dat een Password database op een encrypted disk wordt opgeslagen...

Nee nooit over nagedacht (op mijn desktop pc althans). Ik sync het ook altijd naar mijn eigen NAS, die is ook niet encrypted. Het idee van een password manager is dat deze de encryptie toepast.

Toegang tot het hybernation bestand, is volgens mij niet heel moeilijk te verkrijgen? Zowel via hacken als fysieke toegang tot de harde schijf. Een keylogger (wat het zelfde kan bewerkstelligen), lijkt me lastiger uit te voeren. Als je een laptop steelt, kun je dus nu in theorie een flink gedeelte van wachtwoorden "gemakkelijk" uitlezen.

[TheTeek]

waarom niet gewoon het hoofdwachtwoord wijzigen na de update?

M_snel was me te snel af in de reacties zie ik...;)

[Reactie gewijzigd door TheTeek op 22 juli 2024 22:47]

[twiFight]

Ik vond de uitleg van KeepassXC wel erg duidelijk om te snappen wat er nu gebeurt, dus die quote ik hier even voor anderen die snel willen snappen wat de exploit is. Ook te vinden via de link van @MadEgg

The flaw exploited here is that for every character typed, a leftover string is created in memory. Because of how .NET works, it is nearly impossible to get rid of it once it gets created. For example, when "Password" is typed, it will result in these leftover strings: •a, ••s, •••s, ••••w, •••••o, ••••••r, •••••••d. The POC application searches the dump for these patterns and offers a likely password character for each position in the password.

[Franckey]

Een string in .NET is immutable, elke aanpassing levert een nieuwe string op. Oplossingsrichting zal denk ik zijn om de invoer niet in een string op te slaan. Men gebruikt blijkbaar al een custom control voor passwords, dat zal dan aangepast moeten worden.

Persoonlijk vind ik het niet zo'n issue omdat misbruik hiervan vooral hypothetisch is. Als je dat kan, kan kan je, zoals al genoemd, ook een key logger installeren.

[supersnathan94]

Een String in Java is ook immutable, maar toch lijkt Java hier wel anders mee om te gaan dan .NET.

[latka]

Java gebruikt standaard een char[] voor wachtwoorden. Die zijn wel mutable en kun je dus clearen. Klinkt als een oversight in de .net wereld als men voor wachtwoorden strings gebruikt.

[supersnathan94]

Goed punt. Die was ik even vergeten. voordeel is dan ook dat je dat niet even per ongeluk naar console logt toch een pluspuntje.

[Herko_ter_Horst]

Huh wat? Je kan een char[] net zo goed (naar de console) loggen als een String.

[supersnathan94]

Dat kan wel, maar daarvoor moet je wel wat extra’s doen dan een “sout(char[]variabele)”. Anders krijg je namelijk alleen de pointer.

Misschien dat SLF4J het automagisch wel omzet, maar dat weet ik niet.

[Herko_ter_Horst]

Hoe wachtwoorden worden opgeslagen, is een keuze van de programmeur, niet van de taal. Je kan prima in Java een String gebruiken en in .Net een char[] om een wachtwoord in op te slaan. Dit is geen "oversight in de .net wereld", maar een oversight in KeePass.

[latka]

Technisch heb je gelijk, maar het maakt nogal wat uit hoe de standaard API omgaat met wachtwoorden omdat de eigen oplossing eerder gebaseerd zal zijn op het patroon in het onderliggende platform. Dus in Java is het: https://docs.oracle.com/j...ack/PasswordCallback.html (char[]) en in .Net is het een String (https://learn.microsoft.c...aspnet/mt151562(v=vs.108)). Dit zijn 2 willekeurige APIs dus wellicht dat het elders in .Net wel op char[] gebaseerd is, maar als ik snel wat bij elkaar wil programmeeren en voor inspiratie even kijk naar het platform op zoek naar best-practices dan kom ik bij .Net van een koude kermis thuis, zo lijkt het.

[Mel33]

The POC application searches the dump for these patterns and offers a likely password character for each position in the password.

Om daar dan even op in te gaan. POC zal met een stuk Ai vast wel tot een 99% score kunnen komen.

Kan het stuk(je) geheugen wat .NET nodig heeft. Niet in een soort secure RAM enclave draaien? Link met een stuk diepgang over ram-beveiliging

Het zal niet lang meer duren voordat Ai exploids gaat/kan zoeken.

[Reactie gewijzigd door Mel33 op 22 juli 2024 22:47]

[Cyb]

Gebruikers moeten voor de zekerheid mogelijk het besturingssysteem van hun pc opnieuw installeren en bestaande gegevens overschrijven.

In de bron wordt het wat genuanceerder beschreven:

Even after the new version is released, the master password may still be stored in memory files. The researcher warns that to be 100% safe that it is not lurking on the system, you would need to delete your system's swap and hibernation files, format your hard drive using the "overwrite data" mode to prevent data recovery, and do a fresh OS install.

For most, though, restarting the computer, clearing your swap file and hibernation files, and not using KeePass until the new version is released are reasonable safety measures for the time being.

En dan nog is een fresh os install overdreven, je kan namelijk ook een free space wiper gebruiken. Deze hebben vaak ook gestandaardiseerde overwrite methodes, wat het nog veiliger maakt.

Ook kan een gemiddelde keylogger hetzelfde bereiken.
Dus als je KeePass niet gaat gebruiken vanwege deze exploit, dan doe je dat uit vrees dat lokale malware je masterpass kan onderscheppen door deze exploit. Maar zelfs zonder deze exploit, zou een keylogger hetzelfde kunnen bereiken. Met andere woorden: er is niet echt een flink verhoogd risico t.o.v. normaal. Desalniettemin is het uiteraard goed om dit te fixen.

Ook zou je, indien KeePass belangrijke wachtwoorden bevat, niet louter en alleen authenticatie moeten berusten op een masterpass, maar MFA moeten toepassen, bijv. met een Yubikey.
Wel zou het gevaarlijker kunnen worden indien er ook exploits komen, waarmee hardware tokens kunnen worden omzeilen, wat misschien ook wel mogelijk is, afhankelijk van of er nog meer gerelateerde kwetsbaarheden zijn.

[Reactie gewijzigd door Cyb op 22 juli 2024 22:47]

[Nickkname]

Misschien een domme suggestie, maar als je geen fresh OS install wil doen, kun je dan niet gewoon je hoofdwachtwoord veranderen na de fix? (als je je echt zorgen maakt)

[Cyb]

Dat kan, en is een goede suggestie. Wel bestaat er de kans dat op een gecompromiteerd systeem dan alles al is buitgemaakt, voordat de fix er is. Als je niet wilt wachten op de fix, dan kan je overstappen op KeePassXC, welke meestal compatible is met KeePass files, en vervolgens het wachtwoord wijzigen.
Dan hoef je inderdaad ook geen geheugen dump files etc te verwijderen, en ook geen free disk space overwrites uit te voeren (waar een fresh OS reinstall onder valt).

[Reactie gewijzigd door Cyb op 22 juli 2024 22:47]

[YopY]

Dat kan, maar KeePass maakt gebruik van een los bestand; als dat bestand gejat is voordat je je wachtwoord aangepast hebt (en als iemand toegang heeft tot het geheugen om het wachtwoord eruit te halen zal dat zeer waarschijnlijk zijn) ben je alsnog laatst.

Als je denkt dat je wachtwoorddatabase gestolen is moet je de wachtwoorden van alle diensten die daarin staan opnieuw instellen.

[Bliksem B]

[...]
Ook kan een gemiddelde keylogger hetzelfde bereiken.
Dus als je KeePass niet gaat gebruiken vanwege deze exploit, dan doe je dat uit vrees dat lokale malware je masterpass kan onderscheppen door deze exploit. Maar zelfs zonder deze exploit, zou een keylogger hetzelfde kunnen bereiken. Met andere woorden: er is niet echt een flink verhoogd risico t.o.v. normaal. Desalniettemin is het uiteraard goed om dit te fixen.
[...]

Precies mijn gedachte: Bliksem B in 'Kwetsbaarheid in wachtwoordmanager KeePass, oplossing volgt in juni'
Echter, wanneer je fysieke toegang hebt tot een harde schijf een apparaat, gaat dit dus niet op. Als je dacht dat je wachtwoorden veilig waren wanneer je laptop wordt gejat (en je hebt geen schijf encryptie toegepast), is dat nu dus niet meer het geval.

[Cyb]

Goed punt, dat jatten, die had ik niet meegenomen. Ik gebruikte daarom voor de zekerheid "niet echt flink verhoogd", aangevende dat het wel een verhoogd risico is, er is immers een ander type attack vector bijgekomen. Ook bij het jatten is het overigens nog maar de vraag of het masterpass achterhaald kan worden, het hangt af of de computer nog aan is, of dat er geheugendumps zijn (waaronder swaps, page files en hibernate).

Maar eigenlijk zou iedereen die belangrijke passworden bewaart, sowieso MFA erbij moeten gebruiken.

Persoonlijk vind ik de wijze waarop dat KeePass team is omgegaan met nieuws: NCSC waarschuwt voor kwetsbaarheid in KeePass die ontwikkelaar niet w... eigenlijk nog wel schokkender. Daarbij was MFA zelfs niet veilig, en de hack was zeer eenvoudig uit te implementeren.

[Karel_Appel]

SSD's vinden een free space wiper niet leuk.
Een secure erase van een SSD doe je toch het best in 1 keer volledig? (dus een verse installatie daarna)
Of zijn daar inmiddels wel goede alternatieven voor?

[supersnathan94]

Mwah. Zelfs als je 35 cycles doet is dat slechts 35 writes per cell.

Voor eenmalig gebruik is dat geen probleem met een beetje fatsoenlijke SSD.

[vgroenewold]

Het verbaast mij dan weer dat er uberhaupt nog voldoende mensen gebruik van maken, dit is de zogenaamde nagel in de doodskist. Sowieso is openheid al 1 van de meest belangrijke zaken om dit soort software (oftewel, neem de eerdere bug sneller serieus), maar nu dit ook nog.

edit: Ik heb mij ook nog verward met een andere manager, ik had niet door dat deze offline was. Excuus!

[Reactie gewijzigd door vgroenewold op 22 juli 2024 22:47]

[KeiFront]

Wel sterk overdreven reactie, er is ten eerste lokale toegang nodig om dit te exploiteren en het probleem is al gefixt zie volgende link voor snapshot versie en uitleg https://sourceforge.net/p...f3438e6283/?limit=25#0829

When running on Windows, KeePass now calls Windows API functions for getting/setting the text of the text box directly, in order to avoid the creation of managed strings. For most lengths, no "●...●?" fragments occur in the process memory anymore, but for a few lengths, there still is one (maybe Windows is occasionally allocating a new buffer for the text box content?).

Probleem wordt dus veroorzaakt door Windows API die gegevens lekt.

Direct link naar versie die probleem fixt/omzeilt: https://keepass.info/filepool/KeePass_230507.zip

[Reactie gewijzigd door KeiFront op 22 juli 2024 22:47]

[vgroenewold]

Ja inderdaad, mea culpa!

[telenut]

als de Windows Api verantwoordelijk is... hebben dan niet heel veel programma's hier last van?

[Emcee]

Wat zijn goede alternatieven?

[vgroenewold]

Bitwarden doet het goed, 1password idem. Het is voor mij met name van belang hoe er wordt omgegaan als er wat gebeurt.

[xzaz]

Hoe in hemelsnaam is een online repro veiliger dan een offline repro? Wat als ze van de ene op de andere daf stoppen? Of als het offline is?

Ik sla mn wachtwoorden nog liever plaintext op dan dat ik ze bij iemand anders onderbreng.

[estej]

Bitwarden is relatief makkelijk zelf te hosten!
Komt met een bash script wat het starten, stoppen en updaten van de server software doet.
Draai het zelf al jaren, en nog nooit problemen gehad

[William_H]

Ik denk dat 99% van de mensen afhaakt bij "Bash script".
Dan kan je beter adviseren om een offline kluis te blijven gebruiken.

[The Zep Man]

Bitwarden is relatief makkelijk zelf te hosten!

Al ga je voor selfhosting, ga dan voor Vaultwarden. Lichter dan Bitwarden, meer functionaliteit dan de gratis versie van Bitwarden, en compatibel met Bitwarden-clients.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 22:47]

[Neo_TGP]

Nou, de kans dat er iets op een endpoint zelf mis gaat acht ik aanzienlijk groter dan een centraal gehoste en beveiligde omgeving, al was het maar omdat er op een endpoint over het algemeen meer software draait en er dus een grotere kans op (eventueel nog niet ontdekte) kwetsbaarheden bestaat.

Dus ieder scenario heeft zijn plek, maar de aanname dat zaken lokaal hebben staan per definitie veiliger zou zijn kan wel wat meer nuance gebruiken.

[batjes]

De kans dat ik getarget wordt om dit soort specifieke exploits op los te laten is dan weer minimaal. Terwijl de cloud jongens 24/7 doelgericht onder vuur liggen.

Keer op keer blijken die online partijen de beveiliging toch niet helemaal op orde te hebben. No thanks.

Doe mij maar zo'n open source project zoals Keepass, dat ik zelf in beheer heb.

[arbraxas]

Kans dat ze Arbraxas op de korrel nemen? 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 ofzo.
De kans dat die online diensten aangevallen worden? 100%

Ook al is de kans bij mij persoonlijk groter op een fuckup als bij de profs, de kans dat het opgemerkt word is bijna verwaarloosbaar. Komt bij dat de reden dat ik WW moet aanpassen, altijd maar dan ook altijd is om dat iemand anders database (webshop, verzekeraars, banken) gehacked is. Waarom? Die zijn veel interressanter. Arbraxas gehacked? 1 persoon aan gegevens. Het is gewoonweg niet rendabel. Of je moet een Quote500 bewoner zijn ofzo. Helaas gewoon loonslaaf.

En dit is een strikt persoonlijke, maar bij dit soort programma`s heb ik altijd het Lord of the rings gevoel.
One password to rule them all.

[Reactie gewijzigd door arbraxas op 22 juli 2024 22:47]

[Zer0]

Kans dat ze Arbraxas op de korrel nemen?

100%... is het niet door scans naar kwetsbaarheden via internet, dan is het wel malafide email, websites, links etc.
Nee, die zijn niet persoonlijk op jou gericht, maar als ze er mee kunnen pakken dan pakken ze je.

[arbraxas]

Dat klopt, maar daar veranderd een lastpass oid ook niets aan.

[Zer0]

Lastpass heeft echter wat meer mensen in dienst om de boel te bewaken

[arbraxas]

Yup en al die diensten zijn onfeilbaar, want veel mensen in dienst.

Hoe meer mensen in diens,t hoe groter het bedrijf, hoe groter het doelwit, hoe groter de kans van een fuckup door een van die mensen.

Tot nu toe gaat het me aardig af. Uiteraard is het nooit een garantie, maar dat zijn dit soort tools ook niet.

[curkey]

Een keertje een infectie met wat cryptolockers en je hebt thuis een interessante test case voor recovery.
Met een database in een cloud kun je vanaf een known good locatie bij je credentials komen zonder gedoe.

Voor beide cases valt wat te zeggen.

[ShadLink]

Of je neemt de opslag in eigen beheer. Bijvoorbeeld door een NAS te gebruiken. Want als je cloud gehacked wordt zit je met een groter probleem

[curkey]

Een beetje crypto neemt je NAS ook mee natuurlijk.

Ik gebruik zelf Keepass maar heb de database gesynct via een cloud drive, plus ik maak een lokale backup. Mocht er een inbraak zijn, dan heb ik hopelijk nog genoeg ingangen ook bij mijn spullen te komen

[arbraxas]

Alles wat ik perse moet houden staat ook nog eens op 2 losse harddrives die niet 24/7 online zijn.
Beste firewall die er is, stekker eruit. Hack away zou ik zeggen.

Ik ben helemaal niets kwijt zou mijn systemen gelockt worden. De meeste particulieren hebben echt geen TB aan data als backup nodig. Een USB stick doet wonderen. (En die gaan vandaag de dag tot TB )

[Marcelkoedijk]

Verschil tussen offline of online wachtwoordmanagers is voornamelijk wie er voorzorgt dat de servers gehardned en continue gepatched worden. In dat opzicht zijn online wachtwoord managers wellicht veiliger omdat we meer aandacht is voor hardenen en patchen. Ook hebben meerdere wachtwoordmanagers een bounty programma waar hackers betaald worden voor het vinden van een lek en worden wachtwoordmanagers onderheven aan audits en bijvoorbeeld of ze gdpr complaint zijn en/of een soc2 certificering hebben. 1password is zo’n wachtwoord manager die daarin voorziet en anders is bitwarden ook een nette oplossing die je zowel online als offline kan gebruiken voor als je de cloud cloud echt wantrouwd… maar is de cloud wel zo onveilig.

[Anoniem: 1802422]

Bedrijven als Bitwarden en 1Password zullen echt niet pardoes, van de ene dag op de andere ophouden te bestaan. Dat is onzinnige bangmakerij. En dan liever je wachtwoorden in plaintekst lokaal opslaan? Ik wens je veel succes! Lol.

[Zappert]

Knappe jongen die na bij mij ingebroken te hebben mijn plaintekst met wachtwoorden gaat vinden tussen de duizenden files op mijn HDs. De file heeft natuurlijk niet de extensie txt of een naam die duidt duidt dat het om een lijst met wachtwoorden gaat. En als je al een woord kunt verzinnen uit die file dan ben je nog uren bezig in een ongeïndexeerde windows. Mijn bank wachtwoord staat er natuurlijk niet in.

[InsanelyHack]

ah daar zijn hele handige scriptjes voor die dat binnen notime hebben gevonden. Denk in de richting van spaties, tabs en CRLF etc.

[Zappert]

Oké mag hij daarna duizenden files gaan openen waar die dingen in voorkomen. Maar goed als die de pc meeneemt naar huis heeft ie natuurlijk alle tijd. Moet ie wel eerst mijn woning op de bovenste verdieping kiezen en zien binnen te komen. Heb een beetje paranoïde buren die elke scheet in het trappenhuis horen en daar een verborgen cameraatje hebben hangen.

[svane]

Hoe in hemelsnaam is een online repro veiliger dan een offline repro?

Wie beweert er dat een online repo veiliger is? Online is meestal 'veilig genoeg'. De wachtwoorden worden geëncrypt voordat de data het internet op gaat. De clients zijn open-source, dus dit kan je zelf controleren. Zelfs als de servers van Bitwarden gehackt worden, hebben ze helemaal niks aan die data (want: encrypted).
Het voordeel is dat je niet al je wachtwoorden kwijt bent als je pc/laptop een keertje kapot gaat, of wordt gestolen. Wat doe jij dan met je plaintext bestand? Voor 99% van de mensen weegt dit voordeel op tegen het 'nadeel' van online hosten.

Wat als ze van de ene op de andere daf stoppen? Of als het offline is?

Dan staat de database óók gewoon nog op je pc/telefoon. Net zoals een offline oplossing. Alleen het syncen tussen apparaten gaat dan niet meer.

Ik sla mn wachtwoorden nog liever plaintext op dan dat ik ze bij iemand anders onderbreng.

Iedereen z'n eigen keuze, maar ik hoop niet dat je dit advies aan anderen geeft....

[Tom Paris]

Bij een offline programma heeft de aanvaller toegang tot jouw pc nodig. Bij een cloud-hosted programma ben je overgeleverd aan de hoster... Geen enkele oplossing zal vrij zijn van bugs, maar offline is de drempel voor een breach veel hoger als je zelf je 'IT hygiëne' op orde hebt.

[InsanelyHack]

Bij een cloud-hosted programma ben je overgeleverd aan de hoster...

Hoezo overgeleverd? Het hoofdingredient bij zo'n dienst is altijd de private key. Deze key bezit jij en staat alleen op jouw devices. De public key staat dan in de cloud en wordt aangemaakt en opgeslagen bij zo'n cloud service. Zonder de private key kan de cloud dienst of de hacker hier niks mee. Zo werkt encryptie nu eenmaal. Dat is dus denk ik ook de kwetsbaarheid in keepass daar heeft het keypair de informatie dus in het geheugen gedecrypt en een hacker kan dus met malware dan toegang krijgen tot de geheugen delen waar keypass de wachtwoorden dan bewaard. Dat is denk ik een designfout. Je moet de content van de passwords encrypted in het geheugen laten en pas decrypten wanneer de gebruiker via de Gui een wachtwoord wil gebruiken. Dat is al een hele verbetering maar heeft het probleem nog steeds niet 100% opgelost, misschien moet je dan denken richting dubbele encryptie o.i.d.

[Tom Paris]

Ben je bekend met de LastPass hacks van 2022 en 2023?

[InsanelyHack]

Nee niet specifiek maar nu ik dit heb gelezen concludeer ik dat men de broncode heeft gestolen op een laptop van een een LastPass medewerker. Hier ging het om de intellectuele eigendom die LastPass verloor en de klantgegevens zoals naam / betaalmiddel ed die hoorde bij het businessmodel. Maar ik las in dit artikel niet dat er een hack was op klanten passwords. Dat was dus ook het bezwaar van mij, op jouw comment. Zolang je de private keys hebt of nog niet zijn gecomprimiteerd kan een hacker nog steeds weinig.

[Reactie gewijzigd door InsanelyHack op 22 juli 2024 22:47]

[Tom Paris]

Nee. Via een privé-device van een werknemer hebben aanvallers toegang gekregen tot de infrastructuur van LastPass. Daar zijn data vaults inclusief encryption-keys buit gemaakt, in deze vaults staan (o.a.) wachtwoorden van LastPass gebruikers die enkel met AES versleuteld zijn, niet met keypairs.

Daarnaast heeft LastPass veel kritiek gekregen op het gebrek aan transparantie en trage communicatie over deze hack, wat je als gebruiker ook aan het denken moet zetten.

Meer info hier: https://arstechnica.com/i...nd-stole-corporate-vault/

[InsanelyHack]

LastPass gebruikers die enkel met AES versleuteld zijn, niet met keypairs.

Tja dan heb je dus gewoon de verkeerde online password manager service gebruikt denk ik, want ik begon er ook mee dat een hoofdingrediënt altijd een keypair dient te zijn waarbij jij alleen de private-key hebt en de online-dienst de public-key.

Daarnaast heeft LastPass veel kritiek gekregen op het gebrek aan transparantie en trage communicatie over deze hack, wat je als gebruiker ook aan het denken moet zetten.

Ja 2,5 maand is inderdaad niet erg snel. De wijze van communiceren is vrij uitgebreid en transparant vind ik.

[Reactie gewijzigd door InsanelyHack op 22 juli 2024 22:47]

[CriticalHit_NL]

Ook bitwarden is niet foolproof: https://www.bleepingcompu...-passwords-using-iframes/
1Password is overigens niet gratis.

Overigens zou ik persoonlijk wel wegblijven van zaken die in de cloud draaien.

Ieder programma heeft wel lekken, je kan blijven overstappen tot je een ons weegt, maar bovenal dien jezelf ook goed om te gaan met je machine want zodra een aanvaller toegang heeft tot je lokale machine dan is wel wel veel meer aan de hand en daar kan je software ontwikkelaars moeilijk voor gaan opknopen.

[supersnathan94]

En toch gebruik ik nog met veel plezier Apple iCloud Keychain.

Ik vertrouw een bedrijf wat miljarden verdient aan informatiebeveiliging en hardware iets meer dan mijzelf op dat vlak.

Overigens zit daar MFA op met 3 factoren en autofill heeft biometrics.

[CriticalHit_NL]

Ja men dacht ook veilig te zijn door alle pikante privé foto's op hun icloud te zetten, bleek achteraf toch niet zo'n goed idee.

Wat er aan het internet hangt is te stelen, vrij simpel.

[supersnathan94]

Tjsa met een beetje social engineering kan dat ja. Daarom hebben ze ook additionele maatregelen getroffen.

Toch zul je dit soort issues sneller hebben als je zelf je NAS aan het internet knupt. Want dan is security natuurlijk helemaal aan je zelf.

Een shared password vault (als is het maar met mobiele telefoon) moet toch ergens aan het internet hangen. Ik heb geen illusies dat ik met een offline versie altijd uit de voeten kan overal (op vakantie bijvoorbeeld) dus dat gaat em niet worden.

En als ik dan op een manier een online vault moet realiseren doe ik dat liever zoveel mogelijk met oplossingen die breed gedragen worden door veel gebruikers en een bedrijf wat er simpelweg veel geld tegenaan kan gooien in geval van problemen.

En de meerdere authenticatie vormen die allemaal nodig zijn is dan mooi meegenomen.

[NitSuA]

Idd, en daarnaast, bij de cloudproviders staan je sleutels niet opgeslagen, enkel de encrypted database. Daar kunnen ze niet zoveel mee, als de encryptie wordt gekraakt is er een veel groter probleem in de wereld dan de wachtwoord kluizen. En over het kraken van encryptie zijn al heel wat mensen gepromoveerd met de conclusie dat dat op dit moment nog niet mogelijk is.

[Zidane007nl]

Ik ben een tijdje geleden overgestapt naar KeePassXC vanwege een andere kwetsbaarheid die niet snel werd opgelost. KeePassXC is niet kwetsbaar.

[Frappuccino]

Dat is wel heel naief. Alle stukjes software kunnen kwetsbaarheden hebben, ook KeePassXC.

[Zidane007nl]

Ik bedoel meer dat KeePassXC niet kwetsbaar is voor deze kwetsbaarheid. KeePassXC heeft in het verleden ook kwetsbaarheden gehad.

[William_H]

Dat vraag ik mij dus oprecht af, want KeePassXC is afgeleid van KeePass.
Te vroeg gevraagd. Verderop in de comments wordt dit uitgelegd.
KeePassXC lijkt dus niet kwetsbaar.

[Reactie gewijzigd door William_H op 22 juli 2024 22:47]

[N8w8]

Ik ken Keepass niet zo maar Password Safe is op sommige punten wel vergelijkbaar (open source, crossplatform, offline), en voor mij werkt dat prima.
Het is overigens ontworpen door Bruce Schneier, en kan me geen security issues herinneren.

Nu heb ik een Yubikey en was ik wel aan t rondkijken of iets daar beter bij past.
Daarbij kwam ik uit bij Pass en afgeleiden (want er is een heel ecosysteem van varianten).
Een voordeel is dat als je een wachtwoord nodig hebt, hij alleen dat wachtwoord ontsleutelt. Dus ook als een aanvaller je hele systeem heeft overgenomen (toetsenbord en RAM kan lezen), is dan hooguit alleen dat wachtwoord gestolen.
Terwijl de meeste andere oplossingen (ook in geval van Yubikey support) altijd de hele kluis ontsleutelen, dus kan alles worden gestolen.
Weet overigens niet of dat er ook voor Windows is maar gebruik ik niet.
Er zijn ook Windows varianten.

[Reactie gewijzigd door N8w8 op 22 juli 2024 22:47]

[memen]

KeepassXC [0], zie de recente audit op de site, zelfde idee maar dan modern. Cross-Platform (Windows, Linux, Mac), heeft browser extensies, en voor Android heb je KeepassDX [1].

[0] https://keepassxc.org/
[1] https://www.keepassdx.com/

[Sensor55]

Alternatief: KeePass 1.x
Beetje simpel, maar werkt prima.

[Cyb]

Als daar de functionaliteit van https://cve.mitre.org/cgi...e.cgi?name=CVE-2023-24055 in zit, dan heb je dan te maken met een nog ergere kwetsbaarheid. Ook de wijze waarop de developers met dat probleem omgaan, wekt niet echt vertrouwen in dat team.

[Stangg]

Het verschil tussen versie 1.x en 2.x is dat 2.x in C#/.Net is gebouwd. 1.x is geschreven in C++, dus daarmee heeft het niet dezelfde kwetsbaarheid en API's.
https://en.wikipedia.org/wiki/KeePass

[Reactie gewijzigd door Stangg op 22 juli 2024 22:47]

[Anoniem: 111246]

Voor mij is het grote voordeel dat KeePass een offline Password database is.
Niks online, dus kans dat door een exploit bij een leverancier je passwords opstraat liggen is een stuk kleiner.

Ja, dit is een bug die ze moeten pletten, maar als je de condities ziet waaronder iemand er uberhaupt iets mee zou kunnen, maak ik me een hele stuk minder zorgen dan bij een online dienstverlener.

[mjl]

Helemaal mee eens, daarnaast moeten ze dan toegang hebben tot mijn PC en kunnen inloggen en toegang hebben tot de database. Een “low likelihood” scenario.

Verder wel slordig, hopen dat het dus snel opgelost is en er een ‘cleanup’ tooltje komt zodat je de OS installatie niet opnieuw hoeft te doen.

En Juni is al dichtbij…

[Reactie gewijzigd door mjl op 22 juli 2024 22:47]

[webhalla]

De Auteur van de exploit, vdohney, schrijft:

The vulnerability was assigned CVE-2023-32784. It should be fixed in KeePass 2.54, which should come out in the beginning of June 2023. Thanks again to Dominik Reichl for his fast response and creative fix!

Als vdohney even had gewacht op de fix voor zijn publicatie, was er niet zoveel onrust geweest. vdohney's grootste probleem was dat hij Dominik Reichl niet goed kon bereiken en daarom de exploit publiek heeft gemaakt. Hij heeft inmiddels een tijdelijke versie van Dominik Reichl gekregen en de fix al getest en zijn exploit is niet meer van toepassing hierop.
vdohney schrijft in https://sourceforge.net/p...329220/thread/f3438e6283/:

Nice, that's a pretty creative fix! I've tested it and it seems to be doing the job, even the order in which the strings appear is useless now (the dummy strings can come both before and after the real character). I can no longer reproduce the attack.

De vraag of een systeem opnieuw geïnstalleerd moet worden berust natuurlijk niet op de vraag of je een (geheugendump van een) wachtwoordmanager moet vertrouwen op een gecompromitteerd systeem, maar of je met een gecompromitteerd systeem wil blijven werken. vdohney schrijft zelf ook terecht https://github.com/vdohney/keepass-password-dumper

Should You Be Worried?
Depends on your threat model. If your computer is already infected by malware that's running in the background with the privileges of your user, this finding doesn't make your situation much worse.

Maar goed dat deze software getest en zo steeds beter/veiliger wordt.

[mjl]

Thanx voor de inzichten!

[batjes]

Als iemand toegang heeft tot mijn pc, staat 9/10 keer Keepass toch al open en kan men er toch bij.

[vgroenewold]

Dat is wel een goed punt inderdaad, die heb ik gemist.

[marcieking]

Ik begrijp echt niet waar je het over hebt. Dit is toch een open-source password manager?

[vgroenewold]

Over het in eerste instantie niet willen dichten van een lek eerder dit jaar, dat is samen met andere mogelijkheden tot een lek zoals deze, niet echt iets wat mij vertrouwen zou geven. Dat moet gewoon een super solide antwoord geven, of dat nu opensource is of niet.

edit: Overigens verwoord ik het wat te sterk, nagel in de doodskist is overdreven ja.

[Reactie gewijzigd door vgroenewold op 22 juli 2024 22:47]

[IStealYourGun]

Die andere lek ging over een configuratie aanpassing die werd opgeslagen in je paswoord database. M.a.w. als een aanvaller dat kon aanpassen was je file al compromised.

Encryption is niet meer en niet minder dan een tool die een aanval complexer of moeilijker kan maken, maar het is geen heilige graal die je tegen alles kan en zal beschermen.

Ik herinner mij nog dat op de oude website van TrueCrypt zo een hele waslijst aan security recommendations stond om veilig met hun encryptie om te gaan.

[Djerro123]

Het is gratis, daarom maken mensen er gebruik van denk ik.

[bbr]

Gratis, offline, en open source.
Flinke plus punten.

[Zer0]

En blijkbaar niet zo veilig en de ontwikkelaar is traag met het oplossen van kwetsbaarheden.... flinke minpunten.

[bbr]

Het is open source, dus iedereen kan hem helpen.
Wellicht dat de hoofdontwikkelaar een OTAP straat volgt die pas recent is geplaatst en niet zomaar een release naar buiten kan pushen.

[Zer0]

Het is open source, dus iedereen kan hem helpen.

Dan moet de maintainer die hulp wel accepteren, en doorvoeren naar het eindproduct. Doet hij dat niet dat moet je gaan forken, en die fork weer zelf bijhouden etc etc. Open source is niet heilig.

[Pietervs]

Tja, als dat criteria zijn dan zijn er nogal wat programma’s en complete besturingssystemen die het raam uit kunnen.

Natuurlijk is het niet goed dat er kwetsbaarheden open blijven staan/lang duurt voor het opgelost is. Maar ik denk dat een KeePass heel erg veel aan beveiliging toevoegt ten opzichte van de losse papiertjes en opschrijfboekjes die mensen nog in gebruik hebben.

Wil je dat zaken sneller opgelost worden? Dan moet je naar betaalde alternatieven gaan kijken: daar zit het geld om programmeurs een SLA op te leggen.

[Zyphrax]

Ik gok dat je aan LastPass dacht

[vgroenewold]

Dat denk ik idd ja, ik word wat oud schijnbaar.

[MadEgg]

Ik gebruik zelf KeepassXC, deze lijkt niet kwetsbaar te zijn gelukkig: https://github.com/keepassxreboot/keepassxc/discussions/9433

Keepass zelf is wmb een gebruikersonvriendelijk gedrocht. KeepassX en later XC is zo veel beter, zeker cross platform met integratie in de native UI van het betreffende platform.

[BounceMeister]

Is daar ook een Android app van? Die kan ik niet vinden namelijk.

[Mavamaarten]

Van KeepassXC niet nee. Maar genoeg android-apps voor keepass-databases beschikbaar. Ik gebruik zelf Keepass2Android met grote tevredenheid 😊

[Anonymoussaurus]

CC: @EepSweech

Wel interessant. Ik ben juist van KeePass2Android overgegaan op KeePassDX omdat het ontwikkelteam groter is en dus regelmatigere releases en een modernere interface. Vraag me af waarom jullie KeePass2Android verkiezen.

[EepSweech]

Het is een tijdje geleden dat ik keepassDX heb geprobeerd dus misschien is wat ik nu ga zeggen niet meer van toepassing.

Maar het synchroniseren van de database opgeslagen in cloud providers was wat ik destijds miste.

[Anonymoussaurus]

Oh, want KeePassDX kan dat, anders was ik het nooit gaan gebruiken. Dus bij deze: https://github.com/Kunzis...iki/File-Manager-and-Sync

[EepSweech]

Oke ik wist niet dat die functie was toegevoegd!
Dan ga ik keepassDX toch nog maar een keer uitproberen

[Mavamaarten]

Heb een hele tijd geleden alle opties geprobeerd en ik vond Keepass2Android makkelijker in gebruik. De cloud sync doet goed zijn werk en het doet wat ik wil inclusief autofill in apps en websites, dus blijf ik trouwe gebruiker

[BounceMeister]

Oh, dus Keepass2Android werkt wel samen met KeePassXC? Dat zou makkelijk zijn!

[Clemens123]

Het database formaat is dan ook hetzelfde.

[batjes]

Ik dacht xc is er wel voor Android. Is het keepassdx. Die staat in ieder geval in fdroid.

[EepSweech]

Meerdere varianten, persoonlijk vind ik keepass2android fijn om te gebruiken.
Andere zijn keepassDX of kpass

[Kargin]

Op F-Driod is KeepassDX te vinden. Integreert ook met Autofill op Android.

[lamlion]

Nee, keepass2android is denk ik het beste alternatief voor de “XC” variant op de desktops.
https://play.google.com/s...s2android.keepass2android

[Anonymoussaurus]

Heb ik ook een tijdje gebruikt, maar sinds kort over op KeePassDX ivm groter ontwikkelteam, meer releases en betere interface:

• https://www.keepassdx.com/
• https://github.com/Kunzisoft/KeePassDX

[lexited]

Waarop baseer je 'groter ontwikkelteam, meer releases en betere interface'

De releases https://github.com/Kunzisoft/KeePassDX/releases

[Anonymoussaurus]

Vergelijk de tussenpozen maar qua releases met https://github.com/PhilippC/keepass2android. Aantal contributors én commits zijn groter. En tja, dus ook meer releases (maar kan ook zijn dat KeePassDX langer bestaat).

[Reactie gewijzigd door Anonymoussaurus op 22 juli 2024 22:47]

[ccnl]

Op Google Store staat
KeePassDX https://play.google.com/s...om.kunzisoft.keepass.free, uitgebracht 10 mei 2020
Keepass2Android Password Safe https://play.google.com/s...s2android.keepass2android, uitgebracht 11 mrt 2013

Also Keepass2Android bestaat veel langer (ook logisch omdat het van de maker keepass is)

[Anonymoussaurus]

Volgens mij snap je het niet helemaal... "Uitgebracht op" slaat op de eerste keer dat het uitgebracht is. Oftewel: KeePass2Android bestaat langer, maar KeePassDX heeft meer releases (vergelijk de GitHub-pagina's maar). Wellicht dat je doelt op "Geüpdatet op:".

En nee, KeePass2Android's ontwikkelaar is helemaal niet dezelfde ontwikkelaar als van KeePass. Sterker nog: alle ports zijn niet gelieerd aan de KeePass ontwikkelaar Dominik Reichl.

[Stangg]

KeepassXC en Keepass kunnen hetzelfde database bestand gebruiken, maar ze hebben destijds besloten geen Andoid en IOS app te maken omdat die al bestaan (en die werken met hetzelfde bestand):

For Android, we recommend KeePassDX and KeePass2Android.
And for iOS, we suggest Strongbox and KeePassium.

Zie hier onder het kopje "Does KeePassXC work on mobile phones? If not, which app would you recommend?"

[Anonymoussaurus]

Heb ik ook overwogen vanwege deze kwetsbaarheid, maar nadeel van KeePassXC vind ik dat er geen enkele mogelijkheid voor synchroniseren is dmv de cloud oid. Ik ga niet de hele godganse dag met een USB-stickje rondlopen, veel te veel gedoe. Overigens heb ik dan een SPOF als er iets naar de knoppen gaat waar als enige mijn database-bestand op staat.

[William_H]

Uhm, en als je je kluis nu bijv. op Onedrive zet, en hem daar vanaf laadt? Dan staat ie in de cloud, en je kunt 'm eventueel nog offline opslaan. Laadt je 'm weer uit de cloud, en sla je bij wijzigingen weer offline op. Beste van twee werelden.

[Anonymoussaurus]

Dat is dus exact wat ik op het moment doe inderdaad, maar KeePassXC heeft daar geen native ondersteuning voor. Dan zal ik daar de cloudapplicatie voor moeten installeren, en dat vind ik ruk, want dat betekent een extra continu proces op mijn computer (die overigens óók weer moet starten bij het opstarten van mijn systeem).

[MadEgg]

Op mijn iPhone gebruik ik Strongbox, die heeft wel een client voor webdav dus die laadt het rechtstreeks in van mijn NextCloud. Volgens mij doet die ook andere platformen zoals Dropbox. Dat is wel ideaal - zou op de desktop ook prettig zijn. Maar daar heb ik in de regel al wel een sync client geinstalleerd omdat er meer op mijn NextCloud staat.

[well0549]

Uhm, en als je je kluis nu bijv. op Onedrive zet, en hem daar vanaf laadt? Dan staat ie in de cloud, en je kunt 'm eventueel nog offline opslaan. Laadt je 'm weer uit de cloud, en sla je bij wijzigingen weer offline op. Beste van twee werelden.

Staat je wachtwoord voor OneDrive dan niet in keeppass....

[Anonymoussaurus]

Ja, maar E2EE hè, want je hebt zelf (als het goed is) een uniek wachtwoord voor je versleutelde database dan OneDrive.

[HollowGamer]

Ik gebruik op Linux tegenwoordig https://apps.gnome.org/app/org.gnome.World.Secrets/ - deze werkt met meerdere formaten out-of-the-box.

Keepass gebruikt dat ik nog steeds .NET, terwijl inderdaad KeepassXC veel beter is. Alleen heeft de ontwikkeling daarvan ook even stilgelegen.

[DrPoncho]

En het gebruik van .NET is een probleem?

[sfranken]

Niet elk platform heeft de mogelijkheid .NET te installeren / te gebruiken

[HollowGamer]

Op Linux wel.

[sfc1971]

Ja want het is juist .NET dat hier de fout in gaat door *a **s ***s ****w *****o etc in het geheugen op te slaan.

[DrPoncho]

Eh, nee. De dev.

[mjl]

Das mooi, die cliënt ga ik ook eens proberen.

Zakelijk is KeePass de standaard, eens kijken of ik ze kan overtuigen hier nog eens een risico analyse van te maken.

[batjes]

Keepass vind ik zelf dan weer niet gebruikersonvriendelijk, maar meer dan auto-type gebruik ik eigenlijk niet. Op mobiel gebruik ik KeepassXC wel, want die stond in F-Droid.

Ik houd het liever bij de basis, Keepass wordt zelf beter voor het licht gehouden dan de forks.

[curkey]

Tot nog toe vind ik de keepass OG prima te gebruiken, zowel zakelijk als prive. Het initieel inregelen van de auto type is even wat werk, maar daarna is het best wel care-free.
Onder Linux gebruik ik XC versie, maar ik zie daar niet vreselijk veel verschil in.

[BounceMeister]

Het lek zit hem in het systeem waarop Keepass gebruikt is begrijp ik? Dus alleen de losse databasefile op een ander systeem opgeslagen, is nog wel veilig?

[xzaz]

Het komt door .NET het paswoord textbox laat de regels achter in een memorydump wanneer het wachtwoord typt. Zeker bij een crash kan dit gedumpt worden.

[Clemens123]

Ja het is enkel een probleem daar waar je keepass gebruikt

[Lontano]

Ik begrijp het straks opnieuw installeren van het besturingssysteem niet goed.
Is het niet voldoende om na de update in juni het hoofdwachtwoord te veranderen?

[William_H]

Het is inderdaad een nogal raar advies. Het opnieuw instellen van kluiswachtwoord(en) zou voldoende moeten zijn. Dan gebruik je namelijk niet meer dat wachtwoord wat in die geheugendump te vinden is en heeft een aanvaller er niks aan.

[R4gnax]

Ik begrijp het straks opnieuw installeren van het besturingssysteem niet goed.
Is het niet voldoende om na de update in juni het hoofdwachtwoord te veranderen?

Ja. Of alle memory dumps; pagefiles en hibernate files wissen.

Het probleem is eigenlijk transient; de aanwezigheid van gedeeltelijke kopiën van het wachtwoord in vluchtig werkgeheugen. Maar door mechanismes aanwezig in het OS, zoals het opslaan van een memory dump op disk als een process crasht; het opslaan van data in een page file (en dat page file niet secure wissen bij reboot); en het gebruik van fast-resume/hibernate functionaliteit die snapshots van geheugen op disk bijhoudt, wordt het persistent.

[fps]

Dat is ook de reden waarom ik op al mijn partities encryptie toepas. Dan kan er van alles worden opgeslagen, maar kan er in normale gevallen niemand bij die dumps komen.

[Clemens123]

Zou voldoende moeten zijn inderdaad, vergwis ook dat eventuele oudere databases (bv aangemaakt in een conflict situatie met een tweede device) gewist worden / ook een nieuw masterpasswoord krijgen.

[kered]

Opnieuw installeren is volgens mij overkill. Opnieuw opstarten is voldoende om het werkgeheugen te wissen.

[Toet3r]

Interessant, ik heb nog een oude keepass file waarvan ik het hoofdwachtwoord kwijt ben. Eens proberen of ik het met deze methode kan achterhalen.

[M3m3nt0m0r1]

Dan moet je ook een oude memory dump hebben, of swap file. Anders werkt het niet.

[Franckey]

Dan kan niet, want je moet eerst je juiste password invoeren om het via een memory dump te kunnen vinden.

[Finraziel]

Misschien begrijp ik het niet goed... maar waarom is deze kwetsbaarheid gewoon meteen de openbaarheid in geslingerd?! Is het dat het opensource is en er daarom niet één entiteit achter zit waar je dit soort problemen kunt melden?
Als er wel een bedrijf achter zou zitten dan zou ik verwachten dat je het probleem daar aankaart en hooguit als ze na geruime tijd er niks aan gedaan hebben het openbaar maakt om een oplossing te forceren. Maar dit leest alsof de vinder van het probleem het gewoon maar het internet op geslingerd heeft en boeien dat er iemand misschien door gehackt kan worden?
Ok je hebt fysieke toegang nodig en dat beperkt het risico gelukkig een hoop, maar alsnog vind ik het een vreemde gang van zaken.

[LinuZZ]

Volgens mij komt dat omdat er geen responsible disclosure contact is. De melder heeft netjes gevraagd om een responsible disclosure maar wordt volkomen genegeerd op dat punt:

https://sourceforge.net/p...329220/thread/f3438e6283/

[kodak]

Het lijkt een combinatie te zijn van gebrek aan een duidelijk responsible disclosure adres (lijkt er niet te zijn), niet al te veel moeite doen (als onderzoeker kan je ook op niet publieke manieren in contact komen met de ontwikkelaar) en inschatten dat gebruikers die hier last van hebben hoe dan ook al een groter probleem hadden (de crimineel kon al het wachtwoord achterhalen en zelfs al bij de database).

Het is behoorlijk teleurstellend dat beiden het prettiger lijken te vinden dat problemen maar disclosed worden voor er een oplossing is. Voor hun is het makkelijk: ze hebben er geen last van wat de gebruikers overkomt als een crimineel het gebruikt. Het gevolg van de weinige moeite die ze zichzelf besparen leggen ze daarmee helaas wel bij al die gebruikers.

[Franckey]

Aanvallers die toegang hebben tot de pc...

Als dat kan dan heb je sowieso al een groter probleem. Dan kan de aanvaller bijvoorbeeld ook een key logger installeren.

Gebruikers moeten voor de zekerheid mogelijk het besturingssysteem van hun pc opnieuw installeren...

Wat een vreemd advies voor het beschreven probleem. Na herinstallatie ben je nog even kwetsbaar zodra je weer Keepass gebruikt. Maar ik maak mij er niet druk om en blijf deze fijne tool gebruiken, ook met deze kwetsbaarheid.

[Frame164]

Typisch. Als er een lek bij een bedrijf is wordt dat bedrijf op dit forum zo'n beetje met de grond gelijk gemaakt maar zelf vinden er het blijkbaar geen probleem om gecompromitteerde software te gebruiken. Ik hoop dat je op je werk daar anders mee om gaat.

[Franckey]

Niet alle security issues zijn even ernstig. In dit geval denk ik dat het vooral een hypothetisch probleem is. Geen reden voor paniek.