[English]Noch ein kleiner Infosplitter zum Sonntag. Microsofts Entwickler legen die Kennwörter für den Zugriff auf IMAP-Konten für Outlook in der Registrierung ab. Ist zwar DAPI-encrypted, lässt sich aber im System mit einem API-Aufruf entschlüsseln. Dieser Ansatz wird auch von Tools genutzt, um das Kennwort zu ermitteln.
Anzeige
Wer denkt, dass in Outlook abgelegte Kennwörter für den Zugriff auf IMAP-Konten sicher sind, sollte das nochmals überdenken. Mir ist die Information bereits vor einiger Zeit in diesem Tweet unter die Augen gekommen und ich bin beim Durchgehen meiner Linkliste wieder darauf gestoßen.
Die Aussage: IMAP-Kennwörter liegen bei Outlook in der Registry in DPAPI-verschlüsselter Form vor. Der Schlüssel ist beispielsweise:
HKCU\Software\Microsoft\Office\16.0\Outlook\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
Im Tweet schreibt mgeeky, dass ein simpler CryptUnprotectData()-API-Aufruf diesen Wert aus der Registrierung entschlüsseln kann.
Anzeige
In einem Antwort-Tweet schreibt FU Weissinger, dass der Teams Full-Client-Cache auch unverschlüsselt im Browser-Cache speichert. Das Gleiche gibt für den Teams Web-Client, der Chats unverschlüsselt im Browser-Cache speichert. Die erlauben kein Teams mehr auf unverwalteten Clients – und ich hatte kürzlich auf das Problem im Beitrag Microsoft Teams speichert Authentifizierungstoken als Klartext in Windows, Linux, Macs hingewiesen.
Zusatzinformationen zu DPAPI
Das Kürzel DPAPI steht für Data Protection API, eine einfache kryptografische Anwendungsprogrammierschnittstelle, die als integrierte Komponente in Windows 2000 und späteren Versionen von Microsoft Windows-Betriebssystemen verfügbar ist. Theoretisch kann die Datenschutz-API jede Art von Daten symmetrisch verschlüsseln; in der Praxis wird sie im Windows-Betriebssystem in erster Linie für die symmetrische Verschlüsselung asymmetrischer privater Schlüssel verwendet.
DPAPI speichert selbst keine dauerhaften Daten; stattdessen empfängt es lediglich Klartext und gibt Chiffretext zurück (oder umgekehrt). Die Sicherheit von DPAPI hängt von der Fähigkeit des Windows-Betriebssystems ab, den Hauptschlüssel und die privaten RSA-Schlüssel vor Kompromittierung zu schützen. Dies hängt in den meisten Angriffsszenarien in hohem Maße von der Sicherheit der Anmeldeinformationen des Endbenutzers ab. Der Hauptschlüssel für die Ver- und Entschlüsselung wird mit Hilfe der PBKDF2-Funktion aus dem Passwort des Benutzers abgeleitet.
Von Microsoft gibt es diesen Beitrag zur DPAPI und dieser Beitrag geht ausführlicher auf DPAPI ein. Auch der Beitrag hier aus dem Threat Hunter Playbook diskutiert die Details. Dieser deutschsprachige Beitrag aus der Schweiz fragt denn auch, wie sicher die Passwörter seien. Wird einen normalen Nutzer nicht interessieren, aber Tools wie der DataProtectionDecryptor von Nirsoft nutzen die DPAPI, um Kennwörter zu entschlüsseln.
DataProtectionDecryptor, Quelle: Nirsoft
Anzeige
Danke – gut zu wissen!
Heutzutage kann man nur jedem Raten für jeden Dienst eigene sichere Kennwörter zu verwenden – und via Passwortmanager zu verwalten (z.B. KeePass).
Gleichzeitig wünscht Microsoft den Einsatz von TPM2.0, VirtualBasedSecurtiy und dutzende weitere Schichten wie Defender, Thirdparty Antivirus, ModernApps-Einschränkungen um seine Anwender zu schützen. Finde da wer den Fehler.
Ich würde neben Keepass auch die kompletten Festplatten verschlüsseln. Das hilft zwar nicht zur Laufzeit, aber schon wenn Platten oder ein Laptop abhanden kommen. Es gibt diverse Programme welche Passwörter auf die Festplatte speichern und ohne Masterpasswort sehr unsicher sind, wie z.B. Webbrowser. Viele Anwender speichern Passwörter im Webbrowser, weil dieser das immer so schön aktiv anbietet. Diese können dann einfach ausgelesen werden.
Gruß Singlethreaded
und ein shice Trojaner reicht aus um dir all deine PW zu stehlen, dann nützt es auch nix das du für jeden Dienst ein eigenes 64/128/xxx Zeichen langes PW hast.
PW gehören niemals auf dem zu schützenden Gerät selbst gespeichert!
Komfort geht halt immer zu Lasten der Sicherheit!
Ich hab nen sicheres PW + Dienstanhang + Dienstanhang per Algo kodiert, so muss ich mir genau ein PW merken und hab damit doch für jeden Dienst ein eigenes sicheres PW.
Gespeichert wird da auf keinem Gerät, somit auch nicht auslesbar, nen Trojaner kann mir auch nur im Moment der Eingabe ein PW klauen, bis ich es merke. Muss halt die PW eingeben was nicht so bequem ist dafür sicher!
Da ich mittlerweilen ein Alter erreicht habe , bei der Alzheimer und Co nicht mehr unwahrscheinlich sind, ist das PW auch nochmals auf nem Zettel im Safe hinterlegt.
> Finde da wer den Fehler.
Hier:
> Thirdparty Antivirus.
Ich denke inzwischen das es durchaus sinnig ist das Thirdparty-AV nachwievor exisiteren. Diese decken oftmals Schwachstellen auf.
Zudem fehlen Windows-Defender meines Wissens Mailserver checks.
Auch mag MS Defender ansich ein sinnvolles Tool sein: die UI ist für Unmanaged Umgebungen ist definitiv deutlich zu spatanisch.
Wenn ich richtig bedenke gibts kein Fehler … das Kennwort muss letztlich fürs System auslesbar gespeichert werden, wenn ich als Anwender "speichern" wähle.
Das Zielverzeichnis wo die Daten gespeichert liegen, ist per Default via NTFS-Berechtigungen geschützt. Die Registry-Zweige HKCU sind ebenfalls auf den User eingeschränkt.
Der Vorschlag mit Veracrypt die Daten zu sichern hilft nur bedingt.
1. wenn das Archiv eingemounted ist, ist auch alles lesbar.
2. Bevor ich ein sicheres VeraCrypt-Kennwort eingebe, kann ich auch gleich die Mailserver-Kennung manuell eingeben.
Habe ich Schadsoftware auf dem System kann sie letztlich jede Sicherheitshürde umgehen. Somit kann man das Kennwort dann auch so speichern.
Sicher, dass es HKLM ist?
Wenigstens Outlook 2016 speichert das unter HKCU (danach gleicher Pfad), unter HKLM gibt es den Unterschlüssel "Profiles" gar nicht.
Outlook 2016 auf Win10 PRO:
Edit: …wenn ich kurz drüber nachdenke _muss_ das PW (wenn in der Registry dann) in HKCU stehen, sonst weiss die Maschine ja gar nicht, zu welchem Benutzerprofil es gehört…
Edit2: Im Screenshot des Tweets ist es HKCU
Ach ja: "…\00000005\IMAP Password" gilt nur für das erste Konto in Outlook.
Das 2. Konto ist unter …\00000009\…, danach zählt es immer 1 hoch.
Du hast Recht, es wird hkcu sein
Hi…
Bei mir ist unter dem Schlüssel, natürlich adaptiert auf meine Outlook-Version (14 auf W7), weder bei HKLM noch HKCU ein Profiles-Ordner zu finden – und nun, hab' ich dsbzgl. der thematisierten Lücke nichts zu befürchten?
>> Edit: …wenn ich kurz drüber nachdenke _muss_ das PW (wenn in der Registry dann)
"Muss" leider nicht:
Microsoft selbst legt unter u.g. Pfad je UserID einen Unterschlüssel an:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection\Users\
Befüllt via "gpedit.msc"
> Benutzerkonfiguration > Administrative Vorlagen > Windows-Komponenten > Datensammlung und Vorabversionen > Telemetrie zulassen
die Alternative wäre nur, den Client mit einem extra einzugeben Passwort zu schützen / die DB Datei.
das Passwort muss ja für den Client lesbar sein, da es remote eingegeben wird.
ist bei der Konkurrenz ebenso nicht anders.
bei Thunderbird nehme ich die logins.json und key3 bzw. key4.db
und kann mir damit ebenso alle Benutzer und Passwort im Klartext anzeigen lassen.
sowohl der Regkey als auch die Dateien bei Thunderbird liegen im Benutzerprofil und sind damit nur für den jeweiligen Benutzer U. für einen Admin (dann aber mit Eintrag im Log) zugreifbar.
natürlich ebenfalls für andere Programme im Benutzerkontext aber wie oben geschrieben ist das "Standart".
Nun kann man in Outlook und Thunderbird auch ein Masterpasswort vergeben. interessant wäre nun ob bei einem oder beiden clients dann auch das Passwort damit geschützt wird.
Ich mache das so: Das komplette Thunderbird-Profil liegt in einem VeraCrypt-Container. Ich starte Thunderbird mit einem kleinen Shell-Skript, das erst das VeraCrypt-Passwort abfragt, den Container öffnet und dann Thunderbird startet.
So hoffe ich (relativ) sicher zu sein.
Ich nehme an, dass Veracrypt den verschlüsselten Container dann als Laufwerk einbindet und Thunderbird von diesem sein Profil liest. Sobald der Container aber eingebunden ist, könnten auch andere Anwendungen auf dessen Inhalte zugreifen. Auch ist die Frage ob der Container ausgeworfen wird, wenn man Thunderbird wieder schließt?
Das Ganze erhöht die Sicherheit, solange Thunderbird nicht genutzt wird bzw. falls der Rechner gestohlen wird. In diesen Fällen sind die Profildaten erstmal nicht zugänglich.
Trotzdem bleibt das Kernproblem, dass die sichere Nutzung eines kompromittierten Systems nicht möglich ist. Hat jemand Drittes Zugriff, so wird dieser über kurz oder lang immer Zugangsdaten abgreifen können.
Gruß Singlethreaded
Man könnte "best practices" aus dem Linux-Bereich anwenden: Anwendungen laufen unter einem dedizierten User.
'Paranoide' können also den Container mit NTFS formatieren und nur dem dedizierten Benutzer "TB" Rechte darauf einräumen, unter dem TB gestartet wird.
Einen Schritt kleiner wäre es, in der lokalen Ordnerstruktur zu speichern, aber nur "TB" (und dem BackupOperator) Rechte auf die Verzeichnisse zu gewähren.
Geht übrigens auch für Outlook, wenn man die Rechte der entsprechenden Schlüssel richtig setzt.
Bei Verwendung von NTFS müsste dann aber auch per NTFS verschlüsselt werden. Baut jemand den Speicher (HDD, SSD) aus einem Notebook aus und hängt diesen in ein anderes Windows-System auf welchem er Administratoren-Rechte hat, so kann er den Besitz der Dateien übernehmen und sich dann wieder selbst den Vollzugriff einräumen.
Das macht es aber wieder komplizierter, weil man sich über ein Backup der Schlüssel Gedanken machen muss.
Auch muss der User für Thunderbird ja per Passwort authorisiert werden. Ist schon ein Lauscher auf dem System kann er das Passwort ggf. mitlesen "Keylogger", oder noch schlimmer aus dem Skript auslesen, wenn es dort jemand hart eingetragen hat (big fail).
Solche kleinen "Tricks" erschweren sicherlich den Zugang und können gerade bei automatischen Massenattacken helfen, werden aber einen gezielten Zugriffsversuch nicht wirklich abwehren können.
Liest sich ein wenig wie "es hilft nicht viel" und das ist mMn falsch.
Ich halte es mit dem Pareto-Prinzip: Mit wenig Aufwand erreicht man viel Wirkung – viele Angriffe über gemeine (Mit-)Benutzerkonten werden so abgewehrt.
Physische Angriffe sind ja noch einmal ein ganz anderes Bedrohungsszenario, dagegen braucht man eben FDE oder die VC-Container von denen mein Namensvetter schrieb.
Wer wirklich paranoid ist (oder wirklich vulnerabel) muss halt TB/Outlook/XYZ in einer dedizierten VM laufen und holt sich nur das Fenster auf den Bildschirm der Arbeisstation.
Wieviel es hilft hängt von der konkreten Situation ab. Mir ging es mit meinem Kommentar um eine meiner Meinung nach möglichst realistischen Einschätzung der Schutzwirkung.
Auf keinen Fall sollte der Kommentar von der Maßnahme an sich abraten. Ergänzend würde ich zum Beispiel empfehlen starkes Augenmerk auf das Patchen des Betriebssystems und der Anwendungen zu legen.
Durch eine verringerte Angriffsfläche sinkt die Gefahr erheblich, dass sich Dritte unbefugt Zugriff verschaffen können.
"Ich nehme an, dass Veracrypt den verschlüsselten Container dann als Laufwerk einbindet und Thunderbird von diesem sein Profil liest."
Genau so, ja.
"Sobald der Container aber eingebunden ist, könnten auch andere Anwendungen auf dessen Inhalte zugreifen."
Logisch. Geht ja auch nicht anders; Thunderbird braucht die Passwörter nun einmal im Klartext, um sich bei den Mail-Providern anzumelden.
"Auch ist die Frage ob der Container ausgeworfen wird, wenn man Thunderbird wieder schließt?"
Ja. Bzw. genauer, wenn man VeraCrypt im Anschluss an Thunderbird schliesst.
"Das Ganze erhöht die Sicherheit, solange Thunderbird nicht genutzt wird bzw. falls der Rechner gestohlen wird. In diesen Fällen sind die Profildaten erstmal nicht zugänglich."
Das ist genau der Sinn der Sache.
"Trotzdem bleibt das Kernproblem, dass die sichere Nutzung eines kompromittierten Systems nicht möglich ist."
Natürlich. Ist ja klar. Nach meinem Verständnis ist ein kompromittiertes System nie sicher zu verwenden.
Das Masterpasswort von Outlook ist ein Witz! Mit PstPassword von Nirsoft knackt meine Oma das in 3 Sekunden!!!
Zumindest war das bis Version 2013 so. Aber weil es niemanden interessiert hat (oder niemanden interessieren durfte?) ist es sicher immer noch so.
Nein, für Serverpassworte müssen Sie sein "Mail PassView" (mailpv.exe) benutzen, "PstPassword" ist nur für die *.pst selbst.
Powershell bietet relativ einfach an, Passwörter als "Secure-String" zu ver- und entschlüsseln.
Der binary IMAP-Passwort Eintrag in meiner Registry ist aber zu komplex für mich.
Möchte jemand Codes zum Entschlüsseln teilen?
Und was ist mit Fido2?
Fido2 braucht keinen Klartext zum Anmelden.
Warum wird das so weit boykottiert?
Heise versucht es zu verkaufen, benutzt es aber selbst nicht.
Weil Google und Facebook dann keine Zentrale Anmeldung mehr machen müssen?
weil FIDO2 nur wirklich toll ist wenn du zusätzliche Hardware in Form von USB Keys etc. verwendest. Das will aber keiner weil extra Hardware oder einfach nur zu dumm und bringt wieder andere Probleme mit sich.
/edit/ wenn du das nämlich wirklich sicher nutzt, ist dein gesichertes Konto weg, wenn der Key kaputt geht. Und so Wiederherstellungstoken haben wieder das Problem, das Malware diese abgreifen kann…
Jedes System hat eben Schwachstellen, man muss für sich selbst entscheiden welche Daten welche Sicherheit benötigen und welche Nachteile man dafür in Kauf nimmt.
Ich halte das so das ich meine PW nicht speichere (siehe mein Kommentar oben) somit kann da nen Trojaner maximal ein PW bei Eingabe abgreifen … sicher und noch komfortabel genug.
leider kann ich nicht für mich entschieden, da fido2 kaum angeboten wird.
immerhin erlaubt das übliche Password Verfahren daß ein Dritter unbemerkt zugreifen kann.
das geht bei Fido2 nicht.
es muß ein Key verwendet werden.
Absolute Sicherheit gibt es nicht.
das als Argument gegen ein Verfahren anzuführen ist Polemik.
Und das es ein Dreieck zwischen Komfort Sicherheit und Preis gibt ist auch nicjts neues
Nein das ist keine Polemik, das zeigt nur das jedes Verfahren eben seine Vor- und Nachteile hat und man deshalb eben abwägen muss welches verfahren man wo einsetzt.
Sicherheit gilt so viel wie nötig nicht so viel wie maximal möglich!
fido2 ist ebend nicht nur extra Hardware.
es ist ein anderes Protokoll, das keine Speicherung von Passwörter erfordert.
das nennst Du dumm?
informiere Dich Mal genauer darüber.
das ist kein woodoo mit verschlüsselten Festplatten und welcher Bastlerkram hier zu lesen war.
wo bitte habe ich behauptet das FIDO dumm ist?
Lesen verstehen ist nicht so deins, oder?
Die Aussage es wird nicht benutzt, weil man extra Hardware braucht oder der User schlichtweg zu dumm dafür ist!
Und auch FIDO hat seine Nachteile…
Ja, schon gut. Muss ja nicht gleich beleidigend werden. weil Du missverstanden wurdest :)
Bez. Imap und pop3 erinnere ich mich gerade an eine Statistik eines VPN Betreibers.
Er stellte sehr viele Verbindungen auf den genannten Protokollen fest.
Auffällig war, das die Passwörter meist falsch waren…
:)
Ist die Aufregung hier evtl. "etwas" übertrieben? :)
Mei, wenn wer Drittes an die Registry kommt besteht doch wohl ein ganz anderes Problem, oder?
Also es ist schon mal wieder immer das ewig gleiche Problem.
Dass Passwörter in der Registry liegen ist mE generell nichts Neues. Es liegen mE alle Passwörter da, sofern das Programm auf PC ist.
Wer hier was von "Keemanager" oder auch "Keymanager" genannt schreibt, muss auch wissen was er meint. Jedenfalls sollte dieser nicht in den Browsern liegen. Es bieten ja alle an.
Es gibt ein Ausleseprogramm dieser Paßwörter von Nirsoft, siehe auch im Artikel von Günter. Zu den Programme von Nirsoft hat Günter mE sogar mehrere Artikel geschrieben. Das (dieses) Programm von Nirsoft erkennen aber meine AV-Programme wie MS Defender oder Malwarebytes sofort. Ich brauchte mal wieder die Passwörter und das Programm liegt separat auf einem USB-Stick und wenn ich die Passwörter von den PCs mal wieder auslesen muss, so wird a) das Internet getrennt und b) die AV-Scanner abgeschaltet. Das Ganze dauert eben diese oben beschriebenen 3 Sekunden der Oma. Dann muss aber Oma wieder die AV-Scanner anschalten, Hinweis an oben.
Das Programm heißt aber mE "Mail Passview" und das letzte Mal hatte ich es vor einem Jahr mir wieder geholt, (weil eben MS-Defender das gelöscht hat). Auf der Internetseite vin Nirsoft und in der readme.txt-Datei des Programms wird auch darauf hingewiesen.
Ich habe hier das Problem noch nicht erkannt. Das ist alles weder für Vergessliche wie mich, krimimelle Hacker oder (kriminelle ) Spionalgedienste (sind immer kriminell) nichts Neues. Es liest aber nicht alles aus. Das ist Schade und da muss man doch mal bisschen im klassischen Leitz-Ordner und/oder auf einen ganz "geheimen" (und vergessenen) Ordner auf dem PC suchen. Hier hilft ggf E-Mail-Ordner aus IMAP herausgenommen.