NCSC waarschuwt voor kwetsbaarheid in KeePass die ontwikkelaar niet wil dichten

Het Nederlandse Cyber Security Centrum heeft een waarschuwing uitgegeven voor het gebruik van wachtwoordmanager KeePass. Aanvallers met toegang tot een pc kunnen wachtwoorden in plaintext uitvoeren. De ontwikkelaar wil het lek niet dichten.

KeePass aanmelden

Het dreigingsniveau van de aanval is niet zo hoog, omdat het toegang tot de pc vereist waarop de database staat. Daarom zegt de ontwikkelaar volgens de CVE-melding dat een fix niet nodig is. KeePass is niet bedoeld om beveiligd te zijn tegen aanvallers die al binnen zijn gedrongen op de pc van het slachtoffer.

De aanval is te pareren door de configuratie zo aan te passen dat het masterwachtwoord nodig is voor een export van de opgeslagen database van wachtwoorden. Dat voorkomt dat de exporttrigger uit de aanval werkt. Het NCSC waarschuwt organisaties om de configuratie van KeePass na te lopen om te zorgen dat die aan staat. "Daarnaast wordt organisaties geadviseerd om een risicoafweging te maken voor het gebruik van KeePass."

Reacties (273)

[Robtimus]

Overigens klopt dit volgens mij niet:

De aanval is te pareren door de configuratie zo aan te passen dat het master-wachtwoord nodig is voor een export van de opgeslagen database van wachtwoorden. Dat voorkomt dat de export-trigger uit de aanval werkt.

Want dit staat in de CVE:

** DISPUTED ** KeePass through 2.53 (in a default installation) allows an attacker, who has write access to the XML configuration file, to obtain the cleartext passwords by adding an export trigger. NOTE: the vendor's position is that the password database is not intended to be secure against an attacker who has that level of access to the local PC.

De aanval is dus uit te voeren door de XML configuratiefile aan te passen. Raad eens waar de configuratie staat dat het master-wachtwoord nodig is voor een export? Juist - in diezelfde configuratiefile. Dus als een aanvaller daar al toegang toe heeft, dan kan die ook de configuratie aanpassen zodat het master-wachtwoord niet meer nodig is voor een export.

Wat ik daarom graag als verbetering zou willen zien, na het lezen van bovenstaande en wat testen, is dat de flag om het master-password nodig te hebben voor een export niet in de tool zit, maar in de database zelf. Succes met het aanpassen van de configuratie als de flag daar niet instaat.

[ShadLink]

Je kan de policy ook forceren door in de map waar KeePass in geïnstalleerdd is (Program Files) een enforced config op te slaan. Let wel dat je dit bestand tegen schrijven beveiligd.

Zie: https://keepass.info/help/kb/config_enf.html

[BounceMeister]

Maar als ik de database naar een andere map kopieer, kan ik toch weer gewoon de database openen met een andere keepass.exe?

[pdukers]

Als "hacker" schiet je daar niks mee op want je hebt het master wachtwoord niet. Als ik het goed begrijp is het bij deze kwetsbaarheid nodig dat je de rechtmatige eigenaar de vault laat openen en op de achtergrond door de gewijzigde setting de wachtwoorden geexporteerd worden.

[mjtdevries]

Nee, dat is het probleem, dat is niet nodig.
De standaard instelling is dat wanneer je die xml aanpast dat de export bij de volgende start van keepass plaats vind zonder dat het master wachtwoord gevraagd word.

[Verwijderd]

Gelukkig is het niet *zo* erg.
De export kan alleen plaatsvinden vanuit de "active" database. Dus eentje waarin met master-pw is ingelogd. Een trigger op "start" van keepass applicatie zal dus nooit een export kunnen veroorzaken als er een wachtwoord op zit.

[pdukers]

"export bij de volgende start van keepass" als in een keepass executable opent de kdbx en voordaat je het master wachtwoord invoert heeft de export al plaatsgevonden?

Je hebt zo te zien nog een export trigger nodig. De enige relevante trigger die ik kan vinden is "export active database". Het active betekent volgens mij dat de database met het master wachtwoord geopend moet zijn, voordat er op de achtergrond zonder het nogmaals invoeren van het master wachtwoord de export plaatsvindt.

Als dit daadwerkelijk zonder wachtwoord mogelijk is, dan zou dat nl. betekenen dat je iedere willekeurige kdbx die je in je handen krijgt kunt hacken. Dan zou de CVE score echt wel hoger zijn en einde van keepass zijn.

[pdukers]

Is het niet inherent veiliger als dit soort settings in de kdbx file zelf worden opgeslagen en ingelezen op het moment dat je de vault opent? Enforced settings horen m.i. niet thuis in een client specifiek bestand.

[Reactie gewijzigd door pdukers op 22 juli 2024 14:47]

[kodak]

Heb je alsnog weinig aan als er geen verdere scheiding in rechten is, zoals de app aan kunnen passen of een eigen alternatieve keepassversie uitvoeren.

[mjl]

De developers van KeePass linnenkast gewoon hardcore in de software ipv het eisen van het Master password voor een export. Lijkt me niet heel ingewikkeld om dit aan te passen en ik snap niet waarom ze dat niet willen doen.

[Noxious]

Dat is al het geval; in dit geval gaat het om een geautomatiseerde export bij het opstarten, die bedoelt is als mogelijkheid om data te syncen. Om dat in te stellen heb je al administrator-rechten nodig op het systeem.

[RobbieB]

Maar zelfs als een aanvaller administrator rechten heeft zou ik verwachten dat mijn KeePass Vault veilig is en alleen toegankelijk met het masterpassword.

Dit is echt next level nalatigheid hoe ze er nu mee omspringen.

[Noxious]

en alleen toegankelijk met het masterpassword

Dat is ook bij deze 'aanval' nog steeds het geval hoor. Je moet 'm zelf actief unlocken om het te laten slagen.

[mjtdevries]

Voor welk gedeelte heb je volgens jou dan admin rechten nodig?
Je hebt alleen schrijf rechten nodig.

[Noxious]

De installatie staat by default in Program Files.
By default heb je daar ook geen schrijfrechten, tenzij je admin bent.

Als je de rechten van systeemfolders gaat aanpassen heb je onder de streep nergens geen admin rechten meer voor nodig.

[mjtdevries]

In de praktijk situaties waar ik keepass gebruikt hebt zien worden in het bedrijfsleven stond het nooit in de Program Files.
Voor prive gebruik zal het ongetwijfeld wel veel normaler zijn.

[Noxious]

Ah, dat is in mijn ervaring precies andersom

[Farmeur]

Slecht te begrijpen dit.

[Codin the Coder]

Hoe bestaat het dat er uberhaupt een export zonder master pw mogelijk is? Encrypt/decrypt KeePass alle entries dan niet?

Daarbij... ik begrijp dat m'n passwords veilig zijn als een aanvaller m'n KeePass file niet heeft. Maar mocht ie hem in handen krijgen, dan wil ik dat ie juist wel secure is. Daarom gebruik KeePass toch ook?

[Argantonis]

Dat is ook niet mogelijk. Ze kunnen alleen een configuratie maken dat zodra jij zelf de database opent met je wachtwoord, er dan een export wordt gemaakt. Maar inderdaad, de database is gewoon encrypted opgeslagen.

Als iemand op dat niveau toegang tot je pc heeft dan kunnen ze ook een keylogger installeren voor je master wachtwoord.

[deroby]

Mja, maar een keylogger zou (mogelijk) een alarm kunnen triggeren van je AV of iets dergelijks.
Iemand die met notepad die .xml config file (in %APPDATA%) snel effe aanpast gaat dat zeker niet doen.. de POC is super-triviaal om te implementeren.

Ik vind het toch maar raar dat steeds opnieuw gesteld wordt dat 'eens ze op je pc zitten ben je toch al verloren'. Het spreekt voor zich dat die situatie problematisch is/kan zijn maar dat betekent nog niet dat je het dan maar makkelijk moet maken vind ik. Als iemand 5 minuten achter je rug op je pc zit dan is elke hindernis welkom.

PS: Wat een beetje mankeert in het artikel is hoe dit (enigszins) te mitigeren.Na wat zoeken vond ik https://sourceforge.net/p...f6b/?page=1&limit=25#73e4 en https://sourceforge.net/p...f6b/?page=1&limit=25#2120 wel nuttig.

Ik voorlopig dus maar de .exe en dat enforced.xml bestandje dichtgetimmerd in het OS .. al vrees nu wel dat mijn volgende upgrade iets 'lastiger' gaat zijn. Toch eens uitkijken voor een iets meer 'basic' alternatief dat minder te lijden heeft onder toeters en bellen.

[Argantonis]

Klopt, ik vind het ook niet ideaal maar het is wel wat anders dan zomaar je database kunnen exporteren.

[GekkePrutser]

Precies, het loggen van toetsaanslagen is zeer verdacht. En vereist meestal ook admin rechten.

Het aanpassen van een random XML file is zeer laagdrempelig.

[Andreplusplus]

Anti Tamper Protection implementeren

[MischaBoender]

Ik vind het toch maar raar dat steeds opnieuw gesteld wordt dat 'eens ze op je pc zitten ben je toch al verloren'.

Eens. Dan kun je je inderdaad ook afvragen waarom mensen een fysieke kluis hebben. Als ze inbreken in je huis ben je toch al verloren...

[Andreplusplus]

Precies, keepass bevat juist passwords voor andere systemen

[alexdekker]

Het klopt wat je zegt echter als ze jouw account al hebben kunnen ze ook je snelkoppelingen naar jouw KeePass binary aanpassen naar 1 van hen. Als je dan iemand bent die snelkoppelingen gebruikt of niet goed op het verschil let bij het starten van je KeePass, is het mogelijk dat de kwetsbare binary er met je passwords vandoor gaat. Enige manier om die te voorkomen is om een apart systeem steeds om je passwords te vragen.
Die moet dan zo werken dat hij steeds een wachtwoord vraagt alvorens hij password terug geeft. Maarja hoe goed vertrouw je dat systeem dan weer...

En een dikke vette honeypot als LastPass oid voel ik me ook niet fijn bij. Immers als een hacker dat bedrijf kan hacken (en daarmee dus hun software, aka supply chain attack) dan zijn ze gelijk binnen. Vergeleken daarbij ben ik niet interessant en heb ik dus hoogstwaarschijnlijk enkel te maken met wat malware en phishing waar ik op moet letten.

[Kansloze zaak]

Het zou ook kunnen zijn dat ze wel bij je bestanden kunnen maar verder niet. Bijvoorbeeld doordat er een share open staat die niet open had moeten staan.
In dat geval is nu alsnog die database te exporteren en dat lijkt mij iets waartegen je toch beschermd moet zijn.

Als ze gewoon root zijn op je hele machine, dan ben je de sjaak. Maar verder is dit wel te makkelijk.

[mjtdevries]

Dat is ook niet mogelijk.

Dat is wel mogelijk. Dat is nou precies waarom de NCSC er voor waarschuwt.
Je kunt de xml aanpassen zodat bij het volgende keer starten van keepass deze de export maakt zonder om het masterwachtwoord te vragen.

