War Stories

War Stories from Google's
Vulnerability Reward Program

Gábor Molnár molnarg@
2016-10-20
Proprietary + Confidential
Introduction
Software Engineering BSc & MSc from BUTE Hungary

Founding member of
the !SpamAndHex CTF team and CrySyS Student Core
Information Security Engineer at Google Switzerland
Web security, foosball and internet cat enthusiast
Agenda
The VRP
A Great Report
Good vs Bad Reports
The VRP
VRP from the outside
You send us
vulnerability reports.
We fix the bugs and

reward good reports.
Source: Google Security Blog

VRP from the inside

A team of Information Security Engineers
in a weekly rotation
handling incoming vulnerability reports for
all Google web applications

all Google Android applications
and everything else Google
(except core Android OS components and Chrome)

Reports we receive
> 150 reports per week
6 minutes per report
90%: no bug filed
Source: Wikipedia, Secrets of Google VRP

Reports we receive
? Low quality Good Amazing
Source: Lorem ipsum dolor sit amet, consectetur adipiscing elit. DuisSource:
non erat
1 2sem
34
Life of a VRP report
Bugfix Remediation
Bug Product team
Triage
submission ACK
Panel Reward
Reproduction
Finding duplicates
Severity assessment
Source: Lorem ipsum dolor sit amet, consectetur adipiscing

Source: Secrets
elit. Duisofnon
Google
erat sem
VRP
A Great Report:
Account Hijacking with XSS
See also: blog post
The Report
From Ramzes, one of our top reporters

Combination of several bugs
Multi-step exploit
Victim visits attacker page → attacker can change victim’s password
Reward: USD 12,500
Attack scenario
1. User opens attacker site (phishing, etc.)

2. Attacker site exploits vulnerabilities on www.google.com
3. Password reset email is sent to the attacker
Context: Account Recovery
Restoring account access after losing password

Takes many signals into account.
A few good signals:
● Usual IP address
● Same browser as usual
● Good questionnaire answers
● …
Source: Bughunter University

Application (on ?.google.com domain)
1. XSS on www.google.com
Embeddable help popover
Uses an iframe (content frame)
Content frame uses an API: query → HTML
API communication: iframe + postMessage
API URL: specified in URL param, no filtering Content iframe (www.google.com)
Query
→ HTML can be attacker provided HTML
Check URL when creating iframe: good fix?

Invisible comms iframe (API domain)
Real fix: check every message!
Source: Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis non erat sem
2. Starting Account Recovery
XSS payload runs on www.google.com
Account Recovery first step is on www
Email address is easy to extract on www
3. CSRF on
Redirect 2 on www
accounts.google.com URL: …?est=TOKEN
Next step is on accounts.google.com

Same Origin Policy → payload has no access Redirect 1 on www
Goal: submit this form with “I don’t know”
Form submit target URL = page URL
Page URL contains token (CPR) Prev. step on www
This acts as CSRF protection
Redirect 2 works without cookies
1. Read EST token (on www)
2. Repeat redirect 2 on server
3. Send back CPR token
4. Submit form using CPR token
4. Choosing the
questionnaire
Back on www
Goal: send password reset link to attacker
Not to the secondary email address
Only choice: “Verify your identity by answering

multiple questions about your account.”
5. The questionnaire
6. Win
Password reset email is
sent to the attacker
Good vs Bad Reports
Choose target carefully Applications enabling account takeover:

https://accounts.google.com
Different reward amount per application.
Highly sensitive applications:
High value targets probably mean more Search, Gmail, Inbox, Wallet, Cloud Console,
work. Play, etc.
XSS on sandbox domain is out of scope. Normal applications:

YouTube, Blogger, etc.
Beginners: try acquisitions.
Non-integrated acquisitions, other apps:
BandPage, Pixate, etc.
Source: VRP rules page

Choose target carefully No monetary reward for recent acquisitions

(6 months blackout period):
Different reward amount per application. Apigee
High value targets probably mean more Out of scope: XSS in sandbox domains:
work. ad.doubleclick.net
googleusercontent.com
XSS on sandbox domain is out of scope. googlecode.com
codespot.com
Beginners: try acquisitions. feeds.feedburner.com
...
Source: VRP rules page

Include an Attack Scenario Good Attack Scenario
What does the victim and the attacker do? 1. Victim visits the attacker’s website
2. The victim is tricked into clicking on
Attacker privileges: less → more the website
3. The attacker exploits a clickjacking
How likely is that the victim will do this? bug using this click.
4. The attacker has JS execution on
Safe to assume that the victim
xyz.google.com, can steal data.
● is logged in to Google
● clicks on a link (phishing works)
● clicks once or twice on an attacker
website (Clickjacking works)
Source: This is not real VRP report

Include an Attack Scenario Weak Attack Scenarios

1. Install Burp on the machine
Don’t assume that the victim
2. Read user cookies at https://google.com
● downloads and executes a binary
3. BAAAAM you’re pwned
● runs a browser with a vulnerability
● gives physical access to their 1. Victim opens attacker website
unlocked machine/phone to attacker 2. Attacker uses the CVE-X Chrome UXSS
to read cookies from https://google.com
Typical weak attack scenario:
more privileges → less privileges 1. Victim leaves his computer unlocked
2. Attacker installs keylogger
3. Attacker is able to read emails written
1. Victim opens page with

