KeePass 2.53.1 bessert bei Schwachstelle CVE-2023-24055 nach

Sicherheit (Pexels, allgemeine Nutzung)[English]Die Entwickler des Passwort-Safes KeePass haben in der neuen Version KeePass 2.53.1 bezüglich der Schwachstelle CVE-2023-24055 nachgebessert. Konkret wurde die Export-Funktion für Passwörter abgesichert. Vorangegangen war eine Warnung des Cyber Emergency Response Team aus Belgien (CERT.be) vom 27. Januar 2023, die auf eine Schwachstelle hinwies. Passwörter konnten u.U. problemlos von einem lokalen Angreifer exportiert werden.


Anzeige

KeePass Password Safe ist ein von Dominik Reichl entwickeltes, freies, unter den Bedingungen der GNU General Public License erhältliches Programm zur Kennwortverwaltung. KeePass verschlüsselt die gesamte Datenbank, welche auch Benutzernamen und Ähnliches enthalten kann. Der Passwort-Manager dürfte bei einigen Nutzern in Verwendung sein.

Die CERT.be-Warnung vor Passwortklau

Zum 27. Januar 2023 warnte das Cyber Emergency Response Team aus Belgien (CERT.be) vor einer Schwachstelle (CVE-2023-24055) in KeePass. Im Standard-Setup waren Schreibzugriffe auf die XML-Konfigurationsdatei möglich. Das führt zur Schwachstelle CVE-2023-24055, die  einem Angreifer den Weg öffnen könnte, die Klartext-Passwörter durch Hinzufügen eines Export-Triggers zu erhalten (Unauthenticated RCE, Information disclosure).

Ich hatte hier im Blog im Beitrag CERT-Warnung: Standard KeePass-Setup ermöglicht Passwort-Klau (CVE-2023-24055) berichtet. Es gab dann eine Menge Diskussionen bezüglich der vorgeschlagenen Härtungsmethoden. Unter dem Strich: Wenn ein lokaler Angreifer auf dem System ist, ist die Verwendung eines Passwort-Managers kritisch zu sehen. Das war auch die Argumentation des KeePass-Entwicklerteams.

KeePass sichert Export-Funktion

Blog-Leser Stefan K. wies mich bereits am 8. Februar 2023 darauf hin, dass die KeePass-Entwickler offenbar nachgebessert hätten (danke dafür). In der KeePass Version 2.53.1 wurde der Export ohne Eingabe des Masterpassworts komplett entfernt.

KeePass 2.53.1

In den Release Notes heißt es dazu: Das Anwendungsrichtlinien-Flag "Export – No Key Repeat" wurde entfernt; KeePass fragt nun immer nach dem aktuellen Hauptschlüssel, wenn es versucht, Daten zu exportieren. Ansonsten enthält die neue Version von KeePass eine Reihe weiterer Korrekturen, die in den Release Notes nachlesbar sind.

Ähnliche Artikel:
CERT-Warnung: Standard KeePass-Setup ermöglicht Passwort-Klau (CVE-2023-24055)
Vorsicht: audacity.de und keepass.de verbreiten Malware (Feb. 2022)
KeePass-Plugin KeepassRPC aktualisieren …


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Software abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

