CERT-Warnung: Standard KeePass-Setup ermöglicht Passwort-Klau (CVE-2023-24055)

Sicherheit (Pexels, allgemeine Nutzung)[English]Kurzer Hinweis bzw. Warnung an Nutzer des KeePass Password Safe zur Verwaltung von Kennwörtern und Zugangsdaten. Das Cyber Emergency Response Team aus Belgien (CERT.be) hat am 27. Januar 2023 eine Warnung zu KeePass veröffentlicht. Im Standard-Setup sind 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). Es gibt aber weniger bekannte Möglichkeiten, das Setup etwas zu härten – ob es sinnvoll ist, steht auf einem anderen Blatt. Hier eine Übersicht über dieses Thema.


Anzeige

Die CERT.be-Warnung vor Passwortklau

Ich bin durch Blog-Leser Dreisenberger auf Twitter über die Warnung Warning – An attacker who has write access to the KEEPASS configuration file can modify it and inject malicious triggers von CERT.be vom 27. Januar 2023 informiert worden – danke dafür.

CERT.be: Keepass security advirsory

Der Keepass Passwort-Manager

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.

Hintergrund: Das Keepass Event-System

KeePass verfügt über ein System zur Auslösung von Ereignissen, Bedingungen und Aktionen. Mit diesem System können Arbeitsabläufe automatisiert werden. Das Problem: Ein Angreifer könnte diese Funktion missbrauchen, indem er bösartige Auslöser (Trigger) in die KeePass XML-Konfigurationsdatei einschleust. Dazu benötigt ein Angreifer aber Schreibberechtigungen auf dem System des Keepass-Nutzers.

Das Profilproblem bei der Installation

Keepass hat in diesem KB-Beitrag die Informationen offen gelegt und schreibt: Ein Angreifer, der Schreibzugriff auf die KeePass-Konfigurationsdatei hat, kann diese böswillig verändern (z. B. könnte er böswillige Auslöser einfügen). Dies ist jedoch keine wirkliche Sicherheitslücke von KeePass. Zum Problem wird dies aber unter Windows, wenn Nutzer die Standard-Vorgaben beim Setup des Programms verwenden.

Dann wird KeePass vom Setup-Programm so installiert, dass die Konfigurationsdatei im Anwendungsdatenverzeichnis des Benutzers in

"%APPDATA%\KeePass"

gespeichert wird. Dieser Ordner befindet sich innerhalb des Benutzerprofilverzeichnisses ("%USERPROFILE%"). Das bedeutet aber, dass jede im Benutzerkonto ausgeführte Anwendung Zugriff auf die KeePass-Konfigurationsdatei hat und diese auch schreibend verändert kann. Ein Angreifer bräuchte also nur eine Anwendung im Kontext des Benutzerkontos auszuführen, und erhält Schreibzugriff auf die Konfigurationsdatei. Dadurch sind verschieden Angriffsszenarien denkbar.


Anzeige

Verschiedene Angriffsszenarien

CERT.be weist in seiner Warnung nun darauf hin, dass ein Angreifer, der Schreibzugriff auf die KeePass-Konfigurationsdatei hat, diese verändern und bösartige Trigger einschleusen kann, z. B. um die Klartext-Passwörter durch Hinzufügen eines Export-Triggers abzufischen. Geht man in den Keepass KB-Beitrag, werden noch ganz andere Probleme genannt. Ein Angreifer könnte beispielsweise Malware in den Startordner unter

"%APPDATA%\Microsoft\Windows\Start Menu\Programme\Startup"

einfügen. Diese Malware würde nach der nächsten Benutzeranmeldung automatisch ausgeführt und könnte anschließend Desktop-Verknüpfungen (in "%USERPROFILE%\Desktop") ändern, die Registrierung des Benutzers manipulieren (in HKLU bzw. in der Datei "%USERPROFILE%\NTUSER. DAT"), oder Konfigurationsdateien anderer Anwendungen ändern (z. B. um einen Browser dazu zu bringen, automatisch eine bösartige Website zu öffnen) usw.

Verwendet der Benutzer die portable Version von KeePass, wird die Konfigurationsdatei im Anwendungsverzeichnis gespeichert (das die Datei "KeePass.exe" enthält). In diesem Fall ist der Schreibzugriff auf die KeePass-Konfigurationsdatei in der Regel gleichbedeutend mit dem Schreibzugriff auf das Anwendungsverzeichnis. Mit dieser Fähigkeit kann ein Angreifer zum Beispiel die Datei "KeePass.exe" einfach durch eine Malware ersetzen.

Keepass schreibt zwar, dass Schreibzugriff auf die KeePass-Konfigurationsdatei in der Regel bedeutet, dass ein Angreifer weitaus mächtigere Angriffe als die Änderung der Konfigurationsdatei durchführen kann (und diese Angriffe können sich letztlich auch auf KeePass auswirken, unabhängig von einem Schutz der Konfigurationsdatei).

Einsatz nur in sicherer Umgebung

