6 ms·

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 GitH

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. Internal bad actors? So location wouldn't matter?

verdverm 4y ago
If you read the details... > 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.
- throwaway010523 4y ago
  Wouldn't private git hosting add another barrier for the attackers? In addition to the tokens, they would also need to somehow gain access to the network through VPN or through an opening in the firewall?
  - hardware2win 4y ago
    Github repos can require using company's vpn
  - trollied 4y ago
    Yes. By way of example, my employer does this: * gitlab hosted internally * VPN needed to access gitlab * VPN requires a gsuite login, with 2FA * You can only login to a gsuite account on a employer-provided machine (so no access to anything on a non-employer machine, even email) You'd have to steal a company laptop, or social engineer yourself into a building with a desktop machine, to even start to get near the code repository. The "must login from a employer-provided machine" thing can be disabled on a per-user basis by remote policy (via an administrator), if needed.
    - tcmb 4y ago
      > You can only login to a gsuite account on a employer-provided machine How is this achieved?
      - trollied 4y ago
        There's an Endpoint Verification plugin that integrates with gsuite.
- KingOfCoders 4y ago
  Would a hardware token have prevented this (noob question)?
  - dijit 4y ago
    It's a fair question, but likely not. There are "application credentials" or "API tokens" that get generated for various purposes and live long. There are many programs that do not support "credential helpers", abd those would need you to input an API token that is generated usually just once and has almost always has enough permission to clone a repository (at a minimum). The `hub` and `lab` CLI tools work exactly in this manner. If you are familiar with intellij: certain plugins that integrate with github or gitlab also require the generation of an access token so that you can do API calls to see merge requests and such: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token https://docs.github.com/en/authentication/keeping-your-accou... & https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html https://docs.gitlab.com/ee/user/profile/personal_access_toke... Applications that support credential helpers are docker (for optionally authenticating with docker registries) and git itself.
    - KingOfCoders 4y ago
      I thought "Maybe" because it mentioned "Slack employee tokens".
  - jchw 4y ago
    Is it possible for a hardware token to prevent this in theory? You could use a hardware token to compute challenge-response answers without having external access to the private key matter, as opposed to using simple secret API keys like we do today. This is basically how an HSM works too. But does it solve the problem? It prevents the keymatter from leaking, but the problem is that the API key was put somewhere sensitive and then stolen. Presumably you'd need access to be able to use the keymatter from any location where you'd normally need API keys: CI machines, developer workstations, production, etc. Worse, if you have some machines (CI, HSM) that are accessed over network traffic and that traffic is secured with an API key, you are back to square one again, where a stolen API key allows for continuous access. Would this help for auditing? No, not really. You can already have plenty of auditing and alerting to try to prevent exfiltration anywhere an API key is used. In other words, probably not. It might help a little bit just by making exploitation harder, in optimal circumstances, but it doesn't fundamentally change the problem; if dev workstations or CI are compromised, you're going to have a bad time.
cj 4y ago
> 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.
- lrvick 4y ago
  > there are ways to use Windows (and Github) securely. No proprietary software you have no control over or ability to audit can ever be considered secure.
  - ElevenLathe 4y ago
    It depends, as always, on the threat model you are trying to defend against.
    - lrvick 4y ago
      If you give a third party essentially limitless access to execute arbitrary code on your hardware, then you cannot really assert anything with certainty about that machine. That makes meeting most/all threat models difficult.
      - ElevenLathe 4y ago
        I get what you're saying but if my threat model doesn't include Microsoft or state-level actors that can co-opt Microsoft or buy/develop hoarded Windows zero-days, then a patched Windows box is probably good enough.
  - intelVISA 4y ago
    Fuzzing any 'enterprise' SaaS is a frightful experience.
jerf 4y ago
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.

verdverm 4y ago

If you read the details... > 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.

throwaway010523 4y ago
Wouldn't private git hosting add another barrier for the attackers? In addition to the tokens, they would also need to somehow gain access to the network through VPN or through an opening in the firewall?
- hardware2win 4y ago
  Github repos can require using company's vpn
- trollied 4y ago
  Yes. By way of example, my employer does this: * gitlab hosted internally * VPN needed to access gitlab * VPN requires a gsuite login, with 2FA * You can only login to a gsuite account on a employer-provided machine (so no access to anything on a non-employer machine, even email) You'd have to steal a company laptop, or social engineer yourself into a building with a desktop machine, to even start to get near the code repository. The "must login from a employer-provided machine" thing can be disabled on a per-user basis by remote policy (via an administrator), if needed.
  - tcmb 4y ago
    > You can only login to a gsuite account on a employer-provided machine How is this achieved?
    - trollied 4y ago
      There's an Endpoint Verification plugin that integrates with gsuite.
KingOfCoders 4y ago
Would a hardware token have prevented this (noob question)?
- dijit 4y ago
  It's a fair question, but likely not. There are "application credentials" or "API tokens" that get generated for various purposes and live long. There are many programs that do not support "credential helpers", abd those would need you to input an API token that is generated usually just once and has almost always has enough permission to clone a repository (at a minimum). The `hub` and `lab` CLI tools work exactly in this manner. If you are familiar with intellij: certain plugins that integrate with github or gitlab also require the generation of an access token so that you can do API calls to see merge requests and such: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token https://docs.github.com/en/authentication/keeping-your-accou... & https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html https://docs.gitlab.com/ee/user/profile/personal_access_toke... Applications that support credential helpers are docker (for optionally authenticating with docker registries) and git itself.
  - KingOfCoders 4y ago
    I thought "Maybe" because it mentioned "Slack employee tokens".
- jchw 4y ago
  Is it possible for a hardware token to prevent this in theory? You could use a hardware token to compute challenge-response answers without having external access to the private key matter, as opposed to using simple secret API keys like we do today. This is basically how an HSM works too. But does it solve the problem? It prevents the keymatter from leaking, but the problem is that the API key was put somewhere sensitive and then stolen. Presumably you'd need access to be able to use the keymatter from any location where you'd normally need API keys: CI machines, developer workstations, production, etc. Worse, if you have some machines (CI, HSM) that are accessed over network traffic and that traffic is secured with an API key, you are back to square one again, where a stolen API key allows for continuous access. Would this help for auditing? No, not really. You can already have plenty of auditing and alerting to try to prevent exfiltration anywhere an API key is used. In other words, probably not. It might help a little bit just by making exploitation harder, in optimal circumstances, but it doesn't fundamentally change the problem; if dev workstations or CI are compromised, you're going to have a bad time.

cj 4y ago

> 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.

lrvick 4y ago
> there are ways to use Windows (and Github) securely. No proprietary software you have no control over or ability to audit can ever be considered secure.
- ElevenLathe 4y ago
  It depends, as always, on the threat model you are trying to defend against.
  - lrvick 4y ago
    If you give a third party essentially limitless access to execute arbitrary code on your hardware, then you cannot really assert anything with certainty about that machine. That makes meeting most/all threat models difficult.
    - ElevenLathe 4y ago
      I get what you're saying but if my threat model doesn't include Microsoft or state-level actors that can co-opt Microsoft or buy/develop hoarded Windows zero-days, then a patched Windows box is probably good enough.
- intelVISA 4y ago
  Fuzzing any 'enterprise' SaaS is a frightful experience.

jerf 4y ago

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.