[Verwijderd]

nee natuurlijk niet. Dat masterpasswoord heb je nodig om de DB te decrypten. Als dat zo zou zijn dan zou het passwoord ergens anders in de computer opgeslagen zijn, dat is natuurlijk niet zo.

[mjtdevries]

Ga de eerder genoemde threads bij die CVE eens lezen.
De export word gedaan zonder dat om het masterpassword word gevraagd.
Vanwege deze optie die standaard aan staat in keepass: "Do not require entering current master key before exporting"

[Verwijderd]

Klopt, als je export triggered of zelf doet hoef je niet NOG een keer het paswoord in te voeren. Dus alleen als de database al open staat ("active"), DAN hoef je geen paswoord in the voeren.
Maar er is GEEN sprake van automatisch exporteren zonder paswoord bij opstarten van Keepass.

[Verwijderd]

Bij ons bedrijf wordt keepass specifiek gebruikt en zelfs als enige toegestaan, dus ik heb dit meteen getest, vandaar dat ik er zo zeker over was.

Ik ben het verder helemaal met je eens en heb al aangegeven dat we naar een andere tool moeten.

[Surkow]

Ik ben het verder helemaal met je eens en heb al aangegeven dat we naar een andere tool moeten.

KeePassXC?

[Reactie gewijzigd door Surkow op 22 juli 2024 14:47]

[MischaBoender]

Op zich staat het redelijk duidelijk in de CVE:

KeePass through 2.53 (in a default installation) allows an attacker, who has write access to the XML configuration file, to obtain the cleartext passwords by adding an export trigger.

En ook in de gelinkte forum threads:

If an attacker modifies the xml config file (adding an export trigger on 'Opened database file') he will be able to export all the passwords, without us knowing it. Shouldn't the user be asked to confirm before exporting ?

Deze trigger zorgt er dus voor dat de export gedaan wordt zodra je de database opent, waarvoor je dus eerst je master password moet invoeren.

[Codin the Coder]

Duidelijk.

Tnx!

[SteefOne]

Maar ik kan toch gewoon de XML aanpassen en het laten exporteren naar een locatie naar keuze? Laat het slachtoffer maar Keepass gebruiken, graag zelfs; want dan vult hij voor mij zijn masterkey in en ontvang ik rustig de plaintext.

Of begrijp ik het verkeerd..

[MischaBoender]

Of begrijp ik het verkeerd..

Nee, helemaal juist. De aanvaller past de XML aan en zet er dus die export trigger in. Daarna is het wachten tot de gebruiker zijn database opent en daarbij zijn master wachtwoord invoert, dat trigger die plain text export.

[Argantonis]

Dan begrijp je weinig van hoe dit soort databases werken ben ik bang.

[Argantonis]

Ik heb het gelezen. Het zou je sieren als je gewoon toegeeft dat je het niet helemaal hebt begrepen. Uiteraard is het wachtwoord nodig om de db te decrypten en staat die informatie niet allemaal unencrypted op je opslagmedium. Dat zou echt belachelijk zijn en het hele punt van een password database voorbij gaan.

[Andreplusplus]

Als je een kopie hebt kun je altijd een brute force attack uitvoeren.

[Codin the Coder]

Daarom heb ik ook een lang password.

[GekkePrutser]

Klopt, bij ons op het werk hebben de pentesters deze techniek al succesvol uitgebuit, al een paar maanden geleden zelfs.

[Scriptkid]

Kip en ei,

Hoe open je dan de master database , om te configuratie uit te lezen.


neem aan dat je nu eerst de database moet openen voordat je de export kunt starten. ?

[moonlander]

Bruteforcen?

[Nappie]

Als je het master password kan bruteforcen, dan hoef je ook geen trucs uit te halen om het te exporteren. Vanaf dat moment heb je gewoon toegang tot de encrypted data. Maar je mag er denk ik vanuit gaan dat elke Keepass gebruiker wel weet dat het master password een sterk wachtwoord moet zijn.

[Scriptkid]

Success,

Keypass gebruikt een delay die je in kunt stellen voor de DB, bij mij 3 sec.

met mijn 32 char passwoord en alle tekens allawed ben je een paar triljoen jaren bezig voor mijn passwoord,

Kun je beter social engineering doen dat gaat sneller

[DiedX]

En wat houdt mij tegen om direct op de database te gaan hammeren? Niets , want ik weet hoe de encryptie werkt.

Ik vermoed dat de gekozen encryptie er voor zorgt dat het nog niet triviaal is, maar die drie seconden kloppen echt niet.

[pascallj]

Het gaat in dit geval niet om een vaste vertraging, maar om een berekening die er op deze pc 3 seconde over doet. Door het aantal iteraties van een bepaald deel van de encryptie aan te passen, kan je instellen hoe lang het op jouw pc duurt voordat een berekening klaar is.

Als je direct op de database gaat hammeren, zal je nog steeds moeten voldoen aan dit aantal iteraties om de boel te kraken. Uiteraard is het wel zo dat dezelfde berekening op een supercomputer minder tijd in beslag neemt.

[Kansloze zaak]

Een betere versleuteling kost meer tijd om te kraken. Maar als iemand je database heeft dan kan hij er met duizenden per seconde tegenaan lopen rammen. Het kan snel gaan.

[pascallj]

Onderschat de kwaliteit van hedendaagse versleuteling niet. Uiteraard komt het aan op de kwaliteit van het gekozen wachtwoord en of er een karakterset bekend is waarover geïtereerd moet worden.

Met een willekeurig gekozen wachtwoord van voldoende lengte met speciale tekens gaat het jou vandaag de dag niet lukken om dit te kraken binnen jouw levensduur. NSA-level apparatuur en quantum processors buiten beschouwing gelaten dan.

Als jij met duizenden per seconde tegen bovenstaande database aan wilt rammen, heb je dus een computer nodig die 3000 keer zo snel is als bovenstaande.

[Reactie gewijzigd door pascallj op 22 juli 2024 14:47]

[woopdiedoo]

Hilarisch. Ik wens je veel succes met een "paar grafische kaarten" vs Argon2. Als je een beetje moderne PC of laptop hebt en je geeft om de beveiliging van je keyvault is het helemaal niet gek om deze zo in te stellen dat het decrypten 2 seconden duurt op 8 CPU cores, met 1 of 2GB aan geheugen gebruik. Oeps, ineens zijn al je GPU cores niet zo veel meer waard.

[IamBANE]

De ontwikkelaar kaart dit risico zelf al aan sinds 2019:

Write Access to Configuration File
An attacker who has write access to the KeePass configuration file can modify it maliciously (for example, he could inject malicious triggers). This is not really a security vulnerability of KeePass though.

These attacks can only be prevented by keeping the environment secure (by using an anti-virus software, a firewall, not opening unknown e-mail attachments, etc.). KeePass cannot magically run securely in an insecure environment.

https://keepass.info/help/kb/sec_issues.html#cfgw

[mjtdevries]

Dat is een veel te makkelijk excuus.
Door de xml aan te passen kun je instellen dat bij de volgende start van keepass deze automatisch een export maakt zonder dat je het master wachtwoord hebt ingegeven.

Er is geen enkele rechtvaardiging te bedenken waarom je een dergelijke mogelijkheid in een xml config file regelt.

Als dat een valide excuus is, dan is er geen meerwaarde van keepass tov een TXT file.

[pdukers]

Als dat een valide excuus is, dan is er geen meerwaarde van keepass tov een TXT file.

De export zonder wachtwoord kan alleen maar plaatsvinden NADAT de database geopend is mbv het wachtwoord. Dit betekent dat ik je bij wijze van spreken een kdbx kan geven en de wachtwoorden daarin nog steeds veilig zijn. Dat is nog altijd vele malen beter dan wachtwoorden plain text opslaan.

[mjtdevries]

Dat is niet wat er in de CVE beschreven staat en de maker zegt dat ook niet in de discussie waarnaar gelinked is in de CVE.
Hij geeft aan dat keepass inderdaad niet veilig is als iemand de xml kan aanpassen. En dat dat by design is.

[pdukers]

De CVE is inderdaad niet zo heel duidelijk. Je moet al de reference links gaan doorlezen om de procedure te achterhalen.

De CVE vermeldt wel dat er een export trigger nodig is. De enige export trigger die keepass kent is "export active databse". Active betekent hier dat de database al geopend is mbv het master wachtwoord. Ik heb het zelf getest en geen mogelijkheid gevonden om een export te triggeren voordat de database geopend is.

[mjtdevries]

De reference links helpen ook niet, want die ben ik juist gaan lezen omdat de CVE zelf niet duidelijk is. En daar geef men juist aan dat de database niet geopend hoeft te worden.

Maar ook als het alleen op geopende databases werkt blijft het een groot security issue, want je kunt het exporteren zonder dat de persoon die keepass gebruikt kan zien dat die export plaats vind.
Zo'n functie wil je nooit standaard aan hebben staan en nooit aanpasbaar willen hebben door iemand die het masterwachtwoord heeft.
Ik vind het onbegrijpelijk dat ze weigeren dat aan te passen. Als je dit optie aan wilt bieden dan kan je dat heel makkelijk op een veilige manier implementeren. Maar verzoeken daartoe zijn al meerdere keren gesloten.

[pennywiser]

Probeer het reproduceren zou ik zeggen. Volgens mij moet de db geopend zijn tijdens exports. Prove me wrong.

[pennywiser]

Door wie, kabouters? Ik ben niet zo paranoia als jij denk ik.

[mjtdevries]

Waarom gebruik je dan keepass als jij er van overtuigd bent dat jij absoluut de enige bent die ooit toegang heeft tot je pc? Dan is een txt file ook voldoende.

[pennywiser]

Dat is dus niet zo. En nu stop ik.

[Winst]

Ik stopte al bijna met lezen toen ik las dat je eerst toegang of controle over de computer moest hebben.
Als je daar al in bent geslaagd dan is het installeren van wat software ook niet heel ingewikkeld meer...

[Cergorach]

Maar dat is veel te kort door de bocht! Wat als iemand je met een Masterkey versleutelde password database in handen krijgt (bv. een backup). Kan die gewoon Keepass installeren op een PC en vervolgens dat kopie daarnaartoe verplaatsen om dan een export te maken, of moet je eerst een keer aanmelden/ontsleutelen op die database? Ik ben even wat linkjes gaan volgen en het was mij niet duidelijk. Ik betwijfel of de auteur van het Tweakers.net artikel wel die duidelijkheid boven water heeft gekregen. NCSC vind het een issue, de Keepass developers niet, waar zit de waarheid?

Daarnaast is een keylogger installeren een heel stuk ingrijpender en veel meer detecteerbaar dan een waarde in een bestaande applicatie aanpassen. Probeer dat maar eens te vinden als security expert!

EDIT: @Creesch komt met een duidelijke POC: https://github.com/alt3kx/CVE-2023-24055_PoC De gebruiker moet dus wel aanmelden op de database met de Masterkey. Maar mijn tweede punt blijft.

