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

31–40 of 45 posts

Re: Exploiting CI / CD Pipelines for fun and profit

#31

Post by throwaway8481 »

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…

At my work, I often see these 2 things throughout the codebase:

- an identifier for an environment variable that gives us the azure key vault scope (another identifier) - an identifier for the token to pull from that scope

Then the scope name and token name are used to pull the token secret value using the secrets api.

I am not experienced in how this is "supposed to be". Would it make sense to make both of these environment variables so neither identifier appears directly in code? (scope name and token name)

Thank you for the insight :)

Re: Exploiting CI / CD Pipelines for fun and profit

#32

Post by lloeki »

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…

> 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)?

Sometimes it's not "you":

https://github.com/actions/checkout/issues/485

Re: Exploiting CI / CD Pipelines for fun and profit

#33

Post by the_gipsy »

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.

I am not sure, but it sounds like the pipeline runs for any pushed branch/PR, and it runs the pipeline configuration of that branch (so you can run a pipeline configuration without having to merge to master).

I'm not saying that this is fine, just that access to master is probably protected, but it's still vulnerable.

Re: Exploiting CI / CD Pipelines for fun and profit

#34

Post by apwheele »

mukesh610 wrote: post #25
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.

Even with secrets if the CICD machine can talk to the internet, you could just broadcast the secrets to wherever (assuming you can edit the yaml and trigger the CICD workflow).

I was thinking maybe a better approach instead of CICD SSH into prod machine is to have the prod machine just listen to changes in git.

Re: Exploiting CI / CD Pipelines for fun and profit

#35

Post by yabones »

ransom1538 wrote: post #29

100% of the script kiddies moved to .env and .git. My logs are filled with request for GET /.env 404. All the kiddies focus mainly on those two, I think the return is the best for their effort. The .env file is super trendy now and used across languages now.

A super easy way to protect yourself is to just block any IP that hits `/.env` or `/wp-admin`. I've taken this as far as to ban any IP that hits my default vhost (hitting the IP instead of actual hostname) more than ten times, and I get about about 99% less scanners and spam as a result.

https://nbailey.ca/post/block-scanners/

Re: Exploiting CI / CD Pipelines for fun and profit

#36

Post by kolme »

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.

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 in the `.git/config` file, defined in the [remote "origin"] section. This is the way they won full access to the repo.

Re: Exploiting CI / CD Pipelines for fun and profit

#37

Post by SkyBelow »

OtherShrezzing wrote: post #18
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…

>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)? People & organisations tend to follow the path of least resistance. If it's easier to put passwords into a plaintext config file than not, passwords will invariably end up in plaintext config files in some projects. `PASSWORD = ope…

"Security at the expense of usability, comes at the expense of security." strikes once again (if you squint and see usability to include following the path of least resistance, which I think counts).

Good security is expensive. Bad security is cheap (be it the example you mentions or a multitude of other ways). Management will favor the bad security done cheaply because the cost of bad security is extremely rare, and when it does happen, it rarely falls on the managers head. Either no one gets blamed (general blame the company, if at all these days), or the developer who made the choice to go with the cheap option gets blamed.

Re: Exploiting CI / CD Pipelines for fun and profit

#38

Post by theamk »

throwaway8481 wrote: post #31
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…

At my work, I often see these 2 things throughout the codebase: - an identifier for an environment variable that gives us the azure key vault scope (another identifier) - an identifier for the token to pull from that scope Then the scope name and token name are used to pull the token secret value using the secrets api. I am not experienced in how this is "supposed to be". Would it make sense to make both of these env…

The question you want is, "will anything bad happen if this source code is widely shared / leaks on the web" - and the answer in your case seem to be "no", the identifiers/token names are pretty useless without accompanying machine auth. You are fine.

Re: Exploiting CI / CD Pipelines for fun and profit

#39

Post by Concept5116 »

kolme wrote: post #36
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.

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.

Re: Exploiting CI / CD Pipelines for fun and profit

#40

Post by sebazzz »

I don’t understand why some authentication mechanisms, like Github Tokens don’t use a refresh token mechanism. So the token can be handed in once to create a refresh token, and then with that expiring access token can be requested. Now we (as users) have to bother with constantly expiring long-term tokens, not nothing in which of the hunderds of places we’ve might have put them.
Post reply on HN