KeePass2 betroffen?

[whiizy]

Ich steige gerade nicht so ganz durch, ob auch die Linux-Version von KeePass unter Debian von dem getriggerten Passwort-Export betroffen ist:

https://nvd.nist.gov/vuln/detail/CVE-2023-24055

Debian stable (Bullseye):
Package: keepass2
Version: 2.47+dfsg-2

Da dort etwas von "through 2.53" steht, würde ich sagen ja, aber weiß es einer genauer?

[schwedenmann]

Hallo


So wie ich die Diskussion darum vertsanden habe,sind alle Versionen bis einschließlich 2.53 sind betroffen, also auch deine. Gefixt wird das von Machern des paßwortmanagers nicht.

mfg
schwedenmann

[whiizy]

So weit war ich ja auch schon, danke.

Dann bleibt vielleicht KeePassXC als Alternative. Das scheint zumindest nicht dieses Triggersystem von KeePass zu haben. Hoffentlich.

[hikaru]

Im CVE steht:

allows an attacker, who has write access to the XML configuration file, to obtain the cleartext passwords by adding an export trigger.

Sollte es dann nicht ausreichen, anderen Usern die Schreibrechte zur Konfigurationsdatei zu entziehen?*
Dann könnten nur noch der rechtmäßige Besitzer und root die Schwachstelle ausnutzen. Und wenn man sich darüber sorgen machen muss, dann hat man ohnehin andere Probleme, wie ebenfalls erwähnt wird:

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.

Wenn man diese Logik zu Ende denkt, stellt sich allerdings die Frage, wozu man überhaupt einen Passwortmanager braucht. Eine Plaintext-Datei mit passenden Rechten (600) sollte dann ausreichen.
Offenbar ist das nicht die akzeptierte Praxis, also soll ein Passwortmanager wohl auch gegen kompromittierte User- und root-Accounts absichern.

*) PS: Sollte das nicht ohnehin der Fall sein?

[cosinus]

Eine Plaintext-Datei mit passenden Rechten (600) sollte dann ausreichen.

Du vergleichst jetzt nicht wirklich eine banale Textdatei mit KeePass oder?
Du hast alle möglichen Funktionen bei KeePass. Und sei es nur das komfortable Suchen, Sortieren der Spalten, Passwortgenerator inkl. Anzeige wie sicher das PW ist, Passworthistorie, Mülleimer, Ablaufdatum und und und ...

[MSfree]

Ich finde die Beschreibung zu dem angeblichen Fehler eher verwirrend. Auch die Meldung auf Heise bringt nicht viel Klarheit.

Ich hatte verstanden, daß man die Konfigurationsdatei von Keepas verändern kann. Nun gut, wenn es so eine Datei gibt, ist es wohl auch Ziel, diese verändern zu können. Wo ist also das Problem?

Die eigentliche Passwortdatenbank ist durch die Veränderung der Konfigurationsdatei zunächst nicht kompromitiert. Man benötigt also trotz Veränderung der Konfiguration das Passwort zum Entsperren der Datenbank. Wo ist hier also der Angriffsvektor, wenn das Entsperrpasswort dem Angreifer unbekannt ist?

Wenn dem Angreifer das Entsperrpasswort bekannt ist, wozu muß er dann die Konfigurationsdatei manipulieren?

Für mich klingt das nach einem Sturm im Wasserglas.

[debilian]

wo liegt denn diese .xml Datei, ich finde die bei mir nicht wirklich....

[hikaru]

Du vergleichst jetzt nicht wirklich eine banale Textdatei mit KeePass oder?

Mir ging es um den reinen Sicherheitsaspekt.

[schwedenmann]

Hallo


@hikaru

Sollte es dann nicht ausreichen, anderen Usern die Schreibrechte zur Konfigurationsdatei zu entziehen?*

Wäre es nciht besser,die xml per passphrase zu sichern und so auch bei einem kompromierten System das Auslesen,manipulieren zu verhindern ?


Für die Macher ist das kein bug,für andere schon. Das könnte man jetzt auich so beschreiben da das Ego der Macher gereizt wurde,machen die jetzt auf Vogel-Strauß-Politik Anstatt das Problem zu fixen.



mfg
schwedenmann

[MSfree]

Für die Macher ist das kein bug,für andere schon. Das könnte man jetzt auich so beschreiben da das Ego der Macher gereizt wurde,machen die jetzt auf Vogel-Strauß-Politik Anstatt das Problem zu fixen.

