How simple source code share may kick you out of the live system

The tedious topic of security narrated with real-world cases always sounds more familiar and draws more attention.

Once upon a time, a client has come to us asking for penetration testing of his web app. He had quite a few reasons for concern, and the most disturbing was the one: “A few months ago a new developer joined our team. We gave him access to the source code, documentation, test server. Two days passed, and he vanished into thin air. We still haven't heard a word from him. Should I be threatened about my system? We didn't give any access to the live system though.”

We are not going to talk about developers' mistakes that could lead to serious holes in the live system. Everything is much simpler - the source code itself may contain direct instructions and access - a cherry pie for someone with bad intentions.

I will give you some actual examples we came across during the penetration testing audits. In brief, just having access to the source code we easily intruded web systems. By now, security techs had already patched all those gaps, and irrelevant data in the screenshots is hidden.

System 1. Sensitive information in the source code

The cloned Git code contains not only the latest version, but also the whole history of changes. Usually, we run the source code for sensitive information using gittyleaks. Working on this project, we found a private encryption key, once removed from the code, but kept to be used on the live system. This key served for authentication goals and knowing authentication mechanism we could generate any auth cookie of any user, including the administrator.

System 2. Open SSH port

A git utility can help to find all files that have ever been deleted. In this system, we found the deployer.pem file in the project root folder removed a long time ago. Developers used the file for automated deployment to the servers via the SSH tunnel. Turned out, SSH port on the live system was open. And why do you think it was open? The developers answered that they didn’t close it because their build machine had a dynamic IP address. “Who's gonna guess the SSH key anyway,” they thought innocently… But we could.

System 3. Real passwords in database scripts

This case was even more obvious. It may be worth getting into the database scripts and see how users are created by default. Usually developers assign the first created user with admin's highest privileges. In the system scripts we found out that hash was generated out based on real passwords and stored hashes to the database. Surprisingly, 5 users were created, but to our even greater amazement, the password for the most important admin slipped into the live system. And by the way, this code has been around for several years, and more than one person had worked with it.

Conclusion:

1. If your project is git-based, open it and run a couple of commands from the root folder:
pip install gittyleaks
gittyleaks --find-anything

git log --diff-filter=D --summary

2. One golden rule. The live system should always have unique keys, unique user passwords, and every single element should be restricted all the way.

The article is provided for training and educational purposes only. Presented examples illustrate mistakes that should be avoided in your work.

Denis Koloshko, CISSP