How to lose access to the live system, simply by fumbling the source code
Security with real-world examples is always more interesting.
Once a client came in with a request for penetration testing. He had many reasons for concern, and among others he sounded like this: “A few months ago, a new developer came to us, got access to the source code, documentation, test server, disappeared two days later and still does not respond. How can this threaten me? He was not given access to the live system. ”
We are not going to talk about the mistakes of developers who can become serious holes in the live system. Everything is much simpler - the source code itself may contain direct instructions and access.
')
From various projects that we tested for security, I’ll give real examples, when having only the source code, we could penetrate the system itself. All these problem areas were eliminated, and any unnecessary information in the screenshots is hidden.
System 1.
The cloned code from the gita is not only the latest version, but also the history of all changes. We usually run the source code for sensitive information using gittyleaks .
In this project, we found a private encryption key, which was once removed from the code, but it continued to be used on the live system. This key was used for authentication, and knowing the mechanism we could generate any authentication user of any user, including the administrator.
Picture 1. Output: gittyleaks --find-anything
System 2.
You can use the git utility and ask it to show all files that have ever been deleted. In this system, we found the deployer.pem file that once lay in the project’s root and was used to automatically deploy the project to the servers via the SSH channel. SSH port in live system has been opened. Why open? The developers responded that the build machine they had was sitting at a dynamic IP address, and they decided not to close the port - “nobody will pick up the SSH key anyway”. Gee-gee ...
Picture 2. Output: git log --diff-filter = D --summary
System 3.
With this system, everything was even easier. It may be worth getting into the database scripts and see how users are created by default. Usually the first user to create an admin with the highest privileges. In the scripts we found the code that generated a hash from real passwords and wrote it into the database. What is surprising - 5 users were created, but to our amazement, the password for the most important admin passed in the live system. And this code is not the first year, by the way, and not one person worked with it.
Picture 3. As in the base scripts you can find real passwords
Promise
1. If your project is on git, 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 everything should be closed to the maximum.
The above information is provided only for educational and educational purposes, how to make their systems is not necessary.
Denis Koloshko
Once a client came in with a request for penetration testing. He had many reasons for concern, and among others he sounded like this: “A few months ago, a new developer came to us, got access to the source code, documentation, test server, disappeared two days later and still does not respond. How can this threaten me? He was not given access to the live system. ”
We are not going to talk about the mistakes of developers who can become serious holes in the live system. Everything is much simpler - the source code itself may contain direct instructions and access.
')
From various projects that we tested for security, I’ll give real examples, when having only the source code, we could penetrate the system itself. All these problem areas were eliminated, and any unnecessary information in the screenshots is hidden.
System 1.
The cloned code from the gita is not only the latest version, but also the history of all changes. We usually run the source code for sensitive information using gittyleaks .
In this project, we found a private encryption key, which was once removed from the code, but it continued to be used on the live system. This key was used for authentication, and knowing the mechanism we could generate any authentication user of any user, including the administrator.
Picture 1. Output: gittyleaks --find-anything
System 2.
You can use the git utility and ask it to show all files that have ever been deleted. In this system, we found the deployer.pem file that once lay in the project’s root and was used to automatically deploy the project to the servers via the SSH channel. SSH port in live system has been opened. Why open? The developers responded that the build machine they had was sitting at a dynamic IP address, and they decided not to close the port - “nobody will pick up the SSH key anyway”. Gee-gee ...
Picture 2. Output: git log --diff-filter = D --summary
System 3.
With this system, everything was even easier. It may be worth getting into the database scripts and see how users are created by default. Usually the first user to create an admin with the highest privileges. In the scripts we found the code that generated a hash from real passwords and wrote it into the database. What is surprising - 5 users were created, but to our amazement, the password for the most important admin passed in the live system. And this code is not the first year, by the way, and not one person worked with it.
Picture 3. As in the base scripts you can find real passwords
Promise
1. If your project is on git, 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 everything should be closed to the maximum.
The above information is provided only for educational and educational purposes, how to make their systems is not necessary.
Denis Koloshko
Source: https://habr.com/ru/post/459552/
All Articles