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!

Looker is a business intelligence (BI) and data analytics platform within Google Cloud. It allows connecting data sources, creating data models, and performing analytics. This product has both cloud-hosted and self-hosted versions.

Looker provides a feature for managing model files in Git repos, allowing users to pull or push changes to the repo. To integrate with Git, it will use JGit. When interacting with a git repo configured over SSH, Looker uses the native Git command-line tool instead. To do this, it will check out the repo and execute git commands against the directory.

When the .git file is deleted, it's possible to get the main part of the repo to get looked at for git commands. Using this, it's possible to execute arbitrary bash commands in files like config. As a result, when a user deletes a directory, Looker will validate the deletion request. In particular, it checks if the directory is .git.

The deletion command does NOT check whether or not the name is /! So, it's possible to delete the entire directory, including the git repo. At first glance, this means that the attack above wouldn't work; there's no content in the directory at all. This is where the internals of git and the Ruby file manager come into play...

The process of file deletion can take a long time. Since there is concurrent access to this file system, the idea is to trigger the folder deletion to remove the git repo, then make another request that triggers the RCE in the complete state. To hit this timing window, a lot of extra files need to be created, and the window is tight. It does seem like the author was able to hit this fairly consistently though.

Once on the box with RCE, they decided to review the container for other issues. Upon doing this, they noticed that the Kubernetes service account credentials were mounted onto the box. This allowed updating the namespace secrets, affecting other Looker instances. Because this was production and modifying these secrets would have broken something, they stopped there. Google confirmed it was possible to escalate privileges to access other instances in the same Kubernetes cluster though.

This report is pretty awesome for two reasons. First, the vulnerability they found required A) understanding why the protection was there and B) bypassing it. These second-order-type issues in complex systems are always a great place to look. Second, they really did right by Google. They asked for permissions at the proper times and didn't destroy anything, while finding two impactful vulnerabilities. Great find by this author!