10 Antworten zu KeePass 2.53.1 bessert bei Schwachstelle CVE-2023-24055 nach

  1. 1ST1 sagt:

    Die Argumentation "wenn der Angreifer eh auf dem System ist, bekommt er eh alle auf dem System verwendeten Passwörter mit" führt nicht zum Ziel. Denn in so einer Passwortdatenbank können auch Passwörter von überall her stecken, Domain-Admin, Zugänge zu SAN-Storage-Systemen, der Unternehmensfirewall, Hersteller-Accounts, irgendwelche Zertifikate, usw… – die man in irgendeiner Remote-Session benutzt und somit für Mimikatz und Co lokal nicht sichtbar sind. Außerdem ist zu bedenken, dass Keepass Mehrbenutzer-fähig ist, mehrere Leute können gleichzeitig die gleiche auf einem Netzwerkshare gespeicherte Datei öffnen, und das synct Änderungen auch automatisch zwischen den Benutzern.

    Dass jetzt immer nach dem Masterpasswort beim Export gefragt wird, ist ein guter Schritt, aber besser ist der Umstieg auf KeePassXC, das unterstützt den Export-Trigger überhaupt nicht.

    • Aaron sagt:

      Die Argumentation "wenn der Angreifer eh auf dem System ist, bekommt er eh alle auf dem System verwendeten Passwörter mit" führt nicht zum Ziel.

      Doch, sehr wohl. Wenn ich Kontrolle über ein System habe, welches für die Anzeige oder das Abrufen von weiteren Zugangsdaten zuständig ist, dann ist das der Definition nach kompromittiert.

      Ich kann ja auch einen Keylogger mitlaufen lassen, mir die Datenbank abgreifen und dann selbst öffnen. Dazu kommt, dass das Kennwort für die Datenbank oftmals nicht super-sicher ist, da man es sich ja wirklich merken muss.

      Wenn der Angreifer bis zu dem PC vorgedrungen ist, musst Du danach – meiner Meinung nach – dennoch alle Zugangsdaten ändern.

      • MOM20xx sagt:

        wenns eh wurscht ist dann brauch ich auch keinen passwort manager. der sollte schon auch noch etwas schutz bieten. wenn der gleich mit dem windows account fällt der schutz, dann ist der pw manager auch unnütz

    • McAlex777 sagt:

      > aber besser ist der Umstieg auf KeePassXC <

      Bin Aufgrund der Aktion jetzt final nach KeePassXC gewechselt.

      Nicht wegen des Fehlers: sondern wegen der Diskussionsart der Entwickler das Problem als Nichtigkeit abzutun, und erst zu reagieren als das Problem Medial Präsent wurde.

  2. McAlex777 sagt:

    Auch wenn das ständig wiederholt wird, greift die Argumentationen im Fall von KeePass nicht.

    >> Ich kann ja auch einen Keylogger mitlaufen lassen <> Wenn ich Kontrolle über ein System habe, welches für die Anzeige oder das Abrufen von weiteren Zugangsdaten zuständig ist, dann ist das der Definition nach kompromittiert. <<

    Mit Userrechten existiert keine Kontrolle über das "System". Dennoch können Out-Of-Box mit ungepatchtem KeePass alle Kennwörter mit Userrechten ausgelesen werden.

  3. Frred sagt:

    Langsam bin ich es leid, immer wieder zu lesen "ein Zugriff mit User-Rechten sei gleichzusetzen mit einem installierbaren Keylogger". Gerade hier im Thema Keepass, wo in früheren Versionen ein einmaliger Zugriff mit User-Rechten ausgereicht hätte.
    Ein gutes Beispiel ist der Beitrag von Aaron, der zwar richtig darauf hinweist, dass man im Falle eines Angriffs weiter denken muss, aber dabei impliziert, die voran gegangenen Überlegungen seien falsch. Dem ist nicht so.
    Wer mal Keyboard-Treiber programmiert hat oder auch einen Keylogger, wird feststellen, dass das Admin-Rechte mindestens für die Installation erfordert. Auch ein Intrusion Detection System sollte den Versuch Eingaben fremder Prozesse abzugreifen, erkennen.
    Die naive Argumentationskette "ein wenig Sicherheitsverlust ist gleich dem vollständigen Verlust" führt in die Irre, weil Angriffe durch mehrere Schichten abgesichert werden sollten. Diese Art des Denkens führt systematisch dahin, Sicherheit aufzugeben, statt sie zu verbessern. Und diskreditiert unberechtigt die Personen, die sich um eine Ebene der Sicherheit bemühen.
    Weiterhin wird dann oftmals noch suggeriert, andere Sicherheitsmaßnahmen wären auch nicht ganz sicher. Das mag für die eine oder andere Situation auf Systemen zutreffen, läßt sich aber keinesfalls allgemein als Argument gegen die Verbesserung von Maßnahmen nutzen.
    Wer solche Fehler in der Argumentation macht, um einen eigenen Standpunkt durchzusetzen, hilft nicht, sondern schadet der Diskussion um IT-Sicherheit!
    Ich bewerte die Diskussion auf Basis unsinniger Behauptungen dann allgemein als Zeitverschwendung. Alles was 1ST1 im ersten Beitrag schrieb, gilt es bei Maßnahmen zu beachten. Danke für den Beitrag.

  4. Andy (007 aus Wien) sagt:

    Das Argument, es handle sich um ein Microsoft Windowsproblem, hat mich zu Beginn beeindruckt. Warum kann MS Office technisch die Konfigurationsdatei von KeePass editieren? Ich weiß MS wird das nie tun.

    Das andere Argument, wer die Konfigurationsdatei von KeePass editieren kann, der kann auch einen Keylogger installieren, hat mich nie überzeugt. Die Installation eines Keyloggers ist weitaus schwieriger als eine *.xml Datei zu editieren. Ein Keylogger wird doch von der lokalen Security abgefangen. Mein lokales Securitysystem hat einen Produktmanipulationsschutz und die Einstellungen sind Passwortgeschützt. Der Betrieb eines Keyloggers hinterlässt Spuren und löst einen Alarm im Unternehmen aus.

    Warum ist eine Passwortdatenbank eines Passwortmanagers verschlüsselt? In einer sicheren Umgebung braucht man keine Verschlüsselung.

    Jetzt mal ehrlich. Meldet sich wirklich jeder User, wenn er den Arbeitsplatz verlässt, vom System ab. Ablenkungen sind menschlich. Beispielsweise eine neue Arbeitskollegin verwendet einen Lippenstift. Wer denkt da an das "Abmelden vom System". Da denkt man doch eher daran, die neue Kollegin auf einen Kaffee in die Betriebskantine einzuladen. Während dieser Zeit kann ein Arbeitskollege einfach die Konfigurationsdatei ändern.

  5. Paulo sagt:

    „ Ausserdem ist zu bedenken, dass Keepass Mehrbenutzer fähig…" Das ist bezüglich Risiko noch „ein Stück Holz mehr". Bin ich im Besitz der Keepass dB, übernimmt KeepassXC das einlesen der db. Ab dann alles im Klartext. Risko ist ein grosses Wort. Die klugen haben ein Massnahmen Katalog und wieso nicht die Account Zugänge, eben nach Wichtigkeit in mehrere dB verteilen. Strukturiertes vorgehen nennt man das. Hilft bei Pannen oder wenn das System kompromittiert ist. Im Übrigen stecken viele Unternehmungen – sehr viel Geld – in das Prozessmanagement, als Vorbereitung, wenn tatsächlich das System geknackt wurde. Die wissen – was ab jetzt zu tun ist.

Schreibe einen Kommentar zu Aaron Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.