[Reactie gewijzigd door Cergorach op 22 juli 2024 14:47]

[pennywiser]

Je moet eerst een keer ontsleuteld hebben zodat die XML gegenereerd wordt natuurlijk.

[WhatsappHack]

Maar dat is geen reden om dan alles dat de boel kan bemoeilijken of vertragen achterwege te laten of de deur nog maar iets verder open te zetten. Zo van “oh je bent binnen? Nou, welkom dan. Kopje thee? Hier staan mijn credit card gegevens, hier m’n privéfoto’s. Anders nog iets?”.

Al moet ik daaraan toevoegen dat ik dit in algemene zin zeg, heb dit lek nog niet gedetailleerd bekeken om daar een mening over te vormen. Ging me puur om deze uitspraken dat het allemaal fair game is zodra iemand binnen is.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 14:47]

[mjtdevries]

Als je daar al in bent geslaagd dan is het installeren van wat software ook niet heel ingewikkeld meer...

Wat is dan nog de reden om keepass te gebruiken?
Want als het geen extra beveiliging bied tov een TXT bestand met wachtwoorden, waarom zou je het dan gebruiken?

[Kansloze zaak]

Omdat je wel eerst een keer moet inloggen.
De database is versleuteld.
Een aanpassing in de config zorgt dat er een dump gemaakt wordt nadat je bent ingelogd.

Dus als iemand alleen je bestand heeft, is er niet zo veel aan de hand.
Hebben ze toegang tot je computer, dan kunnen ze de config aanpassen en, nadat je bent ingelogd, de database exporteren.

Het is 10000000% veiliger dan een tekstbestand op je PC.

[jeanj]

Ik zit met rot te zoeken (ik gebruik versie 1) maar dit betreft alleen versie 2, en niet versie 1 aangezien deze geen triggers bevat.

Gemeld bij auteur

[Reactie gewijzigd door jeanj op 22 juli 2024 14:47]

[Megalodon86]

Wel belangrijk verschil, aangezien versie 1 ook nog steeds geüpdatet wordt; is er niet persé een reden om altijd naar de nieuwste 2.x te updaten.

[jeanj]

Juist versie 1 en 2 worden beide nog gesupport, al jaren en bestaan naast elkaar. Ik heb specifiek voor v1 gekozen omdat ik dat formaat kon uitlezen met een app op mijn telefoon. Die app bestaat niet meer, maar ik zit nog steeds op bestandsformat v1 (en de app op de pc)

[pdukers]

Voor mij persoonlijk is de enige reden om 2.x te gebruiken de mogelijkheid om mbv een plugin automatisch een backup als ik de database save.

Ik ga vanwege dit issue nu ook overstappen naar 1.x of keepassxc aangezien deze geen trigger functionaliteit hebben. Moet alleen een oplossing verzinnen voor het maken van backups.

//edit: Blijkbaar heeft keepassxc een eenvoudige backup funtionaliteit, nl. ""backup database file before saving" Helaas geen versioning functionaliteit, maar goed genoeg voor nu.

[Reactie gewijzigd door pdukers op 22 juli 2024 14:47]

[sircampalot]

" omdat het toegang tot de pc vereist waarop de database staat."

Als dat de voorwaarde is om de database te ontcijferen, dan is geheel keepass overbodig.
Een textbestandje in je documenten directory is dan net zo veilig, kan je namelijk ook pas bij als je toegang tot de computer hebt.

En blijkbaar is de workaround ook niet waterdicht, zoals in de eerste post te lezen.

[Reactie gewijzigd door sircampalot op 22 juli 2024 14:47]

[pdukers]

De export zonder wachtwoord kan alleen maar plaatsvinden NADAT de database geopend is mbv het wachtwoord. Dit betekent dat ik je bij wijze van spreken een kdbx kan geven en de wachtwoorden daarin nog steeds veilig zijn. Dat is nog altijd vele malen beter dan wachtwoorden plain text opslaan.

Dat de workaround niet waterdicht is klopt.

Maar zo ernstig als jiij het schetst is het gelukkig niet. De CVE score zou dan vele malen hoger zijn en in de praktijk het einde van keepass betekenen.

[pennywiser]

Alleen tijdens dat de db geopend is hoop ik, of ook als deze daarna weer afgesloten is?

[pdukers]

Alleen als deze geopend is. De export vindt nl. alleen maar plaats dmv triggers die een geopende database vereisen.

[pennywiser]

Dat lijken er maar weinig hier verder in te zien

[pdukers]

Neem ik zie niet kwalijk. Dit artikel en ook de references in de CVE zijn niet duidelijk genoeg.

Fix is ook vrij simpel door gebruik te maken van een keepass variant die geen trigger functionaliteit heeft. Bijv. KeepassXC of Keepass 1.x. Persoonlijk mis ik dan alleen de mogelijk om dmv een plugin automatisch een database backup te maken bij iedere database save.

//edit: Blijkbaar heeft keepassxc een eenvoudige backup funtionaliteit, nl. ""backup database file before saving" Helaas geen versioning functionaliteit, maar goed genoeg voor nu.

[Reactie gewijzigd door pdukers op 22 juli 2024 14:47]

[smiba]

Wat een nutteloze CVE is dit ook.

Als een aanvaller gewoon configuratie bestanden op je computer kan aanpassen, kan deze ook wel even met een keylogger of een andere manier door iets te installeren in je KeePass safe komen.

[Reactie gewijzigd door smiba op 22 juli 2024 14:47]

[RobertMe]

En volgens die logica is KeePass dan dus inherent onveilig

Iets dat bij andere password managers niet perse speelt. Immers heb je met een wachtwoord nog niet perse toegang tot de vault in dat geval. Bij KeePass kun je zoals je zelf al aangeeft met een virus het bestand van het systeem af halen en met een keylogger het wachtwoord stelen. Ik kan mij zomaar indenken dat andere password managers hier beter beschermd tegen zijn doordat je bv niet continu met het wachtwoord werkt en de opslag niet een simpel bestandje in Mijn Documenten is dat je zo heen en weer kunt kopiëren.
Uiteraard werken die cloud based password managers normaliter ook met een versleutelde offline database. Maar die zal vast "gelocked" zijn aan een systeem naast dat de boel überhaupt versleuteld is. En met alleen een keylogger het master password onderscheppen ben je er nog niet om in de cloud in te loggen. Of in ieder geval niet als de gebruiker netjes 2FA gebruikt, naast dat een cloud based password manager vast en zeker een mail stuurt bij logins vanaf onbekende systemen en de gebruiker daardoor gewaarschuwd wordt voor het "uitlekken".

[smiba]

Ik zie niet hoe dit anders is, als jou password manager automatisch inlogt of in je browser geintegreerd is lijkt me het net zo onveilig. Deze moet tenslotte ergens zijn credentials opslaan.

Zodra iemand toegang heeft tot je data kan deze ook gewoon die credentials uit lezen

Ik denk dat erg veel mensen hier (in de tweakers comment sectie) onderschatten hoe desastreus het is als een aanvaller toegang heeft tot je bestanden. Dat is effectief vergelijkbaar met een complete take-over van je machine, vanaf daar kan je namelijk tools uitvoeren en dus wat voor data ook verkrijgen

[Reactie gewijzigd door smiba op 22 juli 2024 14:47]

[RobertMe]

Ik zie niet hoe dit anders is, als jou password manager automatisch inlogt of in je browser geintegreerd is lijkt me het net zo onveilig.

Ik moet Bitwarden ontgrendelen (al dan niet met een apparaat specifieke / lokale pincode) voordat ik deze kan gebruiken, net zoals je KeePass moet ontgrendelen voor gebruik.

Het probleem in deze van KeePass is echter dat iedereen die toegang heeft tot jouw systeem (bv een huisgenoot of collega als je even koffie bent halen of naar de WC bent of ... en vergeet te vergrendelen) met deze configuratie aanpassing al dan niet direct (ik zag ook al een verwijzing naar een PoC met upload naar een server voorbij komen) de database in plain tekst kan exporteren de eerstvolgende keer dat je deze ontgrendeld. Terwijl elke zelfrespecterende password manager de vault automatisch lockt na X minuten inactiviteit. Dus als ik vergeet mijn PC te vergrendelen is de kans best groot dat mijn vault vergrendeld is. Maar bij KeePasd kan een aanvaller dan alsnog "iets doen waardoor die op een later moment toegang heeft". Door dus die setting aan te passen, te wachten tot je als argeloze gebruiker terug komt, en de eerstvolgende keer KeePass ontgrendeld. En * plop *, alle wachtwoorden zijn in plain tekst geëxporteerd.

Terwijl zonder deze setting die ander/aanvaller niet meer kan dan de encrypted vault file kopiëren (/"stelen"), maar dan heb je nog steeds het master password nodig.
En ja, keyloggers and what not zijn opties, maar daarvoor heb je al wat meer kennis nodig, waarschijnlijk langer toegang tot het systeem nodig, een antivirus staat ee installatie niet toe (en uitzetten AV kan niet doordat de lokale gebruiker geen admin is en met admin wachtwoord moet bevestigen).

[DataGhost]

Op het moment dat iemand genoeg toegang tot jouw systeem heeft en specifiek password managers aanvalt, kan deze nadat jij je Bitwarden ontgrendelt gewoon over diezelfde sessie in heel je database gaan neuzen, al dan niet merkbaar of zichtbaar. In het simpelste geval worden je toetsenbord en muis gewoon uitgeschakeld terwijl een scriptje je (interessantste) password entries bij elkaar klikt en doorstuurt. Maar ook venstermanipulatie in de achtergrond (in die paar minuten tot de hervergrendeling) is niet onwaarschijnlijk, of nog simpeler door gewoon je cookies/sessiegegevens te gebruiken in een achtergrondprogrammaatje vanaf jouw eigen machine/IP kan het helemaal onzichtbaar. En met "nog meer" genoeg toegang kunnen ook gewoon binaries vervangen worden voor een soort UI-MITM.

[Reactie gewijzigd door DataGhost op 22 juli 2024 14:47]

[RobertMe]

Klinkt dan wel alsof zo'n scriptje een stuk meer "toegang" nodig heeft. Als in: een keylogger draait vermoed ik niet effectief onder een "guest" account (i.p.v. admin account, dus is een admin wachtwoord nodig om het te installeren). En een antivirus kan dat ook zomaar oppikken.

En die password database zal bij de meeste (cloud) oplossingen ook lokaal staan. Die doen, lijkt mij, allemaal lokaal cachen. Bitwarden in ieder geval dus wel (ook de browser extensie etc). Uiteraard wel netjes in encrypted vorm en alleen te lezen met het master password / lokale pin / ....

En natuurlijk zijn ze uiteindelijk allemaal te kraken (als je met en keylogger het master password achterhaald / ...). Maar KeePass zet de deur wel heel erg wagenwijd open voor elke 5 jarige script kiddy wannabe door deze optie te bieden.

[DataGhost]

Je kan Chrome ook gewoon installeren zonder admin-credentials, onder een "guest" account. Programma's hoeven niet vanuit Program Files te draaien. Iets als AutoHotKey kan een soort keylogger zijn, en daar is gewoon een portable versie van die werkt zonder dat je iets hoeft te installeren, dus ook onder een "guest" account. Dus whatever er op de achtergrond meekijkt en evenveel accountrechten heeft als het programma wat jij gebruikt om mee bij je lokale danwel cloud-vault te komen, kan ook een hele hoop afluisteren. Als het je key niet is dan wel een sessie. Dit is allemaal met hetzelfde toegangsniveau als wat nodig is om de config van KeePass aan te passen.

[Reactie gewijzigd door DataGhost op 22 juli 2024 14:47]

[fdh]

Heeft iemand eigenlijk toegang nodig tot jouw systeem of is gewoon een copy van de db file (bv uit een backup) voldoende?

[Creesch]

Mja het is wel iets subtieler, de configuratie staat ook "actions" toe die automatisch zaken doen in de applicatie. Een van die acties is dus ook de mogelijkheid tot exporteren zonder dat de gebruiker dit merkt.

Natuurlijk heeft iemand die die configuratie kan aanpassen wel toegang tot veel meer en kan ook via andere wegen wellicht de inhoud van de database bemachtigen. Maar, dit maakt het nog een stuk makkelijker.

Zie ook de PoC github repository: https://github.com/alt3kx/CVE-2023-24055_PoC

(1) An attacker who has write access to the KeePass configuration file KeePass.config.xml could inject the following trigger, [xml voorbeeld even weggelaten]

En vervolgens

(2) Victim will open the keePass as normally activity , saving changes, etc...., the trigger will executed on background exfiltrating the credentials to attacker server

[smiba]

Maar als iemand die config file kan aanpassen, wat weerhoud een aanvaller er dan van om gewoon de KeePass.exe met een variant te vervangen in beheer door de aanvaller

Dat is ook exact wat de developers bedoelen, als iemand al toegang heeft tot al je data ben je eigenlijk al vrijwel compleet geowned.

[RoestVrijStaal]

Als ik zo die repository met PoC en de issues die deze CVE bespreken lees, krijg ik de indruk dat het Trigger-systeem van Keepass zowat als een scripting engine werkt, waarin elke willekeurige commando en/of applicatie kan worden uitgevoerd.

Nu wordt er met deze CVE de indruk gewekt dat er wachtwoorden mee te stelen valt, wat natuurlijk ook klopt. Maar het kon net zo goed rm -rf $HOME of start msedge tweakers.sexy zijn.

Sowieso waarom zou je zoiets krachtigs moeten willen? Waarom zit die configuratie van dat Trigger systeem in een plaintext-configuratie bestand en niet in de databases? Ik kan me voorstellen dat je voor ieder wachtwoord-database een iets andere trigger met dito acties wil hebben dan allemaal hetzelfde.

De locatie van het configuratiebestand is niet echt het probleem. De schrijf, lees- en uitvoerrechten zijn niet echt het probleem. De inhoud van het configuratiebestand is het probleem.

Daarnaast, een plaintext config bestandje aanpassen zodat er "rogue commando's" worden uitgevoerd kan iedere scriptkiddie. Echter de source code van KeePass aanpassen en er een Keepass.exe van compileren met hetzelfde certificaat als dat van de bonafide ontwikkelaars, zul je niet veel mensen zien doen.

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 14:47]

[Creesch]

Aanpassingen in "program files" zullen over het algemeen een prompt geven, aanpassingen in een config in appdata niet. Ik ben het er mee eens dat als dit gebeurt er al een hoop meer fout zit, maar dit mechanisme zorgt er wel voor dat het aantal stappen gereduceert wordt.

[dutchgio]

Maar dan duurt het wel heel erg lang voor je alle wachtwoorden hebt verzameld en bovendien zijn er andere methoden om keyloggers etc. te detecteren.

Als een keylogger dat al ziet, want ik vermoed dat als je een password manager gebruikt dat je wachtwoorden niet gelogged worden.

Alsnog wel wat slordig dat je bij de wachtwoorden kan komen zonder het master password, en dat ze het ook nog eens niet op willen lossen.

[brabbelaar]

Alsnog wel wat slordig dat je bij de wachtwoorden kan komen zonder het master password, en dat ze het ook nog eens niet op willen lossen.

Dat kan niet. De bug is een setting veranderen: Als het wachtwoord wordt ingevoerd kan dat een trigger zijn om de wachtwoorden te exporteren zonder bevestiging. Dan staat er daarna dus een passwords.csv of iets dergelijks op je pc. Maar nog steeds slordig inderdaad.

[Creesch]

Wat ik kwalijk vind is dat exporteren überhaupt een geautomatiseerde actie kan zijn. Dat vind ik in de basis een bedenkelijk stukje functionaliteit.

[CAPSLOCK2000]

Ik neem aan dat het is om backups te maken.

[Creesch]

Backups van wachtwoorden in plain text? Lijkt me een heel slecht idee. Exporteren zou echt alleen maar nodig zijn op het moment dat je naar een andere oplossing toe migreert in mijn optiek.

[LurkZ]

Voor migratie heb je dus plain text nodig.
Zoniet dan moet het export programma het databaseformaat van alle ander soortgelijke tools kennen.

[aikebah]

Maar zo'n migratie is een bewuste actie, dus die hoeft niet met een automatische trigger op de achtergrond

[Creesch]

Dat betwist ik ook niet. Migratie is echter een eenmalige actie, niet iets wat je geautomatiseerd in de achtergrond doet elke keer als je de applicatie opent.

Context is belangrijk.

[mjtdevries]

Dat kan niet. De bug is een setting veranderen: Als het wachtwoord wordt ingevoerd kan dat een trigger zijn om de wachtwoorden te exporteren zonder bevestiging.

Dat kan dus wel!!!
De bug is dat je de xml file kunt veranderen.
Bij het volgende keer starten van keepass exporteert ie dan de wachtwoorden ZONDER dat er om het master wachtwoord word gevraagd.

Ik noem dat niet slordig, ik noem dat totaal gestoord.
Hoe kun je nu met een security product bezig zijn en een dergelijke optie inbouwen? Dan ben je niet goed bij je verstand.

[brabbelaar]

Ik noem het ook totaal gestoord - in beide scenario's, want er worden plain text lijstjes met je wachtwoorden op je schijf gezet. Als ik dat doe is dat met intentie en weet ik waar ik ze laat. Dat er bij iedere start van het programma op die manier een nieuwe 'backup' wordt gemaakt is natuurlijk niet handig.

De bug begreep ik toch wel als iets waarvoor alsnog het wachtwoord moet worden ingevoerd. Dat is ook logischer, want hoe kan de database (encrypted immers) geëxporteerd worden zonder master password?

[mjtdevries]

Dat ligt er aan of de database encrypted is met jouw master password. (waarbij je dan ook afhankelijk bent dat jouw master pasword goed genoeg is om als encryptie key te dienen. Bij bv Bitlocker is jouw key niet de encryptie sleutel)
De CVE is er niet duidelijk over en de references evenmin of je een export kan doen op een niet geopende database. Daar claimen mensen dat niet geopende database geexporteerd kan worden, maar een paar mensen hier hebben op hun keepass getest en zeggen dat dat bij hen niet mogelijk is.
Dus dat maakt de situatie is een tikkie minder erg, maar het blijft een groot en onnodig risico.

[smiba]

Ik bedoelde een keylogger die gewoon je master password sniffed, om bij je KeyPass database te komen moet je daar gewoon eerst doodleuk je password voor invoeren.

Keylogging van passwords in KeyPass lijkt me dan wel weer sterk, tenzij je specifiek iemand zijn clipboard in de gaten houd. Deze typ je namelijk eigenlijk zelden over (tenzij je hier de macro voor gebruikt)

[Reactie gewijzigd door smiba op 22 juli 2024 14:47]

[DataGhost]

Je kan kiezen je master password alleen in te voeren op de "secure desktop", dat is datzelfde ding als waar je je UAC-prompts te zien krijgt en daar zouden zaken zoals software-keyloggers en dergelijke niet bij moeten kunnen komen, tenzij er een flink lek in Windows zit.

[smiba]

Ok laat ik het anders aanpakken, wat weerhoud een aanvaller die dus al write access heeft naar je filesystem om een gemodificeerde keypass.exe te plaatsen die al je data nog steeds dumpt zodra je inlogt?

Zoals ik in een andere reactie zei, ik denk dat veel mensen hier niet snappen hoe ver iemand al in je systeem zit als deze write rechten heeft op je filesystem. Je bent effectief eigenlijk op dat moment al compleet geowned.

[woekele]

het plaatsen van die gemodificeerde keypass.exe vereist nog write-access tot program files. Dat is elevated rights. Het aanpassen van de config vereist alleen write-access tot appdata als ik het goed begrijp. Dat is gewoon normale user rechten.

[jpfx]

KeePass kan net zo goed standalone zijn. Hoeft in zijn geheel niet in program files te staan.

edit:
auto correctie gecorrigeerd :-)

[Reactie gewijzigd door jpfx op 22 juli 2024 14:47]

[woekele]

In dat geval is het inderdaad niet makkelijk te beveiligen.

[DataGhost]

Verschil tussen account-level en system-level rechten. Als gebruiker heb je helemaal geen schrijfrechten in Program Files (waar keepass.exe staat) en ook niet tot de map met de snelkoppeling. Daar is minimaal een UAC prompt voor nodig. Dus als de exploit zich beperkt tot alleen de account waar keylogging op plaatsvindt, kan je van de secure desktop niks afluisteren. Als er system-level toegang is, tsja, dan is nog maar heel weinig veilig. Ook de online databases waar velen zo lekker op gaan zijn dan niet meer veilig zodra je die als gebruiker opent.

[Terrestrial]

Dat is waar inderdaad en dat is ook de reden waarom ik niet in wachtwoord kluizen geloof, want zit er eenmaal malware op je computer steelt die de gehele inhoud van de klus, kun je nog beter ouderwets op een papiertje schrijven.

[DennusB]

Tja, dan heb je waarschijnlijk nu ontzettend makkelijke wachtwoorden die zo te kraken zijn. Dan neem ik liever het risico (en een goede virusscanner) maar wel met hele veilige wachtwoorden

[rjd22]

Makkelijk te onthouden wachtwoorden zijn eigen veel beter dan complexe wachtwoorden die niet te onthouden of makkelijk over te schrijven zijn.

Bijvoorbeeld een wachtwoord dat bestaat uit 4 woorden met een streepje ertussen ik vaak moeilijker te kraken dan een complexe reeks van 10 karakters.

Obligatory xkcd: https://xkcd.com/936/

[System]

Een bestaand woord in een wachtwoordzin is even sterk als een random karakter.
Een bibliotheek op uw wachtwoord loslaten is het eerste wat ze doen. Pas daarna proberen ze brute force.

[DataGhost]

Een random karakter wordt doorgaans uit een set van minder dan 100 mogelijkheden gekozen. Last time I checked bestaan er meer, veel meer dan 100 verschillende woorden, dus een bestaand woord is veel sterker dan een random karakter. Dat wordt ook min of meer duidelijk gemaakt in de gelinkte xkcd. Wel is een woord van X tekens doorgaans minder sterk dan X random tekens ja, daarom zal een wachtwoordzin wat langer moeten zijn maar dat is vanwege het makkelijkere onthouden geen enkel probleem.

