GitHub repositories have become something of a trending target for hackers as of late, as stolen source code offers them a multitude of possibilities. Popular collaboration tool Slack is the latest to suffer a security breach of this nature, with the company reporting that externally hosted private code repositories were hit in late December.
Slack says that the stolen code did not come from its primary code base and that customer information was not present, but that a “limited number” of employees were impacted. It also said that service would not be impacted, but thefts of code always leave natural concerns about what the attackers will find within it.
Slack GitHub repositories infiltrated via stolen employee tokens
Slack did not reveal exactly what the GitHub repositories contained, other than confirming that they were hosted externally and not used for the platform’s primary codebase or any sort of customer data.
It also said that the security breach did not stem from a “vulnerability inherent to Slack,” which raises a couple of possibilities. One is a breach of a third-party vendor or contractor. This may immediately cause Okta to spring to mind, given that the company suffered its own raid on internal GitHub repositories earlier in December. Okta and Slack have an integration feature, though Okta has said that the 0Auth token system that underpins it was not part of that security breach. 0Auth tokens were stolen in a direct April attack on Microsoft’s code sharing platform that involved the cloning of legitimate GitHub repositories, but thus far there are no concrete indications that any of these security breaches are related.
Despite assurances from Slack that the GitHub repositories did not contain anything that could negatively impact customers, the platform’s estimated 18 million users will likely want to pay attention to the story as potential untapped vulnerabilities can end up emerging when attackers comb through stolen code. In the past this has been as simple as finding employee authentication tokens buried in code, or even login credentials stored in plain text.
As Bleeping Computer points out, there is also some cause for concern in the way in which Slack is seemingly trying to downplay the incident and keep it out of the news as much as possible. The security breach reportedly took place on December 27, so the fact that Slack did not publicly disclose it until just before the New Year’s holiday is not necessarily suspicious. However, Slack has not published its security notification on its international blog (only a December 31 post on its United States blog) and has marked the page to prevent it from being indexed by search engines. Bleeping Computer notes that Slack also previously de-indexed the public notice for an August 2022 security breach in which it accidentally exposed password hashes for about 0.5% of its users.
Slack has taken some measures in response to the incident, however, including invalidating the stolen tokens that opened the doors to the GitHub repositories and rotating all relevant credentials. Customers have not been advised to do anything at this time.
Source code increasingly the focus of security breaches
Security experts have been sounding alarms about the generally lax handling of GitHub repositories for years now, but most companies have placed this item far down the priority list as understaffed IT teams deal with more immediate and lethal threats. This rash of security breaches indicates that it is now time for source code to receive better attention and protection.
The sort of source code commonly stashed in GitHub repositories offers hackers multiple tantalizing possibilities: the ability to sell it on the black market for big money, the possibility that vulnerabilities or login information will be discovered within it, and even the long-term possibility of inserting backdoors into code that is still in development. Attackers have definitely noticed that organizations tend to leave loose ends when it comes to GitHub repositories and are honing in on them; these weaknesses are often simple oversights such as failing to cancel the credentials of developers that have left or not locking down project configuration settings.
Another long-term issue with the security of GitHub repositories has been the fact that vulnerability reports in public repositories had to be made equally public, creating significant hesitance to report when issues were discovered. GitHub addressed this in late November with a new private reporting feature.
The incident also highlights the fact that companies often attempt to downplay security breaches with initial announcements, sometimes not making the full extent of damage clear until months later. Though Slack claims that customers were not impacted, at minimum a change of passwords is probably prudent given the company’s recent tendency to try to minimize the media exposure of such incidents.
Source: CPO Magazine
