How Forgotten Resources Can Become a Door to the Intranet
We recently reported on the successful participation of UCSB experts in the Pentest Award for penetration testing specialists and promised to return with a detailed description of the interesting cases that our pentesters participated in.
In this article, we will share how one of our customers' pentesters discovered a vulnerability in time that potential attackers could use to gain a foothold in the internal corporate network.
Using this case as an example, you will be able to learn about new attack vectors, assess the risks to your infrastructure, and find tips on how to eliminate such vulnerabilities and increase the level of security.
Intelligence
In one of our projects, we conducted reconnaissance over a scope of several thousand IP addresses.
One of the reconnaissance tasks was to collect old or forgotten domain names using the Passive DNS technique.
Passive DNS – a set of records containing the results of DNS resolution for domains to the corresponding IP addresses.
One of the services that provides access to Passive DNS data is VirusTotal. By writing a small script that sends requests to the VirusTotal API, we collected quite a few interesting domain names.
It was as a result of collecting domains using Passive DNS that the very forgotten web service was found, which later turned out to be vulnerable. The domain name of this service was literally five-story, let's call it this way: web1.smth.smth.companyname.com.
This was a self-written service for monitoring some other services, which, judging by the logs, was last accessed about a month ago. We gained access to it using default credentials, created a separate administrator account for further testing and, of course, notified the customer's information security department about the vulnerability.
The next day, the information security department closed the vulnerable resource, although at the same time there was a request from the customer to continue testing this web application. Well, no problem – we continue to study the endless outer perimeter.
Now one important point: before the information security department disabled the vulnerable service, we parsed all user credentials that were stored in plain text directly in the HTML markup. Naturally, administrator accounts were among them.
Here, for example, is what a piece of the user list looked like:
And here's how the password was stored:
We used the obtained accounts on other company resources. Half of the users actually existed, but the passwords had been changed long ago.
But let's return to further study of the outer perimeter. One of the parallel tasks was to enumerate subdomains using gobuster. After some time, the L4 domain already familiar to us reached it along the conveyor *.smth.smth.companyname.com and… voila! The same resource was found, but with a different alias – let it be called vulnerable.smth.smth.companyname.com.
Alias — an additional name that gives the user access to content from the main domain without redirection.
Search for vulnerabilities and flaws
There were no default admin credentials here, so we used the admin account from the resource dump we had made earlier. web1.smth.smth.companyname.com.
We get access, analyze the application – find SQL injection. The discovery was made already in the evening, at first we managed to implement error-based SQLi and blind (time-based) SQLi. We could also read local files using the built-in MS SQL function – OpenRowset.
The OpenRowset function in MS SQL can read data from a file without loading it into the target table.
The Path to RCE
In the evening of the same day, we completed the injection to Out-Of-Band using the following payload:
In general, nothing supernatural – in one line we assign an arbitrary variable, assign the hostname of the remote server to the variable, and send it for execution using the exec function. We had to do a little magic with the hostname, most likely the WAF blocked requests to *.oastify.com. With the help of simple manipulations – dividing the FQDN into parts and concatenating the strings – we get a response to the remote server.
To further develop the attack, it was necessary to solve two problems:
– get rights to use the xp_cmdshell function,
– bypass network restrictions: all TCP traffic was dropped, only DNS requests using UDP were passed.
We sorted out the first issue pretty quickly. Using the master database, we configured the use of xp_cmdshell, since we had a service account at our disposal. sawhich by default has write permissions to the database masterThis was achieved using a classic payload: use master; sp_configure 'xp_cmdshell', '1'; RECONFIGURE.
The reconfiguration process was successful, now we can execute the code remotely.
Fixing
Now it remains to solve the issue of obtaining a session and fixing it. It was not possible to obtain a regular reverse shell due to network-level restrictions. Therefore, we turned to our well-known colleague and comrade for help @s0i37. Very the article was useful about methods of transferring files via DNS, as well as the client-server itself for DNS shell.
It remains to be seen how we can convey .vbs client to web server. After some thought, we came to the conclusion that we only have one option – encode .vbs-script in base64 and line by line transfer to a file via Burp Intruder. Then, using certutil, we decode the file and get a working DNS client.
This is roughly what the line-by-line file transfer looked like:
And this is how we decode the DNS client file on the server side:
A session was obtained using DNS shell. On the advice of our infrastructure engineers, we checked network access from the compromised machine to the DC and found that SMB communication was allowed:
All that's left to do is to perform a local privilege escalation and hand over the machine to fellow internal infrastructure testing specialists.
In local elevation, we will be helped by the enabled SeImpersonatePrivilege, we take an exploit from the “potato” family or PrintSpoofer, we increase our privileges and pass the machine to our colleagues.
Conclusion
List of vulnerabilities in the chain:
1. Using dictionary passwords
2. Insecure storage of passwords
3. Error-based SQL injection
4. Enabled SeImpersonatePriveleges privilege for the service account
This is what the complete perimeter “breakthrough” scheme looks like:
What lessons can be learned from this case?
First of all, dictionary passwords should not be allowed, so it is necessary not only to implement password policies, but also to monitor their compliance.
It is also obvious that storing passwords in plaintext, much less in page markup, is a bad idea. Also, remember to use parameterized queries to avoid SQL injections.
Finally, the last links in the chain show how important it is to disable account privileges if they are not necessary – in particular privileges like SeImpersonate Privilege.
Author: Semyon Tumashev, security analysis specialist at the Central Security Service.