Zeg dat een random karakter een kleine letter, hoofdletter, cijfer (nu al 62), spatie en alle interpunctie en rare tekens op je toetsenbord kan bevatten, dan zit je aan iets van 95 tekens. Voor een wachtwoord van 3 random karakters zijn er dus 95³ = 857375 mogelijkheden. De woordenboeken van Nederlands en Engels tezamen zijn goed voor zo'n 750000 woorden, dus heel veel verschilt dat niet, maar als je vindt dat het minder is kunnen diezelfde woordenboeken nogmaals meegeteld worden waarbij alle woorden een hoofdletter aan het begin krijgen, dan zijn er 1,5 miljoen mogelijkheden. Dus het wachtwoord "System" is ongeveer even veilig als drie random karakters. Het wachtwoord "System system system system system" is, gek genoeg, dus veiliger dan een wachtwoord van 15 random karakters, ook met een dictionary attack, alleen het is veel makkelijker te onthouden.

[rjd22]

Als aanvulling hierop:

Daarnaast weet een aanvaller meestal niet welk wachtwoord systeem je gebruikt. Gebruik je 3 of 4 woorden? Eindig je ze met een punt of niet? Hebben de woorden hoofdletters of niet? Is het scheidings teken een spatie, streepje of underscore?

Dit soort onzekerheden zorgen ervoor dat je niet zomaar een dictionary attack kan toepassen en dus terug moet vallen op brute forcing. Want met een verkeerd ingestelde aanval kan het zo maar zijn dat je nooit een resultaat hebt.

[DataGhost]

Het gebruik van een wachtwoordmanager gaat niet per se over wachtwoordcomplexiteit (dat wordt daarmee toevallig wel een volkomen non-issue) maar vooral over het voorkomen van hergebruik en het gebruik van afgeleide wachtwoorden. Het is heel leuk om "bijvoorbeeld dit stukje midden in deze zin" als wachtwoord te hebben voor website X, maar het onthouden daarvan wordt een stukje lastiger als er arbitraire eisen gesteld worden zoals dat je wachtwoord twee verschillende vreemde tekens en een getal moet bevatten, maximaal 10 tekens lang mag zijn en oh ja, spaties mogen ook niet. En ja, er zijn nog steeds sites die zo werken helaas. Zeker als je dit bij heel veel websites moet doen wordt dit een probleem. Ik heb op het gebied van websites alleen al momenteel 462 wachtwoorden waarbij ik me dus helemaal niet druk hoef te maken over een of ander algoritme om makkelijk te onthouden wachtwoorden te verzinnen die voor al die sites verschillend zijn maar waarbij ik wel weet welk wachtwoord bij welke site hoort.

[LurkZ]

Als de website het toelaat gebruik je een complexe reeks van 20 of 30 karakters.
Je hoeft niets te typen of te onthouden, dus waarom korte passwords?

[Terrestrial]

En hoe ga je die kraken dan, nogmaals het grootste gevaar zit 'm vaak niet in de lengte van een wachtwoord of de complexiteit maar social enigneering en het her gebruik van wachtwoorden. En dat op zichzelf is ook nog geen directe ramp maar het probleem is dat er wel is wat kan uitlekken bij 1 van de sites omdat die bijv. niet op een correcte manier jou wachtwoord opslaan. (dat kan er sprake zijn van bruteforcing) Uiteraard kan je wachtwoord uitlekken door malware icm een keylogger op je systeem op het moment je ergens inlogt maar dan hebben ze alleen die account en niet al je accounts/wachtwoorden wat bij een wachtwoord kluis wel meteen het geval is.

Ook een hele goede virusscanner houdt helaas geen custom versleutelde malware/spyware tegen.

[stefanhendriks]

Lengte heeft wel degelijk zin. Denk aan rainbow hashes. Deze tabellen hebben meen ik tm 8 of zelfs 12 characters elk mogelijk wachtwoord in zich. Zeer lange wachtwoorden zijn dan ook niet eenvoudig (of duurt onmogelijk lang) om (brute force) te kraken.

[Terrestrial]

ja oke maar in de praktijk zie je juist dat er bijna nooit gebruteforced wordt.(teveel gedoe) Het lekt meestal op andere manieren uit.

[lamme23]

Maar wanneer steeds meer wachtwoorden gegenereerd worden zullen de brute forces toch weer meer gebruikt gaan worden. De meeste wachtwoorden die ik tegenwoordig gebruik zijn 16 characters bestaand uit willekeurige karakters. De kracht van systemen neemt ook steeds meer toe, o.a. door quantum computing, waardoor het ook minder gedoe gaat worden.

[Terrestrial]

Nee denk daar maar is over na. Stel je hebt een wachtwoord van maar 5 karakters maar waar heb je nog de mogelijkheid om onbeperkt te proberen ? Na een paar keer wordt je account of ip adres tijdelijk geblokkeerd, dus dan ben je alsnog jaren bezig. Het zou alleen kunnen werken als je al een gehashde wachtwoord tabel hebt en die moet dan ook niet salted zijn. Meestal lekken wachtwoorden uit omdat ze in clear-text op een server zijn opgeslagen of een een programmeer fout in de software zit waardoor je hele database kan dumpen.

[Reactie gewijzigd door Terrestrial op 22 juli 2024 14:47]

[stefanhendriks]

Vaak probeert men dat als ze bijv een dump van de db hebben. Niet via een login form.

[DataGhost]

Omgedraaid, hoe ga je die onthouden dan? Heb jij voor elke site een ander wachtwoord en onthoud je ze allemaal? Als je wachtwoorden allemaal van elkaar zijn afgeleid is het dus voor een aanvaller alsnog te beredeneren wat jouw mogelijke wachtwoorden zijn voor dienst B na lek bij dienst A. Ondertussen heb je wel het gezeik met verschillende password policies waardoor je misschien aanpassingen moet maken op je algoritme en dat ook weer moet onthouden. Of schrijf je ze serieus op papier op?

[PageFault]

Of een papiertje die iemand kan jatten.

[RoestVrijStaal]

kun je nog beter ouderwets op een papiertje schrijven.

Dat heeft ook geen zin als malware kan keyloggen

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 14:47]

[Menesis]

Is dat ook zo met bij 1Password en iCloud Keychain?

[Scriptkid]

Dat is ook precieswaariom de CVE Disputed is,

Kluis zit op slot, Maar als de aanvaller al toegang heeft tot de sleutel doos kun je er nog zo veel sloten op zetten dat is totaal zinloos.

[jmvdkolk]

Zoals ik het begrijp is het zo dat de kluis op slot zit. En dat de aanvaller een commando kan opgeven dat ongemerkt uitgevoerd wordt als de kluis geopend wordt. Als KeePass op jouw computer staat dan moet iemand inderdaad al schrijfrechten binnen jouw account hebben. Maar, als KeePass op het netwerk staat, wat voor schijnt te komen, dan kan je met schrijfrechten op die netwerkplek aan alle credentials komen.

[Scriptkid]

nee het gaat over de config file die in je user profile staat,

maar als we de security boundrys van windows volgen kun je met een user account compromise heel makkelijk een hele hoop andere dingen doen om de keypass data te accessen, Daarom heeft het totaal geen nut om die file of config te beschermen , je bent dan aan het dweilen met de kraan open.

zie Scriptkid in 'NCSC waarschuwt voor kwetsbaarheid in KeePass die ontwikkelaar niet wil dichten'

[Mushroomician]

Dat is waarom ik potentiële malware altijd installeer in een unpriviliged LXC container.
Wachtwoorden staan hier gewoon in een textbestandje, maar wel met AES versleuteld dankzij GnuPG. Met gebruikersgemak dankzij Pass.

[Reactie gewijzigd door Mushroomician op 22 juli 2024 14:47]

[beerse]

Bedenk dat de meesten een wachtwoordkluis hebben voor accounts van andere machines en andere diensten. Dus als ze op je desktop binnen zijn, hoppen ze zo naar alles wat je netjes in je keypas gezet hebt.

En nee, een keylogger is niet een alternatief. In mijn wachtwoordkluis staan heel veel accounts die ik maar af en toe en sommigen helemaal nooit gebruik. Het is ook een plek voor de backup-keys voor zaken die normaal met een mfa toegankelijk zijn. Die gebruik je als het goed is nooit. Maar als ze 'veilig' in je keepass bestand staan kan de inbreker/misbruiker zonder mfa door hoppen...

[pennywiser]

'Tools' → 'Options' → tab 'Policy' → turn off the option 'Export - No Key Repeat'.

Waarom staat dit dan niet gewoon uit standaard? Dat lijkt mij de fix.

[Reactie gewijzigd door pennywiser op 22 juli 2024 14:47]

[ShadLink]

Nog beter, maak een xml bestand: KeePass.config.enforced.xml in je "%ProgramFiles%\KeePass Password Safe 2" map met de volgende xml:

<Configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Security>
<Policy>
<ExportNoKey>false</ExportNoKey>
</Policy>
</Security>
</Configuration>

Maak dat bestand readonly en zorg ervoor dat je gebruikeraccount er geen schrijfrechten op heeft.

[3_s]

Waarom?

[blobber]

Dat xml bestandje zorgt ervoor dat bovengenoemde optie in keepass enforced uit staat (greyed out in keepass)

[pennywiser]

Inderdaad, er zal toch altijd wel iemand schrijfrechten hebben als die eenmaal achter je pc zit. Niet heel zinvol.

[Verwijderd]

Dus het gaat hier om een kwetsbaarheid van de Windows app Keepass? Dat haalt ik niet duidelijk uit het artikel. Er zijn overigens ook Linux downloads van deze app. Die zullen niet zo vaak gebruikt worden vermoed ik (want de meeste distributies ondersteunen KeepassXC), maar deze bevatten wellicht dezelfde kwetsbaarheid.
Dus KeepassXC heeft deze vulnerability niet? En Keepass2Android welke ik gebruik om op Android mijn database te benaderen ook niet. Althans, voor zover bekend...

[ShadLink]

Nou ja, apps die ondersteuning hebben voor triggers en die triggers via een plaintekst bestand kunnen aanpassen hebben dit.

Je kan ook de broncode van KeePass downloaden en de functie er helemaal uit halen. (KeePass is gewoon opensource)

[Lapjespoes]

Nog beter, deinstalleer KeePass en schakel over op een alternatieve wachtwoordmanager.

[pdt75]

En die zijn? Lastpass? Bitwarden?

[UPPERKEES]

KeePassXc

[yozgoesdigital]

zodra iemand je database dan opent met Keepass ben je toch nog steeds kwetsbaar?

[Bacchus]

Zodra "iemand," anders dan jijzelf, je wachtwoorddatabase heeft geopend ben je sowieso kwetsbaar. Sterker nog: zelfs zelf je wachtwoorddatabase geopend hebben maakt je enigszins kwetsbaar.

