{"id":267063,"date":"2022-06-12T00:15:00","date_gmt":"2022-06-11T22:15:00","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=267063"},"modified":"2023-08-02T17:53:59","modified_gmt":"2023-08-02T15:53:59","slug":"chrome-speichert-passwrter-im-speicher-im-klartext","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2022\/06\/12\/chrome-speichert-passwrter-im-speicher-im-klartext\/","title":{"rendered":"Chrome speichert Passw&ouml;rter im Speicher im Klartext"},"content":{"rendered":"<p><img decoding=\"async\" style=\"float: left; margin: 0px 10px 0px 0px; display: inline;\" src=\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2021\/06\/Chrome-01.jpg\" \/>[<a href=\"https:\/\/borncity.com\/win\/?p=24837\" target=\"_blank\" rel=\"noopener\">English<\/a>]Das ist ist schon ein dickes Ei, auf das Sicherheitsforscher der CyberArk Labs beim Google Chrome-Browser gesto\u00dfen sind. Dieser speichert Passw\u00f6rter und Cookies im Klartext im Arbeitsspeicher des eigenen Prozesses. Das bedeutet, ein entsprechendes Tool k\u00f6nnte diese Klartext-Passw\u00f6rter auslesen. Ich habe es am Google Chrome und am Ungoogled-Chromium-Clone getestet &#8211; das Problem d\u00fcrfte alle Chromium-Browser betreffen (also auch den Edge).<!--more--><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/vg08.met.vgwort.de\/na\/8252fde2972a4a868a8cce33136cc1cc\" alt=\"\" width=\"1\" height=\"1\" \/>Ich bin die Woche auf Twitter auf den nachfolgenden <a href=\"https:\/\/twitter.com\/CyberarkLabs\/status\/1534617693944438785\" target=\"_blank\" rel=\"noopener\">Tweet<\/a> der CyberArk Labs Sicherheitsforscher gesto\u00dfen, die den Sachverhalt offen legen und detaillierter im Blog-Beitrag <a href=\"https:\/\/www.cyberark.com\/resources\/threat-research-blog\/extracting-clear-text-credentials-directly-from-chromium-s-memory\" target=\"_blank\" rel=\"noopener\">Extracting Clear-Text Credentials Directly From Chromium's Memory<\/a> beschreiben.<\/p>\n<p><a href=\"https:\/\/twitter.com\/CyberarkLabs\/status\/1534617693944438785\" target=\"_blank\" rel=\"noopener\"><img decoding=\"async\" title=\"Chrome browser stores password in clear text in memory\" src=\"https:\/\/i.imgur.com\/KNBDuHO.png\" alt=\"Chrome browser stores password in clear text in memory\" \/><\/a><\/p>\n<p>Das Ganze ist eine Zufallsentdeckung von Zeev Ben Porat, der im Rahmen eines Projekts einen Mini-Dump aller aktiven Chrome.exe-Prozesse anlegen lie\u00df. Spontan beschloss er zu pr\u00fcfen, ob ein Passwort, das er k\u00fcrzlich in den Browser eingegeben hatte, in einem dieser Dumps auftaucht. Zu seiner \u00dcberraschung stellte er fest, dass das Kennwort im Klartext an mehreren verschiedenen Stellen im Speicher von zwei dieser Prozesse gespeichert war.<\/p>\n<p>Er begann dann etwas genauer nachzuschauen und fand dabei heraus, dass Satyam Singh bereits 2015 Sicherheitsprobleme in Browsern in seinem\u00a0 Blog-Beitrag <a href=\"https:\/\/web.archive.org\/web\/20230324085736\/https:\/\/resources.infosecinstitute.com\/topic\/browser-based-vulnerabilities-in-web-applications\/\" target=\"_blank\" rel=\"noopener\">Browser-based vulnerabilities in web applications<\/a> angesprochen hatte. Dazu geh\u00f6rte auch das Thema \"Passw\u00f6rter werden im Arbeitsspeicher laufender Prozesse abgelegt\".<\/p>\n<h2>Ein Alptraum f\u00fcr Nutzer<\/h2>\n<p>Nach diesen Erkenntnissen begann der Sicherheitsforscher genauer nachzuschauen, was der Google Chrome-Browser so treibt, und konnte seinen Augen kaum glauben, was er herausfand:<\/p>\n<ul>\n<li>Anmeldedaten (URL\/Benutzername\/Kennwort) werden im Speicher von Chrome im Klartextformat gespeichert.<\/li>\n<li>Zus\u00e4tzlich zu den Daten, die dynamisch eingegeben werden, wenn man sich bei bestimmten Webanwendungen anmeldet, kann ein Angreifer den Browser dazu bringen, alle Passw\u00f6rter in den Speicher zu laden, die im Passwort-Manager gespeichert sind (\"Login-Daten\"-Datei).<\/li>\n<li>Die Daten von Cookies (Wert und Eigenschaften von Cookies) werden im Speicher von Chrome im Klartext gespeichert (wenn die betreffende Anwendung aktiv ist). Dies schlie\u00dft sensible Sitzungscookies ein.<\/li>\n<\/ul>\n<p>Diese Informationen k\u00f6nnen effektiv von einem Standardprozess (ohne erh\u00f6hten Status) extrahiert werden, der auf dem lokalen Computer l\u00e4uft und direkten Zugriff auf den Speicher von Chrome hat (unter Verwendung der APIs <em>OpenProcess<\/em> und <em>ReadProcessMemory<\/em>). Die extrahierten Daten k\u00f6nnen verwendet werden, um Benutzerkonten zu kapern. Das gilt selbst dann, wenn diese durch einen MFA-Mechanismus gesch\u00fctzt sind &#8211; denn dann lie\u00dfen sich \"Session-Cookies\" auslesen und verwenden.<\/p>\n<p>Der Sicherheitsforscher hat Beispiele f\u00fcr Session-Hijacking f\u00fcr Gmail, OneDrive und GitHub erfolgreich getestet. Er stellte \u00e4hnliche Schwachstellen im Microsoft Edge-Browser fest und vermutet, dass es bei anderen Chromium-Clones nicht anders ist. Die Details seiner Ermittlungen lassen sich im Blog-Beitrag <a href=\"https:\/\/www.cyberark.com\/resources\/threat-research-blog\/extracting-clear-text-credentials-directly-from-chromium-s-memory\" target=\"_blank\" rel=\"noopener\">Extracting Clear-Text Credentials Directly From Chromium's Memory<\/a> nachlesen.<\/p>\n<h2>Mein eigener Test<\/h2>\n<p>Ich habe das zum Anlass genommen, am Samstag kurz einen eigenen Test mit dem Google Chrome, dem Ungoogled-Browser (Chromium-Clone) und dem Firefox-Browser zu fahren. Dazu habe ich mir das Tool Process Hacker f\u00fcr Windows von <a href=\"https:\/\/processhacker.sourceforge.io\/\" target=\"_blank\" rel=\"noopener\">GitHub heruntergeladen<\/a> und zur Auswertung der Memory-Inhalte verwendet.<\/p>\n<p><img decoding=\"async\" title=\"Process Hacker\" src=\"https:\/\/i.imgur.com\/lyzmGIz.png\" alt=\"Process Hacker\" \/><\/p>\n<p>Es reicht, den Hauptprozess per Rechtsklick anzuw\u00e4hlen und dann im Kontextmen\u00fc <em>Properties <\/em>anzuklicken. Im Eigenschaftenfenster geht man zur Registerkarte <em>Memory <\/em>und w\u00e4hlt dort die Schaltfl\u00e4che <em>Strings<\/em>. Im angezeigten Dialogfeld ist eine String-L\u00e4nge anzugeben (Standard ist 10). Das Ergebnisfenster listet alle Strings auf, die der Prozess-Hacker im Speicher f\u00fcr den jeweiligen Prozess gefunden hat.<\/p>\n<p>Anschlie\u00dfend l\u00e4sst sich im Ergebnisfenster mittels der Schaltfl\u00e4che <em>Filter <\/em>ein Men\u00fc mit Befehlen zur Suche aufklappen. Ich habe mit f\u00fcr <em>Contains <\/em>bzw. die Variante ohne Gro\u00df-\/Kleinschreibung beim Suchbegriff entschieden. Hier die Ergebnisse eines kurzen Tests:<\/p>\n<ul>\n<li>Google Chrome: Die Passw\u00f6rter tauchen im Klartext auf<\/li>\n<li>Ungoogled-Browser: Die Passw\u00f6rter tauchen im Klartext auf<\/li>\n<li>Firefox: Die Passw\u00f6rter tauchen im Klartext auf<\/li>\n<\/ul>\n<p>Die bittere Erkenntnis: Wer ein kompromittiertes System hat und den Google Chrome- oder einen anderen Chromium-Browser verwendet, hat keinen Schutz vor Passwort-Klau. Lediglich der Firefox schien es beim 1. Versuch, dass keine Passw\u00f6rter gefunden werden. Mir scheint ein Fehler unterlaufen zu sein, da bei einem erneuten Test die Kennw\u00f6rter im Klartext auftauchten. Ich habe das Ganze unter Windows 7 getestet, es d\u00fcrfte aber in anderen Windows-Versionen ebenfalls so sein. Wie es unter macOS oder Linux ausschaut, und was auf Mobil-Plattformen wie Android oder iOS so beim Chrome passiert, habe ich nicht mehr testet.<\/p>\n<h2>Kein offizieller Fix &#8230;<\/h2>\n<p>Zeev Ben Porat hat das Ganze am 29. Juli 2021 an das Chrome-Team gemeldet und bekam umgehend von einem Projektmitglied die obige R\u00fcckmeldung, dass das Ganze nicht gefixt werde. Die Begr\u00fcndung, warum das Team das nicht als Problem ansieht, kann <a href=\"https:\/\/chromium.googlesource.com\/chromium\/src\/+\/refs\/heads\/main\/docs\/security\/faq.md#why-arent-physically_local-attacks-in-chromes-threat-model\" target=\"_blank\" rel=\"noopener\">hier nachgelesen<\/a> werden. Allgemein sind die Aussagen zutreffend, aber f\u00fcr den obigen Fall springt das Entwicklerteam in meinen Augen zu kurz &#8211; Kennw\u00f6rter sollten nicht im Klartext im Browser-Speicher zu finden sein.<\/p>\n<p><a href=\"https:\/\/i.imgur.com\/C4HkKe3.png\" target=\"_blank\" rel=\"noopener\"><img loading=\"lazy\" decoding=\"async\" title=\"Chrome password issue\" src=\"https:\/\/i.imgur.com\/C4HkKe3.png\" alt=\"Chrome password issue\" width=\"635\" height=\"121\" \/><\/a><\/p>\n<p>Zeev Ben Porat schreibt in seinem Blog-Beitrag, dass er nach seiner Meldung an das Chromium-Entwicklerteam aber einige Ver\u00e4nderungen beobachtet, die m\u00f6glicherweise als \"Entsch\u00e4rfungsversuche\" zu werten sind. Ungef\u00e4hr einen Monat nachdem er die Erkenntnisse an die Entwickler meldete, gelang es seinem Testprogramm nicht mehr, Cookies-Daten zu extrahieren. Es stellte sich heraus, dass das allgemeine Speicherlayout ge\u00e4ndert worden war (sowohl in Chrome als auch in Edge). Mit einer Modifikation konnte er aber weiter Cookies extrahieren, bis das Programm nach zwei Monaten wieder (f\u00fcr Chrome und Edge) scheiterte. Aber die Klartext-Kennw\u00f6rter lassen sich nach meinen Beobachtungen weiterhin aus dem Speicher extrahieren.<\/p>\n<p><strong>Erg\u00e4nzung:<\/strong> Warum das ein echtes Problem ist, habe ich &#8211; aus gegebenem Anlass &#8211; gleich in meinem Blog-Beitrag\u00a0<a href=\"https:\/\/borncity.com\/blog\/2022\/06\/12\/2-nachlese-zum-gehrteten-sparkassen-browser-s-protect\/\" rel=\"bookmark noopener noreferrer\" data-wpel-link=\"internal\">2. Nachlese zum geh\u00e4rteten Sparkassen-Browser S-Protect<\/a> aufgezeigt. Die benutzen die Web-Rendering-Engine von QT5 als Browser. Diese basiert wohl auf der Blink-Rendering Engine von Chromium (wenn ich nicht g\u00e4nzlich falsch liege). Der geh\u00e4rtete Browser soll auch auf infizierten Systemen mit Trojanern das Online-Banking sch\u00fctzen. Da wird richtig Aufwand getrieben, um das S-Protect-Browser-Paket abzusichern und das Abgreifen der Online-Banking-Zugangsdaten durch Phisher und Trojaner zu verhindern. Und dann kann ich die URL der Sparkasse samt meinem Zugangsdaten im Klartext aus dem Arbeitsspeicher auslesen.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>[English]Das ist ist schon ein dickes Ei, auf das Sicherheitsforscher der CyberArk Labs beim Google Chrome-Browser gesto\u00dfen sind. Dieser speichert Passw\u00f6rter und Cookies im Klartext im Arbeitsspeicher des eigenen Prozesses. Das bedeutet, ein entsprechendes Tool k\u00f6nnte diese Klartext-Passw\u00f6rter auslesen. Ich &hellip; <a href=\"https:\/\/borncity.com\/blog\/2022\/06\/12\/chrome-speichert-passwrter-im-speicher-im-klartext\/\">Weiterlesen <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1356,426],"tags":[406,4328],"class_list":["post-267063","post","type-post","status-publish","format-standard","hentry","category-google-chrome-internet","category-sicherheit","tag-chrome","tag-sicherheit"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/267063","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=267063"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/267063\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=267063"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=267063"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=267063"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}