- You guys are cool! So no one has let us down yet!
- We tried our best.
Yes, the life of vulnerability hunters is full of specific compliments from customers and no less specific situations. Over the past year, we have completed more than fifty penetration tests in different companies and, it must be said, have seen everything. One password for all accounts and systems, open storage of passwords in the database, the remains of debugging functionality in a combat environment ... Therefore, when our colleagues from JSOC CERT told
several stories on cyber incident investigations, we in the Pentest department decided to keep up and show the other side of the “barricade” »: Customer’s infrastructure through the eyes of a hacker. Today we’ll tell you about the most interesting external pentests in recent times, when we had to penetrate the internal perimeter of the customer, having only a list of his external IP addresses and domain names.
- Guys, start faster with a pentest - you only have 3 weeks to hack us. But keep in mind that your chances are minimal: they check us every year and find no clues.
After 4 hours:
“We are already inside.”
- Come on? It can not be! Now let's check the logs ...
- Damn, really. How is that?! But since time did not work out, maybe you will look for something else?
- Sure, not a problem.
And we began to search. Scanning the perimeter of the organization, we came across a host on which 4 web applications were spinning, an FTP server, and the phpMyAdmin admin panel hung. The analysis of web applications did not reveal any critical vulnerabilities (for example, SQL injections, XXE, RCE, etc.) that would allow us to access the server. At some point, they switched to FTP - and here it was already more interesting: anonymous access was opened on the server, but only for reading.
For several days, we examined the contents of the server and found some strange lines in the logs - several incorrectly entered passwords for one of the admins of the web application.
Based on the wrong options, we made an assumption about what the password should look like, and it came up. We decided to try it for phpMyAdmin, and - oh, a miracle - it also came up. Next, it was a small matter - upload the shell, gain access to the internal network, gain a foothold there and develop already inside.
This is how ordinary laziness (and how else to explain the reluctance to enter different passwords for each admin panel?) Paves the way for hackers to the organization’s internal network.
Why debug in a combat environment?
Most of our breakthroughs occur through web applications, and often we come across curious “remains” of development and testing times. Often we find logs, some pieces of debug-modes, but not always with their help we managed to conduct RCE (remote code execution).
During one of our clients, we discovered a CRM system on which we decided to spend a little more time (and, I must say, it later paid off). Carrying out the analysis of the application, we found the remains of the tests, which, apparently, were used at the development stage. Authentication occurred in them in a very miraculous way: only the username and the fact of passing a parameter containing some password were checked. Five minutes of searching and reading standard documentation - and we have in our hands the name of the built-in superuser account. Filling the shell was already a matter of technology.
Another example. At the start of the project, we launched a recursive bruteforce of subdomains and left it. After some time, to our surprise, a fifth-level subdomain called test.debug.application.client.ru came up, on which we found a web application with Adminer installed there. This is a lightweight database administration application, in the old versions of which, with incorrect settings, you can interact with a SQLite database without a password.
The fact that there was no data in this database was not important - after all, in SQLite you can create a database on an arbitrary path with a simple web shell inside, thereby gaining the ability to conveniently manage the server and execute commands on it from a web page.
All that remained was to find out the full address of the web application on the server. Here we were helped by all the “beloved” CMS 1C-Bitrix, which, in an error message, gladly shared with us where it is located. Then it only remained to fill the shell and finish the project.
Work with SQLite DB can be viewed here
Found logs? Passwords as a gift!
A customer asked us to conduct a pentest of a web application. For the previous three years, he held pentests with another team and probably managed to patch some of the holes on the perimeter, so we did not expect quick success.
During the fuzzing of the web application, we found a page on which user authorization was logged. The time and login of the user who logged into the application was displayed in the log. We wrote a script that once a couple of minutes polled this page, parsed the response and wrote down the logins found in the file. After a few days, we managed to collect about a hundred logins. We decided to start the selection of passwords - for 5 logins they were found in the list of TOP-500 worst passwords
Having gained access to the application, we continued to analyze it and found another interesting file - all real-time database queries were displayed in it. With such a convenient debugging tool, searching for vulnerabilities and exploiting the found Boolean-Timebased SQL injection has
become a trivial task.
Despite the fact that it's already 2019, people still believe that storing passwords in a database in an open form is a good idea. We use this and found SQL injection and get an administrator account with which to fill in the web-shell and open access to the internal network of the organization was not a big deal.
First, conduct periodic penetration testing - they will help you find thin spots that you might have missed at the development stage or when moving from test environments to combat ones.
Secondly, always consider the human factor: people are just too lazy to change passwords, and they can even use one password on several sites. Yes, yes, admins also sin this.
Third, remove debugging modes in combat environments.
In general, the everyday life of the Pentest department is full of all kinds of “entertainments” and, of course, external tests are not the only one. The customer may wish to check for vulnerabilities of the internal perimeter (internal pentest), or analyze the security of web and mobile applications, as well as WiFi networks, or arrange for employees to check using social engineering methods.
In our free time from projects, we
look for new vulnerabilities, improve our tools and techniques. And we are engaged in a bugbounty (where without it).
You will learn about the diversity of our “adventures” in the following posts.