from Hacker News

Anatomy of a Cloud Infrastructure Attack via a Pull Request

by twakefield on 9/18/21, 12:41 PM with 14 comments

• by _alxk on 9/18/21, 2:51 PM

  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.

• by dlor on 9/18/21, 2:40 PM

  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.

• by tedk-42 on 9/18/21, 2:15 PM

  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

• by devwastaken on 9/18/21, 4:55 PM

  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.

• by choeger on 9/18/21, 3:09 PM

  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.

• by wdella on 9/18/21, 4:32 PM

  Hi! I wrote this. I’m happy to answer any questions.