[yozgoesdigital]

ah tuurlijk dit gebeurd pas nadat je het masterwachtwoord hebt ingevuld bij het openen en al volledig toegang hebt. Dan begrijp ik de houding van KeePass iets beter.

[UPPERKEES]

Toegang hebben tot de applicatie die unlocked is, ja. Maar de redenering van de dev is gewoon fout. Mijn printer settings in GNOME zijn nog beter beveiligd.

[Joydashy]

Nee, 1Password natuurlijk. Zowel Bitwarden alsmede LastPass hebben gepubliceerde vulnerabilities.

[Robtimus]

Dat is precies waar pdt75 naar linkte.

[Scriptkid]

Ehh,

De aanvaller heeft al controle over je PC,

Dus hij grabbed met screencapture software alles wat op je scherm staat, met keylogger alles wat je intyped Inc je master password ,

Waarom zou hij de moeite doen om een export te injecten als hij je master password al heeft , ???

[deroby]

Omdat 'sommige aanvallers' louter beschikken over je keyboard en scherm terwijl jij effe naar het toilet bent ... (en voor je zegt "Nouja, dat is dan dom", dat komt IMHO vaker voor dan je lief is).

=> als de aanvaller dan probeert een keylogger ofzo te installeren dan gaat of de AV of op zijn minst UAC een alarm geven
=> als diezelfde aanvaller een .xml bestandje aanpast met notepad dan is er geen vuiltje aan de lucht, je kan de POC code gewoon van een website plukken, het is echt belachelijk eenvoudig.

Niet alle aanvallen worden uitgevoerd door state-sponsors, soms is het gewoon de klusjesman.

[Scriptkid]

vertel dat even aan HP die gewoon standaard key logger mee instaleerde in hun sound driver

[mjtdevries]

Waarom zou hij de moeite doen om screencapture software te installeren als ie alleen maar de xml file hoeft aan te passen om zonder dat het master password gevraagd word al je wachtwoorden te exporteren?

Waarom zou jij de moeite doen om keepass te gebruiken, als het geen enkele extra bescherming biedt boven een TXT file???

[Scriptkid]

txt file is 24/7 access ,

keepass moet je ingelogd zijn geweest,

Ik log gemiddeld 1 keer per week aan geeft my 1-7 dagen om infecties te detecteren,

met die txt file ben ik binnen 1 sec de klos

[mjtdevries]

En als keepass niet zo dom in elkaar zat was je helemaal niet de klos.
1sec, 7 dagen of helemaal niet. Ik weet welke optie ik prefereer.
Zeker aangezien de oplossing super simpel is.

[Scriptkid]

Je mist een heel stuk van de puzzel , en past nu tunnelvisie op de keepass toe

Als hij bij je config file kan kan hij veel meer wat veel makkelijker is zie de windows security posts

[Reactie gewijzigd door Scriptkid op 22 juli 2024 14:47]

[GekkePrutser]

Omdat het installeren van een keylogger erg snel opgemerkt wordt. Er zijn weinig applicaties die daar legitieme redenen voor hebben.

Een modern EDR systeem houdt continu in de gaten wat een applicatie allemaal uit loopt te vreten en zoiets wordt zeer snel opgemerkt.

[Scriptkid]

vertel dat even aan HP die gewoon standaard key logger mee instaleerde in hun sound driver

[kodak]

In het nieuws staat niet zomaar dat keepass niet ontworpen is tegen aanvallen waar al toegang tot het account van de gebruiker is.

Er is behoorlijke discussie over geweest over dit soort 'oplossingen' die niet zomaar meerwaarde hebben. Als iemand toegang tot je account heeft en al moeite doet om een export te krijgen kan die dus al eerst alle configuratie aanpassen en exporteren. En hopen dat een crimineel dan niet slim genoeg is of dat je virusscanner deze wel weet te detecteren om dit soort opties te beschermen is vooral leuk voor een goed gevoel, maar niet als die gegevens je zoveel waard zijn. Er zijn dagelijks nieuwe stealers die vermomd als handige apps of na een andere besmetting gemaakt zijn om passwordopslag leeg te roven door eerst dit soort instellingen goed te zetten en zelfs te wachten op momenten dat de gebruiker de sleutels in tikt.

Keepass is duidelijk: de app is niet ontworpen tegen aanvallen waarbij een crimineel al keyloggers kan installeren en opties kan aanpassen.

Een oplossing als @ShadLink zou dan handiger zijn, maar ook dat moet eerst bewezen worden of dat voldoende is tegen exporteren.

[pennywiser]

Dat is geen goede oplossing, want eenmaal achter die pc is niets erop meer read only. Kan je er niet direct bij, haal je de disk eruit. Gewoon vinkje uitzetten in Keepass is dus voldoende.

En keyloggers, dat probleem geldt voor alle wachtwoordkluizen. Of beter gezegd alle software op alle pc's. Je typt toch wachtwoorden in? Met Keepass niet, dan copy paste ik deze, en die copy blijft vervolgens maximaal 10 seconden bestaan.

Keepass heeft 2fa, gebruik die dan ook.

[kodak]

We hebben het over de situatie dat het account is overgenomen, niet de hele pc. Dat is ook waarom keepass stelt dat het niet ontworpen is tegen overname van een account. Dat het daarmee ook niet ontworpen is als iemand genoeg beheerrechten heeft of zelfs toegang tot de hele opslag mag duidelijk zijn.

[pennywiser]

Dan nog is het vinkje voldoende, dit triggert het opnieuw in moeten geven van het master pw.

[kodak]

Ik raad je aan de genoemde discussie te lezen en te bedenken wat de betekenis is dat de crimineel die masterkey dus kan afluisteren en gebruiken. Keepass is niet ontworpen dat iets wat de gebruiker kan doen voorkomt dat de crimineel een export kan maken. Zolang de crimineel dezelfde rechten heeft heb je een probleem.

[pennywiser]

Maar als je een keylogger hebt, heb je met alle passwordmanagers een probleem volgens mij.

[kodak]

Dat klopt. Hoeveel risico je hebt hangt dus ook af van andere omstandigheden, zoals geluk hebben dat je alleen een crimineel treft die niet te veel moeite doet, of dat andere beveiliging zoals geen malware uitvoeren je bescherming geeft, of dat het niet lukt om de gegevens bij de crimineel te krijgen of hoe groot het probleem is als die wachtwoorden lekken als je bijvoorbeeld 2fa hebt.

[mjtdevries]

Waar is keepass dan wel voor ontworpen?

Want op deze wijze bied het geen enkele toegevoegde waarde tov een TXT file met je wachtwoorden.

[kodak]

Die onduidelijkheid is inderdaad een probleem. Want daardoor zijn er dit soort verschillen van mening over wat nog te verwachten mag zijn waar het bescherming tegen geeft.

Keepass geeft, net als andere software, oplossingen die beschermen tegen simpele problemen zoals meekijken over een schouder of virussen die niet te veel moeite doen. En zo zijn er nog andere voordelen om risicos te beperken. Maar het kan geen kwaad als ontwikkelaars dan heel duidelijk zijn waar het niet voor ontworpen is. Gelukkig doet keepass dat ook: je kan er maar beter rekening mee houden dat als iemand of een virus dezelfde rechten heeft je bescherming onvoldoende is.

[mjtdevries]

Maar bij andere password tools is iemand of een virus met dezelfde rechten niet in staat om de wachtwoorden te zien. Dan moet je echt een keylogger installeren.

[kodak]

Dan heb je kennelijk nog niet helemaal begrepen dat zelfde rechten hebben niet de betekenis heeft als andere rechten. Andere password tools hebben niet spontaan meer rechten of andere rechten dan de gebruiker en dus ook niet meer als een crimineel of virus dat die rechten van de gebruiker heeft.

[mjtdevries]

Ik heb het niet over meer rechten of andere rechten.

Als een password tool jou niet de gelegenheid geeft om een export te maken zonder dat de gebruiker dat ziet, dan heb je die kwetsbaarheid niet.
Als de default instelling is dat zo'n export niet mogelijk is, en dat je dat alleen kan activeren met het master wachtwoord, dan heb je deze kwestbaarheid ook niet.
Als de instelling voor het wel of niet kunnen maken van de export in de database staat, die je alleen kunt benaderen als je het master wachtwoord hebt, dan heb je deze kwetsbaarheid ook niet.

Dan heb je het dus over exact dezelfde rechten als waarbij keepass een kwetsbaarheid optreed.

Bedenk je dat in een bedrijfssituatie er vrijwel altijd IT mensen zijn die jouw lokale disk kunnen benaderen. En ontevreden IT-ers die kwaad willen bestaan echt wel.

[kodak]

Het is te makkelijk om te stellen dat andere apps het probleem niet hebben als die de export niet hebben. Het probleem is namelijk niet slechts het kunnen exporteren, maar dat het een combinatie is van rechten hebben om bij de gegevens te kunnen. Dus zelfs al heeft een andere app die exportfunctie niet, er is hoe dan ook al uitvoer mogelijk als een crimineel deze rechten heeft. Het beveiligingsprobleem is dus niet slechts een kwestie van deze functie is te gebruiken, maar als je dit soort rechten hebt heb je hoe dan ook al een probleem dat je er niet op kan vertrouwen dat je gegevens die je met die rechten aan het beschermen bent nog veilig zijn.

Natuurlijk kan je het op detailniveau gaan bekijken als een verschil in verkrijgen en dus een anderen combinatie, maar het probleem is er niet zomaar minder om. Dus in plaats van te stellen dat andere apps het probleem niet hebben is het vooral belangrijk dat gebruikers beseffen dat als ze last van een virus met dezelfde rechten hebben ze hoe dan ook al het probleem hebben dat die wachtwoordmanagers ze niet makkelijk meer kan beschermen tegen lekken.

[Reactie gewijzigd door kodak op 22 juli 2024 14:47]

[Andreplusplus]

tuurlijk wel. Txt file is leesbaar voor iedereen met toegang tot je C$ share of als het ding op een netwerk share of Onedrive(for business) staat

[turbojet80s]

'Tools' → 'Options' → tab 'Policy' → turn off the option 'Export - No Key Repeat'.

Waarom staat dit dan niet gewoon uit standaard? Dat lijkt mij de fix.

Kun je vervolgens niet heel makkelijk de portable versie gebruiken van KeePass om ze alsnog te exporteren? Of het DB bestand meenemen naar je eigen computer en ze daar exporteren?

[Reactie gewijzigd door turbojet80s op 22 juli 2024 14:47]

[PhWolf]

Natuurlijk kan dat, maar dan open je de DB dus opnieuw in een ander programma en moet je alsnog de master key invoeren. Voor een aanvaller is dat niet anders dan het exporteren in de geïnstalleerde versie van Keepass wanneer je deze optie uitvinkt.
Deze aanval is überhaupt alleen mogelijk wanneer je al fysieke toegang hebt tot een computer waarin de DB geopend is (en dus leesbaar) in Keepass.

[pennywiser]

In het kort: nee, want je moet de master key nu weer invoeren eerst..

[Scriptkid]

En hoe is dat erg voor een aanvaller,