Für mich ist das ebenfalls kein Bug, siehe meinen Kommentar oben.

[JTH]

Ich finde die Beschreibung zu dem angeblichen Fehler eher verwirrend. Auch die Meldung auf Heise bringt nicht viel Klarheit.

Ich hatte verstanden, daß man die Konfigurationsdatei von Keepas verändern kann. Nun gut, wenn es so eine Datei gibt, ist es wohl auch Ziel, diese verändern zu können. Wo ist also das Problem?

Ich verstehe das so, dass man dir, ohne dein Wissen, über die unverschlüsselte Konfig unterjubeln kann, dass deine Passwörter beim nächsten Entsperren der Datenbank durch dich an beliebige Stelle exportiert werden.

Das finde ich schon bedenklich. Diese Exportfunktion sollte wohl besser in der Datenbank selbst mit und damit manipulationssicher konfiguriert werden.

[MSfree]

Ich verstehe das so, dass man dir, ohne dein Wissen, über die unverschlüsselte Konfig unterjubeln kann, dass deine Passwörter beim nächsten Entsperren der Datenbank durch dich an beliebige Stelle exportiert werden.

Danke, das steht nämlich nirgends so klar, wie du es hier beschreibst. Wenn es denn so ist.

Diese Exportfunktion sollte wohl besser in der Datenbank selbst mit und damit manipulationssicher konfiguriert werden.

Zumindest sollte es keinen automatischenExport bei Entsperrung der Datenbank geben.
Wenn der Anwender einen Export erstellen will, soll der das bitte aus dem Programm heraus veranlassen, aber nicht unkontrollierbar im Hintergrund ausgeführt werden.

[thoerb]

Wenn man diese Logik zu Ende denkt, stellt sich allerdings die Frage, wozu man überhaupt einen Passwortmanager braucht. Eine Plaintext-Datei mit passenden Rechten (600) sollte dann ausreichen.

Es geht da um eine Config-Datei. Die befindet sich bei mir in ~/.config/KeePass/ und da stehen auch keine Geheimnisse drin.

Die Datenbank selbst ist verschlüsselt und mit einer Passphrase geschützt.

Ich verstehe das so, dass man dir, ohne dein Wissen, über die unverschlüsselte Konfig unterjubeln kann, dass deine Passwörter beim nächsten Entsperren der Datenbank durch dich an beliebige Stelle exportiert werden.

Aber dann ist der Angreifer eh schon auf dem Rechner.

[whiizy]

Ich wette darauf, daß KeePass diesen getriggerten Autoexport in einer nächsten Version abschaffen wird. Wenn diese config-Option nicht mehr existiert, kann sie auch nicht ausgebeutet werden.

Wenn der Angreifer es allerdings schafft, dir danach wieder die ältere keepass Version (<=2.53) unterzujubeln, dann wird beim nächsten völlig arglosen Login des Users erneut der Textexport im Hintergrund getriggert. - Die ganze Situation ist durchaus verzwickter, als sie auf den ersten Blick erscheint. Hikaru hatte Implikationen ja schon angerissen.

[JTH]

Aber dann ist der Angreifer eh schon auf dem Rechner.

Ja, richtig. Aber er braucht immer noch eine Möglichkeit, an deine trotzdem noch verschlüsselt vorliegenden Passwörter zu kommen. Und um hier deine benutzereigene Konfiguration zu manipulieren, braucht ein böser Nutzer noch nicht einmal root-Rechte. Deine normalen Benutzerrechte reichen.

Natürlich kann man, wenn man mit bösen Absichten schon soweit ist, auch anderes heranziehen, um deine zukünftigen Tastatur- und sonstige Eingaben abzufangen. Aber wenn der Passwortmanager dem Angreifer da schon was einfaches mitbringt …

Wenn man den Passwortmanager auf diesem Weg zum automatischen Exportieren bewegen kann, ist er doch eigentlich wirklich nicht mehr als eine Plaintextdatei mit mehr Komfort.

[thoerb]

Wenn man den Passwortmanager auf diesem Weg zum automatischen Exportieren bewegen kann, ist er doch eigentlich wirklich nicht mehr als eine Plaintextdatei mit mehr Komfort.

Das stimmt natürlich.

[whiizy]

Für mich ganz persönlich ist das eine Backdoor in KeePass, da ein Angreifer -- ohne meine Credentials dieses Passwort-Safes kennen zu müssen -- unbemerkt den Inhalt bei normaler Nutzung auslesen kann.

[TRex]

