Anatomy of a Cloud Infrastructure Attack via a Pull Request

Shameless plug for something I&#x27;ve been working on: <a href="https:&#x2F;&#x2F;github.com&#x2F;ovotech&#x2F;gitoops&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ovotech&#x2F;gitoops&#x2F;</a><p>I wrote GitOops to map attack paths through GitHub and CI&#x2F;CD systems, at scale.<p>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&#x2F;intern with GitHub&#x2F;Lab access is enough to lead to a disaster scenario.

Attacks here are incredibly common. Fortunately they&#x27;re usually unsophisticated and are just plain crypto mining to steal CPU cycles.<p>Worst case is if a CI system has permissions to deploy to production, which is really common too.<p>Another common one to watch out for is permissions to publish artifacts. It&#x27;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&#x27;t touch production directly, it can still be used to pivot to more sensitive targets.<p>Great find and write-up from the teleport team.

For every company I&#x27;ve worked at, the CI system basically had admin access over our infrastructure. It has to in order to do infrastructure as code.<p>As the article states, accepting public pull requests and letting them run on your internal CI is a big mistake.<p>Public CIs are fine though. Ones that literally only do code builds, tests etc

You don&#x27;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&#x2F;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&#x2F;calls. It&#x27;s easier and more effective, and it gets swept under the rug because closed source gets no public view and companies don&#x27;t like revealing every time a employee falls for a scam.

That&#x27;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).<p>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.

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