An dieser Stelle kommen wir zum Kernproblem: Viele Nutzer verwenden Passwort-Manager um sich einerseits die vielen Zugangsdaten nicht merken zu müssen, aber andererseits vielleicht auch, um einen Passwort-Klau zu vermeiden (die Zugangsdaten für Benutzername und Kennwort werden ja verschlüsselt gespeichert). Wenn die Umgebung, in der KeePass läuft, manipuliert werden kann, so dass sich die Kennwörter im Klartext exportieren lassen, gibt es ein Problem.

Angriffe auf KeePass und die Umgebung können nur  verhindert werden, indem der Anwender die Umgebung sicher hält. CERT.be und KeePass schreiben, dass die Sicherheit gewährleistet werden könne, indem eine Antiviren-Software und eine Firewall verwendet werde, keine unbekannten E-Mail-Anhänge öffnet werden etc.

Da kein Patch zur Verfügung gestellt wird, schlägt der CCB (Centre for Cyber security Belgium) vor, eine Entschärfung über die erzwungene Konfigurationsfunktion zu implementieren. Dazu werden im KeePass Hardening Guide (KeePass Enhanced Security Configuration) auf Github Möglichkeiten zur Verbesserung der Sicherheit über eine wenig bekannte erzwungene Konfigurationsdatei aufgeführt.  Diese Funktion ist in erster Linie für Netzwerkadministratoren gedacht, die bestimmte Einstellungen für Benutzer einer KeePass-Installation erzwingen wollen, kann aber auch von Endbenutzern verwendet werden, um ihre KeePass-Einrichtung zu härten.

Einstellungen in der erzwungenen Konfigurationsdatei KeePass.config.enforced.xml haben Vorrang vor Einstellungen in globalen und lokalen Konfigurationsdateien. Mit den verschiedenen, im GitHub-Repository Keepass-Enhanced-Security-Configuration dokumentierten Optionen zum Härten einer KeePass-Umgebung ist es zum Beispiel möglich, die Trigger-Funktion zum Passwort-Export vollständig zu deaktivieren (XPath Configuration/Application/TriggerSystem). Macht aber nur Sinn, wenn Nutzer diese XML-Datei nicht manipulieren können.

Allerdings ist das alles eine aufwändige Geschichte und jeder Schritt will bedacht sein (es ist zu prüfen, ob die Härtung wirklich ausreichend ist). CERT.be schreibt dann auch: Organisationen könnten auch den Wechsel zu einem alternativen Passwort-Manager mit Unterstützung für KeePass-Passwort-Tresore in Betracht ziehen.

Ergänzung: Die KeePass-Entwickler diskutieren nun, ob die Warnung des CERT.be berechtigt ist oder nicht. Die Kollegen von Bleeping Computer haben das hier aufgegriffen.

Ergänzung 2: Die KeePass-Entwickler haben wegen der Schwachstelle nachgebessert, siehe KeePass 2.53.1 bessert bei Schwachstelle CVE-2023-24055 nach


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

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