Einfache sicher/nicht sicher Aussagen helfen hier nicht, wenn den anderen Teilnehmern nicht klar ist, was damit möglich ist und was nicht.

Wenn man den Passwortmanager auf diesem Weg zum automatischen Exportieren bewegen kann, ist er doch eigentlich wirklich nicht mehr als eine Plaintextdatei mit mehr Komfort.

Das stimmt natürlich.

Das stimmt nicht. Ein Angreifer mit Vollzugriff - ja, dann schon. Aber das ist auch das Wurstcase-Szenario, auf dessen Ebene auch der Keepass-Dev argumentiert. Was wäre bei einem Bug (in einer anderen Software auf dem Rechner des Opfers), der dem Angreifer Schreibzugriff auf eine beliebige Datei gibt? Dann muss er warten, bis das Opfer KeePass ausführt. Dann wird die DB in eine Textdatei exportiert - hat der Angreifer Lesezugriff, kann er ab da auch zugreifen. In beiden Fällen muss er warten, bis das Opfer KeePass ausführt. Bei einer Textdatei mit Klartextpasswörtern hätte natürlich der Lesezugriff ausgereicht.

[OrangeJuice]

Hier beschreibt jemand in einem Kommentar wie es ablaufen könnte.

In der Konfigurations-Datei von Keepass ist ein "Trigger" (Auslöser) hinterlegt, der das nachfolgende macht: Du öffnest Keepass und darin einen Keepass-Container, je nach deiner Sicherheitseinstellung wirst du nach nur Passwort gefragt, oder du musst (zusätzlich) eine Schlüsseldatei angeben. Sobald das abgeschlossen ist und dein Container offen ist, startet automatisch dieser "Trigger" und schreibt den Inhalt deines Keepass-Containers unverschlüsselt und ohne weitere Rückfrage oder Hinweis als reine ASCII-Datei irgendwo auf die Festplatte. Diese Datei ist z.B. per notepad.exe im Klartext zu lesen, mit allen darin enthaltenen Zugangsdaten, und lässt sich selbstverständlich auch per Email oder wie auch immer (per Schadprogramm) automatisch zum Angreifer transferrieren

Quelle: borncity.com/blog

Warning - An attacker who has write access to the KeePass configuration file can modify it and inject malicious triggers

[JTH]

Eigentlich wollt ich auf das Thema ja gar nicht richtig einsteigen Aber wenn man sich einmal drauf einlässt …

Bei einer Textdatei mit Klartextpasswörtern hätte natürlich der Lesezugriff ausgereicht.

Klar, das Gleichsetzen war von mir überspitzt.

Dann wird die DB in eine Textdatei exportiert - hat der Angreifer Lesezugriff, kann er ab da auch zugreifen.

Hab mal nachgeschaut: Man kann dort als Aktion u.a. schon beliebige Kommandozeilen eintragen (Triggers: Actions, URL Field: Executing Command Lines). Das würde doch schon reichen, um mit einmaligem Schreibzugriff (ja, der natürlich ist notwendig) auf die Konfig eine „Komplettlösung“ zu konfigurieren, die nach dem Export die lesbaren Daten auch irgendwo hochlädt. Einen Export direkt zu einer URL (http://, ftp://, …) gibt es auch, vllt lässt sich sogar der hier missbrauchen.

[thoerb]

Ich fände es gut, wenn man einen Export noch mal mit dem master key bestätigen müsste.

[hikaru]

Ein Angreifer mit Vollzugriff - ja, dann schon. Aber das ist auch das Wurstcase-Szenario, auf dessen Ebene auch der Keepass-Dev argumentiert.

Vollzugriff (root) braucht man dafür nicht. Es reicht Zugriff auf eine Shell des Users, entweder weil der Angreifer dessen Passwort schon hat oder über einen anderen Weg.
Das Wurst-Käse-Szenario entsteht erst durch KeePass2, denn das spuckt hier im Zweifelsfall auch das root-Passwort der Maschine aus.

[MSfree]

So richtig einsichtig scheinen die Entwickler wohl nicht zu sein, aber immerhin wird jetzt wohl eine Nachfrage aufgepoppt, wenn so ein Export stattfinden soll:
https://www.heise.de/news/Umstrittene-K ... 89944.html

[thoerb]

...aber immerhin wird jetzt wohl eine Nachfrage aufgepoppt, wenn so ein Export stattfinden soll:

Habe die neue Version gerade auf Windows installiert. Es kommt jetzt eine Passwortabfrage. Auch wenn man xml oder csv exportieren möchte.