📜 ⬆️ ⬇️

How I found vulnerabilities in Google's bug tracking system and got $ 15,600

Have you ever heard of Google Issue Tracker? Probably not if you’re not a Google employee or a developer who recently reported problems in Google’s tools. And I didn’t know either, until I noticed that my vulnerability reports are now being processed, by opening a new discussion, in addition to regular email notifications.

So I immediately started trying to hack it.

image
')
So what is this site? According to the documentation, Tracker Issue (also called Buganizer System) is a tool used by Google to track down bugs and requests to add new features during product development. It is available outside of Google for use by the public and partner users who need to collaborate with the Google team on specific projects.

In other words, when someone has a problem (issue) with a Google product, he goes to a bug tracker. It makes sense, right? We, as external users, see only the tip of the iceberg: a small set of pre-approved categories and problems associated with Google’s adding an external account, for example, vulnerability reports. But how much information is under the surface?

image

By observing the IDs assigned to the latest published bugs, we can easily estimate how much use this tool receives from the inside. During business hours in Mountain View, there are about 2000-3000 problems per hour. It looks like data leakage from this system will be of great value. Let's crack it!


The translation was made with the support of the company EDISON Software , which is professionally engaged in the development of video surveillance services , applications for the virtual cellular operator and the development of programs in C and C ++ (IPTV player) .


Vulnerability # 1: Getting a Google Employee Account


One of the first things that I noticed when detecting a bug tracker is the ability to participate in discussions by sending emails to a special address that looks like this:

buganizer-system + componentID + issueID @ google.com

(in which componentID is a number representing a category, and issueID is a unique identifier for a discussion in which you answer)

It reminded me of a recent discovery called Ticket Trick , which allowed hackers to enter the organization's chat system using such an email system.

Given that this is an email address @ google.com, I tried to register with Google Slack using it. The login confirmation page, which I saw, looked very promising:

image

Alas, not a single letter from Slack has come.

The next thing I could think of is getting a Google account with a google .com domain , which I hope will give me additional privileges in Buganizer. Registering such an account from outside Google did not work:

image


However, I found a way to bypass this filter: if I registered at any other fake email address, but I could not confirm my account by clicking on the link received by email, I was allowed to change my email address without any restrictions. Using this method, I changed the email of a new Google account to buganizer-system+123123+67111111@google.com .

Shortly after, I received a confirmation email in the form of a message on the corresponding problem page:

image

Fine! I clicked on the confirmation link and logged into the Tracker Issue and ...

image

I was redirected to the corporate login page. And no, my Google credentials were not accepted there. Bummer.

However, this account has given me a lot of additional benefits elsewhere around the Internet, including the ability to travel (maybe for free?), So the security issue opened many doors for malicious users.

Total: 11 hours | Reward: $ 3,133.7 | Priority: P1

Vulnerability # 2: Receive Internal Ticket Notifications


Another feature of the bug tracker that caught my attention when I was introduced to the user interface was the ability to mark discussions. Ticking a discussion means that you are interested in the problem being discussed, and you want to receive email notifications when someone adds a comment.

image

An interesting thing I noticed about this functionality was that there were no errors when trying to flag those discussions that I did not have access to. Access control rules have never been applied in this endpoint, so I logged into my second account and tried to flag the vulnerability message from my main account, replacing the bug ID in the request. Then I saw this message, which means that the action was successful:

1 people tagged this issue.
Does this mean that I can easily spy on Google open vulnerabilities? I quickly posted a comment on this issue to see if the notification would come to my second account.

image

But again, not a single message appeared.

For some reason, which I really do not remember, I decided to conduct another test. Therefore, I took the recent ID of the bug and extrapolated several thousand IDs that should match the latest ID bugs in the database. Then I marked them all.

Within a few minutes, my mailbox looked like this:

image

My first thought when opening the Inbox was “Jackpot!”.

However, upon further consideration, there was nothing particularly interesting in these discussions. Apparently, I could only eavesdrop on discussions related to translation, where people discussed the best ways to convey the meaning of a phrase in different languages.

I even decided to wait a couple of hours and not send a message about the found vulnerability, hoping that I would find a way to increase the level of severity. In the end, I realized that the Google security team would probably be interested in finding possible pivot methods and options, so I sent the details.

Total: 5 hours | Reward: $ 5000 | Priority: P0

Vulnerability # 3: Game over


When you visit Tracker Issue as an external user, most of its functions are hidden, which leaves you with extremely limited privileges. If you want to see all the cool things that Google employees can do, you can find the end points of the API in JavaScript files. Some of these features are completely disabled, others are simply hidden in the interface.

When developing this limited version of the system, someone was good enough to leave us with the option to remove ourselves from the CCs list, in case we lose interest in the problem or no longer want to receive emails with information about it. This can be achieved by sending a POST request as follows:

 POST /action/issues/bulk_edit HTTP/1.1 { "issueIds":[ 67111111, 67111112 ], "actions":[ { "fieldName":"ccs", "value":"test@example.com", "actionType":"REMOVE" } ] } 

However, I noticed some shortcomings here that could lead to a huge problem:

  1. Incorrect access control : there was no explicit verification that the current user actually had access to the problems indicated in issueIds before attempting to perform this action.
  2. Silent failure : if you specified an email address that was not currently included in the CCs list, the endpoint will return a message that the email was successfully deleted.
  3. A detailed description of the problem in the answer : if during the action there were no errors, the other part of the system decided that the user has the appropriate access rights. Thus, every detail about this ID of the bug will be returned in the body of the HTTP response.

Now I can view the details of each problem in the database, replacing the issueIds in the query above. Bingo!

I tried to look at only a few consecutive IDs, and then attacked myself from an unlinked account to confirm the severity of the problem.

Yes, I could look at the details of the vulnerability reports, as well as everything else posted on Buganizer.

Worse, I could pull out data on several tickets in one request, so monitoring all internal activity in real time probably would not cause any speed limiters.

I quickly sent the details of the problem to Google, and their security team turned off the damaged endpoint after an hour. Impressive response time!

Result: 1 hour | Reward: $ 7,500 | Priority: P0

When I first started looking for information leaks, I assumed that this would be the holy grail of Google's bugs, because it reveals information about all other errors (for example, HackerOne pays at least $ 10,000 for something like that).

But, having discovered this, I quickly realized that the impact would be minimized, because all dangerous vulnerabilities would in any case be neutralized within an hour.

I am very pleased with the reward, and I intend to search for bugs in other products from Google.

Translation: Vyacheslav Bukatov

Source: https://habr.com/ru/post/341752/


All Articles