Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploiting CI / CD Pipelines for fun and profit

blog.razzsecurity.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Exploiting CI / CD Pipelines for fun and profit

#21

Post by zettabomb »

ponytech wrote: post #20
TiddoLangerak wrote: post #19

Am I missing something, or does the step in > Pushing Malicious Changes to the Pipeline mean that they already have full access to the repository in the first place? Normally I wouldn't expect an attacker to be able to push to master (or any branch for that matter). Without that, the exploit won't work. And with that access, there's so many other exploits one can do that it's really no longer about ci/cd vulns.

edit: Credentials for modifying the piepline were found in the .git/config file

With Bitbucket, as well as Gitlab and likely others that I haven't used, the CI pipelines are stored as a plaintext configuration in the repo itself. So, repo commit access automatically gives you the ability to modify the pipeline.

Re: Exploiting CI / CD Pipelines for fun and profit

#22

Post by matharmin »

ponytech wrote: post #20
TiddoLangerak wrote: post #19

Am I missing something, or does the step in > Pushing Malicious Changes to the Pipeline mean that they already have full access to the repository in the first place? Normally I wouldn't expect an attacker to be able to push to master (or any branch for that matter). Without that, the exploit won't work. And with that access, there's so many other exploits one can do that it's really no longer about ci/cd vulns.

edit: Credentials for modifying the piepline were found in the .git/config file

It's right at the start of the post - the git remote including credentials was exposed via the .git directory

Re: Exploiting CI / CD Pipelines for fun and profit

#23

Post by lost_womble »

zettabomb wrote: post #21
ponytech wrote: post #20

Earlier quoted context omitted.

edit: Credentials for modifying the piepline were found in the .git/config file

With Bitbucket, as well as Gitlab and likely others that I haven't used, the CI pipelines are stored as a plaintext configuration in the repo itself. So, repo commit access automatically gives you the ability to modify the pipeline.

This is why things like codeowners files are so important

Re: Exploiting CI / CD Pipelines for fun and profit

#24

Post by mukesh610 »

TiddoLangerak wrote: post #19

Am I missing something, or does the step in > Pushing Malicious Changes to the Pipeline mean that they already have full access to the repository in the first place? Normally I wouldn't expect an attacker to be able to push to master (or any branch for that matter). Without that, the exploit won't work. And with that access, there's so many other exploits one can do that it's really no longer about ci/cd vulns.

You're right, there are other avenues of exploitation. This particular approach was interesting to me because it is easily automatable (scour the internet for exposed credentials, clone the repo and detect if Pipelines are being used, profit).

Other exploits might need more targeted steps to achieve. For example, embedding a malware into the source code might require language / framework fingerprinting.

Re: Exploiting CI / CD Pipelines for fun and profit

#25

Post by mukesh610 »

ram_rattle wrote: post #13

naive question: Doesn't github secret scan kind of thing wont catch this?

No, in my YAML example, you could see that there were no credentials directly hard-coded into the pipeline. The credentials are configured separately, and the Pipelines are free to use them to do whatever actions they want.

This is how all major players in the market recommend you set up your CI pipeline. The problem here lies in implicit trust of the pipeline configuration which is stored along with the code.

Re: Exploiting CI / CD Pipelines for fun and profit

#26

Post by ghxst »

Does this actually occur with real or high-value targets? I'm genuinely curious, as I can only envision this happening with smaller side projects. However, I'd be interested to hear any stories of encountering this in the wild. It's a good reminder to stay mindful of what might accidentally be exposed.

Re: Exploiting CI / CD Pipelines for fun and profit

#27

Post by brightball »

theamk wrote: post #6

The real problem is keeping sensetive information in .git directory. Like WTH would you put your password, in plaintext, in some general ini file? (or into a source file for that matter)? When I see things like those, they look so wrong to me. But sadly it's apparently uncommon nowadays: not only random bloggers, even my coworkers see nothing wrong with putting passwords or tokens into general config or source code f…

Gitleaks is the easiest way to deal with this. I make a point to include it in my build pipelines and have dev teams set it up as a precommit hook to prevent the problem.

Re: Exploiting CI / CD Pipelines for fun and profit

#28

Post by jalict »

mlhpdx wrote: post #2

I’ve never deployed a .git folder and wonder what systems/approaches lead to such a thing. How does that happen?

index.html and rest of project is rooted in well.. root. And simple push deploy your root git repo to your /var/www or whatever.

Ex. you use github pages and do homemade brew html or whatever that is not static-generator that outputs to a subfolder.

Re: Exploiting CI / CD Pipelines for fun and profit

#30

Post by crabbone »

__float wrote: post #11
a99c43f2d565504 wrote: post #5

Earlier quoted context omitted.

To not have to remember that one can not use a .dockerignore at all and instead explicitly pick the files and directories from the build context that need to be in the image.

This is annoying and error prone if you use an interpreted language that relies on loading source files at runtime. For a Go service? Sure, that's easy and makes a ton of sense.

> This is annoying and error prone if you use an interpreted language that relies on loading source files at runtime.

That's a bit of misconception. (Not to mention terminology mish-mash) what you probably call "interpreted" is languages like Python, JavaScript or Ruby. In all these cases, the projects are supposed to be compiled into an installable package, and then that package is supposed to be installed. So, compilation step is very similar to languages like C or Go.

Regrettably, developers rarely follow the due process and "deploy" what essentially amounts to the project's source code... This has a bunch of other problems, beside the security issues with potentially copying passwords into the deployment environment. This whole process reminds me of the early days of PHP where Web was full of examples of "guest books" which taught a generation of PHP programmers to interpolate values straight from the URL request into SQL queries. And then, PHP took the blame for "allowing it".

Post reply on HN