GitHub waited 3 months to notify about potential compromise

217 pointszwass3y ago77 comments

It seems GitHub became aware of the issue around March 2 (or before, since the fix was released on March 2), and waited until June 16 to disclose the problem.

See full text below:

Hi zwass,

We're writing to let you know that between 2022-02-25 18:28 UTC and 2022-03-02 20:47 UTC, due to a bug, GitHub Apps were able to generate new scoped installation tokens with elevated permissions. You are an owner of an organization on GitHub with GitHub Apps installed that generated at least one new token during this time period. While we do not have evidence that this bug was maliciously exploited, with our available data, we are not able to determine if a token was generated with elevated permissions.

User privacy and security are essential for maintaining trust, and we want to remain as transparent as possible about events like these. GitHub itself did not experience a compromise or data breach that either created or resulted from this event. Read on for more information.

* What happened? *

GitHub learned via a customer support ticket that GitHub Apps were able to generate scoped installation tokens with elevated permissions. Each of these tokens are valid for up to 1 hour.

GitHub quickly fixed the issue and established that this bug was recently introduced, existing for approximately 5 days between 2022-02-25 18:28 UTC and 2022-03-02 20:47 UTC.

GitHub Apps generate scoped installation tokens based on the scopes and permissions granted when the GitHub App is installed into a user account or organization. For example, if a GitHub App requests and is granted read permission to issues during installation, the scoped installation token the App generates to function would have `issues:read` permission.

This bug would potentially allow the above installation to generate a token with `issues:write`, an elevation of permission from the granted `issues:read` permission. The bug did not allow a GitHub App to generate a token with additional scopes that were not already granted, such as `discussions:read` in the above example. The bug did not allow a GitHub App to access any repositories that the App did not already have access to.

In order to exploit this bug, the GitHub App author would need to modify their app's code to request elevated permissions on generated tokens.

* What information was involved? *

The following GitHub Apps generated scoped installation tokens during the bug window for your organization(s). We are not able to determine if a token was generated with elevated permissions.

Organization: GitHub Apps <redacted>

* What GitHub is doing *

GitHub immediately began working to fix the bug and started an investigation into the potential impact. However due to the scale and complexity of GitHub Apps and their short-lived tokens, we were unable to determine whether this bug was ever exploited.

We are notifying all organization and user account owners that had GitHub Apps installed and had a scoped installation token generated during the bug window so that they can stay informed and perform their own audit of their installed GitHub Apps.

As a followup to this investigation, GitHub is looking at ways to improve our logging to enable more in-depth analysis on scoped token generation and GitHub App permissions in the future.

* What was the potential impact? *

Due to the variety of GitHub Apps, their possible scopes, and the repositories they may have been given access to, we are unable to advise on any potential impacts as each customer's situation will be unique.

* What you can do *

While we have updated our systems to resolve this bug and no action is required on your end, we do recommend you review your installed GitHub Apps. You can use the following guidance for assessing GitHub Apps, their permissions, and their access to your private organization repositories:

https://docs.github.com/en/organizations/keeping-your-organization-secure

77 comments

cypherg3y ago

They explained it themselves - there's no evidence of abuse/exploitation. They literally have no legal requirement to even tell you as much as they did. You should be commending them for filling you in at all.

chrisseaton3y ago

> They literally have no legal requirement to even tell you as much as they did.

Is ‘fulfilling legal requirements’ all you look for in a business relationship?

A restaurant has no legal requirement to make this food tasty but it’s what I’m looking for when choosing where to go.

PradeetPatel3y ago

As someone who works in the reputation management sector, fulling legal requirements is crucial in establishing a presence in key markets. However, oversharing of internal information that's not required by legal requirements can lead to unnecessary reputation damage, which would lead to a decrease in value for key stakeholders.

I think many engineers often overlook the business implication of disclosing security issues, as it would impact multiple business units as well as the board's stance on security, resource allocation, and potentially the stock price too.

>A restaurant has no legal requirement to make this food tasty Food is a core deliverable for a restaurant, whereas information on a potential breach is not for a SaaS service unless it is legally required.

3 more replies

akagusu3y ago

Since almost every popular tech company is a quasi monopoly, they use this "fulfilling legal requirements" strategy to abuse the market providing overpriced services with bad quality.

Unfortunately, people got used to this practice and gladly accept when such companies fulfill all their legal obligations, even when this hurt them or their business.