Hvordan jeg hackede Googles selve fejlsporingssystem for 15.600 dollars i dusør

Nemme bugs til hårde kontanter

Har du nogensinde hørt om Google Issue Tracker? Sandsynligvis ikke, medmindre du er en Google-medarbejder eller en udvikler, der for nylig rapporterede fejl i Google-værktøjer. Og det havde jeg heller ikke før jeg bemærkede, at mine sårbarhedsrapporter blev håndteret ved at åbne en ny tråd der ud over de sædvanlige e-mail-meddelelser.

Så jeg begyndte straks at prøve at bryde det.

Så hvad er netop dette websted? Ifølge dokumentationen er Issue Tracker (internt kaldet Buganizer System) et værktøj, der bruges internt hos Google til at spore fejl og anmodninger om funktioner under produktudvikling. Den er tilgængelig uden for Google til brug af eksterne offentlige og partnerbrugere, der har brug for at samarbejde med Google-teams om specifikke projekter.

Med andre ord, når nogen har et problem med et Google-produkt, går det i udgivelsessporeren . Det giver mening, ikke? Som eksterne brugere kan vi kun se toppen af ​​isbjerget: Et lille sæt forudgodkendte kategorier og problemer, hvor nogen hos Google eksplicit tilføjede en ekstern konto, såsom rapporter om sårbarhed . Men hvor meget information ligger der under overfladen?

Ved at observere numeriske id'er, der er tildelt de seneste offentlige tråde, kan vi nemt estimere, hvor meget brug dette værktøj får internt. Der åbnes ca. 2000–3000 udgaver i timen i arbejdstiden i Mountain View, og kun 0,1% af dem er offentlige. Det ser ud til, at en datalækage i dette system ville have en ret stor indvirkning. Lad os bryde det!

Forsøg nr. 1: Få en Google-medarbejderkonto

En af de første ting, jeg bemærkede, da jeg opdagede problemsporeren, var evnen til at deltage i diskussioner ved at sende e-mails til en særlig adresse, der ser sådan ud:

buganizer-system + componentID + issueID @ google.com

(hvor componentID er et tal, der repræsenterer en kategori, og issueID er en unik identifikator for den tråd, du reagerer på)

Dette mindede mig om et nylig fund kaldet Ticket Trick, som tillod hackere at infiltrere i organisationers chat-systemer ved at udnytte denne form for e-mail-system. I betragtning af at dette er en @ google.com- e-mail-adresse, forsøgte jeg at tilmelde mig Googles Slack-team ved hjælp af det, og bekræftelsessiden, jeg fik til at se meget lovende ud:

Ak, der kom aldrig nogen e-mail fra Slack.

Det næstbedste, jeg kunne tænke på, var at få en Google-konto med en @ google.com hoved-e-mail-adresse, hvilket forhåbentlig ville give mig nogle ekstra privilegier på Buganizer. Det skulle ikke være tilladt at registrere en sådan konto uden for Google:

Jeg fandt dog en metode til at omgå dette filter: Hvis jeg tilmeldte mig en anden falsk e-mail-adresse, men ikke kunne bekræfte kontoen ved at klikke på et link modtaget via e-mail, fik jeg lov til at ændre min e-mail-adresse uden nogen begrænsninger. Ved hjælp af denne metode ændrede jeg e-mailen til en ny Google-konto til [email protected].

Kort efter modtog jeg bekræftelses-e-mailen som en besked på den tilsvarende udgave side:

Pæn! Jeg klikkede på bekræftelseslinket, logget ind på Issue Tracker og ...

Jeg blev omdirigeret til virksomhedens login-side. Og nej, min Google-konto legitimationsoplysninger fungerede ikke der. Øv bøv.

Ikke desto mindre gav denne konto mig mange ekstra fordele andre steder på internettet, herunder muligheden for at køre en tur (gratis, måske?), Så det var stadig et sikkerhedsproblem, der åbnede mange døre for ondsindede brugere.

Accepteret: 11 timer | Bounty: $ 3.133,7 | Prioritet: P1

Forsøg nr. 2: Få besked om interne billetter

En anden Issue Tracker-funktion, der fangede mit øje, mens jeg blev fortrolig med brugergrænsefladen, er evnen til at stjerne emner. Stjernemarkering af et problem betyder, at du er interesseret i problemet, der diskuteres, og at du vil modtage e-mail-underretninger, når nogen tilføjer en kommentar.

Det interessante, jeg bemærkede ved denne funktionalitet, var den tydelige mangel på fejl, når jeg forsøgte at bruge den til problemer, jeg ikke havde adgang til. Adgangskontrolregler syntes aldrig at være anvendt på dette slutpunkt, så jeg loggede ind på min anden konto og forsøgte at stjerne en sårbarhedsrapport fra min hovedkonto ved at erstatte problem-id'et i anmodningen. Jeg så denne meddelelse, hvilket betyder, at handlingen havde været vellykket:

1 person har stjernet dette problem.

Kan det være så let at spionere på åbne Google-sårbarheder? Jeg sendte hurtigt en kommentar til problemet for at se, om jeg min fiktive angriberkonto ville få besked om det.

Men igen dukkede der aldrig nogen e-mail op.

Af en eller anden grund, som jeg virkelig ikke kan huske, besluttede jeg at lave nogle yderligere test på denne. Så jeg fik et nyligt ID-nummer og ekstrapolerede et interval på et par tusinde ID'er, der skulle falde sammen med de nyeste udgaver i databasen. Derefter stjernede jeg dem alle sammen.

I løbet af få minutter så min indbakke sådan ud:

Min første tanke ved åbning af indbakken var “Jackpot!”.

Men ved nærmere eftersyn skete der ikke noget særligt interessant i disse tråde. Tilsyneladende kunne jeg kun aflytte oversættelsesrelaterede samtaler, hvor folk diskuterede de bedste måder at formidle betydningen af ​​en sætning på forskellige sprog.

Jeg overvejede endda ikke at rapportere dette i et par timer og håbede, at jeg ville finde en måde at eskalere sværhedsgraden. Til sidst indså jeg, at Googles sikkerhedsteam sandsynligvis ville være interesseret i at finde mulige drejningsmetoder og varianter, så jeg sendte detaljerne ud.

Accepteret: 5 timer | Bounty: $ 5.000 | Prioritet: P0

Forsøg nr. 3: Afslutning af spillet

Når du besøger Issue Tracker som en ekstern bruger, fjernes det meste af dets funktionalitet, hvilket efterlader dig med ekstremt begrænsede privilegier. Hvis du vil se alle de seje ting, som Google-medarbejdere kan gøre, kan du kigge efter API-slutpunkter i JavaScript-filerne. Nogle af disse funktioner er deaktiveret fuldstændigt, andre er simpelthen skjult i grænsefladen.

Ved design af denne begrænsede version af systemet var nogen dejlig nok til at efterlade en metode til, at vi fjernede os fra listen over CC'er, hvis vi mister interessen for et problem eller ikke længere vil modtage e-mails om det. Dette kunne opnås ved at sende en POST-anmodning som denne:

POST /action/issues/bulk_edit HTTP/1.1
{ "issueIds":[ 67111111, 67111112 ], "actions":[ { "fieldName":"ccs", "value":"[email protected]", "actionType":"REMOVE" } ]}

Imidlertid bemærkede jeg nogle tilsyn her, der førte til et kæmpe problem:

  1. Forkert adgangskontrol: Der var ingen eksplicit kontrol af, at den aktuelle bruger faktisk havde adgang til de problemer, der er angivet i, issueIdsinden han forsøgte at udføre den givne handling.
  2. Lydløs fejl : Hvis du angav en e-mail-adresse, der ikke var i øjeblikket på listen over CC'er, ville slutpunktet returnere en besked om, at e-mailen var blevet fjernet med succes.
  3. Fuldstændige problemoplysninger som svar: Hvis der ikke opstod fejl under handlingen, antog en anden del af systemet, at brugeren havde de rette tilladelser. Således vil hver eneste detalje om det givne problem-ID blive returneret i HTTP-responsorganet.

Jeg kunne nu se detaljer om hvert problem i databasen ved at erstatte issueIdsi anmodningen ovenfor. Bingo!

Jeg prøvede kun at se et par på hinanden følgende id'er og angreb mig derefter fra en ikke-relateret konto for at bekræfte sværhedsgraden af ​​dette problem.

Ja, jeg kunne se detaljer om sårbarhedsrapporter sammen med alt andet, der er hostet på Buganizer.

Endnu værre kunne jeg exfiltrere data om flere billetter i en enkelt anmodning, så overvågning af al den interne aktivitet i realtid ville sandsynligvis ikke have udløst nogen satsbegrænsere.

Jeg sendte straks udnyttelsesoplysningerne til Google, og deres sikkerhedsteam havde det berørte slutpunkt deaktiveret en time senere. Imponerende svartid!

Accepteret: 1 time | Bounty: $ 7.500 | Prioritet: P0

Da jeg først begyndte at jage efter denne informationslækage, antog jeg, at det ville være den hellige gral af Google-bugs, fordi den afslører oplysninger om enhver anden fejl (for eksempel betaler HackerOne mindst $ 10.000 for noget lignende).

Men efter at have fundet det, indså jeg hurtigt, at virkningen ville blive minimeret, fordi alle de farlige sårbarheder alligevel neutraliseres inden for en time.

Jeg er meget tilfreds med de ekstra kontanter og ser frem til at finde fejl i andre Google-produkter.