Heroku admits customer credentials were stolen in cyberattack

Heroku

Heroku has now revealed that stolen GitHub integration OAuth tokens from last month further led to the compromise of an internal customer database.

The Salesforce-owned cloud platform has acknowledged that the same compromised token was used by attackers to exfiltrate customers’ hashed and salted passwords from a “database”.

Heroku’s update comes after BleepingComputer contacted Salesforce yesterday.

Like many users, we unexpectedly received a password reset email from Heroku, even though BleepingComputer has no OAuth integration that uses the Heroku apps or GitHub. This indicated that these password resets were related to another issue.

Heroku Explains Forced Password Resets

This week, Heroku began performing forced password resets for a subset of its user accounts after last month’s security incident. without explaining why.

On Tuesday evening, some Heroku users received emails titled “Heroku Security Notice – User Account Passwords Reset May 4, 2022”, notifying users that their account passwords were in progress. reset in response to the security incident. The reset would also invalidate all API access tokens and require users to generate new ones, the email explained.

But, the original security incident being referred involved threat actors stealing OAuth tokens issued for Heroku and Travis-CI and misusing it to download data from private GitHub repositories owned by dozens of organizations, including npm.

“On April 12, GitHub Security opened an investigation that uncovered evidence that an attacker misused stolen OAuth user tokens issued to two third-party OAuth integrators, Heroku and Travis-CI, to download data from dozens of organizations, including npm,” GitHub had said. previously disclosed.

These tokens had previously been used by Travis-CI and Heroku OAuth apps to integrate with GitHub to deploy apps.

By stealing these OAuth tokens, threat actors could access and download data from GitHub repositories belonging to those who authorized compromised Heroku or Travis CI OAuth applications with their accounts. Note that GitHub infrastructure, systems, or private repositories themselves were not affected by the incident.

But that still didn’t explain why Heroku would need to reset some user account passwords, until now.

It turns out that the compromised token of a Heroku machine account obtained by hackers also allowed unauthorized access to Heroku’s internal customer account database:

“Our investigation also revealed that the same compromised token was used to access a database and exfiltrate hashed and salted passwords from customer user accounts,” Heroku explains in a post. updated security notification.

“For this reason, Salesforce ensures that all Heroku user passwords are reset and potentially affected credentials are refreshed. We have rotated internal Heroku credentials and implemented detections We are continuing to investigate the source of the token compromise.”

A YCombinator Hacker News reader alleged that the “database” referred to might be what used to be called “core-db”.

The drive in question is Craig Kerstiens of the PostgreSQL CrunchyData platform, which has formerly affiliated with Heroku.

“The latest report talks about ‘a database’ which is presumably the internal database,” says Kerstiens.

“I don’t want to speculate too much, but it seems [the attacker] had access to internal systems. It was GitHub that detected and noticed it and reported it to Heroku. Don’t argue that there should be more clarity, but it’s best to follow up with Salesforce on this.”

BleepingComputer has contacted Kerstiens who confirmed having written these comments.

Customers call vague disclosure a ‘train wreck’

Heroku’s initial disclosure of the security incident said the unauthorized access had been linked to GitHub repositories owned by accounts that used Heroku’s compromised OAuth tokens.

“Compromised tokens could provide the threat actor with access to customers’ GitHub repositories, but not to customers’ Heroku accounts,” the company previously said.

But the password reset emails rightly raised concerns among customers that Heroku’s investigation may have uncovered other malicious threat actor activity that was not disclosed.

Some YCombinator Hacker News Readers double the disclosure “a complete train wreck and a case study of how not to communicate with your customers.”

In his quest to be more transparent with the community, Heroku shed some light on the incident, which started a few hours ago.

“We appreciate the transparency and understand that our customers are looking for a deeper understanding of the impact of this incident and our response to date,” Heroku said.

The cloud platform further said that after working with GitHub, threat intelligence providers, industry partners and law enforcement during the investigation, it has reached a point. where more information could be shared without compromising the ongoing investigation:

“On April 7, 2022, a threat actor gained access to a Heroku database and downloaded stored client GitHub integration OAuth tokens. Access to the environment was gained by exploiting a compromised token for a Heroku machine account.According to GitHub, the threat actor began listing metadata on client repositories with uploaded OAuth tokens on April 8, 2022. On April 9, 2022, the attacker uploaded a subset of the Heroku private GitHub repositories from GitHub, containing Heroku source code.

GitHub identified the activity on April 12, 2022 and notified Salesforce on April 13, 2022, when we began our investigation. As a result, on April 16, 2022, we revoked all GitHub integration OAuth tokens, preventing customers from deploying apps from GitHub through the Heroku dashboard or through automation. We remain committed to ensuring the integration is secure before re-enabling this feature.”

In contrast, another third-party integrator, Travis-CI, revealed the next business day following GitHub’s announcement original notice that no customer data was impacted by the incident.

Heroku users are advised to continue monitoring the security notification page for updates related to the incident.

Update, May 5, 2022 9:30 a.m. ET: We have confirmed that the reader quoted in the article is indeed Kerstiens.

Leave a Comment