Passwortmanager KeePass 2 potentiell angreifbar

[Snoopy69]

Passwortmanager KeePass 2 potentiell angreifbar (http://www.computerbase.de/2016-06/sicherheit-keepass-2-potentiell-angreifbar/)

Ich prüfe das sowieso nochmal mit SHA256, aber trotzdem gut zu wissen.

[Trap]

Ich prüfe das sowieso nochmal mit SHA256, aber trotzdem gut zu wissen.
Und die SHA256 lädst du über https?

[Rente]

Es geht dabei "nur" um die Update-Routine, deaktivieren und (vermutlich) gut.

[Kontrollfreak]

Eigentlich ist der Updater ja nur ein Update-Check, der den Benutzer auffordert, die KeePass-Website manuell anzusteuern und darüber das Update herunterzuladen.

Dass die Website kein ordentliches Zertifikat für HTTPS hat, ist irgendwie... unglücklich. Aber immerhin ist der Installer kryptografisch signiert und kann auch mit OpenPGP (http://keepass.info/integrity_sig.html) (keybase.io (https://keybase.io/reichl)) verifiziert werden.

Das ändert natürlich alles nichts daran, dass die Benutzer, die das nicht prüfen, reihenweise in die Falle tappen werden, falls mal irgendwo irgendwer irgendwie einen MITM-Angriff auf KeePass durchführt.

Ach und andere (http://www.heise.de/security/meldung/Crapware-Viele-Updater-von-PC-Herstellern-haben-eklatante-Sicherheitsluecken-3226857.html) sind noch viel schlimmer. Die führen sogar Programmcode aus, der über eine ungesicherte Verbindung lief ;D

[Snoopy69]

@ Trap

Ich hole mir beides über https...


@ Kontrollfreak

Demnach sollte man besser alle Auto-Updater deaktivieren.


Weiss zufällig jemand, wie Kaspersky sich seine Virendefinitionen holt?

[lumines]

Demnach sollte man besser alle Auto-Updater deaktivieren.

Nö, die Autoupdater sollten einfach entweder per https laufen oder die Updates kryptografisch signieren. Im besten Fall natürlich Letzteres, dann könnte man sich auch https sparen, wenn man das aus irgendwelchen Gründen will.

[Leonidas]

Ein Programm, welches für seine Hauptfunktion kein Internet benötigt - und hat Internet-Zugriff? Geht bei mir nicht, rammt gegen die Firewall. Ohne Zutun, ohne Einschränkungen, ohne manuelle Eingriffe. Problem gelöst.

[Argo Zero]

Grundaätzlich würde ich Keepass auch nicht updaten wollen. Es funktioniert alles und bei einem Update hätte ich ehrlich gesagt Bammel, dass er mir was zerschießt. Bei so etwas bin ich ganz bei dem "don't touch a running system".

[lumines]

Es funktioniert alles und bei einem Update hätte ich ehrlich gesagt Bammel, dass er mir was zerschießt.

Dafür machst du doch Backups, damit man davor keine Angst haben muss.

[Argo Zero]

Nein, dafür mache ich keine Backups.
Backups mache ich, damit ich meine Daten wieder habe im Falle eines Hardwareausfalls.

[sloth9]

Gefixt:
"The version information file (which the optional update check downloads to see if there exists a newer version) is now digitally signed (using RSA-4096 / SHA-512); furthermore, it is downloaded over HTTPS."

[Snoopy69]

@ Argo Zero

Ganz schön leichtsinnig...
Schließlich könnte deine Datenbank Opfer von "Alzheimer" deiner Laufwerke oder fälschlicher Datenübertragung deiner Consumer-HW werden. Passiert ja immer mal. Nur merken tun es die Wenigsten.

[Kontrollfreak]

Gefixt:
"The version information file is now digitally signed; furthermore, it is downloaded over HTTPS."

Doppelt hält anscheinend besser :wink: Wenn er keepass.info jetzt noch komplett verschlüsselt (am besten mit aktiviertem HPKP, HSTS und DANE) und die Binary darüber verteilt anstatt einen Drittanbieter wie Sourceforge, gäbe es nichts mehr zu meckern.

[lumines]

TLS mit HPKP und HSTS ersetzt DNSSEC / DANE vollständig. Vor allem macht man sich mit DNSSEC je nach TLD durch staatliche Angriffe verwundbar.

DNSSEC wird übrigens noch immer überwiegend mit 1024 Bit RSA-Keys benutzt. Sogar die Root-Zone ist noch nicht davon weg.

Ich möchte auch nur einen normalen Nutzer sehen, der ernsthaft DNSSEC validiert. Es ist usabilitytechnisch das pure Grauen. Ist vielleicht besser so, dass sich das nicht durchsetzt.

[Kontrollfreak]

TLS mit HPKP und HSTS ersetzt DNSSEC / DANE vollständig.

Stimmt im Prinzip. Allerdings hat man mit DANE/TLSA noch eine Art zusätzliche DNS-basierte CA, die ebenfalls geknackt werden müsste.


Vor allem macht man sich mit DNSSEC je nach TLD durch staatliche Angriffe verwundbar.

Nur, wenn das die einzige Methode ist, mit der der Client die Verbindung prüft.

[lumines]

Allerdings hat man mit DANE/TLSA noch eine Art zusätzliche DNS-basierte CA, die ebenfalls geknackt werden müsste.

Wenn man DNSSEC validieren würde (Hand aufs Herz – machst du es?), wenn sie nicht schwache Keys benutzen würden und wenn man eine unabhängige Zeitquelle hätte, was hier sicher nicht einmal jemand im Forum hat, obwohl hier viele Leute ziemlich technikaffin sind.

Dagegen steht TLS, das einfach funktioniert.

Nur, wenn das die einzige Methode ist, mit der der Client die Verbindung prüft.

Warum sollte ich dann überhaupt DNSSEC benutzen?

[Kontrollfreak]

Wenn man DNSSEC validieren würde (Hand aufs Herz – machst du es?)

Ja, seit heute :freak: https://addons.mozilla.org/de/firefox/addon/dnssec-validator/ (perfekt ist das nicht...)


[...] wenn sie nicht schwache Keys benutzen würden und wenn man eine unabhängige Zeitquelle hätte, was hier sicher nicht einmal jemand im Forum hat, obwohl hier viele Leute ziemlich technikaffin sind.

Frage: Meintest du unabhängige Zeitquelle oder Zweitquelle?
Falls Letzteres, dann wäre die Zweitquelle ja die normale CA, die das Zertifikat ausgestellt hat. Oder eben der Webserver selbst, falls HPKP zum Einsatz kommt.


Warum sollte ich dann überhaupt DNSSEC benutzen?

Um der CA ihre Macht zu nehmen. HPKP bringt ja nur was, wenn der Client deine Seite schon einmal besucht hat und damit die gültigen Fingerprints kennt.
Das Problem: Beim ersten Mal kann ein Client ohne DANE nur darauf vertrauen, dass die CA keinen Murks gemacht hat. Mit DANE hat er eine zweite Quelle um den öffentlichen Schlüssel gegenzuprüfen. Wenn einer von beiden (CA und TLSA) nicht übereinsteimmt, weiß er, dass irgendwas faul (oder kaputt) ist.

[lumines]

Ja, seit heute :freak: https://addons.mozilla.org/de/firefox/addon/dnssec-validator/ (perfekt ist das nicht...)

Damit validierst du nur für den Browser. Die Browserhersteller haben übrigens schon angekündigt, dass sie DNSSEC nicht unterstützen werden. Du bräuchtest schon einen DNS-Resolver, der DNSSEC validiert. Z.B. Unbound, BIND oder den Knot DNS Resolver.

Erklär einmal jemandem, wie man so etwas aufsetzt und welche Gefahren bei Fehlkonfiguration sich dadurch ergeben können wie DNS-Amplification-Angriffe.

Frage: Meintest du unabhängige Zeitquelle oder Zweitquelle?

Ich meine schon Zeitquelle. Die DNSSEC-Validierung schlägt fehl, sobald die Zeit zu weit abweicht. Besonders doof natürlich, wenn man als Zeitquelle eine Domain (oder in der gesamten Hierarchie auch nur eine TLD wie z.B. org) anfragt (für z.B. NTP), die selbst mit DNSSEC signiert ist. Die Validierung wird somit fehlschlagen und man wird auch nicht die Zeit synchronisieren können, um wieder validieren zu können. Man hat dadurch ein Henne-Ei-Problem. Solange wie man das nicht von Hand auflöst, hat man dann erst einmal kein DNS mehr.

Man braucht also entweder eine unabhängige Zeitquelle wie z.B. einen GPS-Empfänger oder mindestens Geräte, die eine Real-Time-Clock haben und keine hohen Abweichungen aufweisen. Eine kaputte Batterie würde aber schon erst einmal kein DNSSEC mehr zulassen.

Vielleicht wird jetzt klarer, warum das eine extrem fragile Sache ist. Da es für DNS auch keine direkte Schnittstelle für die Anwendungsschicht gibt, sieht ein DNSSEC-Fehler auch erst einmal wie ein genereller DNS-Fehler aus. Es gibt keine DNSSEC-spezifischen Fehlermeldungen. Der Stubresolver sieht nur, dass irgendetwas nicht funktioniert.

Um der CA ihre Macht zu nehmen. HPKP bringt ja nur was, wenn der Client deine Seite schon einmal besucht hat und damit die gültigen Fingerprints kennt.

Nö, die meisten Browser haben schon eine Liste parat. Hält natürlich auch niemanden davon ab, HPKP auch für native Anwendungen zu benutzen und Zertifikate selbst zu pinnen.

[Kontrollfreak]

Man hat dadurch ein Henne-Ei-Problem. Solange wie man das nicht von Hand auflöst, hat man dann erst einmal kein DNS mehr.


Wenn ein Man-in-the-Middle DNS verhindern will, braucht er aber nur den Stecker ziehen ;) Das ist kein Argument gegen Verschlüsselung.



Man braucht also entweder eine unabhängige Zeitquelle wie z.B. einen GPS-Empfänger oder mindestens Geräte, die eine Real-Time-Clock haben und keine hohen Abweichungen aufweisen. Eine kaputte Batterie würde aber schon erst einmal kein DNSSEC mehr zulassen.


Ja okay, DNSSEC ist fragil und bietet mehr Angriffsfläche für DoS. Hilfreich ist es trotzdem.



Nö, die meisten Browser haben schon eine Liste parat.

Bist du dir sicher, dass die Listen Fingerprints enthalten? Soweit mir bekannt ist, sind die nur für HSTS zuständig (preload flag), besagen also nur, ob eine Domain immer HTTPS wünscht oder nicht.

[lumines]

Wenn ein Man-in-the-Middle DNS verhindern will, braucht er aber nur den Stecker ziehen ;) Das ist kein Argument gegen Verschlüsselung.

Was hat das mit einem MitM zu tun? Wenn deine Zeit, aus welchen Gründen auch immer, falsch geht, dann hast du einfach kein DNS mehr. Wenn alle Domains mit DNSSEC ausgestattet wären, dann wärst du effektiv vom Internet abgeschnitten und müsstet die Zeit erst manuell einstellen. Viel Spaß, das normalen Nutzern zu erklären.

Das hört sich vielleicht nach einem exotischen Problem an, aber viele Kleinstgeräte haben eben keine RTC oder einen GPS-Empfänger. Dein Router wird z.B. niemals zuverlässig DNSSEC validieren können. Ich kenne jedenfalls keinen Router mit einer RTC. Nach einem Neustart hast du erst einmal kein DNS, wenn du Pech hast. Dein OS auf dem Host wird wiederum niemals aussagekräftige Fehlermeldungen bekommen, wenn irgendwelche Fehler durch DNSSEC entstehen.

Ich habe es auf meinem Router, auf diversen Hosts und diverse Resolver ausprobiert. Nichts davon ist für normale Nutzer praktikabel. Kann man anders sehen, aber die momentanen Probleme wird man nicht mal eben aus der Welt schaffen können. Am Ende bleibt ein sehr komplexes, veraltetes System, das einen Haufen Nachteile bringt.

Es ist auch kein Argument gegen Verschlüsselung, sondern gegen Sicherheitsprotokolle in so niedrigen Schichten. Warum sollte ich die Verfügbarkeit des DNS schmälern, wenn ich alles auch mit TLS erreichen kann?

Ja okay, DNSSEC ist fragil und bietet mehr Angriffsfläche für DoS. Hilfreich ist es trotzdem.

Aber bei was? Es bietet nur Integrität und Authentizität. TLS bietet auch Vertraulichkeit. Mit HPKP und HSTS habe ich alles, was DNSSEC liefert, aber genau so unabhängig und besser integriert. DNSSEC dagegen packt einen Haufen Komplexität in ein uraltes Protokoll und macht es noch fragiler, als es jetzt schon ist. Ist das wirklich etwas, womit man sich in Zukunft rumschlagen will, obwohl der Nutzen gegen Null tendiert?

Bist du dir sicher, dass die Listen Fingerprints enthalten? Soweit mir bekannt ist, sind die nur für HSTS zuständig (preload flag), besagen also nur, ob eine Domain immer HTTPS wünscht oder nicht.

https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json

Ja, seit heute :freak: https://addons.mozilla.org/de/firefox/addon/dnssec-validator/ (perfekt ist das nicht...)

Übrigens: Viel Spaß, wenn der Resolver, den du anfragst, kein EDNS kann. Dann wird dein DNS nämlich auch nicht funktionieren, weil das zwingend für DNSSEC erforderlich ist. :^)

