Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

This blog is ran by two brothers who like to hunt for bugs together. They had each found several criticals on the this target but wanted an Exceptional Vulnerability - what I'd call a super critical - on this company. They decided to look at a recent acquisition of the company; the scope was simply "anything owned by the company". Since acquisitions may not have the same security controls in place, they were hoping for some low hanging fruit.

To go deeper, they were curious about supply chain vulnerabilities. If you want a super-crit, this is a good way to go. Things like, dependency confusion, artifactory access and other things are great attack methods. Using a mix of these methodologies, they were hopeful of finding a super crit.

They did a bunch of recon around NPM and found what appeared to be a private NPM package. If you have a license, you can setup an organization that has private packages. They were hopeful of source code leakageor dependency confusion here but didn't find anything. With nothing on Github, they turned to Docker and found several unsecured Docker images. Once they pulled the Docker images, they found backend source code for the application. Knarly!

One of the images even had the .git folder still intact, giving them access to the complete git history of it. Under .git/config, they found an authorization bearer token. After some research, they realized that this was for Github Actions! If the token was too permissive, they may be able to manipulate the pipelines or artifacts themselves.

GitHub Action tokens are commonly generated automatically to allow workflows to interact with repository-pushing code but expire once the workflow completes, limiting exploitability. If the artifact containing the token is uploaded before the workflow ends, then the image can be accessed while it's still active. The Docker push was the third to last item, meaning that it may just barely be possible to use the token before it expires. A month after they did this research, some other folks used a similar method to use a Github Action token.

The Dockerfile had a package.json that contained a private package from the npm organization they mentioned before. To pull these, the image would have needed an npm token within the .npmrc, but this wasn't there. This was because the Dockerfile deleted the file in the last build step.

Is this file gone forever? No! Docker has layers that are used for efficient caching. It turns out that these layers can be accessed individually! They found a sick tool called dive for reviewing file system images of Docker. Using this, they found the private npm token that granted them read/write access to the packages.

With the ability to write to this internal organization npm, it was game over. Developers who ran these internal packages were now compromised. The backend web service they mentioned was also compromised. This is a super-crit! Super fun blog post!