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

41–45 of 45 posts

Re: Exploiting CI / CD Pipelines for fun and profit

#41

Post by tomjakubowski »

crabbone wrote: post #30
__float wrote: post #11

Earlier quoted context omitted.

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, comp…

Yeah, this is a bit of a pet peeve of mine. I've seen a lot of Python app Docker images which are built by just copying the git repo straight into the image. Better to build a package from the source in one CI step, and then install that package into the deploy image in another.

Re: Exploiting CI / CD Pipelines for fun and profit

#42

Post by kolme »

Concept5116 wrote: post #39
kolme wrote: post #36

Earlier quoted context omitted.

From TFA: > A surprising number of websites still expose their .git directories to the public. When scanning for such exposures on a target, I noticed that the .git folder was publicly accessible. [...] > With access to .git/config, I found credentials, which opened the door to further exploitation. I could just clone the entire repository using the URL found inside the config file. The URL with credentials was found…

I don't see how this is specific to "exploiting CI / CD Pipelines" when he's really just exploiting someone encoding their github username AND password credentials (unorthodox af) into the url for remote.

Yes, that first part was not. But the article continues like this:

- they use that credentials to make a commit adding malicious code to the CI pipeline

- The rouge pipeline job adds their public SSH key to the `.allowed_keys` file in the production server

As the pipeline is run automatically on push, they get ssh access to the remote server.

That is the "CI / CD Pipelines" bit. That being said, it's a bit underwhelming, because given the title I though they were going to exploit a bug in the CI/CD software itself. I don't know if I'd call that "exploiting" CI/CD software.

Re: Exploiting CI / CD Pipelines for fun and profit

#43

Post by threecheese »

Concept5116 wrote: post #39
kolme wrote: post #36

Earlier quoted context omitted.

From TFA: > A surprising number of websites still expose their .git directories to the public. When scanning for such exposures on a target, I noticed that the .git folder was publicly accessible. [...] > With access to .git/config, I found credentials, which opened the door to further exploitation. I could just clone the entire repository using the URL found inside the config file. The URL with credentials was found…

I don't see how this is specific to "exploiting CI / CD Pipelines" when he's really just exploiting someone encoding their github username AND password credentials (unorthodox af) into the url for remote.

Because 1) the .git directory was deployed with the app code (the exploit vector), and 2) the deployment pipeline automatically integrated and pushed the attacker’s commit to a production system (completing the exploit), I’d say that claim is accurate. These are both defects in the thing the attacker claims to have exploited.

It sure wasn’t a good decision to use git-config to store creds for CI though! I wonder if OP found a developer’s old cached creds in the history that weren’t used anymore but happened to still be valid?

Re: Exploiting CI / CD Pipelines for fun and profit

#44

Post by JamesSwift »

tomjakubowski wrote: post #41
crabbone wrote: post #30

Earlier quoted context omitted.

> 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, comp…

Yeah, this is a bit of a pet peeve of mine. I've seen a lot of Python app Docker images which are built by just copying the git repo straight into the image. Better to build a package from the source in one CI step, and then install that package into the deploy image in another.

Overall, two-phase docker build is a much better model that avoids a lot of miscellaneous issues, including this one. But its also not super well-known for devs who just touch docker every now and then.

Re: Exploiting CI / CD Pipelines for fun and profit

#45

Post by paperplatter »

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…

Maybe they're use Google AppEngine and don't want to deal with storing config secrets the right way for it.
Post reply on HN