Zoals in de CVE staat, Je aanvaller heeft al Full controle over je system,

DUS OOK JE MASTERPASSWORD gezien je die ingegeven hebt in je keyboard en dus al lang verstuurd is naar de aanvaller.

Hij hoeft dus alleen maar de DB te copieren en laden op zijn eigen PC

[pennywiser]

Hoe is die verstuurd naar de aanvaller dan? Magic?

Als dat vinkje uit staat kun je achter die pc blijven zitten tot aan kerstmis, maar het master password krijg je daarmee niet. Kopieer die database wat je wilt.

[Scriptkid]

Die heb jij net ingetyped op je keyboard, anders kon je zelf ook niet in keypass komen,

System compromise = acces om keylogger te installen, Keylogger post alle key tegen attacker API

[deroby]

zoals ik hierboven al aanhaalde, niet elke aanval is super-gesofisticeerd.

'Sommige aanvallers' beschikken louter over je keyboard en scherm terwijl jij effe naar het toilet bent ... (en voor je zegt "Nouja, dat is dan dom", dat komt IMHO vaker voor dan je lief is).

=> als de aanvaller dan probeert een keylogger ofzo te installeren dan gaat of de AV of op zijn minst UAC een alarm geven
=> als diezelfde aanvaller een .xml bestandje aanpast met notepad dan is er geen vuiltje aan de lucht, je kan de POC code gewoon van een website plukken, het is echt belachelijk eenvoudig.

Niet alle aanvallen worden uitgevoerd door state-sponsors, soms is het gewoon de klusjesman.

[RobertMe]

KeePass is niet bedoeld om beveiligd te zijn tegen aanvallers die al op binnen zijn gedrongen op de pc van het slachtoffer.

Volgens die logica is een plaintext bestand op een enkele PC ook veilig? Want om toegang tot dat bestand te krijgen moet je ook toegang tot de PC hebben.

[ShadLink]

Nee, het gaat hier over schrijfrechten. En wanneer je toegang tot iemands %AppData% hebt kan je feitelijk de volledige computer overnemen met spyware/malware. Hoe goed je je keepass ook beveiligd, dat gaat je hier niet helpen.

[1234567y]

Als iemand volledige toegang heeft tot mijn PC, incl schrijfrechten, had ik gehoopt dat mijn wachtwoorden alsnog achter een redelijke encryptie zouden zitten. Helaas blijkt KeePass dus erg gevaarlijk, want iemand kan super makkelijk al je wachtwoorden exporteren.

Blijkbaar kun je wachtwoorden dus beter in een excel bestandje in een OneDrive kluis bewaren ofzo.

[dipje2]

De aanval is alleen een ding wanneer je keepass opent, je wachtwoord (of welke beveiliging dan ook) invult en dan wegloopt met het open te laten staan.

Is zeg maar net zo gevaarlijk als überhaupt weglopen met je PC niet te locken.

Is zeg maar net zo onveilig als dat ik inlog in Lastpass en mijn Vault open, en vervolgens besluit naar de WC te gaan en m'n laptop zo onbeheerd achter te laten.

Ik snap de ontwikkelaar wel.

[mjtdevries]

Ho ho ho, dat is absoluut niet wat er aan de hand is.

Uit de CVE:

KeePass through 2.53 (in a default installation) allows an attacker, who has write access to the XML configuration file, to obtain the cleartext passwords by adding an export trigger. NOTE: the vendor's position is that the password database is not intended to be secure against an attacker who has that level of access to the local PC.

Schrijfrechten hebben tot de configuratie file is iets totaal anders dan keepass geopend hebben met je wachtwoord en dan weglopen van je pc terwijl je je scherm open laat staan.

Daarmee geef je echt een totaal verkeerde voorstelling van zaken.

Ik ken bedrijven die keepass op een fileserver hebben staan voor admin wachtwoorden. Die denken dat het wachtwoord op keepass de admin accounts beschermt, maar die verwachten niet dat schrijfrechten op die share je gelegenheid geeft om die accounts te exporteren zonder dat je het master wachtwoord hoeft in te geven. Dat is natuurlijk je reinste waanzin. Waarom bestaat die optie uberhaupt in keepass?
Zoals andere mensen al aangeven, daarmee is keepass eigenlijk niet veiliger dan een txt bestand met wachtwoorden.

[dipje2]

maar de database is encrypted...

dus wat doet dit? Want je moet sowieso toch je pass ingeven om de dingen te decrypten.
Maar die config file zorgt er dus voor dat 'het moment dat iemand dat doet, keepass zelf automatisch alles gaat exporteren naar een plain text file?'. Want dat klinkt inderdaad wel erger, maar kan me bijna niet voorstellen dat _dat_ is wat er gebeurd.

[mjtdevries]

Het is inderdaad niet voor te stellen, maar dat is precies wat er gebeurt.
Lees de twee discussie threads in de CVE link maar:
https://sourceforge.net/p/keepass/feature-requests/2773/
https://sourceforge.net/p...329220/thread/a146e5cf6b/

Het is echt te belachelijk voor woorden.

[DataGhost]

De wachtwoorden zitten alsnog achter redelijke encryptie. De aanvalsvector is er slechts wanneer de gebruiker zelf zijn wachtwoordkluis opent (ontsleutelt dus) op een geïnfecteerde machine. Dat excel-bestandje op OneDrive lijkt me vele malen makkelijker te bemachtigen met hetzelfde niveau van toegang, en zonder gebruikersinteractie.

[Jerie]

Elke andere password manager op een PC heeft dezelfde rechten als bijvoorbeeld de browser. Malware in je browser resulteert dus in toegang tot een Excel bestandje, versleutelde database, OneDrive of Google Drive

[R4gnax]

wanneer je toegang tot iemands %AppData% hebt kan je feitelijk de volledige computer overnemen met spyware/malware.

Je kunt enkel die ene account overnemen. Niet de hele computer.
Daarvoor zul je toch echt administrator-rechten moeten hebben.

[ShadLink]

Heel veel mensen hebben standaard admin-rechten openstaan. Nog steeds.

[DataGhost]

Daar kan je standaard nog maar heel weinig mee, elke admin-actie vereist enige vorm van UAC-bevestiging en die wordt gevraagd op een manier die niet softwarematig (bijv. door het simuleren van een muisklik) te omzeilen is.

[[Yellow]]

Wat de maker denk ik verkeerd inschat is dat het schrijven van een configuratie bestand een iets ander risico is dan het runnen van malware. Ja, als je de configuratie kunt schrijven als aanvaller is er iets niet goed met je systeem. Maar het installeren en runnen van malware wordt meestal wel opgepikt door een virus scanner. Het aanpassen van een configuratie bestand daarentegen zal door de meeste virusscanners niet opgemerkt worden als een bedreiging.

Los daarvan is het natuurlijk wel een vreemde optie voor een password manager om met 2 aanpassingen in de configuratie settings de mogelijkheid te hebben om zonder master password en zonder gebruikersinteractie een onversleutelde export uit te voeren!

[Reactie gewijzigd door [Yellow] op 22 juli 2024 14:47]

[Blokker_1999]

In dit geval gaat het natuurlijk een stap verder. Je wachtwoorden staan versleuteld in de database, maar wanneer je de deur van je kluis laat openstaan kan een aanvaller die nu gewoon leegroven. Dit terwijl er dus wel een optie bestaat om dat onmogelijk te maken.

[Scriptkid]

Nee hoor , men gaat uit van systeem compromise,

Dus dan is een keylogger om de master sleutel te krijgen een peulen schil. en doet de rest er dus al niet meer toe,

Dat is precies het punt van de maker van keepass

[mjtdevries]

Ja, het punt van de maker van keepass is dat een TXT file met wachtwoorden ook heel veilig is.
Dat is immers ook alleen maar een probleem als er sprake is van systeem compromise.

Sorry hoor, maar hoe kan je dat verdedigen?

Bovendien heb je helemaal geen keylogger nodig om de master sleutel te krijgen. (dan moet je wachten tot de eigenaar weer aanlogt)
Je hoeft alleen maar de xml config file aan te passen en keepass te openen, en dan word een export gemaakt ZONDER de master sleutel te vragen.

[Scriptkid]

Maar dat is toch zelfde werk,

en als het gefixed zou worden fix je nog niks want jij logt in en je master key ligt op straat en kan hij nog een export maken.

Kip en ei

[mjtdevries]

Als je er vanuit gaat dat er altijd een keylogger op je systeem staan, dan heeft geen enkel password zin nee.
Maar dan is er ook nooit een reden om keepass te gebruiken.

[Scriptkid]

Dat is nu juist het hele PUNT.

Zodra een aanvaller controle heeft als onderdeel van een exploit heeft het totaal geen zin meer om betere beveiliging te maken die met local controle omzijlt kan worden.

[mjtdevries]

Het punt is dat het niet vanzelfsprekend is dat een aanvaller voldoende controle heeft om een keylogger te installeren.
Schrijf rechten zijn veel makkelijker te verkrijgen dan voldoende controle om een keylogger te installeren.

[Scriptkid]

Dan moet je toch even de statements door lezen van Keepass / windows 101 security

An attacker who has write access to the KeePass configuration file can modify it maliciously (for example, he could inject malicious triggers). This is not really a security vulnerability of KeePass though.

If the user has installed KeePass using the setup program, the configuration file is stored in the user's application data directory (in "%APPDATA%\KeePass"), which is within the user profile directory ("%USERPROFILE%"). In this case, having write access to the KeePass configuration file is typically equivalent to having write access to the user profile directory. Someone who has write access to the user profile directory can perform various kinds of attacks. For example, the attacker could add malware in the startup folder ("%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup"; the malware will run automatically after the next user logon), modify desktop shortcuts (in "%USERPROFILE%\Desktop"), manipulate the user's registry (file "%USERPROFILE%\NTUSER.DAT"), modify configuration files of other applications (for instance to make a browser open a malicious website automatically), and so on.
If the user is using the portable version of KeePass, the configuration file is stored in the application directory (which contains the "KeePass.exe" file). In this case, having write access to the KeePass configuration file is typically equivalent to having write access to the application directory. With this capability, an attacker can for instance simply replace the "KeePass.exe" file by some malware.
In both cases, having write access to the KeePass configuration file typically implies that an attacker can actually perform much more powerful attacks than modifying the configuration file (and these attacks in the end can also affect KeePass, independent of a configuration file protection).

These attacks can only be prevented by keeping the environment secure (by using an anti-virus software, a firewall, not opening unknown e-mail attachments, etc.). KeePass cannot magically run securely in an insecure environment.

This section gives answers to questions like the following:

Would encrypting the configuration file increase security by preventing changes by a malicious program?
Would encrypting the application (executable file, eventually together with the configuration file) increase security by preventing changes by a malicious program?
Would an option to prevent plugins from being loaded increase security?
Would storing security options in the database (to override the settings of the KeePass instance) increase security?
Would locking the main window in such a way that only auto-type is allowed increase security?
The answer to all these questions is: no. Adding any of these features would not increase security.

