If you don't communicate, you lose the narrative. As the article highlights, it seems Slack has gone out of its way to exclude this incident report from appearing in Google searches. As a result this article will likely appear first.
It is also worth nothing that other major breaches (LastPass) were preceded by source code breaches. The corresponding incident reports also included re-assurances that there was no impact on customer safety. The Slack incident report doesn't specify what type of Github repos were accessed, so it is hard to judge if any sensitive code has been leaked.
From the recent LastPass security incident report:
Based on our investigation to date, we have learned that an unknown threat actor accessed a cloud-based storage environment leveraging information obtained from the incident we previously disclosed in August of 2022 (source code breach)
The article did mention that this breach did not include the “primary codebase”. Where is the rest of the code hosted? I’m guessing some private Git server (e.g. “on-prem” GitHub/GitLab Enterprise)?
This is how LastPass started the efficient downward spiral, no? This isn't shocking, but also is.
Is it wise to simply keep private repositories away from GitHub at this point? It seems the best way to avoid being drawn in with the rest as a target.
> Is it wise to simply keep private repositories away from GitHub at this point?
This sounds like the equivalent of "Use MacOS because most viruses target Windows". Which some people do, and yes it probably lowers your risk, but there are ways to use Windows (and Github) securely.
If you're really paranoid about your source code, you should probably self-host your own instance of Github/Gitlab/etc (and lock it down through VPNs, IP white lists, etc) rather than using their cloud service.
This approach also gives you first hand access to logs that would expose internal bad actors, if that's included in your threat model.
> The incident involves threat actors gaining access to Slack's externally hosted GitHub repositories via a "limited" number of Slack employee tokens that were stolen.
> While some of Slack's private code repositories were breached, Slack’s primary codebase and customer data remains unaffected, according to the company.
The most basic way to analyze security is to look at it in terms of cost to penetrate security versus the benefit to the attacker. Things are not a binary "secure" or "not secure", they are secure when the expected costs are greater than the benefits, preferably by a comfortable margin.
The problem is that there are some resources where the benefit to the attacker goes up faster than the company can afford to cover, and the company has to cover all the attack avenues. You can imagine that the value of Slack's source code can be high to certain people, and it can be difficult to completely seal off something like that when source code by its nature pretty much has to be distributed to hundreds or thousands of people. (At least overall; any given source may not be that distributed, but there will be thousands with some sort of access.)
Major corporations basically have to act as if source compromise is inevitable. Best practices obviously include partitioning who can have access to what (perhaps the best practical argument against a one-company mono-repo, if de facto it has to be broken up by access permissions anyhow) and not including anything in the repo that is directly security catastrophic if it gets out (security secrets mostly), but this is still limiting blast radius rather than "solving" the problem.
It's a perfect storm of being extremely expensive to cover, in terms of money, internal process friction, and having a lot of heterogeneous vectors you need to cover, and for certain companies, being very high value to a number of different kinds of entities.
Being in GitHub specifically would only matter if GitHub was itself compromised. GitHub can not do very much about legit credentials being stolen through completely non-GitHub related means. (Most things, if not all things, that might leap to your mind will also block legitimate usage quite a bit. No matter what crazy thing you can imagine, someone's probably doing it somewhere and it's probably mission critical.)
I expect there have been a great deal more source code compromises than we've heard about.
Does it actually matter? I might be overlooking something but...
Slack is more than its code. The product is really the aggregate of their engineer's knowledge and internal processes. It's not practical to steal code and build a business or spinoff product around it.
The only legitimate threat seems to be the potential for exploitation. I suppose this might also threaten any backend improvements (economic leverage) they made with proprietary algorithms.
I wish, but teams is bad not because Microsoft isn't capable of fixing it.
It is bad because regardless of how infuriating and frustrating the user experience is, people are still gonna be forced to use it under the massive pressure of Microsofts weight.
I neither expect it nor hope so.
I still remember when they bought Skype. Said they'd keep the Linux support to stem community worries then dropped it like a brick about a year after.
This is exactly why secrets should not be stashed in any Git repository. Granted, I'm not sure they're much safer in other managed services dedicated to protecting our secrets, with the news of several breaches as of late :/
It would be so nice if GitHub deprecated their one key takes all and would let us create per-org personal access tokens. Also, organizations having power over these access tokens.
They do this now. I'll find a link. Link below. Organizations can choose to allow these, require approval before they are valid, and deny the use of traditional tokens.
Nope, its a bunch of little communities that are centrally managed and can force their users to a new platform easily. Network effects are minimal, sunk cost of integrations is a greater barrier to moving off platform but that is pretty weak as well.
We've migrated from Slack to Mattermost some time ago. Best decision ever. Not sure why companies keep using Slack nowadays. It's like those companies many years ago using HipChat instead of Slack. Slack's is the HipChat of today.
Could you expand? I think that's incredibly unfair... Slack changed how almost every business communicates. Mattermost is almost a 1:1 open source copy, and is missing most of the ecosystem (which is Slack's real value).
Sure, for some companies, it's really important to own their data completely. I get that (although I personally trust Salesforce more than most one-off companies when it comes to security). But I don't think it's fair to say that Slack is the HipChat of today at all... it's like iOS vs Android, both are just different flavors of a really good product.
I think part of the problem is that there are a lot of integrations from Slack that aren't available on Mattermost. You can certainly make the argument that those integrations won't be developed until more users abandon Slack for Mattermost, but for some it's not worth the loss of functionality.
Self-hosted Mattermost and Gitlab can be done reliably at very low cost, had better uptime than their cloud services for us and would've likely prevented leaks like these. At least you can add some layers of security for self-hosted services so that stolen tokens aren't enough to steal code or messages.
I hope github would start allowing all users to use ip whitelisting features. I understand it is a sell point for enterprise accounts, but tokens/passwords are not secure enough in today's environment.
They say no customer data was compromised and are investigating "potential impact" to customers.
The potential impact here is an attacker now has access to some of their code which could let them find and take advantage of vulnerabilities resulting in customer data being accessed.
Technically "potential impact" is correct but I think companies often underplay how severe a source code leak is. It's the exact blueprint of how their app is built.
[+] [-] openplatypus|3 years ago|reply
Slack is selectively and deliberately limiting public access (discoverability) to the security breach announcements.
[+] [-] muglug|3 years ago|reply
As far as I can tell, Slack's not trying to hide this news.
Slack communicated about the breach here: https://slack.com/blog/news/slack-security-update
There is no `noindex` tag on that page (check the source).
There is a `noindex` tag on an alternate "en-gb" version of that page: https://slack.com/intl/en-gb/blog/news/slack-security-update
This is to be expected — it's presumably SEO equivalent to specifying a canonical URL.
[+] [-] bradhe|3 years ago|reply
[+] [-] have_faith|3 years ago|reply
How do they even provide a plausible excuse for this? very bad look.
[+] [-] captn3m0|3 years ago|reply
1. Slack
2. Okta (https://news.ycombinator.com/item?id=34081154)
3. Coa (https://github.com/veged/coa/issues/99#issuecomment-96169688...)
[+] [-] dijit|3 years ago|reply
[0]: https://circleci.com/blog/january-4-2023-security-alert/
[+] [-] wut42|3 years ago|reply
I can see someone working at Slack try a nightly, they surely work with ML.
[+] [-] swyx|3 years ago|reply
[+] [-] muglug|3 years ago|reply
IMO the headline should be updated — much less than 1% of Slack’s private code can be accessed via github.com.
[+] [-] oxfordmale|3 years ago|reply
It is also worth nothing that other major breaches (LastPass) were preceded by source code breaches. The corresponding incident reports also included re-assurances that there was no impact on customer safety. The Slack incident report doesn't specify what type of Github repos were accessed, so it is hard to judge if any sensitive code has been leaked.
From the recent LastPass security incident report:
Based on our investigation to date, we have learned that an unknown threat actor accessed a cloud-based storage environment leveraging information obtained from the incident we previously disclosed in August of 2022 (source code breach)
[+] [-] jbotdev|3 years ago|reply
[+] [-] photoGrant|3 years ago|reply
Is it wise to simply keep private repositories away from GitHub at this point? It seems the best way to avoid being drawn in with the rest as a target.
Internal bad actors? So location wouldn't matter?
[+] [-] cj|3 years ago|reply
This sounds like the equivalent of "Use MacOS because most viruses target Windows". Which some people do, and yes it probably lowers your risk, but there are ways to use Windows (and Github) securely.
If you're really paranoid about your source code, you should probably self-host your own instance of Github/Gitlab/etc (and lock it down through VPNs, IP white lists, etc) rather than using their cloud service.
This approach also gives you first hand access to logs that would expose internal bad actors, if that's included in your threat model.
[+] [-] verdverm|3 years ago|reply
> The incident involves threat actors gaining access to Slack's externally hosted GitHub repositories via a "limited" number of Slack employee tokens that were stolen.
> While some of Slack's private code repositories were breached, Slack’s primary codebase and customer data remains unaffected, according to the company.
[+] [-] jerf|3 years ago|reply
The problem is that there are some resources where the benefit to the attacker goes up faster than the company can afford to cover, and the company has to cover all the attack avenues. You can imagine that the value of Slack's source code can be high to certain people, and it can be difficult to completely seal off something like that when source code by its nature pretty much has to be distributed to hundreds or thousands of people. (At least overall; any given source may not be that distributed, but there will be thousands with some sort of access.)
Major corporations basically have to act as if source compromise is inevitable. Best practices obviously include partitioning who can have access to what (perhaps the best practical argument against a one-company mono-repo, if de facto it has to be broken up by access permissions anyhow) and not including anything in the repo that is directly security catastrophic if it gets out (security secrets mostly), but this is still limiting blast radius rather than "solving" the problem.
It's a perfect storm of being extremely expensive to cover, in terms of money, internal process friction, and having a lot of heterogeneous vectors you need to cover, and for certain companies, being very high value to a number of different kinds of entities.
Being in GitHub specifically would only matter if GitHub was itself compromised. GitHub can not do very much about legit credentials being stolen through completely non-GitHub related means. (Most things, if not all things, that might leap to your mind will also block legitimate usage quite a bit. No matter what crazy thing you can imagine, someone's probably doing it somewhere and it's probably mission critical.)
I expect there have been a great deal more source code compromises than we've heard about.
[+] [-] shanebellone|3 years ago|reply
Slack is more than its code. The product is really the aggregate of their engineer's knowledge and internal processes. It's not practical to steal code and build a business or spinoff product around it.
The only legitimate threat seems to be the potential for exploitation. I suppose this might also threaten any backend improvements (economic leverage) they made with proprietary algorithms.
[+] [-] nightpool|3 years ago|reply
[+] [-] BoardsOfCanada|3 years ago|reply
[+] [-] gchamonlive|3 years ago|reply
It is bad because regardless of how infuriating and frustrating the user experience is, people are still gonna be forced to use it under the massive pressure of Microsofts weight.
[+] [-] modo_mario|3 years ago|reply
[+] [-] blackoil|3 years ago|reply
[+] [-] schnable|3 years ago|reply
[+] [-] bjd2385|3 years ago|reply
[+] [-] janosdebugs|3 years ago|reply
[+] [-] CubsFan1060|3 years ago|reply
They are actually per repo.
https://github.blog/2022-10-18-introducing-fine-grained-pers...
[+] [-] j45|3 years ago|reply
The cloud remains someone else’s shared computer.
[+] [-] rvz|3 years ago|reply
A great time to self-host.
[0] https://news.ycombinator.com/item?id=34232347
[1] https://news.ycombinator.com/item?id=23102942
[+] [-] ianpurton|3 years ago|reply
[+] [-] ltbarcly3|3 years ago|reply
[+] [-] vaseem|3 years ago|reply
More in this podcast https://darknetdiaries.com/episode/19/
[+] [-] danwee|3 years ago|reply
[+] [-] gkoberger|3 years ago|reply
Sure, for some companies, it's really important to own their data completely. I get that (although I personally trust Salesforce more than most one-off companies when it comes to security). But I don't think it's fair to say that Slack is the HipChat of today at all... it's like iOS vs Android, both are just different flavors of a really good product.
[+] [-] michaelmior|3 years ago|reply
[+] [-] dx034|3 years ago|reply
[+] [-] tourist2d|3 years ago|reply
[+] [-] halukakin|3 years ago|reply
[+] [-] blkhp19|3 years ago|reply
[+] [-] nickjj|3 years ago|reply
The potential impact here is an attacker now has access to some of their code which could let them find and take advantage of vulnerabilities resulting in customer data being accessed.
Technically "potential impact" is correct but I think companies often underplay how severe a source code leak is. It's the exact blueprint of how their app is built.
[+] [-] moonchrome|3 years ago|reply
[+] [-] Suvitruf|3 years ago|reply
[+] [-] umanwizard|3 years ago|reply
[+] [-] marban|3 years ago|reply
[+] [-] realworldperson|3 years ago|reply
[deleted]
[+] [-] tedk-42|3 years ago|reply