[HN Gopher] Anatomy of a Cloud Infrastructure Attack via a Pull ...
___________________________________________________________________
Anatomy of a Cloud Infrastructure Attack via a Pull Request
Author : twakefield
Score : 69 points
Date : 2021-09-18 12:41 UTC (10 hours ago)
(HTM) web link (goteleport.com)
(TXT) w3m dump (goteleport.com)
| devwastaken wrote:
| You don't have to attack cloud infra with actual code. You bribe
| company employees, either of the target company or one that
| creates systems for them/has access. Or simply scam 1 employee
| and use your RAT to later infiltrate. Scammers have been going
| pro and due to the many ridiculous policies of companies are not
| diffable from real emails/calls. It's easier and more effective,
| and it gets swept under the rug because closed source gets no
| public view and companies don't like revealing every time a
| employee falls for a scam.
| choeger wrote:
| That's a really interesting read. I bet the DIND pattern is very
| common because it is a) common to run CI jobs in containers, b)
| common (and a good idea) to describe testing environments in
| containers inside the source code repo and c) a good idea to use
| the same source for a) and b).
|
| One particular instance is gitlab where the declarative pipeline
| demands a docker image. If your repository comes with a docker
| description for test execution, you are pretty much forced to run
| DIND.
| dlor wrote:
| Attacks here are incredibly common. Fortunately they're usually
| unsophisticated and are just plain crypto mining to steal CPU
| cycles.
|
| Worst case is if a CI system has permissions to deploy to
| production, which is really common too.
|
| Another common one to watch out for is permissions to publish
| artifacts. It's very common for a CI system to build and test
| something like a container image, then for another system to
| promote that image to production. Even when the CI system can't
| touch production directly, it can still be used to pivot to more
| sensitive targets.
|
| Great find and write-up from the teleport team.
| wdella wrote:
| Hi! I wrote this. I'm happy to answer any questions.
| tedk-42 wrote:
| For every company I've worked at, the CI system basically had
| admin access over our infrastructure. It has to in order to do
| infrastructure as code.
|
| As the article states, accepting public pull requests and letting
| them run on your internal CI is a big mistake.
|
| Public CIs are fine though. Ones that literally only do code
| builds, tests etc
| wdella wrote:
| > the CI system basically had admin access over our
| infrastructure. It has to in order to do infrastructure as
| code.
|
| > Public CIs are fine though. Ones that literally only do code
| builds, tests etc
|
| I couldn't agree more.
|
| Even internally, the security and authorization needs of
| deployment/release are wildly higher than those for running an
| ephemeral build and test. "CI/CD" needs to be un-bundled, for
| the sake of security, such that _CI_ doesn 't have admin access
| over infrastructure. Only a much more limited CD has this
| access.
|
| In the case of open core products that use public facing CI,
| I'm inclined to put the average employee's CI on the public
| system; for transparency, but also to make sure external
| contributors don't become second class citizens using an
| irregular workflow/toolset. Maintain a separate internal
| release system limited to trusted employees. Principle of least
| privilege, and all that. :)
| _alxk wrote:
| Shameless plug for something I've been working on:
| https://github.com/ovotech/gitoops/
|
| I wrote GitOops to map attack paths through GitHub and CI/CD
| systems, at scale.
|
| As an ex-pentester, for most companies I got to work with, all
| you need to do is open a PR against the right repositories to
| take over sensitive production environments. I suspect for most
| companies, an attacker compromising a single employee/intern with
| GitHub/Lab access is enough to lead to a disaster scenario.
| DelightOne wrote:
| How can they be avoided without stopping the use of CI/CD? I
| assume it is the same with GitLab?
| Normal_gaussian wrote:
| Use protected branches (only inject prod secrets on master,
| which can't be pushed to) and have test secrets for other
| branches. Now your weak spot is only anyone who can hit merge
| on a PR to master, which is easy to control.
| felixhuttmann wrote:
| On gitlab, there has been another way for some time: There
| is a JWT token CI_JOB_JWT available in an env var which
| contains the branch name and other info as one of the
| claims [1]. One can then use this token to obtain
| production secrets based on whether the branch is trusted.
|
| Github has the same feature upcoming [2], which allows to
| get also directly AWS or GCP credentials restricted by
| branch name [3, 4].
|
| [1] https://docs.gitlab.com/ee/ci/examples/authenticating-
| with-h... [2] https://github.com/github/roadmap/issues/249
| [3] https://awsteele.com/blog/2021/09/15/aws-federation-
| comes-to... [4] https://github.com/sethvargo/oidc-auth-
| google-cloud
| Normal_gaussian wrote:
| That is awesome, thank you for telling me!
| wdella wrote:
| > How can they be avoided without stopping the use of CI/CD?
|
| Use separate systems for CI and CD, and don't put sensitive
| "keys to the kingdom" credentials in CI. For example:
|
| Put CI in GitHub Actions or GitLab CI without any credentials
| to write artifacts or knowledge of stage/prod deployments.
| Let the "interns" in the threat model use this.
|
| Put production CD/release in Jenkins or a similar self
| hosted, not publicly accessible system. Limit the folks who
| can trigger jobs in this system to a small group of trusted
| employees, and don't trigger runs on actions that don't
| require U2F auth (e.g. require a manual click through the
| webui protected by SSO, or only deploy from specific branches
| protected to only allow approved PRs -- no git client
| pushes).
|
| > I assume it is the same with GitLab?
|
| Yes. While GitLab does offer some secret and variable masking
| controls, the Travis disclosure earlier this week where all
| secrets were exposed to Pull Request CI shows you probably
| don't want to bet your business on those controls.
| (Acknowledging GitLab != Travis)
|
| See https://travis-ci.community/t/security-bulletin/12081
___________________________________________________________________
(page generated 2021-09-18 23:01 UTC)