{"id":289760,"date":"2023-12-30T01:44:29","date_gmt":"2023-12-30T00:44:29","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=289760"},"modified":"2024-01-07T08:10:55","modified_gmt":"2024-01-07T07:10:55","slug":"undokumentierte-google-oauth-funktion-von-malware-fr-konten-hijacking-missbraucht","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2023\/12\/30\/undokumentierte-google-oauth-funktion-von-malware-fr-konten-hijacking-missbraucht\/","title":{"rendered":"Undokumentierte Google OAuth-Funktion von Malware für Konten-Hijacking missbraucht"},"content":{"rendered":"

\"Sicherheit[English<\/a>]Es gibt eine undokumentierte Funktion in Googles OAuth-Implementierung, die von mehreren Malwarest\u00e4mmen missbraucht wird. Diese verwenden einen Exploit, mit dem sie abgelaufene Cookies wiederherstellen k\u00f6nnen. Das erm\u00f6glicht, sich anschlie\u00dfend an Online-Konten anzumelden, dort Informationen abzugreifen oder das Konto zu \u00fcbernehmen. Die Anmeldung funktioniert sogar, wenn ein Online-Konto zur\u00fcckgesetzt wurde. Aktuell ist unklar, ob Google das Problem im Browser gefixt hat.<\/p>\n

<\/p>\n

OAuth, was ist das?<\/h2>\n

\"\"Das K\u00fcrzel OAuth<\/a> 2.0 steht f\u00fcr \"Open Authorization\" Version 2.0, ein Autorisierungs-Protokoll. Es ist ist ein Standard zur Online-Autorisierung. Eine Website oder Anwendung kann mit OAuth 2.0 auf Ressourcen zugreifen, die von anderen Web-Apps f\u00fcr einen Nutzer gehostet werden. Dieser Standard l\u00f6ste 2012 OAuth 1.0 ab.<\/p>\n

OAuth 2.0 nutzt Zugriffstokens, das sind Daten, die die Autorisierung zum Zugriff auf Ressourcen f\u00fcr den Endnutzer darstellen. OAuth 2.0 definiert kein spezielles Format f\u00fcr Zugriffstokens. Je nach Kontext wird jedoch h\u00e4ufig das \"JSON Web Token (JWT)\"-Format genutzt. Dieses erm\u00f6glicht es dem Aussteller der Tokens, Daten in das Token selbst aufzunehmen. Aus Sicherheitsgr\u00fcnden k\u00f6nnen Zugriffstokens au\u00dferdem ein Ablaufdatum haben.<\/p>\n

OAuth 2.0 erm\u00f6glicht den Zugriff nach Zustimmung und schr\u00e4nkt ein, welche Aktionen der Client ausf\u00fchren darf, ohne die Anmeldedaten des Nutzers zu teilen. Details lassen sich auf der verlinkten OAuth-Seite oder auf Wikipedia<\/a> nachlesen.<\/p>\n

Missbrauch einer undokumentierten Funktion<\/h2>\n

Im Oktober 2023 machte ein Malware-Entwickler mit dem Namen PRISMA eine Ank\u00fcndigung auf seinem Telegram-Kanal. Der Malware-Entwickler hatte eine kritische Sicherheitsl\u00fccke in OAuth 2.0 gefunden, die die Generierung von dauerhaften Google-Cookies durch Token-Manipulation erm\u00f6glicht. Diese Schwachstelle erm\u00f6glicht den kontinuierlichen Zugriff auf Google-Dienste, auch nachdem ein Benutzer sein Passwort zur\u00fcckgesetzt hat.<\/p>\n

Schnelle Verbreitung des Exploits<\/h3>\n

Der Malware-Entwickler erstellte dann einen Exploit, um diese 0-day-Schwachstelle auszunutzen. Ein zweiter Bedrohungsakteur, der gleichzeitig Kunde von PRISMA war, modifizierte dieses Script sp\u00e4ter und integrierte es in den Lumma Infostealer. Der Bedrohungsakteur verwendete fortschrittliche Blackboxing-Techniken, um seine Methode zu sch\u00fctzen. Der betreffende Exploit verbreitete sich schnell unter verschiedenen Malware-Gruppen.<\/p>\n

Der Lumma Infostealer, der die entdeckte Schwachstelle enth\u00e4lt, wurde am 14. November 2024 implementiert. In der Folge \u00fcbernahmen Rhadamanthys, Risepro, Meduza und Stealc Stealer diese Technik. Am 26. Dezember 2023 implementierte auch White Snake den Exploit. Derzeit arbeitet der Entwickler von Eternity Stealer aktiv an einem Update. Der Exploit verbreitet sich rasend schnell und zeigt einen besorgniserregenden Trend, der auf eine schnelle Integration des Exploits in verschiedener Infostealer-Gruppen hindeutet.<\/p>\n

Entdeckung und Analyse<\/h3>\n

Sicherheitsforscher von CloudSEK kamen dem Sachverhalt auf die Spur, weil die kontextbezogene KI-Plattform XVigi diese Ank\u00fcndigung mitbekam. Die Sicherheitsforscher waren nach einer technischen Analyse in der Lage, diesen Exploit auf einen undokumentierten Google Oauth-Endpunkt namens \"MultiLogin\" zur\u00fcckzuf\u00fchren.<\/p>\n

Die MultiLogin-Funktion ist aber nirgends dokumentiert. Die Sicherheitsforscher wurden aber im Quellcode des Chrome-Browsers f\u00fcndig. Aus dem Chromium-Quellcode geht hervor, dass es sich bei dem MultiLogin-Endpunkt um einen internen Mechanismus handelt, der f\u00fcr die Synchronisierung von Google-Konten \u00fcber verschiedene Dienste hinweg entwickelt wurde.<\/p>\n

MultiLogin erleichtert ein konsistentes Nutzererlebnis, indem sichergestellt wird, dass die Kontost\u00e4nde des Browsers mit den Authentifizierungs-Cookies von Google \u00fcbereinstimmen. Dieser undokumentierte MultiLogin-Endpunkt ist ein wichtiger Teil des OAuth-Systems von Google, der Vektoren von Konto-IDs und Authent-Login-Tokens akzeptiert.<\/p>\n

Exfiltration von Token und Konto-IDs<\/h3>\n

Bei der Analyse der Malware-Variante (u.a. durch Austausch mit den Malware-Entwicklern des Exploits) haben die Sicherheitsforscher herausgefunden, dass diese auf die token_service<\/em>-Tabelle von WebData im Chrome-Browser abzielt, um Token und Konto-IDs von angemeldeten Chrome-Profilen zu extrahieren. Diese Tabelle enth\u00e4lt zwei wichtige Spalten: service <\/em>(GAIA ID) und encrypted_token<\/em>. Die verschl\u00fcsselten Token werden mithilfe eines Schl\u00fcssels, der im Local State von Chrome im UserData-Verzeichnis gespeichert ist, entschl\u00fcsselt.<\/p>\n

Und jetzt wird es interessant: Mithilfe der per Malware extrahierten Token:GAIA-Paare aus dem MultiLogin-Endpunkt k\u00f6nnen die Bedrohungsakteure \u00fcber den Exploit abgelaufene Google-Service-Cookies neu generieren. Dadurch erhalten sie dauerhaften Zugriff auf kompromittierte Konten. Das funktioniert auch, falls der Benutzer sein Passwort f\u00fcr das Konto zur\u00fccksetzt – allerdings nur ein Mal. Wird das Kennwort nicht zur\u00fcckgesetzt, kann der Exploit abgelaufene Google-Service-Cookies f\u00fcr den Zugriff sogar wiederholt neu generieren und verwenden.<\/p>\n

Status des Exploits unklar<\/h2>\n

Die Sicherheitsforscher haben ihre Analyse in einem Blog-Beitrag Compromising Google Accounts: Malwares Exploiting Undocumented OAuth2 Functionality for session hijacking<\/a> ver\u00f6ffentlicht. Gleichzeitig standen die Sicherheitsforscher mit den Kollegen von Bleeping Computer im Austausch, die das Ganze in diesem Artikel<\/a> aufgegriffen und auch ein Video von Hudson Rock zur Demonstration des Exploits eingef\u00fcgt haben. Bleeping Computer hatte mehrfach bei Google nachgefragt, ob man diese Schwachstelle schlie\u00dfen will, aber keine Antwort erhalten. Daher ist aktuell unklar, ob der Exploit in aktuellen Chromium-Versionen noch ausgenutzt werden kann.<\/p>\n

Erg\u00e4nzung:<\/strong> Google gibt in einer Stellungnahme an, dass das Ganze nichts neues sei und meint \"Google ist sich der j\u00fcngsten Berichte \u00fcber eine Malware-Familie bewusst, die Sitzungs-Token stiehlt. Angriffe mit Malware, die Cookies und Token stehlen, sind nicht neu; wir aktualisieren routinem\u00e4\u00dfig unsere Abwehrma\u00dfnahmen gegen solche Techniken und sch\u00fctzen Nutzer, die Opfer von Malware werden. In diesem Fall hat Google Ma\u00dfnahmen ergriffen, um alle entdeckten kompromittierten Konten zu sichern\". Die Kollegen von Bleeping Computer haben das Ganze in diesem Blog-Beitrag<\/a> samt obiger Stellungnahme aufgegriffen.<\/p>\n","protected":false},"excerpt":{"rendered":"

[English]Es gibt eine undokumentierte Funktion in Googles OAuth-Implementierung, die von mehreren Malwarest\u00e4mmen missbraucht wird. Diese verwenden einen Exploit, mit dem sie abgelaufene Cookies wiederherstellen k\u00f6nnen. Das erm\u00f6glicht, sich anschlie\u00dfend an Online-Konten anzumelden, dort Informationen abzugreifen oder das Konto zu \u00fcbernehmen. … Weiterlesen →<\/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":[426],"tags":[4328],"class_list":["post-289760","post","type-post","status-publish","format-standard","hentry","category-sicherheit","tag-sicherheit"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/289760","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=289760"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/289760\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=289760"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=289760"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=289760"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}