Exploiting CI / CD Pipelines for fun and profit
blog.razzsecurity.com
Exploiting CI / CD Pipelines for fun and profit
1–10 of 45 posts
Re: Exploiting CI / CD Pipelines for fun and profit
#2I’ve never deployed a .git folder and wonder what systems/approaches lead to such a thing. How does that happen?
Re: Exploiting CI / CD Pipelines for fun and profit
#3I’ve never deployed a .git folder and wonder what systems/approaches lead to such a thing. How does that happen?
It's pretty common in systems where the final output to be deployed is the same as the root of the source tree. More often than not, lazy developers tend to just git clone the repo and point their web server's document root to the cloned source folder. In default configurations, .git is happily served to anyone asking for it.
This seems to be automatically mitigated in systems which might have a "build" / "compilation" phase, because for the application to work in the first place, you only need the compiled output to be deployed. For instance, Apache Tomcat.
Re: Exploiting CI / CD Pipelines for fun and profit
#4I’ve never deployed a .git folder and wonder what systems/approaches lead to such a thing. How does that happen?
Its easy to miss that you need to duplicate your .gitignore into your .dockerignore
Re: Exploiting CI / CD Pipelines for fun and profit
#5I’ve never deployed a .git folder and wonder what systems/approaches lead to such a thing. How does that happen?
Its easy to miss that you need to duplicate your .gitignore into your .dockerignore
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.
Re: Exploiting CI / CD Pipelines for fun and profit
#6The 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 files. "it's just for a quick test"1 they say and then they forget about it and the password is getting checked in, or shown at screenshare meeting.
Maybe that's why there are so many security problems in industry? /rant
(For those curious: for git specifically, use ssh with key auth. If for some reason you don't want this, you can set up git's credential helper to use your OS key store; or use plaintext git-crendetials, or even just good-old .netrc. For source code, something like "PASSWORD = open("/home/user/.config/mypass.txt").read().strip()" is barely longer than hardcoding it, but 100% eliminates chance of accidental secret checkin or upload)
Re: Exploiting CI / CD Pipelines for fun and profit
#7The 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…
> 100% eliminates chance of accidental secret checkin or upload
You've never worked with humans, have you?
Re: Exploiting CI / CD Pipelines for fun and profit
#8Re: Exploiting CI / CD Pipelines for fun and profit
#9I’ve never deployed a .git folder and wonder what systems/approaches lead to such a thing. How does that happen?
It's because dockerignore file does not take this into consideration.
Re: Exploiting CI / CD Pipelines for fun and profit
#10I’ve never deployed a .git folder and wonder what systems/approaches lead to such a thing. How does that happen?
It's pretty common in systems where the final output to be deployed is the same as the root of the source tree. More often than not, lazy developers tend to just git clone the repo and point their web server's document root to the cloned source folder. In default configurations, .git is happily served to anyone asking for it. This seems to be automatically mitigated in systems which might have a "build" / "compilatio…
Or you do a git clone/docker build and that grabs it.
Hidden files only attract the attention of pessimists.