Hacking with GIT: GIT-ENUM Metasploit Module Release

This is release two of three tools from my talk "Hacking with git" which I delivered at Glasgow BSides in 2018. The video of that talk is available at the URL below:

https://secarma.com/secarma-labs-archive/hacking-with-git-the-video

This blog covers the middle section which included how you could add enumerating Git repositories into your post exploitation process.

WHAT IS THIS "POST" EXPLOITATION?

Post exploitation comes after you have compromised a system. Once you have found your foothold you will need to enumerate as much information as possible with the goals of:

• Privilege Escalation - where necessary, can you gain higher privileges?
• Lateral Movement - can you find new systems which are accessible from the compromised node?

There are many tutorials and guides for what to include in post exploitation. The general rule of thumb "everything you can gather" is about right.

WHAT DOES GIT GIVE YOU FOR POST EXPLOITATION?

Git configuration files on a compromised server gives us a lot of good options.

AUTHENTICATION OPTIONS IN GIT

A classic post exploitation task is to find credentials or hashes which can then be used. Git gives us multiple authentication options which exist on disk in the locations shown below:

• Plain-text passwords – ~/.git-credentials
• Personal Access Tokens – ~/.git-credentials
• SSH Public Key – ~/.ssh/id_rsa.pub

Gaining plain-text credentials would give full control over a user's profile and their git repositories. Using passwords is described within Git's documentation here. The following quote from that article explains the security risk well:

"Using this helper will store your passwords unencrypted on disk, protected only by filesystem permissions. If this is not an acceptable security tradeoff, try git-credential-cache[1], or find a helper that integrates with secure storage provided by your operating system. This command stores credentials indefinitely on disk for use by future Git programs."

For a user to save their password to disk they can use the following command:

   git config credential.helper store

When they issue their next push request they will be prompted for their username and password which will then be stored in the user's home folder at "~/.git-credentials". For example, if the user is called "cornerpirate", then the location would be:

   /home/cornerpirate/.git-credentials

GitHub allows personal access tokens to be used instead of passwords. This is particularly useful when 2FA is enabled on the account and repositories are handled over HTTP/HTTPS.

Personal Access Tokens are generated using the steps available here. These can be as valuable as a plain-text password if the token has been generated with all permissions. However, it is possible to provide limited access. The following shows a token being generated with limited access:

On GitHub.com access tokens can have 27 permissions. Tokens with access to private repositories or organisation rights are more valuable to an attacker. As with storing plain-text password you can use the command "git config credential.helper store". With the full workflow being shown below:

When a Personal Access Token is used that stands in for the password. The general form of the URL is:

protocol://<username>:<password_or_token>@<host>

Users can interact with repositories over the SSH. In which case stealing SSH keys will give similar access. However, they will likely require an additional password for operation. Most post exploitation processes would generally look for SSH keys already so this is nothing new. More a reminder that these can be used for Git repositories as well.

In our gathering process we would need to:

1. Find all ".git-credentials" files and analyse them for credentials.
2. Find all SSH keys.

INFORMATION WITHIN .GIT FOLDER

Each repository has a ".git" folder which contains meta information and configuration details. Of use for post exploitation is knowledge of:

• Internal git repository servers
• Possibly “private” repos on public servers such as “github”

Both help you find lateral movement opportunities.

This information is determined from the ".git/config" file. The following image demonstrates the "remote" settings which contain URLs:

If the url protocol is "ssh://" then authentication uses SSH keys. When the protocol is "http://" or "https://" authentication can be either password or token.

In the above the IP address has been obscured but it pointed to an internal GitLab installation where the repository existed. This represents a lateral move since we have now identified where internal source control exists.

Where the URL points to a public source such as GitHub.com a little extra leg work should be conducted to see if it was a private repository. A private respository may contain sensitive information or valuable intellectual property.

In our gathering process we would need to:

1. Find all ".git/config" files and list the remote repository URLs

METASPLOIT MODULE "GIT_ENUM"

The source to "git_enum" has been provided at the URL below:

https://github.com/cornerpirate/metasploit-modules/blob/master/git_enum.rb

This currently targets only Linux hosts and will not work anywhere else. To use it now save the file into the "/modules/post/linux/gather" folder. Ensure that you reload all modules if msfconsole is already running using "reload_all" command, or simply restart msfconsole.

As this is a post module you would use it only once you have established a shell connection from a victim. Then you simply "set SESSION <id>" to the appropriate id before running "exploit" to gather the details. A picture is worth a thousand words so here is that shown clearly:

While the module could do with a bit of work it has worked reliably in testing for me. Any problems then feel free to rant at me on twitter @cornerpirate.

Hope that helps