HackedIN: Hack to the Future

In today's world, the very same features we rely on for integrity and security can be used against us by attackers.

This week's edition of HackedIN provides insights into how I use developers’ own tools against them.

It serves as a reminder that great security demands great responsibility from both attackers and defenders.

Git. What is it?

Git is a technology invented in 2005 by Linus Torvalds for Linux kernel development.

Fast forward to 2022, and it’s the go-to for nearly 95% of developers worldwide.

So what does it do?

On a high level, git is a program used by developers to keep track of all changes in their source-code files, especially useful when lots of developers are working on the same project from different locations.

Chances are you’ve heard of GitHub, Bitbucket, GitLab or Azure DevOps; your company likely uses one or more of them to host its own source code.

These are just SaaS versions of Git, but at the end of the day, the underlying technology is all the same.

Woops. No one saw that, quick delete it!

As a company, the integrity features provided by Git are attractive, but they are also attractive to an attacker in the same right.

Here’s why…

As humans, sometimes we make mistakes.

In the context of development, this could mean a developer accidentally adding a hardcoded password or API key to the source code.

Oftentimes, developers know this is not best practice and that far more secure options for storing passwords and API keys exist, including but not limited to secret vaults.

In such cases, developers will likely re-commit the code, but this time, without the hard-coded values, in which case the code-base would be updated, and the developer can continue working on their app, even deploying it without exposing these values to attackers.

Here’s where the integrity becomes useful to an attacker.

By design, because the system (Git) records ALL changes, both additions and deletions of code, it must also keep a log of those differences, including whatever values were removed from the code.

This becomes a risk when developers delete the exposed data from a git repo but fail to rotate or invalidate the credentials.

In the developer's mind, they can no longer see the exposed credential in the source code, so therefore the problem is solved.

To an attacker, it’s a different picture.

It represents a perfect scenario.

Not only does the developer believe the risk is completely mitigated, but they are also likely embarrassed about the accidental code commit and less likely to raise this with their colleagues, creating the perfect conditions for an attacker.

Valid credentials + embarrassed developer = Long term access

Under the hood.

Recently, during a security engagement, I stumbled upon an exposed .git repository belonging to a client. It was a prime example of how Git's integrity features can be leveraged for unauthorised access.

Fortunately, after cloning the repository and analysing the active branch, no hardcoded secrets were found.

Unfortunately, the git history was a treasure trove.

I used the following command to unearth the hidden gems:

git log --pretty=format:"%H" | while read commit_hash; do git show $commit_hash; done > all_commits.txt        

This command allowed me to export all the previous commits into a text file.

What this command does is list every commit hash in the repository, and then for each hash, it displays the content of that commit, including the changes made, the author, the timestamp, and other metadata as follows:

By redirecting the output to a text file, I effectively created a comprehensive record of every change made in the repository.

The Takeaway

This experience highlights a crucial aspect of cybersecurity: understanding your tools is as important as understanding how they can be misused.

In this case, the very features of Git that ensure the integrity and transparency of code changes became a vulnerability.

Attackers can exploit overlooked aspects of these tools, like the comprehensive history stored in Git.

This makes it essential for developers and security professionals to be vigilant not only in how they use these tools but also in how they manage and secure them.

In the world of cybersecurity, knowledge and awareness of your tools' capabilities – and vulnerabilities – are key.

It's a reminder that with powerful technologies comes the need for equally robust security practices.

To mitigate risks like these, consider the following strategies:

• Implement code scanning tools to automatically detect and alert on exposed secrets in your codebase.
• Establish a protocol for developers to promptly rotate any credentials that might have been accidentally committed.
• Encourage a culture of open communication about accidental code exposures, removing any stigma or embarrassment.
• Document all instances of code exposure, regardless of whether they were accidental or intentional, to maintain a history for security audits.
• Regularly review and update security practices to ensure they align with the evolving nature of software development and cybersecurity threats.