Reports from the Field: Part 2

In the second part of our “Reports from the Field” series, we’ll explore exposed configuration files. If you want to check out our first part on reused credentials, visit: Reports from the Field, Part 1.

Four Ways a .git/config File Can ‘Git’ You

The quick take: Exposed configuration files can be leveraged to build a complete repository index.

The full story: It’s not immediately apparent how much leverage can be gained via the presence of a simple .git/config file. That’s why we chose not 1, not 2, not 3, but 4 use cases to show the extraordinary level of damage that a simple .git/config file exposure can cause.

USE CASE #1: Rebuild a Repository to Recover Credentials and Find Exploitable Vulns

Step One: A presence of a .git/config file is a great indicator that a git repository potentially exists on the server. Once found, the attacker can begin the process of rebuilding the repository index and recovering as many files as possible.

Step Two: Once recovery is complete, attackers can then focus on analyzing the repository’s contents. Typically, two of the most severe findings within those contents are as follows:

• Vulnerabilities that exist in code are revealed by the source . This can lead the attacker to discover a path to remote code execution in the codebase. Remote code execution is one of the most severe threats to an organization’s security. If an attacker succeeded in reaching this point, the results could be devastating.
• Hardcoded credentials left inside the codebase, which can be easily recovered and used against the target in separate ways. Most commonly, these are database credentials or AWS keys, which would allow an attacker full or partial access to your data or AWS instances.

Why is this important? A recovered repository might only be partial, but in most cases even a few recovered files can present valuable vulnerabilities for the attacker to further investigate.

USE CASE #2: Exploit PHP eval() Function to Get Shell Access

How we did it: Our teams discovered a git repository with a custom written PHP application and discovered the developer was using PHP’s eval() function. Once the team figured out a way to pass his crafted payload to the eval() function, he was able to get shell access on the box and recover additional data from the server.

Why is this important? Once shell access is acquired on a system, an attacker can elevate privileges and gain root access on the host. This can lead to additional data loss, such as full access to a local database. In other cases, attackers may choose to pivot to other systems on the network to expand their foothold.

USE CASE #3: Reuse DB Credentials From a Recovered Repository

How we did it: After recovering a partial repository, our team located a configuration file with database credentials for the application. A quick review of the open ports on the host revealed that no database service was listening externally. At first glance, this meant that the credentials recovered weren’t as useful. On a hunch, the team decided to try the database credentials by establishing an SSH connection to the target. He was not only granted access but was able to elevate to root-level access on the box due to the user being included in the ‘sudoers’ file with full access.

Why is this important? Once achieving root-level access, our team then proceeded to recover encryption keys to the database and decrypt the personally identifiable information of the nearly 3 million users that were stored in that database.

USE CASE #4: Uncover AWS keys From a Config File in a Recovered Repository

How we did it: Using an open-source AWS post-exploitation tool, the team was able to remotely execute code on the organization’s domain controller. At this point, the team exfiltrated and cracked numerous hashes from the domain controller – and recovered plaintext passwords for many of the network users.

Why is this important? The team could log into users’ corporate accounts, lock them out of those accounts, and read confidential communications, such as email or instant messages and chats.

Bottom line (for all four use cases): The presence of an innocuous configuration file (like .git/config) gives a skilled attacker enough to launch a multi-thronged and multi-step attack.

Stick around for Part 3, as we dive into how attackers utilize tools to dig for an exploit. To explore more approaches leveraged by attackers and how a continuous offensive security platform can help you stay ahead of threats – download "The Wolf in Sheep's Clothing" eBook.