<img src=google.com/logout>
2. Victim is logged out
Source: Based on true stories
Include a Proof of Concept Good reproduction steps:
or detailed repro steps See my PoC at https://example.com/x
How exactly does the vulnerability work? Details:
Test your PoC before sending 1. With clickjacking, the user clicks on
the “Enable XSS” button.
2. Then an iframe is navigated to the
vulnerable XSS page.
3. The “title” URL parameter is
interpolated without escaping.
4. JS is injected that reads the user’s
emails and alerts the text of the first.
Source: This is not real VRP report

Demonstrate the minimum Good report:
impact - we’ll reward the Hi,

maximum impact
I’ve successfully leaked sensitive user data
Impact: What can the attacker do having from a test account I’ve set up, using an
authentication bypass vulnerability. I didn’t
exploited the vulnerability?
try to exploit this for real user data.
Don’t do real damage, or steal user data.
Use test accounts for testing.
We’ll determine and reward the maximum

impact—no need to demonstrate it.
Source: Based on a true story

Always verify tools’ output I’ve attached a 5MB zip with the text
output of my X tool. EVERY Google
Tools often report false positives. page is affected by these cyber
We very rarely receive valid reports vulnerabilities. Please read it ASAP!!!!
generated by public automatic scanning
tools.
Our top researchers use custom built

scanning tools.
Source: Based on a true story

Include a Video if it’s Hard

to Explain Otherwise
In most cases, text is good enough.
Make it as short as possible.
If you have links, please include them in

the text.
Source: wikimedia.org
+1: Be Polite
“
I have 2 SQLi's I am willing to sell to you
to fix it. that is 20k$. payment only
Don’t CC Larry or Sergey accepted by bitcoin. …
Don’t CC Gerhard (VP Security & Privacy) dont pull magic tricks, or they will be sold
on black market. …
In Russia SQLi hacks you or something

like that. You can call up fbi, fsb, interpol.
I dont care. You know what you have to
do, do it or dont.
”
Source: Anonymous VRP Reporter
+2: Hack for charity! You may have read about Sanmay Ved, a
researcher from who was able to buy
We double rewards donated to charity! google.com for one minute on Google
Domains.
Don’t register a fake charity.
Our initial financial reward to Sanmay—$
6,006.13—spelled-out Google, numerically
(squint a little and you’ll see it!).
Because Ved was donating the money to

charity, Google offered to double the
amount that would go to The Art of Living
India.
Source: Google Security Blog, Business Insider

Bonus Tips for Beginners

Use your native language in the reports (I read the Hungarian reports)
Start with acquisitions + usual web vulnerabilities (probably no reward!)
Read the articles on the Bughunter University
● Usual non-qualifying findings
● Improving your reports
Be persistent - some of our best reporters started with low quality reports, improved a lot over time
THANK YOU
g.co/vrp

War Stories

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

War Stories

Transféré par

Droits d'auteur :

Formats disponibles

War Stories from Google's

Vulnerability Reward Program

Software Engineering BSc & MSc from BUTE Hungary

Good vs Bad Reports

VRP from the outside

We fix the bugs and

Source: Google Security Blog

VRP from the inside

all Google web applications

(except core Android OS components and Chrome)

> 150 reports per week

6 minutes per report

90%: no bug filed

Source: Wikipedia, Secrets of Google VRP

? Low quality Good Amazing

Life of a VRP report

Source: Lorem ipsum dolor sit amet, consectetur adipiscing

From Ramzes, one of our top reporters

1. User opens attacker site (phishing, etc.)

Context: Account Recovery

Restoring account access after losing password

Source: Bughunter University

Embeddable help popover

Uses an iframe (content frame)

Content frame uses an API: query → HTML

API communication: iframe + postMessage

API URL: specified in URL param, no filtering Content iframe (www.google.com)

Check URL when creating iframe: good fix?

2. Starting Account Recovery

XSS payload runs on www.google.com

Account Recovery first step is on www

Email address is easy to extract on www

Next step is on accounts.google.com

Goal: send password reset link to attacker

Not to the secondary email address

Only choice: “Verify your identity by answering

Good vs Bad Reports

Choose target carefully Applications enabling account takeover:

XSS on sandbox domain is out of scope. Normal applications:

Source: VRP rules page

Choose target carefully No monetary reward for recent acquisitions

Source: VRP rules page

Include an Attack Scenario Good Attack Scenario

Source: This is not real VRP report

Include an Attack Scenario Weak Attack Scenarios

1. Victim opens page with

Include a Proof of Concept Good reproduction steps:

or detailed repro steps See my PoC at https://example.com/x

How exactly does the vulnerability work? Details:

Source: This is not real VRP report

Demonstrate the minimum Good report:

impact - we’ll reward the Hi,

Use test accounts for testing.

We’ll determine and reward the maximum

Source: Based on a true story

Our top researchers use custom built

Source: Based on a true story

Include a Video if it’s Hard

Make it as short as possible.

If you have links, please include them in

In Russia SQLi hacks you or something

Because Ved was donating the money to

Source: Google Security Blog, Business Insider

Bonus Tips for Beginners