linkedin Skip to Main Content
Categories

Heroku-GitHub Breach Highlights Integration Risks (Plus Our CSO’s Advice)

Development

Here we go again.

As if worrying about Heartbleed and Log4Shell vulnerabilities was not enough, some companies have found that they may have had a breach of their private repository data hosted on GitHub.

In a move that’s still under investigation, hackers were able to steal OAuth user tokens from the Heroku Dashboard and Travis CI Github integrations in what Travis CI suspects was a  man-in-the-middle 2-factor authentication (2FA) attack

In these types of attacks, malicious actors spoof the target website and are able to intercept the 2FA information and then pass it on to the actual target website to gain access to the victim’s account.

Once the hackers could access the OAuth tokens from Heroku and Travis CI for GitHub, they used them to download the repository contents of select victims. GitHub believes that the hackers’ ultimate goal is to mine for secrets and credentials in repositories in order to pivot into other infrastructures.

GitHub does not believe the breach happened through them as they do not store the tokens for those integrations. However, they quickly disclosed this breach to Heroku (owned by SalesForce) and Travis CI. 

All three entities have since revoked all tokens and auth keys associated with their integrations with one another (i.e., GitHub-Heroku and GitHub-Travis CI) to prevent further intrusions into GitHub repos. Additionally, Salesforce has disabled the compromised user’s GitHub account and OAuth tokens.

Both Heroku and GitHub continue to notify users who may have been affected by the breach. So far, only specific GitHub repos have been breached – including NPM’s – and there are no signs that user accounts in Travis CI or Heroku have been compromised.

GitHub was able to mitigate a lot of the damage by having great security practices, which just goes to show you that even great security won’t always prevent a breach. Here’s what GitHub’s recommending for their users – as well as some risk management advice from our own Chief Security Officer.

Precautions GitHub users should take

GitHub is taking active measures to reach out to affected users. Still, they’re also recommending a couple of practices to maintain a more robust security posture in the future – these are always good practices for any company that uses GitHub:

  1. Review the OAuth apps that are authorized to access your organization’s applications or private repositories and make sure they are both needed and are scoped to only access the data they need to access.
  2. Review your organization’s audit logs and user account security logs for suspicious activity
  3. Review current repos for credentials or secrets that may be stored in them. You can use GitHub’s secret scanning to assist with this.

Both GitHub and Heroku are asking users who notice suspicious behavior in their accounts to notify them as soon as possible to assist in their investigation into the hack.

How to mitigate third-party integration risks

The fact is, we won’t know what went wrong here for quite some time. Both GitHub and SalesForce/Heroku have sizable security budgets, which shows you that something like this could happen to just about anyone.

That doesn’t mean you can’t take steps to reduce and mitigate attacks like these – in fact, this attack may have been much worse without the actions that GitHub and Heroku already had in place.

CoderPad’s Chief Security Officer Frédéric Thirard has some tips on what you can do to reduce risk in your organization.

Define your level of risk

Before working with a third party, you should define the level of risk involved in doing the integration.

Is it with a brand new health tech start-up that requires access to your customer’s Protected Health Information (PHI)?

Or is it with a conservative hundred-year-old insurance company that wants to implement a chat function in your app?

The level of risk will depend on what kind of information you’re sharing with them, what services and resources they will have access to, and their existing protocols for what happens if they have a security incident with your data or services.

Evaluate third-party security measures

You should be doing due diligence on the security measures of your integration partners when you first integrate with them, but you’ll also want to revisit them on an annual basis.

It’s crucial to develop your own set of security requirements that an integration partner should adhere to that match the risk level of the integration. You can quickly tell if the integration will meet your security standards when you do your evaluation.

The evaluation itself can be done in multiple ways:

  • Traditional security questionnaires
  • Verifying security compliance certification (be sure to check the scope matches your usage)
  • Get copies of their most recent penetration test results
  • Use a cyber-rating service to give you a quick insight into a company’s security practices

You’ll want to choose the method(s) that work best for you. Combining approaches will give you more confidence and coverage than using one alone.

Ensure breaches are communicated quickly

In the case of any breach, make sure that paths are in place both for you to easily and quickly communicate to the vendor and for the vendor to communicate with you. 

Make sure that the contact information for your incident response team is up-to-date in their system and vice versa.

Additionally, you should subscribe to the partner’s information channels and social media networks, as incident information will often be published here first.

Have an incident management process in place

Perhaps the most important thing you can do is plan an incident management response before a hack occurs.

No one expects to be breached, yet it happens repeatedly. The companies that respond to incidents successfully and minimize the damage done have their incident response policy in place well before the incident occurs.

It’s also essential to test your processes regularly so that 1) everyone involved knows what to do and 2) you know that your plan works when a breach does happen.

An ounce of prevention is worth something something

It’s cliche, but an ounce of prevention really IS worth a pound of cure. As mentioned earlier, the reason we didn’t see a more significant breach with GitHub and Heroku is precisely because they had processes in place for responding to security issues.

Now is not the time to be complacent with your company’s security – take the steps today to prevent disaster in the future.