Every now and then we are reminded that even the largest, cleverest companies can suffer security failures so unexpected it leaves one gasping in incredulity.
Take the case of Google’s Issue Tracker – the “Buganizer” to its friends – the company’s internal system for tracking general software bugs, feature requests and vulnerability reports in its own products.
This is also where outsiders report newly-discovered security vulnerabilities to Google, so one would assume it would be locked up very carefully. The consequences of not doing so, of allowing the wrong pair of prying eyes to browse through a list of unfixed vulnerabilities in hugely popular Google products, don’t bear thinking about.
Because Google takes security deadly seriously, right? Not according to researcher Alex Birsan who found he was able to manipulate this system as a sort of backdoor to do alarming things he shouldn’t have been able to.
The least serious being:
- Break access control to receive email conversation threads between internal programmers. Not a big deal perhaps but it still earned Birsan a $5,000 (£3,750) bug bounty when he reported it to Google so perhaps extra digging would have revealed more dangerous pivots.
- Change his registered Buganizer email address to an internal Google one by exploiting weaknesses in email updating. He wasn’t able to gain access to the company’s email platform but might have been able to order a taxi using the internal GRide. Reporting this earned Birsan $3,137.
- Receiving details of any security vulnerability (identified by a user ID) simply by pretending to unsubscribe from it. That left Birsan’s bounty account $7,500 to the good.
Birsan concedes that the latter issue might be self-limiting as Google processes serious security flaws in a one-hour time frame but there’s no getting away from what he stumbled upon:
Yes, I could see details about vulnerability reports, along with everything else hosted on the Buganizer. Even worse, I could exfiltrate data about multiple tickets in a single request, so monitoring all the internal activity in real time probably wouldn’t have triggered any rate limiters.
That’s a total of $15,637 for a few hours of digging around in Google Issue Tracker, arguably the most security-critical Google system anyone outside the company has access to.
And it’s not a small platform either, processing an estimated 2000-3000 issues per hour internally. Google later told Motherboard:
We appreciate Alex’s report. We’ve patched the vulnerabilities that he reported, as well as their variants.
Presumably, the company will also be conducting a thorough review of its issue tracker in case there are any other weaknesses it’s missed.
Naked Security like to draw a moral from these sorts of security stories to cheer ourselves up, which in this case is that the simple passing of time is often security’s most under-estimated foe.
Issue Tracker and its predecessors will have been around in some form or other since Google was founded in 1998, long before security was top of anyone’s worry list. Over time, there is a risk of vulnerabilities creeping in as the system is extended or rebuilt – particularly if the work is done by people in a hurry, without the right skills, or with little knowledge of the previous developers’ handiwork.
And, so, layers of assumptions and small mistakes accumulate over time (a phenomenon known in programming circles as technical debt) which aren’t always noticed unless it’s someone’s job to look for them – which in busy companies filling up with new employees, new systems and new ideas, it often isn’t.
It’s something almost every company above a certain size or age should recognise. When the mighty stumble, gloating is a sure-fire way to tempt fate.