KeePass: Diskussion über mögliche Sicherheitslücke
von caschy | 48 Kommentare
Seit einer knappen Woche gibt es einige Diskussionen rund um den Passwortmanager KeePass, den vermutlich alle unsere Leser kennen und viele auch schätzen. Sicherheitsforscher sprechen von einer schweren Sicherheitslücke in Version 2.5x, der Entwickler sieht dies schon länger anders, denn eine ähnliche Geschichte gab es bereits 2019. Entsprechende aktuelle Threads gibt es in der KeePass-Diskussion auf Sourceforge.
Ein Angreifer könnte die Schwachstelle ausnutzen, um Zugriff auf Daten zu erhalten, die in einer KeePass-Datenbank gespeichert sind. Dies betrifft z. B. Benutzernamen, Passwörter und E-Mail-Adressen. Um die Schwachstelle erfolgreich auszunutzen, muss der Angreifer Zugang zu dem System haben, auf dem KeePass installiert ist.
Die Schwachstelle wird dadurch verursacht, dass die Konfiguration von KeePass unverschlüsselt gespeichert wird. Ein lokaler Angreifer kann diese Konfiguration ändern und eine bösartige Exportregel hinzufügen. Wenn ein Benutzer eine KeePass-Datenbank öffnet, bewirkt die Exportregel, dass die gespeicherten Daten an den Angreifer exportiert werden.
Das Ganze lässt sich laut Entwickler direkt in KeePass 2.5x deaktivieren, wenn man da auf der sicheren Seite sein möchte. Mein Screenshot zeigt es: „Tools > Options > Policy > Export – No Key Repeat“ deaktivieren.
Die Diskussion ist derzeit noch in vollem Gange, wir weisen dennoch darauf hin. Die Sicherheitsforscher haben die „Lücke“ unter CVE-2023-24055 eingereicht, gelistet wird sie derzeit als „Umstritten“.
Transparenz: In diesem Artikel sind Partnerlinks enthalten. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir eine kleine Provision. Für euch ändert sich am Preis nichts. Partnerlinks haben keinerlei Einfluss auf unsere Berichterstattung.
Wird geladen ...
Ja bei einem Zugriff auf den Rechner kann er auch einen keylogger nutzen oder Zwischenablage auslesen.
Sonst Bitwarden ist ganz gut 🙂
Oder man stellt KeePass richtig ein.
Dann wird das Passwort in der Sicheren Umgebung von Microsoft ausgeführt, wo der Keylogger nicht hin kommt.
Das gilt aber nur für das Hauptpasswort und nicht für die anderen Passwörter, die man in die Zwischenablage kopieren muss oder per AutoType eintippen lässt. Die sichere Umgebung muss nämlich der Passwortdialog anfordern. Und da funktioniert KeePass dann nicht mehr.
Das ist so richtig.
Besteht das Problem auch bei der Browsererweiterung KeepassHelper?
Nein, das ist sicherer, da Browsererweiterungen einen anderen Kanal nutzen und die Passwörter nicht über Tastatur oder Zwischenablage übertragen.
Man kann bei AutoType auch den „Zwei-Kanal“-Modus aktivieren, bei dem das Passwort über Tastatur und Zwischenablage eingefügt wird. So muss der Keylogger schon beides überwachen, um das komplette Passwort zu erhalten. Wie verbreitet die sind, weiß ich aber nicht. Und es funktioniert wohl auch nicht überall, aber es ist besser als nur einen Kanal zu nutzen.
Danke für die Rückmeldung.
> Dann wird das Passwort in der Sicheren Umgebung von Microsoft ausgeführt
Wie macht man das?
Unter Optionen > Sicherheit > „Hauptschlüssel auf sicherem Desktop eingeben“ (Abschnitt „Erweitert“, drittletzter Eintrag).
Hallo.
Im Screenshot ist nur der Export deaktiviert, richtig wäre meiner Ansicht nach, den Haken darunter zu entfernen.
In dem Fall würde vor dem Export der Key abgefragt.
Ich denke daher, dass der Screenshot nicht ganz korrekt dargestellt ist. Kann das sein?
LG
Martin
Soll man den Export Allgemein verbieten oder den Export – Schlüsselwiederholung?
Screenshot und Text widersprechen sich etwas.
Gilt das in irgendeiner Art auch für Keepass XC?
Danke
Nein, XC kann keine Trigger, dort kann man also nicht im Hintergrund exportieren.
Aber nutzt das nicht das gleiche Datenbankformat? Könnte ich nicht die Schlüsseldatei von KeePassXC nehmen und sie einfach mit KeePass öffnen und damit den Angriff ausführen?
Gleiche Format? Ja klar!
Datenbank mit KeePass öffnen? Dazu braucht man das Passwort 😉
Dazu müsste dem Opfer aber entgehen, dass er grade KeePass benutzt und nicht wie sonst immer KeePassXC. Wenn der Angreifer das selbst machen könnte, wäre es egal, da er ja offenbar das Hauptpasswort schon kennt.
In einem Seminar wurde diese Schwachstelle erwähnt. Dort wurde gefragt, ob es auch die Version KeePassXC betrifft -> diese soll auch davon betroffen sein. Kann das aber gerne am Abend mal testen.
Hi, das wäre super lieb. Bisher sind die Antworten ja ein wenig gemischt.
Danke!
Das ist m.E. keine Sicherheitslücke in KeePass. Das Szenario setzt voraus, dass der Angreifer kompletten Zugriff auf den unverschlüsselten Computer hat. In so einem Szenario kann auch einfach ein Keylogger eingesetzt werden oder der Angreifer kann ein eigenes „KeePass“ installieren, das nur dazu dient, das Passwort abzufangen und die damit verschlüsselte Datenbank zu exportieren.
Netter Versuch des Entwicklers, aber leicht zu umgehen:
Man editiert/ersetzt die config (geht auch während Keepass läuft!) einfach mit der manipulierten Version.
Keinerlei Notiz und KP schreibt die Config auch nicht beim beenden nochmal.
Beim nächsten Start ist der Export dann möglich, z.B. per Trigger.
…aber es ist besser als Nichts. Wer es also machen möchte:
– nach der Policy-Änderung ist ein Neustart von Keepass notwendig!
– lieber direkt „Export“ deaktivieren, dann geht gar kein Export. Wer nämlich kein Plugin wie „KeePassQuickUnlock“ installiert hat ist die häufige Passworteingabe gewohnt, wird u.U. „hä?“ denken, aber das Passwort eingeben.
Die wenigen Male, wenn man exportieren will, schaltet man halt den Export wieder ein und startet Keepass neu.
hab ich in über 10 Jahren nicht einmal genutzt, finde ich erschreckend dass so etwas geht und standardmäßig aktiviert ist :-/
Naja, das ist jetzt m.M.n. keine schwere Sicherheitslücke. Wenn der Angreifer auf dein Windows-System zugreifen kann ist eh alles egal. Wie könnte man dem auf App-Level schon zuverlässig begegnen?
warum denken hier so viele dass der Angreifer auf d den kompletten Rechner Zugriff haben muss? er muss lediglich Zugriff auf die Konfiguration haben, viele haben zum Beispiel keepass als portable Version z.B. auf einem USB Stick und dann wird die Konfiguration editiert und wer achtet da schon drauf? Meldung über den Export gibt’s wohl auch keine ergo liegt die Passwort Datei dann plötzlich irgendwo im Netz?! Echt blöd die Sache!
Achsoo, „lediglich Zugriff auf die Konfiguration“, na dann. 😀
Kompromittiert ist kompromittiert.
Nein. Kompromittiertes System ist nett, aber potenziell noch immer nicht fatal.
Aber durch die Erlangung aller Passwörter eines Nutzers lässt sich echt mist anstellen.
Die Anzahl an Leuten die kein MFA nutzen oder die Anzahl der Dienste die es einfach nicht anbieten ist schier unendlich.
Nein, eine App sollte spätestens in 2022/2022 dem Zero-Traust-Grundsatz folgen und seine Config-Datei entsprechend als nicht vertrauenswürdig behandeln und prüfen (checksum etc.). Alles andere ist nicht mehr state-of-the-art.
DAS kommt darauf an, wo diese Config-Datei abgelegt ist und daher sollte immer „Enforced“-Config genutzt werden. Da ist die Konfiguration im Verzeichnis der Applikation abgelegt und wird immer benutzt – egal was in den anderen Config-Dateien steht. Problem ist da das „portable“ Verwenden der Applikation – da wird nur die Konfiguration in dem Applikations-Verzeichnis abgelegt.
Zusätzlich besteht aber das Problem wie die Config-Datei auf Änderungen zu prüfen wäre? Checksum ist sinnlos.. Möglich wäre auch die se Datei zu verschlüsseln – was aber wieder bei der portable Variante nichts bringt, da Config-Datei einfach gelöscht werden kann…
Ich habe einen rudimentären Schutz so implementiert, dass per TaskManager aller x Minuten der Hash der Config geprüft wird und bei Änderung ein Dialog aufpoppt (die Checksumme muss man halt bei jeder Änderung händisch nachführen).
check_KeePass_config.bat:
REM warn if keepass config changed
certutil -hashfile C:\Users\[snipped]\User\AppData\Roaming\KeePass\KeePass.config.xml SHA256 | find „b231ec23[snipped]14771aafa4“ || GOTO CHANGED
exit
:CHANGED
msg /TIME:0 * Your KeePass config has changed – pls 1st check before working with KeePass!
ich dachte die config wird eh nur beim Start gelesen, dann reicht doch eine Prüfung vor dem Start?!
Sachlich haben Sie Recht.
Aber es ist mir so lieber, als eine Lücke (z.B. Start über „öffnen mit“ oder die .kdbx-Verknüpfung) übersehen zu haben, die zudem (wenn ich die Standards z.B. in der Registry editiere) wieder mit den Standards überschrieben werden könnten (schreiben die Updates z.B. die Werte neu?).
Am Ende des Tages ist es minimal mehr Systemlast, dafür bekäme ich Änderungen auch zeitnah mit und es ist mMn idiotensicherer.
Früher™ habe ich sowas mit Nagios erschlagen, aber im privaten Umfeld erscheint mir das doch ein wenig überrissen.
Was ich oben vergessen habe: Natürlich auch Trigger für Systemstart und Logon.
Und was genau soll das bringen? Definiere lieber eine Enforced-Config im Installationsverzeichnis und schon ist all das was im User-Verzeichnis passiert schlicht egal! (bei portable Use ist all das anders…)
Idee: Config in ein z.b passwort gesichertes zip schreibst und dann über Bat-File entpacken und am richtigen Ort verschieben. Im gleichen Bat file öffnet man Keepass und löscht grad die entpackte config. Somit hat ein angreifer gar nichts zu manipulieren.
Du musst dann zwar zwei passwörter dir merken aber ist immer noch sicherer.
Ah, ist es wieder mal Zeit für eine „Sicherheitslücke“, für die der Angreifer minutenlang Zugang zum entsperrten Rechner haben muss?
Kleiner Denkanstoß: Ein Angreifer, der diese „Sicherheitslücke“ ausnutzen kann, könnte auch noch ganz andere Dinge auf eurem PC machen, z.B. einen Trojaner installieren.
Solche Meldungen sind für mich pure Sensationshascherei. Das erinnert stark an die „Sicherheitslücken“ in irgendwelchen IoT-Geräten, für die der Angreifer eine halbe Stunde Zugang zur Wohnung benötigt um mit Spezialwerkzeug irgendwelche Manipulationen vorzunehmen.
Fakt ist: Wenn jemand an Config-Dateien eurer installierten Anwendungen herumpfuscht, dann wurde eurer Rechner bereits kompromittiert – und das hat nichts mit der jeweiligen Anwendung zu tun.
Hoppla, das sollte ein Kommentar und keine Antwort werden, sorry
Nein, er muss nicht Zugriff auf den Rechner haben, nur auf die Config-Datei, die du bspw. auch auf einem NAS/Cloud-Space/USB-Stick ablegen kannst. Das Problem ist, dass Keypass seine Config nicht adäquat sichert und prüft, sondern sie behandelt wie Windows 3.1 eine .ini-Datei. Das ist einfach nicht state of the art, da die Config-Datei im Betrieb auch weggeändert werden kann und Keypass die Änderungen ungefragt und ohne Rückmeldung an den Benutzer übernimmt und ausführt.
Und wie soll Keypass nun deiner Meinung nach die Config-Datei absichern? Denn eines sollte klar sein: Keypass läuft auch ohne Config-Datei. Eine Möglichkeit wäre die Config-Datei in einem binären Format abzulegen und alle Texte zu verschlüsseln – praktisch? Sicher nicht. Und wirklich sicher auch nicht! (denn wer hindert dich daran, dass du eine veränderte Version des Programms nutzt..)
Und betreffs der Speicherung auf NAS/Cloud – auch ist bei vielen eine Sicherheitseinstellung möglich, bei der ein Schreiben der Config-Datei unterbunden wird! (wer dafür einen USB-Stick nutzt, der zum Schreiben offen ist, ist generell nicht zu helfen oder der ist rein privat unterwegs und da sollte man wissen, was da an Configs benutzt werden!)
Unsinn. Keepass legt seine INI-Datei im geschützen User-Bereich unter %appdata% ab. Das ist absolut State of the Art und hat mit Windows 3.1 nicht das geringste zu tun.
Was du mit irgendwelchen portablen Installationen auf USB-Sticks oder Cloud/NAS (wtf?) anstellst, ist dein eigenes Problem. Im ersten Fall liegt es in deiner Verantwortung, deinen USB-Stick ausreichend zu schützen. Im letzteren Fall würde ich gar an deiner Eignung zweifeln, verantwortungsvoll mit Verschlüsselungssofware umzugehen.
Mein Argument bleibt: Wer so tiefen Zugriff dein System (meinetwegen auch USB-Stick oder NAS) hat, dass er die Config-Datei unbemerkt editieren kann, der könnte auch einfach deine KeePass.exe durch Hax0r-Trojan-4711.exe austauschen (oder die EXE eines beliebigen anderen Programms auf demselben Datenträger).
Das ist eine Sicherheitslücke in deiner persönlichen Nutzungsumgebung und nicht von der darauf installierten Software.
Völliger Unsinn. Und entspricht auch überhaupt nicht aktuellen Designprozessen. Selbstverständlich sichert eine Software selbst ihre Konfigdateien ab und verlässt sich nicht auf die Infrastruktur. Nennt sich zero trust Prinzip. Google es mal, erhellt dich vielleicht.
Aha, ist ja komisch. Dann ist wohl so ziemlich jede Anwendung, die ich installiert habe veraltet, denn die speichern so ziemlich alle in %appdata% inklusive der nativen Windows/Microsoft Software, aber egal.
Zero Trust ist schön und gut, aber hilft dir halt auch nicht weiter, wenn du einem Angreifer unbegrenzten Lese- und Schreibzugriff auf deine Umgebung gewährst, da der dann sowieso so ziemlich alles machen kann, inklusive Keylogger, inklusive Austausch von Keepass.exe, inklusive Trojaner.
Der Einbruch in deine Sicherheit hat längst stattgefunden, noch bevor die Keepass-Config überhaupt angerührt wurde.
Wenn es reicht, dass der PC nicht kompromittiert wird, warum dann die lästige Verschlüsselung der Container mit Passwort und anderen Sicherheitsfeatures. Dann müsste ja eine Textdatei in einem sicheren System reichen. Oder man verpflichet die Programmierer zu Warnhinweisen: Schutz nur gewährleistet, wenn Virenscanner installiert, alle Upadates vorgenommen wurde, der PC verschlüsslet ist, in einer WG oder Familie der Raum abgeschlossen ist etc. Schon mal daran gedacht, dass viele NormalanwenderInnen sich nicht auf Webseiten informieren und sich einfach auf die Aussagen verlassen, dass ein verschlüssselter Container sicher ist. Stimme zu, dass es keine Sicherheitslücke ist: Für ein solch sensibles Programm ist es einfach nur Schlamperei.
Ich sehe das wie Wallo. Diese ganzen Vorschläge in Foren, Keepass sicherer zu machen, bringen doch nur etwas, wenn am Ende ein Update mit entsprechenden Korrekturen steht. Da dieses nicht der Fall zu sein scheint, tun sich die Entwickler mit diesem Verhalten keinen Gefallen. Entweder wechseln viele zu einem anderen Programm, oder das Vertrauen in dieses Programm dürfte leiden. Für eine Passwortverwaltung ist dieses Vetrauen am wichtigsten.
Damit hast du den Angriffspunkt nur verlagert und gleichzeitig öffentlich ins Netz gestellt. Wenn Software auf dem selben Rechner was böses will, ist das nicht sicher zu verhindern. Das ist wahrscheinlich das gesamte Problem bei dieser Diskussion…
Ein kompromittiertes System ist ein kompromittiertes System. Was für lächerliche Sicherheitsforscher sind das? Ist das das Niveau 2023?
Leider ja, aber man sieht ja unter anderem in dieser Kommentarspalte, dass dieser Unsinn scheinbar bei Vielen verfängt. Sogar bei Leuten, die es eigentlich besser wissen müssten.
Noch habe ich aber Hoffnung, dass der CVE letztlich abgelehnt wird, denn er wird ja wenigstens immer noch heiß diskutiert.
Ich habe es probiert. In den Einstellungen kann man den Export verbieten. Das funktioniert auch nach einem Neustart. Aber auch hier kann man die Konfigurationsdatei .xml ändern. Der Export funktioniert dann wieder.
Warum soll das keine Sicherheitslücke sein?
Das Argument „KeePass kann nur in einer sicheren Umgebung betrieben werden.“ hat einen Haken.
Wäre KeePass immer in einer sicheren Umgebung in Betrieb, dann bräuchte man seine Passwörter nicht verschlüsseln.
Welchen Sinn hat eine Passwortverschlüsselung in einer sicheren Umgebung?
Hohes Internet-Gericht : Ich plädiere auf schuldig.
Zusätzlich erforderlich natürlich der Warnhinweis auf den Downloadseiten von Chip, Heise etc. mit einem Sternchen *. Hier wird dann unter dem Artikel erläutert, unter welchen Umständen das Programm sicher sein könnte.
Ich bin für die Bezeichnung „Sicherheitslücke Plus“, falls die Enwickler davon Kenntnis haben, aber keine Lust etwas zu ändern.
Wenn man eine Konfigurationsdatei manipulieren kann, kann man auch die KeePass.exe gegen eine manipulierte Version austauschen. Oder Keylogger installieren. Und wenn ein Angreifer so viele Möglichkeiten hat, warum sollte er sich mit der Konfigurationsdatei befassen?
Gute Nachrichten!
(gefunden bei deskmodder.de)
„KeePass 2.53.1 – Export-Funktion fragt jetzt immer nach Hauptschlüssel
[…]
Das Anwendungsrichtlinien-Flag „Export – No Key Repeat“ wurde entfernt; KeePass fragt nun immer nach dem aktuellen Hauptschlüssel, wenn versucht wird, Daten zu exportieren.“