Probier lieber DNSSEC-Trigger (ein modifiziertes Unbound) aus, denn der macht einen Fallback auf die Root-Hints, wenn es nicht richtig funktioniert: https://www.nlnetlabs.nl/projects/dnssec-trigger/

Es hat sogar ein UI, aber man muss natürlich viel manuell umstellen, wenn irgendetwas fehlschlägt. Stell dir einmal vor, du müsstest das jedes Mal bei DNS-Problemen auf deinem Smartphone manuell auflösen.

[Kontrollfreak]

Interessantes Thema! Hat eigentlich einen eigenen Thread verdient :)

Wenn alle Domains mit DNSSEC ausgestattet wären, dann wärst du effektiv vom Internet abgeschnitten und müsstet die Zeit erst manuell einstellen.

DNSSEC ist optional. Alte Geräte werden auch weiterhin unverschlüsselt DNS abfragen dürfen.


Warum sollte ich die Verfügbarkeit des DNS schmälern, wenn ich alles auch mit TLS erreichen kann?

Es gibt ja nicht nur HTTPS. Einige Mailanbieter implementieren ebenfalls DANE/TLSA. Für Mail-Verschlüsselung lassen sich beispielsweise Signaturen verifizieren. Dabei gilt der gleiche Grundsatz wie bei HTTPS: Zwei Quellen sind besser als eine. Man kann einfach tolle Sachen machen, wenn DNS vertrauenswürdiger wird.


https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json


Danke, sieht vielversprechend aus. Ich erkenne daraus nur auf die Schnelle nicht, ob das auch für den öffentlichen Schlüssel meiner Hinterhof-Domain gilt...

Edit: Ok, verstanden, Domain muss hier angemeldet werden: https://hstspreload.appspot.com/
Gut, das ist eine Lösung für HTTPS. Ich gebe mich also geschlagen auf dem Feld HPKP/HSTS. Das heißt aber nicht, dass ich DNSSEC generell für überflüssig halte.


Übrigens: Viel Spaß, wenn der Resolver, den du anfragst, kein EDNS kann. Dann wird dein DNS nämlich auch nicht funktionieren, weil das zwingend für DNSSEC erforderlich ist. :^)


Das AddOn hat einen Resolver-freien Modus (nutzt ebenfalls Unbound). Der scheint mir direkt mit den Namensservern der jeweiligen Domains zu kommunizieren. Ein zentraler DNS-Cache, der keine Probleme bereitet, ist natürlich effizienter. Meine Fritzbox kann's nicht. Der Cache meines Providers kann's.