Pocket a hefty bounty for breaking something...we should all be so industrious. Alex Birsan, a security researcher, appears to have been smart, resourceful and persistent enough to trick Google’s internal bug tracker into gaining entry to thousands of some of the company’s most compromising vulnerabilities.
For his 17 hours of unsolicited work (more on that below), Google shuttled a cool $15,600 in bounty Birsan’s way along with the appropriate gratitude for alerting it to the three process vulnerabilities he discovered. “Easy bugs for hard cash,” Birsan called it on a blog post (via ZDNet). “I’m very happy with the extra cash, and looking forward to finding bugs in other Google products.”
For the uninitiated user, which in this case is most of us save developers or Google staffers, the company uses an Issue Tracker, aka Buganizer System tool, to track bugs and feature requests that turn up in product development. Birsan noticed that his vulnerability reports were being handled by opening a new thread in the Google Issue Tracker as well as by sending him an email.
“Naturally, I immediately started to break it,” he said. “We, as external users, only get to see the tip of the iceberg: A small set of pre-approved categories, and issues where someone at Google explicitly added an external account, such as vulnerability reports. But how much information lies under the surface?”
By his calculations, Birsan had hit upon a Google treasure trove of vulnerabilities information that, if compromised by a hacker, could create havoc for the company. Some 2,000 to 3,000 issues are opened during working hours, with only 0.1 percent public, he estimated. "Seems like a data leak in this system would have a pretty big impact.”
Here, his own words, is the step-by-step of Birsan’s caper (an interesting full read on his blog, here abridged):
Bug #1: One of the first things I noticed upon discovering the issue tracker was the ability to participate in discussions by sending emails to a special address.
The next best thing I could think of was getting a Google account with an @google.com main email address, which would hopefully give me some extra privileges on the Buganizer. Registering such an account from outside Google was not supposed to be allowed. However...if I signed up with any other fake email address, but failed to confirm the account by clicking on a link received by email, I was allowed to change my email address without any limitations.
Soon after, I received the confirmation email as a message on the corresponding issue page:
I clicked the confirmation link, logged in on the Issue Tracker, and I got redirected to the corporate login page. And no, my Google account credentials did not work there. Nevertheless, this account gave me a lot of extra benefits in other places across the internet, including the ability to hitch a ride (for free, maybe?), so it was still a security problem that opened a lot of doors for malicious users.
Bug #2: The ability to star items...means you’re interested in the problem being discussed and you want to receive email notifications whenever someone adds a comment. The interesting thing I noticed about this functionality was the distinct lack of errors when trying to use it on issues I did not have access to.
I logged in to my second account and tried to star a vulnerability report from my main account by replacing the Issue ID in the request. (He was successful). Could it be that easy to spy on open Google vulnerabilities? I quickly posted a comment on the issue to see if I my fictional attacker account would get notified about it.
But again, no email ever showed up. So I got a recent Issue ID, and extrapolated a range of a few thousand IDs which should coincide with the latest issues in the database. I then starred them all. (His inbox was flooded in minutes).
My first thought when opening the inbox was “Jackpot!” However, upon closer inspection, there was nothing particularly interesting going on in those threads.
Bug #3: When you visit the Issue Tracker as an external user, most of its functionality is stripped away, leaving you with extremely limited privileges. If you want to see all the cool stuff Google employees can do, you can look for API endpoints in the javascript files. When designing this limited version of the system, someone was nice enough to leave in a method for us remove ourselves from the CCs list if we lose interest in an issue or simply don’t want to receive emails about it any more.
However, I noticed some oversights here...There was no explicit check that the current user actually had access to the issues specified...If you provided an email address that was not currently in the CCs list, the endpoint would return a message stating the email had been removed successfully...If no errors occurred during the action, another part of the system assumed that the user had proper permissions.
Obviously, I could now see details about every issue in the database by simply replacing Issue Ids in the request...Bingo!
"When I first started hunting for this information leak, I assumed it would be the Holy Grail of Google bugs, because it discloses information about every other bug," Birsan wrote. "However, after finding it, I quickly realized that the impact would be minimized, because all the dangerous vulnerabilities get neutralized within the hour anyway."
No matter, his pockets are a bit heavier now for the effort.
