Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsSicherheitslücke: Browser speichern Passwörter im Klartext im Arbeitsspeicher
Ach mit einem Certifikat was im jeden Windows im AD rumliegt und der DPAPI(Womit die Passwörter z.b. im Chrome verschlüsselt werden) von Windows kannst du sogar die Passwörter aus nicht aktiv laufenden Browsern auslesen. https://www.ired.team/offensive-sec...dpapi-encrypted-secrets-with-mimikatz-and-c++
Am besten also einen Bunker suchen und dort verstecken.
xx Sekunden reichen locker aus um einen dump zu machen. Besser ist es die Lesbarkeit auf ein minimum zu reduzieren.
W0dan schrieb:
Seh ich nicht so. Praktisch kann doch dann jede beliebige Anwendung jederzeit ohne erweiterte Rechte mitlesen, welche Passwörter ich im Browser eingebe. Das ist ein riesiges Problem.
Bei mobilen Betriebssystemen wie z.B. iOS ist es hingegen so, dass Apps in einer Art Sandbox laufen und nur über festgelegte APIs eingeschränkten Zugriff auf weitere Bereiche bekommen.
Wenn ich bei iOS in Safari ein Passwort eintippe, dann sollte/kann nach meinem Verständnis keine andere App mitlesen (außer natürlich es gibt eine unentdeckte Sicherheitslücke). Bitte korrigiert mich wenn falsch, aber das ist meines Wissens der grundlegende Ansatz.
Wenn das bei Windows anders ist, oder nicht als Problem angesehen wird, dann ist das ein Failure by Design.
Aber ich ahne schon, dass Windows genau so funktioniert. Es fängt ja alleine schon damit an, dass anscheinend jede Anwendung Zugriff auf alle Dateien auf meinem Laufwerk hat. Sprich sämtliche private Dokumente lesen und ins Internet versenden könnte.
Also jetzt mal ohne Witz, da wird ein AUFRISS sondergleichen wegen Spectre und co gemacht, aber dass man mal Hinterfragt, welche Berechtigungen beliebige Anwendungen auf dem System bekommen, auf die Idee kommt keiner. Lächerlich, einfach nur lächerlich. Kann den ganzen Mist echt mehr ernst nehmen...
Du denkst das eine Mantelsoftware hier die Lösung wäre. Ich denke nicht. Kannst es ja selber mal mit Cheatengine probieren deine Passwortsafe App auszulesen.
Ebbend es ist doch möglich durch einen Salt der bei Application start generiert wird und alle Passwörter die dann aus einer Datenbank geladen werden werden dann zu diesem Salt in den Ram gespeichert[...]
1. Application wird gestartet
2. zufälliger Salt wird generiert
3. DatenBank wird geladen
4. User gibt Password ein
5. Alle in der Datenbank gespeicherten Passwörter werden in ein DatenObject mit dem Salt verschlüsselt und im Ram abgelegt
6. Der Datenbank Pointer wird im Ram komplett gelöscht
7. Wenn der User das Passwort lesen/kopieren/ändern möchte wird eine Methode aufgerufen die mit dem Salt ein neues Stück ram reserviert und mit dem Salt das Password aus dem Ram wieder entschlüsselt.
8. Nach dieser Operation wird der zuvor reservierte speicher wieder gelöscht.
Klingt jetzt ehrlich gesagt dramatischer als es wohl ist? Kenne mich nicht aus, aber wie soll denn ein Passwort verschlüsselt eingegeben werden? Von daher überrascht mich das jetzt nicht, dass es zu irgendeinem Zeitpunkt unverschlüsselt "vorliegt". Ob man das jetzt als "Lücke" bezeichnen muss, wenn man bei z.B. Firefox auch einfach unter about:logins seine gespeicherten Passwörter einsehen kann? Oder übersehe ich dabei irgendwas?
mit einem salt wird nichts verschlüsselt sondern gehasht. und eine hashfunktion ist nunmal nicht umkehrbar, d.h. man kann einen hash nicht "entschlüsseln".
Fragt Dich Windows oder Linux danach, wenn Du einen Debugger startest? Debugger sind "normale" Programme, die werden nirgendwo als "Debugger" registriert. So eine Liste von Rechten die einer App eingeräumt werden, wie etwas bei Anrdoid, gibt es bei Windows/Linux nicht.
Das nicht (bzw. halt nur für die Store Apps unter Windows bzw. Snap/flatpack unter linux) , aber unter Windows (und ich vermute auch Linux) kannst du sehr wohl Programme so installieren, dass sie mit erhöhten Rechten ausgeführt werden ohne, dass der User jedesmal gefragt wird.
@Animal Mother
Dir fehlen Grundlagen, allein was eine Hashfunktion ist, wofür Salts gebraucht werden und wie sichere Verschlüsselung funktioniert. Denn auch wenn man Passwörter nur verschlüsselt im Ram hat und bei Bedarf frei gibt. Solang der passende Key im Speicher liegt, bleibt der Angriffsvektor der Selbe.
Sry, jetzt erst gesehen. Finde ich nicht überheblich, wer zB online banking betreibt oder Bezahldienste online nutzt, dem sollte auch die Sicherheit seiner Daten wichtig sein. Und dazu gehört es, das man sich darüber informiert.
Leider sind die Leute im realen leben auch zu gutgläubig und teilweise hohl, wenns um Datensicherheit geht (ich sag nur pin auf Bankkarte notieren). Hab ich bei meiner Mutter auch gehabt und sie zusammengeschissen. seitdem bewahrt sie pin und Karte wenigstens getrennt auf
Da bin ich generell schon bei Dir, vor allem, was der sorgsame Umgang mit Handhabung von solch sensiblen Informationen im Netz angeht. Dennoch sehe ich hier das Problem dann eher beim Anbieter - in unserem Beispiel Entwickler des Browsers. Wenn die Funktion zum "Merken" meiner Accountdaten eher ein Gimmick ist, die Sicherheit der Daten aber gar nicht gewährleistet werden kann, sollte der "Kunde" (Benutzer) aber auch ebenso transparent darauf hingewiesen werden - was natürlich so nicht "beworben" wird. Und genau ein solcher Gedankengang wird den meisten Normalverbrauchern nicht in den Sinn kommen - sich darüber informieren und Gedanken über die Sicherheit solcher Funktionen machen zu müssen. Allein die Nutzung eines Passwortmanagers direkt im Browser wird sich für die Genannten schon als "sicherer Umgang" anfühlen.
Im selben Atemzug fehlt es natürlich nach wie vor an digitaler Aufklärung, aber auch dem Interesse daran, sich hier weiterbilden zu wollen, da schließe ich mich Dir absolut an (das Spiel "Pin auf Bankkarte" kenne ich auch von meinen Eltern leider zu gut. Gleich nach "Post-It" mit Passwörtern (Accounts/WiFi) überall offen rumliegen zu haben.
Geht dieser Angriff auch an einem gesetzen Master Passwort vorbei bzw. werden die Daten auch mit Master Passwort im Klartext im RAM abgelegt? Wäre natürlich fatal.
Habe es eben via ProcessHacker (ohne Adminrechte) mit Chrome, Edge und Firefox getestet.
In Chrome gibt es ja so etwas wie ein Masterpasswort nicht.
In Edge kann man zumindest einstellen, dass immer nach dem Account PW / PIN gefragt wird.
In beiden Browser sind die Passwörter aber dauerhaft unverschlüsselt zugänglich.
In Firefox sind die Passwörter unverschlüsselt zugänglich, sobald man das Master-PW eingegeben hat.
Davor findet man zumindest nichts, wenn man nach dem String sucht.
Deshalb nutze ich auch schon ewig das gute alte KeePass.
Übrigens lässt sich KeePass zumindest vor Memoryzugriffen mit dem aktuellen User schützen (denn nicht alles ist im RAM verschlüsselt. Bsp: Usernames, Notes, Attachments. Siehe https://keepass.info/help/base/security.html#secmemprot)
Einfach als Admin oder im Kontext eines anderen (speziell dafür angelegten) User starten.
Dadurch benötigt der Memoryzugriff dann Admin-Rechte.
Und schlussendlich "Auto-Type selected entry" (mit Two-channel auto-type obfuscation , wenn die Zielanwendung damit klarkommt) statt Copy'n'Paste und man hat zumindest das Bestmögliche getan.
Bei Auto-Type benötigt es nämlich einen Keylogger (was von Malware-Scannern i.d.R. direkt blockiert wird), bei Copy-Paste kann man einfach ohne Probleme die Zwischenablage abgreifen (entweder im Loop oder einfach via Event).
7. Wenn der User das Passwort lesen/kopieren/ändern möchte wird eine Methode aufgerufen die mit dem Salt ein neues Stück ram reserviert und mit dem Salt das Password aus dem Ram wieder entschlüsselt.
8. Nach dieser Operation wird der zuvor reservierte speicher wieder gelöscht.
Diese Frage solltest Du Dir selbst stellen: Wie glaubst Du werden Kopierschutzmechanismen umgangen? In der Computertechnik ist nichts sicher wenn man direkten Zugriff hat. Die Spieleindustrie kämpft dagegen schon seit Jahrzehnten an, meistens erfolglos.
Jeder Prozess bekommt in Linux seinen eigenen Virtuellen Speicher, d.h. jeder Prozess hat seinen eigenen vollen (virtuellen) Adressraum. Standardmaessig benutzt Linux diskrete Zugriffsverwaltung, basierend auf Benutzern und Gruppen. Jeder Prozess erbt die Berechtigungen des ausfuehrenden Benutzers, d.h. wenn Du deinen Browser startest hat dieser prinzipiell die gleichen Berechtigungen wie Du.
Ueber Systemcalls kann kein Prozess direkt auf den Speicher (RAM) eines anderen Prozesses zugreifen. Das geht nur mit einem Umweg ueber das Filesystem (/proc/<pid>/mem). Auf diese Datei hat nur der ausfuehrende Benutzer Zugriff (und root, natuerlich). Das heisst, wenn ein Rechner von zwei Leuten benutzt wird, kann Benutzer A nichts aus dem Speicherraum von Benutzer B lesen, solange er kein priviligierter Benutzer ist.
AppArmor und SELinux setzen Mandatory Access Control um, das heisst die Zugriffsberechtigungen erfolgen nicht nur anhand des Benutzers, sondern man kann Profile fuer einzelne Programme definieren. Damit kann der Zugriff von Firefox auf die fuer ihn notwendigen Daten eingegrenzt werden. Der Webserver-Prozess kann jetzt beispielsweise nicht mehr auf /proc/<firefoxpid>/mem zugreifen, obwohl er als der gleiche Benutzer laeuft. (Edit: vllt. ein schlechtes Beispiel, weil Webserver eh immer als ihre eignen Benutzer laufen, aber das Prinzip wird klar hoffe ich)
MAC Systeme sind aber ziemlich aufwendig in der config, fuer viele Programme gibt es fertige Profile, aber das manuelle konfigurieren ist ziemlich anstrengend (finde ich). Cool ist, dass Du dein System so sogar gegen 0-Days schuetzen kannst.
Viel leichter ist der Einsatz von Containern, LXC zB.
Zum Topic: Ist schon richtig was Google da sagt. Der Zugriff auf den RAM ist ausserhalb des Threadmodels eines Browsers. Das muss schon das OS machen. Selbst wenn der Browser die PWs verschluesselt, muss der Schluessel auch im RAM liegen, d.h. man hat nichts gewonnen.
Viel spannender ist, dass die Leute sich jetzt aufregen, Windows aber seit Jahren NTLM User-Hashes, Kerberos TGTs/TGSs einfach im LSASS (und damit unverschluesselt im RAM) liegen hat. Klar, man muss local Admin sein um da dran zu kommen (bzw. Debug-Privs haben), aber die Priveledge Escalation ist bei den meisten Systemen geschenkt.
Ergänzung ()
Animal Mother schrieb:
1. Application wird gestartet
2. zufälliger Salt wird generiert
3. DatenBank wird geladen
4. User gibt Password ein
5. Alle in der Datenbank gespeicherten Passwörter werden in ein DatenObject mit dem Salt verschlüsselt und im Ram abgelegt
6. Der Datenbank Pointer wird im Ram komplett gelöscht
7. Wenn der User das Passwort lesen/kopieren/ändern möchte wird eine Methode aufgerufen die mit dem Salt ein neues Stück ram reserviert und mit dem Salt das Password aus dem Ram wieder entschlüsselt.
8. Nach dieser Operation wird der zuvor reservierte speicher wieder gelöscht.
Ne, nicht wirklich. Hier ist was ich nicht verstehe:
Wird ein Salt oder ein OTP generiert? Salt/Pepper gibt es nur bei Hashfunktionen, um Angriffe ueber Rainbowtable zu verhindern.
Wenn man die Passwoerter mit dem "Salt" verschluesselt in den RAM legt und der Salt im RAM liegt...Was haelt einen Angreifer davon ab die PWs selber mit dem Salt zu entschluesseln? Die Tatsache, dass er nicht weiss, dass der Salt der Schluessel ist? Das waere dann Security-Through-Obscurity, kostet einen Angreifer vielleicht Zeit, aber sicherer ist das nicht.
Kann die Argumentation von Google gut nachvollziehen, wenn man in diese Richtung forscht landet man irgendwann dabei, eine Anwendung auf einer kompromittierten Maschine trotz allem sicher ausführen zu wollen. Das sollte man im Grunde gar nicht probieren und wenn ich ein Chrome-Entwickler wäre würde ich mich auch fragen ob das nicht irgendwo über das Scope des Projekts hinausgeht. Im Prinzip könnte man das ja auch auf Betriessystemebene lösen und unterbinden, dass ein Prozess den Speicher eines anderen ließt. Aber das hat halt auch wieder so seine Nachteile. Und was ist eigentlich mit kompromittierter Hardware?
Ich war außerdem zuweilen auch mal ganz froh die Firefox-Passwörter auslesen zu können, nach Betriebssystemneuinstallationen und so.
Falc410 schrieb:
Ich frage mich gerade wie es anders gehen soll. Der wird die Passwörter bei Verwendung laden aber die müssen ja entschlüsselt werden.
Man könnte das schon mit einem XOR oder so aufteilen und erst bei der Verwendung wieder zusammensetzen. Die beiden Teile kann man dann eventuell auf zwei Speicherorte verteilen die eventuell nicht beide für jeden Prozess gleichzeitig zugreifbar sind. Aber zu erwarten, dass ein normaler Browser das auch macht ist naiv. Bei einem Veracrypt oder Keepass würde ich sowas aber durchaus erwarten. Das ist letztendlich aber auch eher Security by obscurity, eine wirklich "wasserdichte" Lösung würde den User vermutlich dazu zwingen alle zwei Minuten das Masterpassword einzutippen.
Miuwa schrieb:
Ich muss gestehen, ich hätte nicht gedacht, dass ein normaler Prozess einfach den Speicher eines anderen Prozesses auslesen kann
Irgendwie weiß man es heutzutage nicht mehr so genau da die Systeme so komplex sind und so sehr mit Sicherheit werben, dass man davon ausgeht, dass es eigentlich nicht geht. Aber so funktionieren Computer nicht, letztendlich muss man sich viel eher fragen - warum sollte das denn nicht gehen?
Zeitlupe_1982 schrieb:
Legitime Anwendungsfälle sind ja an einer Hand abzuzählen und können vom User whitelisted werden.
Wenn es geht wird es auch von Entwicklern verwendet. Würde mich nicht wundern wenn ein Verbot mit dem nächsten Patch die Hälfte aller Windows-Software kaputt machen würde, gerade ältere Sachen.
Wenn diese Sicherheitsforscher etwas von ihrem Fach verstehen wird denen sehr wohl bewusst sein, dass die Daten im RAM keine Aufgabe vom Browser, sondern vom Betriebssystem sind.
Und wenn ein Angreifer Zugriff auf den RAM hat kann er auch einfach direkt Eingaben von der Tastatur ablesen. Dafür braucht man nämlich noch weniger Rechte.
Sorry aber dieser ganze Wind ist nur billige Werbung von/für CyberArk Labs.
Wer speichert zB Bank Passwörter schon im Browser? Wer solche Sachen im Browser speichert , ist selbst schuld und lost.
Ich speichere nur Passwörter im Firefox, wo die Dienste unwichtig sind und mir der Verlust egal ist. Die pw weisen auch keinerlei Ähnlichkeit mit wichtigsten Daten auf...
Ich persönlich speichere z.B. überhaupt keine PW im Browser oder sonstirgendwo auf meinen Systemen. Es ist zwar aufwändiger jedesmal die PW einzutippen, aber halt auch sichererer. Außerdem gut für's Gedächtnis 👍🏻
seitdem bewahrt sie pin und Karte wenigstens getrennt auf