67 Antworten zu CERT-Warnung: Standard KeePass-Setup ermöglicht Passwort-Klau (CVE-2023-24055)

  1. mw sagt:

    Gilt das auch für PeePass 1.x oder nur für 2.x?
    IMHO gibt es in version 1.x keine Trigger.

    • Mark sagt:

      Jemand der vollen Schreibzugriff auf dein System hat wird auch da einen Weg finden. Der könnte dir einfach eine andere EXE unterjubeln, die gleich das PW Key-loggt und dann die DB über einen Socket mitsamt PW and einen C2C server sendet.

      Voller Schreibzugriff ist mehr oder weniger bereits ein K.O.

      • mw sagt:

        Das gilt letzendlich für jedes Passwort oder Token, auch für offline gespeicherte. Kompromitierte Rechner sind immer ein K.O.

        Da bleibt Dir nur die vage Hoffnung, daß dein 2. Faktor nicht auch kompromitiert ist.

      • Chris sagt:

        Um alle Passwörter aus dem Safe abzugreifen müsste der Angreifer aber über Wochen/Monate im System sitzen mit der Gefahr irgendwann entdeckt zu werden. Da ist die Möglichkeit alle Passwörter auf einmal aus dem Safe zu exportieren doch schon wesentlich komfortabler.

  2. McAlex777 sagt:

    Auf das Problem wurde hier in den Kommentaren bereits vor einigen Wochen hingewiesen.

    Einfacher Workarround:
    NTFS-Schreibrechte für Benutzer auf folgende Datei entziehen:
    %AppData%\Keepass\KeePass.config.xml

    Alternativ können auch alternative Applikationen verwendet werden. z.B.
    KeePassXC

    • Paul sagt:

      Gute Idee.
      Und wenn der User tatsächlich die Rechte hätte, sich selbst das Schreibrecht zu entziehen, wie bekommt er wieder und warum sollte ein böses Programm mit den Rechten des Users das nicht auch können?

      • McAlex777 sagt:

        >> Und wenn der User tatsächlich die Rechte hätte, sich selbst das Schreibrecht zu entziehen,

        Das hinzufügen von NTFS-Rechten erfordert Adminrechte.

        Somit können nur Programme die im Admincontext laufen die Datei ändern.

        • AllanDanton sagt:

          Dem muss ich widersprechen. Die o.g. keepass.config.xml liegt im Benutzerprofile und damit ist der User auch Eigentümer der Datei. Als Eigentümer kann er sich die Schreibrechte selber wieder geben, wenn er sie entzogen hat.
          Nur wenn man nicht Eigentümer der Datei ist, benötigt man Adminrechte, um das Eigentum an einer Datei zu übernehmen.

          • Stefan Kanthak sagt:

            AUTSCH: beides falsch!

            Richtig ist:
            1) solange die DACL eines Objekts keinen ACE fuer den "trustee" *S-1-3-4 alias "owner rights" enthaelt, der die Zugriffsrechte des Eigentümers EXPLIZIT festlegt, hat dieser IMPLIZIT das Zugriffsrecht WDAC alias "write discretionary ACL" (womit der Eigentümer beispielsweise eine "owner rights" ACE hinzufügen kann, die ihm das Zugriffsrecht WDAC entzieht)
            siehe auch https://skanthak.homepage.t-online.de/tidbits.html#sddl sowie https://skanthak.homepage.t-online.de/download/SDDL.INF
            2) ein Prozess bzw. Thread, in dem das Privileg "SeTakeOwnerShipPrivilege" aktiv ist, kann den Eigentümer unabhängig von der DACL aendern;
            3) ein Prozess bzw. Thread, in dem das Privileg "SeRestorePrivilege" aktiv ist, kann den kompletten "security descriptor" schreiben, d.h. Eigentümer, Gruppe, DACL und SACL, unabhängig von der DACL.
            Beide Privilegien sind u.a. im Konto *S-1-5-18 alias "NT AUTHORITY/SYSTEM" alias "LocalSystem" aktiv; im Konto *S-1-5-21-*-*-*-500 alias "Administrator" bzw. Konten, die der Gruppe *S-1-5-32-544 alias "Administratoren" angehören, sind sie vorhanden, müssen aber aktiv gesetzt werden, wie beispielsweise in https://skanthak.homepage.t-online.de/tidbits.html#process sowie https://skanthak.homepage.t-online.de/tidbits.html#twiddler gezeigt.
            GRUNDLAGEN, Kinder, Grundlagen!

            Soll ich weitermachen?
            Kann beispielsweise der Eigentümer bzw. ein in seinem Konto laufender Prozess die schreibgeschützte XML-Datei kopieren, das Original löschen und der nicht schreibgeschützten Kopie (ggf. nach Ablauf der Zeit des "NTFS tunneling") den Originalnamen geben?
            Siehe dazu https://skanthak.homepage.t-online.de/quirks.html#quirk16 und https://skanthak.homepage.t-online.de/quirks.html#quirk17 (ja, auch den Microsofties ist ihr eigenes System fremd bzw. dessen Dokumentation MANGELHAFT).

            Wer jetzt denkt "Dann schütze ich halt das Verzeichnis" hat schon wieder verloren, denn dieses hat ein ungeschütztes übergeordnetes Verzeichnis — bis hinauf zu %USERPROFILE%
            Und wer dieses gegen Änderungen untergeordneter (Dateisystem-)Objekte schützt darf sich bei der nächsten Benutzeranmeldung nicht wundern…

          • himbeertoni sagt:

            @Stefan Kanthak
            Also Linuxer lache ich jedesmal über NTFS und diese "eigenwillige" urkomische Rechteverwaltung.

          • McAlex777 sagt:

            "Als Eigentümer kann er sich die Schreibrechte selber wieder geben, wenn er sie entzogen hat."

            Sorry, das hatte ich selbst nicht auf dem Radar.

            1.
            =============================
            Ich habe gestern die Datei als "Admin" die Eigentümer-Rechte übernommen, und anschliessend dem entsprechenden User nur Lese/Ausführ-Rechte gegeben.

            Gleiches habe ich mit dem übergeordnetem Verzeichnis "KeePass" gemacht.

            Das sollte als "Workarround" soweit funktionieren.

            2.
            =============================
            Besser ist die unten dargestellte Variante via "KeePass.config.xml" im Applikations-Verzeichnis:

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

            > Disable trigger system.
            > Disallow plugins.

            Diese XML-Datei sollte natürlich auch nur via Administratoren bearbeitbar sein.

            3.
            =============================
            Noch sinnvoller erachte ich KeePassXC.

          • 1ST1 sagt:

            @Stefan Kanthak, bitte mal das Eicar-Testfile von Ihrer Webseite entfernen, das nervt!

            @himbeertoni, bitte erstmal die Leistungsfähigkeit des NTFS-Dateisystems in Bezug auf Rechteverwaltung (vor allem im Zusammenhang mit einem AD) verstehen! Das ist wesentlich leistungsfähiger als das olle chmod-Zeugs (su, owner, group, other) sämtlicher Linux-Dateisysteme!

          • himbeertoni sagt:

            @1ST1
            Überholt. Einfach mal die man pages für setfacl und getfacl ansehen und in der RedHat-Hilfeseite nachsehen, sooo schwer ist das nicht ;)

            Die Zwangsjacke namens AD DS von Windows ziehe ich mir nicht an.

  3. McAlex777 sagt:

    Es macht einen finalen Unterschied ob ich einen Angriff per Root ausführen muss, oder auch schon mit Userrechten ausführen kann.

    Ich möchte hinzufügen das solch "schwere" Sicherheitsprobleme by Design solchen auf "Sicherheit" getrimmten Projekten einen sehr faden Beigeschmack geben.

    • Mardoc sagt:

      reicht es die Datenbank vom User Profil wegzunehmen und irgendwo neutral zu positionieren?

      • McAlex777 sagt:

        Solange solch eine veränderbare XML-Datei aus ganz gleich welchem Verzeichnis dazu führen kann, das Kennwörter unbemerkt exportiert werden können, solang nützen andere Speicherorte reichlich wenig.

        Solche Automatismen haben m.E. nichts in einem Passwort-Safe verloren.

  4. Singlethreaded sagt:

    Könnte man die Konfiguration nicht einfach in der verschlüsselten Datenbank ablegen, so dass diese erst gelesen werden kann wenn der Anwender diese entsperrt?

  5. Andreas F. sagt:

    Sind auch andere betroffen, wie z. B. KeePassxc?

  6. Pete sagt:

    Zu KeePassXC:
    die Datenbank ist ja kompatibel zu KeePass – da braucht man nur KeePass parallel installieren und hat dann wieder das Sicherheitsproblem.

    • McAlex777 sagt:

      >> da braucht man nur KeePass parallel installieren und hat dann wieder das Sicherheitsproblem.

      Solang man Keepass nicht nutzt ist das kein Problem.

      Problematisch wirds wenn geskinnte KeePassXC Ports nicht mehr von KeePass zu unterscheiden sind. Wobei das auch letztlich mit jeder Software gemacht werden kann.

  7. Martin Feuerstein sagt:

    Das Trigger-System lässt sich unter Extras / Trigger / "Triggersystem deaktivieren" deaktivieren.

    In der XML (sinnvollerweise der geforce-ten Konfiguration) ist

    false

    Für die portable Version nützt das wenig, wenn der Angreifer Schreibzugriff hat (wenn das Benutzerkonto das Schreibzugriff-Flag selbst setzen oder die ACL selbst ändern kann ist es vorbei).

    • McAlex777 sagt:

      was nützt das wenn ich das XML von aussen überschreibe und auf true setze?

      • Martin Feuerstein sagt:

        deswegen in der force-XML im Programm-Verzeichnis, wo normale Benutzer keine Schreibrechte haben. Und natürlich nicht mit Admin-Konten arbeiten.

        seh grad, XML hats (mit Recht ;-)) zerhackt. Nochmal mit etwas Umschreibung :-)
        kleinerals TriggerSystem größerals
        kleinerals Enabled größerals false kleinerals/Enabled größerals
        kleinerals Triggers /größerals
        kleinerals/TriggerSystem größerals

        oder einfach selbst über die GUI ändern, XML aus Appdata rauskopieren und Force-Konfiguration erstellen

        • Chris sagt:

          Wenn ich als Angreifer auf dem System bin kann ich aber auch einfach die PW Datei vom Opfer auf meinen eigenen PC kopieren und dort über meine lokalen KeePass Installation hacken.

        • Stefan Kanthak sagt:

          Hilft nichts bei mit .NET verbrochenem Schrott wie KeePass: eine von der CLR bei ihrem Start geladene "Profiler DLL" kann dem Programm ALLES vorgaukeln.
          Und das ist nur eine von VIELEN Schwachstellen und ANFÄNGER-Design/Implementierungsfehlern…

  8. DerManu sagt:

    Ein weiterer Grund sein System modular aufzubauen. Ich wüsste nicht, warum ein Passwortmanager mit irgendwelchen anderen Applikationen kommunizieren sollte.

  9. Paulo sagt:

    Ich habe KeePass auf einen Kingston „SicherheitsStick". Hier ist das KeePass configuration file – ebenfalls auf dem Stick. PW Ablauf > Kingston Stick > YubiKey > gibt PW Eingabe von KeePass frei > KeePass PW > KeePass ist frei zur Nutzung. Auf dem „SicherheitsStick Veränderungen vorzunehmen ist sicher mit hohem Aufwand möglich. Das ist mein Restrisiko.

    • Paul sagt:

      Du hast also den Kingston „SicherheitsStick" in dem einen USB Port, den Yubikey als 2. Faktor und brauchst keine Software auf dem USB host?

      Bei manchen Sicherheits Sticks kann man wählen, wie er die Daten (nach Eingabe des PW) anbieten soll
      Also bootbare CD, Partition etc.
      Da wäre im CD Modus KeePass und andere Software in diesem Design ja sicher. (Man müsste den Sicherheitsstick so geknackt haben, dass der auch vom Host geschrieben werden könnte.)

  10. Paul sagt:

    Mal wieder ein Beispiel für "over featuritis"?
    Ich habe KeePass gerne benutzt, weil wenig davon zu lesen ist.

    So ganz wird mir nicht klar, wieso diese XML nicht in der Datenbank stehen kann, sondern Plain Text sein muß. Schon wenn ich meine automatischen Anmeldungen sichern will vergesse ich doch diese XLM?

  11. Paul sagt:

    Urgs.. Moment..
    Wenn ich eine portable Version habe, mein USB Stick aber keinen Hardware Readonly-Schalter hat, ich das Teil in einen infizierten Rechner stecke, erlaubt dieses Feature, das die Infektion auf dem nächsten Rechner geschleppt werden kann.
    Aber ohne Hardware Schreibschutz könnte ja jede Exe auf dem Stick ersetzt werden. Ja.
    Nur ändert das die Prüfsumme der exe, was auffallen könnte.
    Wenn sich eine Xml ändert würde das nicht auffallen.

    Hm, da gab es doch früher mal so Sticks die auf Wunsch eine CD emulierten. Keine Änderungen möglich, es sei denn, man kommt hintenrum an den Speicher und kann so das Iso verändern.
    Aber das scheint gestorben zu sein?
    Jupp. Wikipedia schreibt :
    "U3 wird seit Juni 2010 nicht mehr unterstützt"

    USB-Sticks mit einem Schreibschutz-Schalter gibt es auch nur wenige.

    Wie kann man sich einen sicheren USB-Stick mit Tools
    machen ohne sich als Virenflagschiff anzubieten?

    (es gilt ja für KeePass portable. Speicher ich da meine Passwörter? )

    • Paulo sagt:

      Kingston Traveller Stick – startet mit einem CD Image – hier ist das PW fällig um an KeePass zu kommen. Nach etwa 5 PW Versuche wird der Inhalt vom Stick gelöscht.

  12. Werner Hermann sagt:

    Mir wird gerade schlecht :D

    Hier ein Artikel aus 2019 … da fragt man sich wieso das Thema jetzt erst auf kommt

    Mithilfe von Triggern mühelos alle Schlüssel und Zugangsdaten des freien Passwort-Managers KeePass auslesen

    Im Prinzip ist die Debatte ob und wie eine config Datei zu sichern ist sinnfrei.
    Wenn ich Lese-Zugriff auf die PWD-Datei selbst habe, kann ich sie in einer eigenen Umgebung "bearbeiten" und ggfls auslesen.

    Und schlimmer noch ( wenn ich es richtig verstehe ):
    Ungeachtet der Passworte sind ja auch noch ganz andere Angriffe möglich, die nicht einmal etwas mit den Passwort zu tun haben.

    • darkfader sagt:

      well spotted. schade, dass das damals unterging und hoffentlich haben es die interessierten kreise nicht zu oft genutzt. uebersehen haben werden sie es sicher nicht.

    • Stefan Kanthak sagt:

      "Mir wird gerade schlecht :D"
      Erst jetzt? Wie wär's mit einem Blick auf die Metadaten der ausführbaren Dateien dieses SCHROTTs?

      1) das in der "portablen" Variante enthaltene Programm KeePass.exe sowie die von diesem UNSICHER nachgeladene DLL KeePass.XmlSerializers.dll wurden mit dem VÖLLIG VERALTETEN, vor Windows Vista veröffentlichten VisualStudio 8 gebaut, d.h. für das veraltete und von Microsoft seit Jahren nicht mehr gewartete .NET Framework 3.0!

      2) das in der "portablen" Variante enthaltene Programm ShInstUtil.exe sowie die vom Programm KeePass.exe UNSICHER nachgeladenen DLLs KeePassLibC32.dll bzw. KeePassLibC64.dll wurden mit dem völlig veralteten, vor Windows 7 veröffentlichten VisualStudio 9 gebaut; ersteres lädt unabhängig von dieser SCHLAMPEREI mindestens VERSION.DLL aus seinem Anwendungsverzeichnis statt dem Windows-Systemverzeichnis, und die beiden DLLs mindestens WINMM.DLL und WINSPOOL.DRV.

      JFTR: der Missbrauch der in WINMM.DLL enthaltenen Funktion timeGetTime() anstelle der das gleiche Datum (Millisekunden seit Systemstart) liefernden Funktion GetTickCount() aus KERNEL32.DLL in beiden DLLs qualifiziert den Autor dieses Schrotts als perfekt ahnungslosen, auf UNSICHERHEIT bedachten Frickler!

      3) das (wie üblich) KAPUTTE Installationsprogramm versagt kläglich, wenn das TMP-Verzeichnis per DACL (D;OIIO;WP;;;WD) geschützt ist, d.h. Dateien wie unter UNIX nicht ausführbar erstellt werden, oder die Umgebungsvariable TMP=NUL: gesetzt ist; außerdem lädt es mindestens NETAPI.DLL sowie unter älteren Versionen von Windows VERSION.DLL und OLEAUT32.DLL aus dem Anwendungsverzeichnis.
      Da es ggf. erhöhte Rechte anfordert ist "escalation of privilege" darüber möglich.

      JFTR: das Installationsprogramm KeePass-2.53-Setup.exe ist ein mit Delphi gefrickeltes DrexDing, das von Windows seit dem letzten Jahrtausend unterstützte Sicherheitsfeatures wie "stack cookies" oder neuere wie ASLR bzw. /DEPENDENTLOADFLAG:2048 ignoriert!
      Ausserdem verwendet es Funktionen wie SetThreadLocale(): siehe https://archives.miloush.net/michkap/archive/2005/04/23/411074.html und https://archives.miloush.net/michkap/archive/2005/08/22/454360.html

      4) es exportiert die 3 Funktionen TMethodImplementationIntercept, __dbk_fcall_wrapper und dbkFCallWrapperAddr, was VÖLLIG BESCHEUERT ist, denn die könn(t)en nur von geladenen DLLs aufgerufen werden. Dummerweise gibt's aber keine gutartigen DLLs, die sowas machen, d.h. der AHNUNGSLOSE Frickler dieses SCHROTTs hat eine Sollbruchstelle eingebaut.

      Geht's Dir jetzt wenigstens etwas besser^Wschlechter?

      • Günter Born sagt:

        Danke für die Ergänzung – mir fehlte die Zeit, das zu ergänzen.

      • McAlex777 sagt:

        Danke für den tieferen Einblick.

      • 1ST1 sagt:

        Auch danke, noch ein Grund besser vom originalen Keepass weg zu kommen. Aber zumindestens wenn Keepass regulär installiert ist, und der Benutzer auf dessen Programmberzeichnis keine Schreibrechte hat (also kein lokaler Admin ist), ist die Gefahr von dll-Hijacking zum Glück nicht ganz so groß.

        Welche Keepass-Alternativen, die einen "sanften" Umsteig, also ohne neues Dateiformat für den Keepass-Conatiner auskommen, sind denn diesbezüglich sicher(er)? Mit welchen Werkzeugen wird z.B. KeepassXC kompiliert und ist das gegen dll-Hijacking geschützt?

      • Ralf sagt:

        @Stefan Kanthak Da Du Dich ja in der Tiefe mit dem Thema beschäftigt hast, darf ich fragen, welchen Passwortmanager Du selbst verwendest?

      • Werner Hermann sagt:

        "Geht's Dir jetzt wenigstens etwas besser^Wschlechter?"
        Jetzt ist mir auch noch schwindelig :)

        "Wie wär's mit einem Blick auf die Metadaten der ausführbaren Dateien dieses SCHROTTs?"
        Mit Verlaub – nicht jeder hat deinen Einblick. Ich könnte nicht einmal beurteilen, ob deine Ausführungen korrekt sind.
        Ich muss es einfach mal annehmen – was schon ein schlechter Start ist, wenn es um so sensible Themen geht.

        Also auch von mir die Frage:
        Wie händelst du das ?

        Textdatei in verschlüsseltem RAR oder VeraCrypt Archiv :D ?

        Ach von mir nochmal Danke für die Fleißarbeit !

      • Hans sagt:

        Das Thema ist ganz eindeutig sehr persöhnlich für dich, so emotional wie du schreibst. DU BRAUCHST auch nicht IMMER irgendwelche WÖRTER groß schreiben. Sowas ERSCHWERT nur das LESEN!

        Nun aber zu deinem Inhalt: Ja gut, klingt alles nicht so gut, aber nun mal wirklich zum thread model: was von deinem aufgeführten Punkten kann tatsächlich ausgenutzt werden (solange der Angreifer keinen vollen zugriff auf das System hat UND solange die Dateien nicht manipuliert werden)?

        Ich vertraue lieber den unzähligen Sicherheitsaudits zu Keepass als deinem emotionalen Erguss – solange du zumindest nicht alternativen aufzeigst.

  13. Paul sagt:

    Ok, danke für den Hinweis.
    Damit kann verhindert werden, das jemand meine XML verändert oder exe tauscht und ich mit meinem Stick die Infektion zum nächsten Rechner trage.
    Das sollte man eh machen :
    Ein Stick nur für Daten, schreibar.
    Der andere nur für Programme.
    Oder die Daten halt per Email versenden.
    Allerdings kann der Fremde Rechner ja meine Daten auf dem Stick lesen.
    Ja kann problemlos erreichen, das ich seine Version von Keypass (oder anderem Passwort Manager) starte obwohl ich die von meinem Stick starte.
    Em…
    Also doch Keypass nur auf dem Handy und Daten-Transfer des Passwortes per QR Reader oder durch abtippen.. Oder der eine Hilfs Tastatur, die per PS/2 das Passwort "eintippt"…

  14. 1ST1 sagt:

    Die ganzen Ideen mit Read-Only-Stick usw. sind Quatsch, denn irgendwann will/muss man ja mal neue Passwörter in der Keepass-Datei ablegen oder welche ändern. Spätestens dann muss man auf den Stick schreiben können, und dann hat ein Angreifer einen im Sack, wenn dessen Angreiferprozess im Hintergrund lauert. Hier hilft wohl nur Application-Control wie Applocker, XDR-Mechanismen usw. damit solche Prozesse erst garnicht gestartet werden können.

    Auch die Idee mit der Extra-XML um den Trigger abzuschalten ist kaum durchführbar, sowas per Loginscript zu verteilen geht auch nicht so einfach. Hab noch nicht probiert, ob ein Loginscript im User-Kontext dem User die Schreibrechte auf die Datei entziehen kann…

    Das einzige was wirklich hilft, ist eine Keepass-Alternative ohne den entsprechenden Trigger, zum Beispiel KeepassXC. Vielleicht kommt ja für das reguläre Keepass bald auch mal ein Update, wo dieser Trigger nicht mehr funktioniert. Der Autor vom originalen Keepass müsste nur verstehen, dass er mit seiner Featuritis den einen oder anderen Schritt zu weit gegangen ist. Vielleicht wacht er ja durch diese Meldung auf!

    • McAlex777 sagt:

      >> Der Autor vom originalen Keepass müsste nur verstehen, dass er mit seiner Featuritis den einen oder anderen Schritt zu weit gegangen ist.

      Diese Funktion ist offensichtlich kein versehen, kein fehlendes Verständnis – sondern beabsichtigtes Designfeature.

      Die Argumentation das jemand mit lokalen Zugriffsrechten sowieso mehr anstellen könne ist fadenscheinig: sie verschweigt das das Auslesen über solche Trigger per Anwenderrechte sehr einfach erfolgreich ist, während andere Angriffe wie Keylogger in der Regel Root-Rechte benötigen.

      Jede lokale Applikation kann sich mit wenigen Zeilen Code zugriff verschaffen.

      • 1ST1 sagt:

        Eben, und in so einer Keepass-Datei könnten Zugangsdaten drin stehen, die einen Angreifer enorm weiter bringen, z.B. ein Domain-Admin mit Passwort, und das ohne Auffälligkeiten wie mimikatz-Prozess starten und warten bis ein Domainadmin "vorbei kommt", um sowas abzugreifen.

        Die Verharmlosung des Keepass-Entwickler sollte einen zum Wechsel zu KeePassXC überdenken lassen, da wird solch eine Funktion nicht unterstützt.

        • McAlex777 sagt:

          Ich sehe gerade das KeePassXC unter Windows/MacOS deutlich veraltete QT v5.15.6 Librarys aus dem Jahr 2020 verwenden.

          Das hinterlässt für mich einen kritischen Eindruck.

  15. Küngelklüngel sagt:

    Ist ein ähnlicher Angriffsvektor auf Android denkbar?

    • Günter Born sagt:

      Ad hoc würde ich ein jein formulieren, da in Android ja Zugriffsberechtigungen für Apps vom Benutzer zugelassen werden. Wenn das nicht alles abgenickt wird, sollte Malware nicht an Keepass ran können. Probleme ist aber, dass Nutzer da pauschal alles abnicken – und wenn sich jemand dann Schad-Apps installiert, wird es mit der Passwortsicherheit auch nichts werden.

  16. Andy (007 aus Wien) sagt:

    Heißt das, dass jedes im Benutzerprofil angeführte Programm wie zB Microsoft Office die Konfigurationsdatei von KeePass ändern kann?

    Ist das dann nicht ein Problem von Windows!!??

    • TomTom sagt:

      Moin

      Meines Wissens nach, aber da bin Ich nicht in der Tiefe also gerne korrigieren :-) ,
      Ist das KEIN Windows Problem.
      Es ist unter Linux, was ja eine striktere Kontentrennung als MS macht, auch nicht anders.
      Ansonsten müßte man im extremsten Fall ALLES abnicken was an Dateien aufgerufen wird. Und Ich habe auf meinem W11 System alleine schon 95000 DLL.
      Ich weiß nicht wieviele alleine schon Windows benötigt.
      Oder MS Office.
      Unter Linux ist das aber nicht anders.
      Aber selbst wenn man sagt die Programme dürfen in Ihrem eigenen Ordner tun und lassen was sie wollen, halt portable Programme:

      In der Regel will Ich ja unter …\Dokumente meine X.docx öffnen mit Word.
      Oder …\Bilder\X.png mit einem Bildprogramm.
      Da gibt es dann die Möglichkeit entweder jedesmal das abzunicken.
      Jedesmal.

      Oder einen Dienst der das übergibt so wie teilen unter Android.
      (Ich sage in X.png Teile mit Paint und der "Teiler" ruft Paint auf und übergibt die Datei.
      Wenn es die Editier rechte am Bild an paint übergibt, ist die Sicherheit etwas verlustig.
      Übergibt sie die Datei und holt sie sich beim Speichern zurück, kann das ganz schön Platz/Performance/Zeit kosten.)

      Nur ist DER ("Teiler") dann übermächtig und fast alleine auf der Angriffsfläche als Ziel dann da.
      Und dann ist es ein Entwickler team des "Teilens" gegen dutzende Malware Teams.
      die Chancen sind gering das keine Lücke gefunden wird.

      Davon ab wird kaum einer das so nutzen…
      Selbst Ich fände es zwar gut aber mehr als nervig.

      Bitte korrigiert mich wenn Ich daneben liege.
      Wie gesagt, Ist nicht mein Bereich ;-)

    • McAlex777 sagt:

      > Ist das dann nicht ein Problem von Windows!!??

      Nein, auch unter Linux kann in der Regel jedes Programm jede Datei im Homeverzeichnis im Usercontext lesen/schreiben.

      Das Problem ist das KeePass den automatischen Export im Hintergrund erlaubt, und das der Export von jedem Programm in dieser beschreibbaren XML-Datei konfiguriert werden kann.

      Ein möglicher Wordarround ist via Dateisystem die Schreibrechte auf die XML-Datei zu entziehen.

      • 1ST1 sagt:

        Solange der Benutzer Besitzer der Datei ist, bringt das nichts, denn jedes Programm, jedes Script im Benutzerkontext kann einen Schreibschutz auch wieder setzen. Wenn man den Besitzer einer Datei innerhalb des Benutzerprofils auf jemand anders ändert, läuft man noch in ganz andere Probleme, ich denke da z.B. an das Thema "Roaming Profiles" auf Terminalservern…

    • Stefan sagt:

      wird hier xml rausgefiltert? :/
      Security
      Policy
      Export>falsefalse</ExportNoKey
      /Policy
      /Security

      • 1ST1 sagt:

        Ja, kannst du machen, aber solange der Angreifer auch diese Datei wieder ändern kann, nützt das garnix. Ist nur ein (bekannter!) Knack-Schritt mehr. Siehe oben drüber.

        • McAlex777 sagt:

          Nicht wirklich – die Config-File kann mit Adminrechten ins Programmverzeichnis abgelegt werden.

          Somit wirkt die Lösung wenn das Programm mit Userrechten ausführt wird.

          Gegen Angriffe mit Root-Rechten (Keylogger etc.) gibts sowieso keinen Schutz.

  17. Cornelia sagt:

    Kann mir irgendwer eine Alternative ausser dem offenbar auch fragwürdigen KeepassXC empfehlen, womit die Daten lokal und nicht bei irgendeinem Anbieter in der Cloud gespeichert werden?
    Mindestens der Import der Keepass-Datenbank muss möglich sein – oder der Import nach einem Export aus Keepass.

    Soll-Kriterien:
    – Automatische Speicherung der neusten 3-5 Versionen als Backup in einem anderen Pfad
    – Automatisches Anbieten (um Erlaubnis fragen) der gespeicherten Login-Daten auf den zugehörigen Webseiten.

    Die letztgenannten Funktionen nutze ich jetzt in Keepass mittels Plugins und möchte ungern darauf verzichten.

  18. thomipomi sagt:

    Verstehe ich das richtig, dass die hier genannte Lücke es ermöglicht die keepass-Datenbank zu kopieren. Dann wäre meines erachtens als nächstes der Passwortschutz dieser DB zu überwinden.
    Oder ist die Lücke dergestallt dass diese DB auch ohne deren Passwort ausgelesen werden kann ?

    • 1ST1 sagt:

      Wohl nicht richtig verstanden… Der Angriffsvektor ist folgendermaßen: 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..

  19. digital_immigrant sagt:

    Die XML Datei zu KeePass benötigt ihr doch gar nicht (außer aus Bequemlichkeit).
    #### Bequemlichkeit ist nicht Security-Konform ####

    Praktisch könntet ihr ein Script um den Aufruf von KeePass stricken, dass die XML Datei
    löscht, KeePass.exe startet und die neu erzeugte XML-Datei beim Beenden löscht.
    Somit seid ihr (fast) sicher, dass beim Starten keine kompromittierte XML-Datei
    untergejubelt wird.

    Das könnte dann in etwa so aussehen:

    if exist "%~dp0KeePass.config.xml" del "%~dp0KeePass.config.xml"
    "%~dp0KeePass.exe" "%~dp0Your_PwD_Safe.kdbx"
    if exist "%~dp0KeePass.config.xml" del "%~dp0KeePass.config.xml"

  20. Ralf sagt:

    Jetzt (9.2.2023) ist die Version 2.53.1 erschienen. U.a. mit der Änderung:
    Removed the 'Export – No Key Repeat' application policy flag; KeePass now always asks for the current master key when trying to export data.

Schreibe einen Kommentar zu 1ST1 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.