Users of one of the leading business communication and collaboration platforms, Slack, have been warned that hackers have stolen several of its private source code repositories. At the same time, Slack insists the damage is minimal.
Slack revealed the incident on December 31. In an effort to avoid drawing too much attention, businesses frequently announce data breaches just before or around big holidays.
Slack, however, claimed to have been aware of the questionable activity on December 29, so it may have simply wanted to alert customers to the situation as soon as possible.
Employee Tokens Stolen And Used To Gain Access
Investigation results indicated that on December 27, the intruders downloaded private code repositories. The hackers could use stolen employee tokens to access the company’s externally hosted GitHub repository. A “small number” of employees, the corporation claimed, were affected.
Consumer data or data that may be utilized to obtain customer data was not included in the affected repositories. Additionally, according to the business, they lacked the core codebase of Slack.
Our current research demonstrates that the threat actor did not get access to other parts of Slack’s environment, such as the production environment, or other Slack resources or customer data. We have also rotated all relevant credentials as a precaution, and there was no effect on our code or services, according to Slack.
Based on the information that is now available, Slack’s vulnerability was not the cause of the unauthorized access; it was added. We will keep looking into it and watching for more exposure.
Slack made its announcement about the theft of some of its source code from its GitHub repositories around a week after Okta, a provider of identity and access management systems did the same. It’s not apparent whether the instances are connected.
This year, there have been a number of source code-related security problems. The private repositories of dozens of organizations were downloaded using stolen OAuth tokens given to Heroku and Travis CI, according to GitHub’s April report. That attack, according to GitHub, was very focused.
Best Practices For Protecting API Keys
The following are best practices to observe in protecting API keys.
- Implementing an API key management program:
This can help reduce some of the dangers described above, which is a crucial step in ensuring API keys are protected. For instance, giving API keys expiration dates can lessen the impact of finding a hard-coded API key. In the event of a hack or breach, key management would enable a company to invalidate the API keys instantly.
- API keys that limit rates:
The API service is maintained in good condition by a rate-limiting and monitoring system that maintains the API keys safe. If an attacker is successful in getting beyond your encrypted authentication and authorization procedures, rate limiting prevents your API from becoming overloaded. For instance, a user’s unusually high volume of requests might be a sign of malicious activity, such as a denial-of-service attack.
- User authentication:
You must be aware of who is using your API in order to provide the most basic level of defense against attackers. Users must therefore register by receiving API keys. You may manage who uses your API by giving out API keys to impose basic authentication. You can watch over and identify who is making API requests, thanks to it.
- Develop secure API code techniques for developers:
Because they frequently comprise the desired function and the payload/content, which may include sensitive data and access to API keys, APIs operate somewhat differently than conventional applications. It’s essential that developers have the training they need to recognize these minute variations and take them into consideration when writing their code.
- Adopt a framework for API specification:
Adopting an API design framework like OpenAPI will support efforts to train developers. This makes ensuring that the API is written in accordance with the given specifications, including how API keys are handled and used. Additional advantages of specification frameworks include increased security overall, consistency, and quality.
An organization cannot ensure the security of its API keys with a single action. It takes teamwork from the security team, application owners, and developers to improve your API key protection posture.
Conclusion
Slack received notification of questionable activity on their GitHub account on December 29, 2022. Following an inquiry, the business learned that a small number of employee tokens had been taken and misused to access a hosted external repository. On December 27, the threat actor also downloaded private code repositories, although neither the main codebase for Slack nor any client data were contained in those downloads. Slack is an instant messaging program for organizational communication. It has more than 10 million daily active users.
“There are two things to consider in the breach, the stolen repositories, and tokens. They have different impacts on Slack and its users. Experienced threat actors can and will use the source code stolen to their advantage, from creating exploits that could impact Slack users and infrastructure. Also, with the stolen Github Tokens, they could have inserted malicious commits in the repositories or created a way to persist access (using GitHub Actions, for example).
From an external perspective and taking into consideration that we do not know the full extent of measures that Slack took to mitigate the security incident, we need to be cautious.
Slack announced that all tokens were revoked, but this action only represents part of the problem. Since the code was not leaked, the threat actor may be planning other attacks against slack, which we will not be aware of until they happen. Since slack was not transparent from the beginning and took measures to hide the breach, as is mentioned in the Bleeping Computer post, the worst possible situation needs to be signalled. From potential malicious code inserted into the repositories to the possibility of the threat actors controlling the pipelines. It is a very pessimistic view of the incident, but when talking about security we need to outline the worst-case scenarios.”
“The recent incident impacting data of people who applied to work at the Five Guys restaurant chain is a stark reminder of the personal cost behind the vulnerability of businesses to increasingly intricate and threatening cyber attacks.
While all parts of a business can hold highly sensitive and personal information, HR departments, in particular, are a treasure trove of current and prospective employee data and must work hard to ensure it remains secure.
We know all too well that once this information is exposed, it can lead to further cyber-attacks, or it could be used for extremely targeted social engineering attacks on those involved. In this instance, thousands of jobseekers had their personal data compromised, rendering them susceptible to follow-on attacks and recruitment scams in the future.
The key lesson for businesses that hold private information is that they must have clearly defined security policies and procedures to increase their cyber resilience. It is also crucial that staff are properly trained in data protection strategies. Security awareness training programmes can now educate employees on the latest threats in real time, including information security, social engineering, malware, and industry-specific compliance topics. Attack simulations can also be used to automatically send users for re-education should any training issues be identified.”
“Based on the information available, it looks like employee access tokens were compromised, which granted an attacker with a way to log into Slack’s GitHub account and access code repositories.
It fortunately looks like customer information wasn’t impacted in this particular incident, but rotating credentials as a response to the breach will not prevent future breaches which could have a larger impact.
These incidences happen every day because organisations let employees make their own keys – i.e. credentials – to access corporate assets. That root error means those credentials can be shared, sold or phished. Meanwhile credentials are also often weak, reused and rotated, making them easy to guess or brute force.
This vulnerability is completely avoidable if organisations manage and encrypt all employee login details for every system. When credentials are encrypted, employees do not know them, therefore they can’t be stolen or phished. Having segmented encrypted access is therefore the most effective way to prevent criminals from not just stealing login credentials but also moving laterally across the network from there.”