10 ms·

It’s called GitHub secrets. Builds off of main get the secrets, pull requests from randos don’t. And public repos don’t pay for CI on GitHub. Not rocket scie

by trevyn 3y ago

It’s called GitHub secrets. Builds off of main get the secrets, pull requests from randos don’t. And public repos don’t pay for CI on GitHub. Not rocket science, people.

n2d4 3y ago
Pytorch did use GH secrets for the valuables and you can see that this wasn't enough, right there in the OP, because the self-hosted runners are still shared
- adnanthekhan 3y ago
  Yup! This is what makes this kind of attack scary and very unique to GitHub Actions. The baseline GITHUB_TOKEN just blows the door open on lateral movement via workflow_dispatch and and repository_dispatch events. In several of our other operations, not just PyTorch, we leveraged workflow_dispatch to steal a PAT from another workflows. Developers tend to over-provision PATs so often. More often than not we'd end up with a PAT that has all scopes checked and org admin permissions. With that one could clean out all of the secrets from an organization in minutes using automated tools such as https://github.com/praetorian-inc/gato https://github.com/praetorian-inc/gato.
  - trevyn 3y ago
    To clarify, this secret stealing is not an issue with GitHub-hosted runners, correct?
    - adnanthekhan 3y ago
      Correct. For fork PR workflows on the pull_request trigger the GITHUB_TOKEN has read only permissions, so you can’t do anything with it. The key thing with a non-ephemeral runner is that (after obtaining persistence) you can grab the GITHUB_TOKEN from a subsequent non-fork PR build or a build on another trigger, which will have write permissions unless restricted by the repository maintainers.
- lmeyerov 3y ago
  I think 'environments' was meant, where diff GHA environments get diff secrets, and policies dictate who gets to run what actions with what envs. But that is real work to setup, audit, and maintain. It'd be better if, like phone app capabilities, the default would be no privs, any privs are explicitly granted, and if they aren't being used, the system detects that and asks if you want to remove specific ones.
- gabriel-samfia 3y ago
  Ouch! This is why ephemeral runners should be used. Preferably virtual machines. On an infrastructure that can define security group rules to prevent lateral movement.
mlazos 3y ago
If they use the same runners, couldn’t the attacker just wait? The runners would need to be sequestered too
- kevin_nisbet 3y ago
  Absolutely. The real difficulty is tests on PR are by definition remote code execution by an untrusted source, so a full risk analysis and hardening needs to be done. Here's a similar mistake on an OSS repo a company I worked for made: https://goteleport.com/blog/hack-via-pull-request/ https://goteleport.com/blog/hack-via-pull-request/
LtWorf 3y ago
> Not rocket science, people. The smugness and overconfidence of someone who's about to be pwned?
- trevyn 3y ago
  Pwn me.

by trevyn 3y ago

It’s called GitHub secrets. Builds off of main get the secrets, pull requests from randos don’t. And public repos don’t pay for CI on GitHub. Not rocket science, people.

n2d4 3y ago

Pytorch did use GH secrets for the valuables and you can see that this wasn't enough, right there in the OP, because the self-hosted runners are still shared

adnanthekhan 3y ago
Yup! This is what makes this kind of attack scary and very unique to GitHub Actions. The baseline GITHUB_TOKEN just blows the door open on lateral movement via workflow_dispatch and and repository_dispatch events. In several of our other operations, not just PyTorch, we leveraged workflow_dispatch to steal a PAT from another workflows. Developers tend to over-provision PATs so often. More often than not we'd end up with a PAT that has all scopes checked and org admin permissions. With that one could clean out all of the secrets from an organization in minutes using automated tools such as https://github.com/praetorian-inc/gato https://github.com/praetorian-inc/gato.
- trevyn 3y ago
  To clarify, this secret stealing is not an issue with GitHub-hosted runners, correct?
  - adnanthekhan 3y ago
    Correct. For fork PR workflows on the pull_request trigger the GITHUB_TOKEN has read only permissions, so you can’t do anything with it. The key thing with a non-ephemeral runner is that (after obtaining persistence) you can grab the GITHUB_TOKEN from a subsequent non-fork PR build or a build on another trigger, which will have write permissions unless restricted by the repository maintainers.
lmeyerov 3y ago
I think 'environments' was meant, where diff GHA environments get diff secrets, and policies dictate who gets to run what actions with what envs. But that is real work to setup, audit, and maintain. It'd be better if, like phone app capabilities, the default would be no privs, any privs are explicitly granted, and if they aren't being used, the system detects that and asks if you want to remove specific ones.
gabriel-samfia 3y ago
Ouch! This is why ephemeral runners should be used. Preferably virtual machines. On an infrastructure that can define security group rules to prevent lateral movement.

mlazos 3y ago

If they use the same runners, couldn’t the attacker just wait? The runners would need to be sequestered too

kevin_nisbet 3y ago
Absolutely. The real difficulty is tests on PR are by definition remote code execution by an untrusted source, so a full risk analysis and hardening needs to be done. Here's a similar mistake on an OSS repo a company I worked for made: https://goteleport.com/blog/hack-via-pull-request/ https://goteleport.com/blog/hack-via-pull-request/

LtWorf 3y ago

> Not rocket science, people. The smugness and overconfidence of someone who's about to be pwned?

trevyn 3y ago
Pwn me.