1. #1

    Registriert seit
    27.01.2013
    Beiträge
    4
    Thanked 1 Time in 1 Post

    Standard KeePass - Relevanz des DLL-Injection-Angriffs

    Es ist ja nun schon einige Zeit her, dass mit KeeFarce ein DLL-Injection-Angriff auf KeePass veröffentlicht wurde. Allerdings scheint mir die Resonanz nicht sonderlich groß gewesen zu sein; in der aktuellen Version funktioniert er unverändert. Zugegeben, es klappt nur, wenn die Datenbank nicht gelocked ist - aber sind die Angriffszenarien dann so sehr konstruiert? Bei Hacker News wurde das auch kurz diskutiert, dort meint einer, dass es nur zeigt, dass kein Tool 100%ig sicher ist - klar. Es kommt offensichtlich zu Problemen, wenn man als Nutzer Software zu viel vertraut und sie vor allem falsch benutzt.
    Aber wie sähe denn eine sinnvolle Nutzungsstrategie aus, wenn man sich dieses Problems bewusst ist? Irgendwann muss die Datenbank ja mal geöffnet sein, um sie nutzen zu können. Und dann liegen auch die Passwörter gewissermaßen blank.
    Und gibt es in der Hinsicht einen Unterschied zwischen den verschiedenen Betriebssystemen?

  2. The Following User Says Thank You to Tecc For This Useful Post:

    DotNet (08.05.2016)

  3. #2
    Avatar von DotNet
    Registriert seit
    10.06.2015
    Beiträge
    661
    Thanked 316 Times in 185 Posts

    Standard AW: KeePass - Relevanz des DLL-Injection-Angriffs

    Das ist doch eine Farce! Natürlich sind die Passwörter im Speicher, wenn der Passwort-Safe entsperrt ist. Wie soll das auch sonst funktionieren? Den Passwort-Safe permanent gesperrt halten, vor der Abfrage jedes Kennwortes dieses durch Eingabe des Master-Passwortes entschlüsseln und danach sofort wieder sperren wäre die einzige Möglichkeit. Da hat der Nutzer aber viel Spaß, wenn er für JEDES Kennwort sein Master-Passwort eingeben muss, vor allem auf Smartphones. Und selbst wenn es so wäre: Dann würde 100% jemand daherkommen und sich beschweren, dass das Kennwort nach diesem entsperren für ein paar Sekunden bis zur Verwendung durch den Nutzer im Speicher liegt

    Hier von einer falschen Benutzung zu sprechen halte ich für total übertrieben. Natürlich könnte sich jemand mit Schadsoftware infizieren oder Zugriff auf einen fremden PC erhalten, auf dem ein KeePass-Safe entsperrt ist. Wobei im letzten Fall nicht mal ein Injection-Angriff nötig ist. Die Frage ist aber doch: Welche Lösung schützt einem in diesem Falle? Ganz einfach gar keine! Jede Software kann nur so sicher sein wie die Plattform, auf der sie läuft. Nun mit dem Finger auf KeePass zu zeigen wegen dieser angeblichen Lücke ist doch Realitätsfremd. Wie sicher sind meine Passwörter, wenn mein System z.B. mit einem Keylogger infiziert ist und ich sie von Hand eingebe? Wie sicher sind generell solche Passwörter die man im Kopf hat, und dementsprechend einfach erraten werden können? Oder noch besser: Überall das Gleiche.

    Ganz abgesehen davon verwendet der typische Standardnutzer ohnehin keinen Passwortsafe. Ich bezweifle daher, dass diese Angriffsmöglichkeit in der Praxis überhaupt auch nur ansatzweise eine Rolle spielt. Dürfte letztendlich dasselbe sein wie mit Viren unter Linux: Macht keiner, weil es a) zu wenige Linux-Nutzer gibt, dies b) schwieriger ist und c) Linux-Nutzer tendenziell meist auch etwas vorsichtiger sind.

    Im Krieg gibt es keine Gewinner, nur Verlierer!

  4. The Following User Says Thank You to DotNet For This Useful Post:

    Dr. Bastardo (08.05.2016)

  5. #3

    Registriert seit
    27.01.2013
    Beiträge
    4
    Thanked 1 Time in 1 Post

    Standard AW: KeePass - Relevanz des DLL-Injection-Angriffs

    Zitat Zitat von DotNet Beitrag anzeigen
    Da hat der Nutzer aber viel Spaß...
    Natürlich, es ist immer eine Abwägung zwischen Bequemlichkeit und (gefühlter) Sicherheit. Aber es gibt Menschen und Situationen, in der so eine Entscheidung mit Sicherheit gerechtfertigt erscheinen kann.

    Zitat Zitat von DotNet Beitrag anzeigen
    ...vor allem auf Smartphones.
    Absolut, das ist das viel größere Problem, da Smartphones als vertrauenswürdige und einsatzfähige Plattform (aktuell) noch viel weniger taugen. Passwort-Manager auf Smartphones dürften wahrlich Exoten sein (wobei es da schon auch Ansätze gibt, siehe z. B. MobileSitter vom Fraunhofer Institut, nur wer nutzt das schon).

    Zitat Zitat von DotNet Beitrag anzeigen
    ...und sich beschweren, dass das Kennwort nach diesem entsperren für ein paar Sekunden bis zur Verwendung durch den Nutzer im Speicher liegt
    Hier würde ich sehr wohl sagen, dass es eine Verbesserung gegenüber der Gesamtheit der Passwörter ist, die offen liegen. Alternativ kann sich eine paranoide Person natürlich auch für jedes Passwort einen eigenen Passwort-Safe erstellen...

    Zitat Zitat von DotNet Beitrag anzeigen
    Nun mit dem Finger auf KeePass zu zeigen wegen dieser angeblichen Lücke ist doch Realitätsfremd.
    Ja, da gebe ich dir Recht; das ist nicht auf KeePass beschränkt. Darauf zielte aber auch ein bisschen meine Frage; gibt es Sicherheitsmechanismen, die eine "Lücke" wie diese u. U. unterbinden können? Mir fällt da nur Virtualisierung ein (?).

    Zitat Zitat von DotNet Beitrag anzeigen
    Ganz abgesehen davon verwendet der typische Standardnutzer ohnehin keinen Passwortsafe.
    Klar, die Diskussion ist (leider) natürlich fern von tatsächlichen Umständen.

    Zitat Zitat von DotNet Beitrag anzeigen
    Ich bezweifle daher, dass diese Angriffsmöglichkeit in der Praxis überhaupt auch nur ansatzweise eine Rolle spielt.
    Als flächenweite Methode um Passwörter abzugreifen: ja, würde momentan noch keinen so großen Ertrag bringen. Aber Menschen / Organisationen, die Passwortmanager verwenden, weil sie fürchten, im Fokus von irgendwelchen Individuen / Organisationen / Staaten zu liegen, dürfen sich hier eben keine falschen Hoffnungen machen. Und da wird es eben schon interessant, wie man vorgehen kann, etwa durch Virtualisierung.
    Oder Passwortmanager sind dann doch die falsche Wahl.
    Geändert von Tecc (08.05.2016 um 17:59 Uhr)

  6. #4
    Avatar von DotNet
    Registriert seit
    10.06.2015
    Beiträge
    661
    Thanked 316 Times in 185 Posts

    Standard AW: KeePass - Relevanz des DLL-Injection-Angriffs

    Diese Fälle gibt es natürlich. In einem Atomkraftwerk würde ich beispielsweise erwarten, dass entsprechende Zugänge nach Nutzung sofort wieder gesperrt werden. Leider hat sich gezeigt, dass dies in der Praxis eine ähnliche Utopie zu sein scheint wie bei den Privatpersonen. Man muss sich nur mal vor Augen halten: Das Passwort für US-Atomraketen war fast 20 Jahre lang 00000000. Mir wird ja alleine schon durch die Tatsache mulmig, dass Imperialmächte wie die USA solche Massenvernichtungswaffen besitzen. Dass sie derart schlecht gesichert wurden, lässt alle Alarmglocken angehen. Die gesamte Welt präventiv überwachen, aber Atomraketen sichert man mit einem Passwort, dass jeder Depp erraten kann? Das kann nur US-Logik sein!

    Bei der Virtualisierung sehe ich das Problem, wie auf die Passwörter zugegriffen wird. Kopiert man diese in die Zwischenablage, ist der Sicherheitseffekt wieder zunichte gemacht. Vorstellbar wäre höchstens, die Http-API auf einer Intranet-IP statt localhost laufen zu lassen, damit Erweiterungen wie KeeFox durch die VM darauf zugreifen können. Für den Zugriff braucht man einen Autorisierungsschlüssel, und beim Anfragen von Zugangsdaten ploppt ein Fenster in KeePass auf, in dem der Zugriff bestätigt werden muss. Die VM ist und bleibt dann natürlich der Schwachpunkt, der geschützt werden muss. Also nichts anderes darauf laufen lassen, am besten gar kein Internetzugriff.

    Beim lesen der Beschreibung fiel mir Spontan eine viel einfachere Lösung ein: Wie sieht es mit Linux aus? KeePass läuft dort zwar nicht nativ sondern über Mono. Aber ich vermute mal stark, dass Mono in einer isolierten Umgebung (ähnlich der JVM) läuft. Mit Low-Level-Programmierung kenne ich mich leider nicht aus. Aber es würde mich aus Sicherheitsgründen doch sehr wundern, wenn Mono vollen Zugriff auf den gesamten Speicher hätte. Außer natürlich man startet es mit root-Rechten. Dies sollte man aber natürlich grundsätzlich aus Sicherheitsgründen vermeiden, daher bezieht sich meine Aussage auf einen Standardbenutzer mit normalen Rechten, der den Mono-Prozess startet.

    Im Krieg gibt es keine Gewinner, nur Verlierer!

  7. #5

    Registriert seit
    27.01.2013
    Beiträge
    4
    Thanked 1 Time in 1 Post

    Standard AW: KeePass - Relevanz des DLL-Injection-Angriffs

    Zitat Zitat von DotNet Beitrag anzeigen
    Joa, da ergeben sich die Probleme mit dem Passwortmanager natürlich gar nicht erst...
    Zitat Zitat von DotNet Beitrag anzeigen
    Wie sieht es mit Linux aus?
    Ich kann nicht sagen, inwieweit der Vergleich hier legitim ist, aber 2011 verfasste eine der Qubes OS1-Entwicklerinnen einen Artikel, dessen Kernzitat lautet:
    Zitat Zitat von http://blog.invisiblethings.org/2011/04/23/linux-security-circus-on-gui-isolation.html
    if you have two GUI applications, e.g. an OpenOffice Word Processor, and a stupid Tetris game, both of which granted access to your screen (your X server), then there is no isolation between those two apps. Even if they run as different user accounts! Even if they are somehow sandboxed by SELinux or whatever! None, zero, null, nil!
    Ob die isolierte Umgebung, die Du ansprichst, hier etwas ändert, kann ich nicht beurteilen.
    Aber Qubes scheint zumindest eines der wenigen Betriebssysteme zu sein, die sich dem annehmen. Subgraph OS gibt es noch, die sind allerdings noch nicht so weit (Alpha ist gerade erschienen). Problem ist bei Qubes momentan leider noch ein etwas spezielleres Set an Anforderungen an die Hardware (benötigt Intel VT-x und Intel VT-d oder die AMD-Äquivalente). Demnächst wird wohl noch die Integration von Whonix2 verbessert, so dass eine ganz akzeptable Kombi aus Sicherheit und Anonymität entsteht.
    Aber bis so etwas in der Industrie Verbreitung findet...

    [1]: Qubes OS ist ein Betriebsystem, das den Ansatz der kompletten Isolierung verfolgt. Auf dem PC läuft ein Xen-Hypervisor, der einzelne Programm-Umgebungen voneinander trennt.
    [2]: Whonix lässt seinen Traffic komplett über Tor laufen und versucht eine Identifizierung des Nutzers mit allen möglichen Mitteln zu verhindern.

Ähnliche Themen

  1. Movie-Vision.de SQL-Injection
    Von Snees im Forum Internet und Technik
    Antworten: 0
    Letzter Beitrag: 30.06.2013, 17:37
  2. [TuT] Simple SQL-Injection am Beispiel von PHP
    Von DMW007 im Forum Tutorials
    Antworten: 6
    Letzter Beitrag: 25.07.2012, 20:30

Stichworte

Diese Seite nutzt Cookies, um das Nutzererlebnis zu verbessern. Klicken Sie hier, um das Cookie-Tracking zu deaktivieren.