3 ms·

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

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.

ponytech 2y ago
edit: Credentials for modifying the piepline were found in the .git/config file
- zettabomb 2y ago
  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.
  - lost_womble 2y ago
    This is why things like codeowners files are so important
- matharmin 2y ago
  It's right at the start of the post - the git remote including credentials was exposed via the .git directory
mukesh610 2y ago
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.
the_gipsy 2y ago
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.
kolme 2y ago
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.
- Concept5116 2y ago
  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.
  - kolme 2y ago
    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.
  - threecheese 2y ago
    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?

ponytech 2y ago

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

zettabomb 2y ago
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.
- lost_womble 2y ago
  This is why things like codeowners files are so important
matharmin 2y ago
It's right at the start of the post - the git remote including credentials was exposed via the .git directory

mukesh610 2y ago

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.

the_gipsy 2y ago

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.

kolme 2y ago

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.

Concept5116 2y ago
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.
- kolme 2y ago
  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.
- threecheese 2y ago
  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?