All security features in KeePass protect against generic threats like keyloggers, clipboard monitors, password control monitors, etc. (and against non-runtime attacks on the database, memory dump analyzers, ...). However in all the questions above we are assuming that there is a spyware program running on the system that is specialized on attacking KeePass.

In this situation, the best security features will fail. This is law #1 of the Ten Immutable Laws of Security (Microsoft TechNet article; see also the Microsoft TechNet article Revisiting the 10 Immutable Laws of Security, Part 1):
"If a bad guy can persuade you to run his program on your computer, it's not your computer anymore".

[Reactie gewijzigd door Scriptkid op 22 juli 2024 14:47]

[mjtdevries]

Allemaal mooie excuses. Maar het is een ontwijk manoeuvre om niet te hoeven toe te geven dat het een dom besluit is om de configuratie van een export zonder het wachtwoord te geven op een makkelijk benaderbare plek te zetten. (xml file)

Ergens anders zegt de ontwikkelaar ook dat de config noodzakelijkerwijze ingelezen moet worden voordat de database geopend is. Dat is uiteraard lariekoek voor deze situatie.
De configuratie of je wel of niet een export mag maken zonder het wachtwoord te geven hoeft helemaal niet ingelezen te worden voordat de database geopend is. Die configuratie setting kun je prima in de database zelf opslaan.

En ja, een aanvaller met onbeperkte mogelijkheden houd je niet tegen. Dat bestrijd ook niemand, maar dat betekent niet dat je geen maatregelen moet nemen tegen de gelegenheidsdief.
Het slot op je voordeur houd een dief die echt binnen wil komen ook niet tegen. Maar je kunt wel een 3 sterren cylinder installeren zodat ze niet in 10 seconden zonder geluid te maken binnen komen.,

Op een thuis pc waar niemand anders op kan komen is het risico uiteraard kleiner.
Maar keepass word ook in bedrijven gebruikt. Waar het voorkomen van schrijfrechten een stuk lastiger is. En collega's (inclusief systeembeheerders) die kwaad willen zijn niet ondenkbaar.
Gaan die een keylogger installeren? Nee, want de anti-malware tools gaan dan alarm slaan.
Maar heel simpel een xml file aanpassen kunnen ze prima ongezien doen.
En als het super simpel is om die methode te voorkomen, waarom dan de onwillendheid om daar iets aan te doen?

[Scriptkid]

manke vergelijkingen men is dan nog niet binnen,

of het moet zijn dat jij samen met de dief die langs je bed staat nog even de 3 punt cilinder er in wilt zetten.

Je kunt het alle kanten uit blijven draaien , Ook je voorbeeld van een collega is JOUW eigen stomme schuld had je je pc maar moeten locken,

Als jij hem niet locked geeft je zoiezo al aljouw account gegevens prijs aan je collegas en verdien je het om op je fouten gewezen te worden. Zeker een systeem beheerder kan enorm veel data en login gegevens van jouw uit jouw user profile trekken zonder ook maar iets te instaleren. zelfde geld voor de persoon die remote code execution doet op jouw pc,

Meschien toch eens verdiepen in de redhat wereld.

[brabbelaar]

Die databases zijn encrypted en worden gewoon in clouds gezet om ook op andere apparaten te kunnen delen toch?

Wat is hier nu voor nodig? Wanneer exporteert Keepass die database? Werkt dit ook bij keepassxc? En is het niet heel weinig moeite om dit te fixen?

Enfin, zoveel vragen, en de zoveelste password manager hack. Ik ga popcorn halen.

Edit,
Ik zie het. Export on user password, dus zodra je de db ontsluit, en dan moet gebruikersbevestiging van die export al uitstaan. Het is een risico en moet gewoon gefixt worden, maar als het risico zich voordoet is je computer ook al wel serieus gehackt.

[Reactie gewijzigd door brabbelaar op 22 juli 2024 14:47]

[Creesch]

Ik kan niet op alle vragen antwoord geven, maar

Werkt dit ook bij keepassxc?

Daar lijkt het niet op. Het gaat specifiek er om dat de applicatie exporteren toelaat zonder bevestiging en dit vanuit de configuratie getriggerd kan worden.

Zie ook: https://github.com/alt3kx/CVE-2023-24055_PoC

Andere implementaties zullen niet perse hetzelfde gedrag vertonen .

[Reactie gewijzigd door Creesch op 22 juli 2024 14:47]

[Cergorach]

Stel je heb remote toegang tot een beveiligde machine (laten we stellen via beheer software). Bij het remote aanpassen van een tekst file verwacht ik niet dat de beveiligingssoftware begint te gillen. Bij het genereren van een xml ook niet, van een kopie maken van die xml ook niet. En de boel weer terug aanpassen en de xml verwijderen op de betreffende PC ook niet. Zo een powershell command zou nog wel eens een alarmpje kunnen veroorzaken. Net als een keylogger installeren.

Dit zie ik als best gevaarlijk, want je maakt geheel gebruik van de native software zonder daar aanpassingen te maken aan het programma zelf, puur een config file.

Stel je voor dat je dit doet met die admin credentials die je in een script hebt gevonden en de beheerder ervan klikt per ongeluk toch op OK via MFA (SchizoDuckie: .geek: Tweaker ontdekte admingegevens Azure-ontwikkelomgeving Belastingdienst...). Via Intune de wijziging doorvoeren, path ergens in een OneDrive of SPO gesyncte folder en het daar uitvissen als admin...

[RobertMe]

dan moet gebruikersbevestiging van die export al uitstaan.

Maar ook dat is weer een setting in een plain tekst bestand die dus aangepast kan worden door een aanvaller Als setting A in bestand B aangepast kan worden is setting C in bestand D natuurlijk ook geen probleem om die aan te passen.

[dutchgio]

KeePass gebruikt een database die je gewoon offline kunt opslaan. En die is dus vrij eenvoudig uit te lezen

[pennywiser]

Als je de XML hebt, niet als je alleen de kdbx hebt.

[mjtdevries]

Export on user password, dus zodra je de db ontsluit, en dan moet gebruikersbevestiging van die export al uitstaan.

Zelfs dat hoeft niet. Je kunt 'm laten exporteren bij het starten van keepass zonder dat je het master wachtwoord ingegeven hebt.

[Zebby]

Ik vind de subtitel erg onduidelijk, "Aanvallers met toegang tot een pc kunnen wachtwoorden in plaintext uitvoeren. "

Wat is uitvoeren in deze context? Bedoelen jullie niet exporteren?

"KeePass is niet bedoeld om beveiligd te zijn tegen aanvallers die al op binnen zijn gedrongen op de pc van het slachtoffer."

Dit vind ik ook wel onzin. Het is toch een versleuteld databasebestand specifiek voor je wachtwoorden. Wat daar in staat moet simpelweg niet in te zien zijn zonder het wachtwoord.

[Robbierut4]

Ik vind de subtitel erg onduidelijk, "Aanvallers met toegang tot een pc kunnen wachtwoorden in plaintext uitvoeren. "

Wat is uitvoeren in deze context? Bedoelen jullie niet exporteren?

Dit is denk ik 1 van die keren dat tweakers doorslaat in alle woorden omzetten naar een nederlands woord.

"KeePass is niet bedoeld om beveiligd te zijn tegen aanvallers die al op binnen zijn gedrongen op de pc van het slachtoffer."

Dit vind ik ook wel onzin. Het is toch een versleuteld databasebestand specifiek voor je wachtwoorden. Wat daar in staat moet simpelweg niet in te zien zijn zonder het wachtwoord.

Als je de cve leest en de gelinkte topics dan gaat het hierom:
een hacker kan een xml bestand aanpassen en daarin een stille export van alle wachtwoorden aanzetten. De eerstvolgende keer dat de gebruiker het wachtwoord invoert worden dan alle bestanden naar een tekstbestand geexporteerd. Zonder dat de gebruiker daar iets van ziet.

De hacker kan vervolgens dat bestandje gewoon downloaden en heeft alle wachtwoorden in plain text.

Waarom een password manager een functie heeft dat je alles kunt exporteren zonder enige melding te geven aan de user gaat mij overigens de pet te boven. Je zou denken dat je voor een export minstens 3 rood knipperende schermen ziet van pas op, dit is mogelijk een risico. Doe alleen als het zeker weet.

[WhatsappHack]

“Waarom een password manager een functie heeft dat je alles kunt exporteren zonder enige melding te geven aan de user gaat mij overigens de pet te boven.”

Exportability om alles over te zetten naar een ander formaat of manager? Just a thought.

[Robbierut4]

“Waarom een password manager een functie heeft dat je alles kunt exporteren zonder enige melding te geven aan de user gaat mij overigens de pet te boven.”

Exportability om alles over te zetten naar een ander formaat of manager? Just a thought.

Oh zeker. Exporteer functie is nuttig. Maar als het gaat om al je wachtwoorden naar plain text exporteren, dan moet er toch op zijn minst een popup komen om te bevestigen dat je dat wil?

[NoobishPro]

Waarom een password manager een functie heeft dat je alles kunt exporteren zonder enige melding te geven aan de user gaat mij overigens de pet te boven.

zoals aangegeven; om verschillende Keepass databases te synchroniseren.

Je kunt b.v. 3 verschillende databases hebben met steeds minder wachtwoorden (voor b.v. senior developers/server managers en/of stagiairs in je bedrijf) en deze met elkaar laten synchroniseren. Omdat ze allemaal hun eigen encryptie hebben, moet dat over plain-text worden overgeheuveld.

Waarom de export dan niet per direct verwijdert weet ik echter ook niet.

[jurgen1976]

Dit kan natuurlijk ook prima opgelost worden mbv public/private key encryption.

Ik moet zeggen via plaintext is voor een wachtwoord manager wel een armoedig, zeker omdat je het ook nog eens aan kan zetten zonder dat daarvoor expliciet 'toestemming' voor nodig is vanuit de versleutelde database.

Anderzijds kan je inderdaad zeggen als iemand al dergelijke toegang heeft tot je lokale systemen, dan is er sowieso al geen redden meer aan. Maargoed dit maakt het wel heel gemakkelijk

[NoobishPro]

Als ik het goed begrepen heb, is de 'toestemming' dus het moment dat jij je wachtwoord invoert.
Dit betekent dat jij het wachtwoord sowieso hebt en je wil in de bedrijfsvoering natuurlijk wel dat alles synchroniseert en niet dat één of andere buttface steeds "nee" klikt uit automatisme.

Ik ben het verder niet oneens met je. Het is vreemd dat dit niet beter beveiligd is.

Betreft een public/private key, dit zou toch betekenen dat als je een lower-security-level database weet te kraken, je ze meteen allemaal hebt? Is dit dan wel een goede oplossing?

[R4gnax]

Ik vind de subtitel erg onduidelijk, "Aanvallers met toegang tot een pc kunnen wachtwoorden in plaintext uitvoeren. "

Wat is uitvoeren in deze context? Bedoelen jullie niet exporteren?

Het woord "uitvoeren" heeft als iets meer archaische betekenis ook "het naar buiten transporteren."
Het is correct; maar niemand die het gaat begrijpen, idd.