"All your Git repos are belong to us."

Summary

During a recent assessment, I made it a point to dig deeper than I usually did when it came to initial reconnaissance with my offensive security efforts. I had a hunch that something interesting was lurking in the shadows with this particular target, so I set off on my journey to sail the recon seas as far as they would take me.

Little did I know that this long journey would lead directly to the pot of gold at the end of the rainbow!

Jumping in with the target, initial discovery, enumeration, permutation, brute force, reverse DNS

Enuma-what? Permuta-huh? What?

Yes, yes, many quirky terms here for some of you reading.

The target in question was an IP range, as well as a wildcard domain.

But wait, what do you use for information gathering, subdomain enumeration, X, Y and Z, etc.?

Recon for me depends on what I'm after, though some of my tool belt consists of Shodan, crt.sh, Security Trails, Amass, AltDNS, OTX AlienVault, and Subfinder, in no particular order. At times, I piece together byte sized Python scripts that combine one or two things for quicker output depending on what I'm looking for. I prefer manual reconnaissance over anything too automated.

NOTE: I won't go into detail over how I use each of the above as that's above the scope of this article, though I do always utilize API keys for each service, some of which comes at a cost (such as Shodan, Security Trails, etc.)

After gathering the relevant network ranges, performing some reverse DNS queries, fingerprinting the main components, and gathering initial information about the target, I moved on to enumerating/brute forcing subdomains. Nothing interesting was sticking here, and it was clear that I had entered 403 city whenever trying to stray from the path of the main functionalities. Though, I decided to dig a bit more and brute forced the already located subdomains in search of even more items to expand my attack surface.

Brute forcing already brute forced subdomain results? What in the world?

Subdomain discovery/brute forcing on the surface pertains to resolving subdomains of a root domain by a wordlist or some other means of identification. This is absolutely fine, and can lead to some solid recon discoveries, however, subdomain permutation and things like recursive DNS brute forcing can provide more of a boost to the entire discovery process.

Permutation allows for the identification of things not generally found in a traditional wordlist through patterns. Generally, though not "always," companies use naming schemes that are similar if not exactly the same across board. For instance, if I identify a subdomain of "something-1.target.com," there is a high chance that perhaps "dev-1.target.com," or "something-2.target.com" exists. AltDNS is great here for this type of thing, as it automates the process by taking in a list of words and then creating permutations of these words with previously discovered subdomains.

This led to the discovery of a slew of fourth-level domains, all owned by the main target. These looked similar to what I saw before, but I decided to enumerate and fuzz them in the same manner, as often these fourth-level domains have things that are forgotten about, or end up being misconfigured.

What's a fourth-level domain?

Fourth-level domains are subdomains of a third-level domain. For example, "http://something.target.com" is known as a third-level domain. If we extend this further, altering it to "http://somethingelse.something.target.com," then we have ourselves a super duper fourth-level domain.

In my case, the initially discovered subdomain was:

• something.target.com

After further discovery as explained above, the final fourth-level domain ended up being:

• dev-01.something.target.com

Heading down the rabbit hole

Having done thorough fuzzing and enumeration on the initially identified endpoints/subdomains, I decided to make a list of all of the previous directories that led to the 403's. Using this, I then fuzzed the fourth-level domains, and found several of these to be accessible, while others still led to the 403. However, one of these new discoveries stuck out as interesting…

An initial attempt to the "/.git" directory resulted in the following 403, which showed that this path existed, though access to it was restricted:

Forcing my way through and traversing the 403 FORBIDDEN lands

Knowing that Git repositories generally contain both "/index" and "/config" directories, I manually checked for these as I always do, as they can encompass interesting information. This action, known as forced browsing, allows for the accessing of directories and files that are otherwise not accessible or referenced by the main server and/or application.

When I tried to add both of these directories to the initial 403 endpoint requests, I saw the glorious 200 responses coming through, indicating that the initial 403 was now completely bypassed:

The Git config in this case contained information related to the repository in question as well as several other items pertaining to this target's web services.

Unraveling the ".git" Directory

Since the exposed "/.git" directory was discovered, I promptly retrieved it for a thorough local analysis using GitTools (courtesy of Sebastian Neef, https://github.com/gehaxelt), a powerful toolkit designed for local Git repository analysis. This allowed me to delve into its contents and explore its version history, configuration files, and other critical data.

To dump the Git repo to a local system, the following was ran:

Next, a status check was ran:

Well, this is unfortunate because all of the items show to have been deleted.

Not so fast…

This is where "Extractor" comes into play, as it allows for the iteration through all commit objects of a repository, ultimately attempting to restore the contents, as shown below:

Sifting through the findings

There was a lot to unpack here, ranging from a large amount of production secrets and source code, all the way to the discovery of a few additional live hosts, which could be enumerated, ultimately exposing PII related to users.

Wrapping up

This was a "Critical" level finding, which the organization tended to immediately.

In conclusion, these findings helped me to realize that going that extra mile can end up being the difference between simplistic findings and actually stumbling upon a gold mine.

Until next time…