How to hack a system through a test environment

Real life safety is always interesting.

The conversation will be about hacking systems through test environments. In the example below from a penetration test for one of our clients, direct access to the cloud was obtained with full access to several live systems at once. We emphasize right away that the vulnerability has already been fixed, sensitive data in the screenshots is hidden, any coincidences are accidental.

So about the reasons:

  1. The whole emphasis is placed on building protection for the production environment, and the test, staging or dev environment is “forgotten”;

  2. The principle of Surface Attack Reduction is violated, when specialists simply do not take into account all possible entry points;

  3. The principle of least privilege is violated, and the service account is given permissions that it does not need;

  4. Test environments use uniform and simple passwords to improve the efficiency of testers’ work;

  5. Debug panels are added to the test environment so that you can optimize performance, but such panels often include a lot of additional information about the system (environment variables, full stack of errors, sql queries, etc.)

Testing, getting more information and penetrating the test environment is part of the penetration testing service. Below we will try to analyze this real case.

So, testing was carried out for a mobile application directly from Google and Apple stores and the server API that this application uses. It is worth noting that the developers and devops did their best, only a few Low level vulnerabilities were found for the live system, which are advisory in nature for closing. We were really upset (we usually get upset if the protection of the system is at its best) until we got to penetration testing through alternative entry points.

The first step was to find out what other subdomains are known for this domain. Possible ways: look at alternative names in the SSL certificate or examine the archives of DNS records in third-party services. This is how we found the location of the test environment specified in both the SSL certificate and the external service. A small digression: domain services can store the history of changes in IP addresses for some domain name, and sometimes it turns out to bypass WAF, substituting the address of the previous IP address instead of the firewall address.

Thus, we were able to find out the address of the administrative panel of the test environment, which was available on the Internet. Then I didn’t even have to brute force the admin panel, the first time I managed to go under admin/admin… There will be no screenshot.

In addition to disclosing the details of how the administrative panel is arranged, what data it operates on, we were interested in the PHP Debug panel, which showed errors with full stacktraces, SQL queries, server paths of the file system.

The most interesting thing we found is the environment variables with which the server docker was launched, and in them are the service keys for accessing the Amazon cloud.

Next, it’s a matter of technology: through the AWS Explorer for Visual Studio, we substituted the AWS keys and connected to the cloud. As a result, it turned out that the production environment uses the same keys, and in general, full privileges were granted for the service account. Three more business systems with full live data were discovered in the cloud. Some of the live data was available for direct download.

The cherry on top was that the same PHP Debug panel was available on the Login page for unauthenticated users, which significantly increased the likelihood of reproducing the attack, and as a result, the total risk of the vulnerability itself.

Worst case scenario: An attacker, remaining anonymous, could clean up all resources in the cloud, including backups of data and files, and at one moment shut down four successful business systems, and possibly the entire business as a whole.

This is a good example, proving that it is worth paying attention to all the resources that are exposed to the public.

Here’s what you can do to protect your test environments right now:

  1. Close access to various test environments at the VPN or Firewall level;

  2. Recheck that all environments use unique system settings (encryption keys, cloud access, other environments);

  3. Recheck that each environment has a strong guarded loop;

  4. All permissions for service accounts are issued in accordance with the Principle of least privilege;

  5. Make sure that “default” logins and passwords are changed for the live system;

  6. Develop a procedure for anonymizing data if live data is needed for analysis in other environments.

The above information is provided only for educational and educational purposes, how to make your own systems is not necessary.

Denis Koloshko

CISSP, OSWE, Penetration Tester

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *