Secure your databases against opportunistic attackers
If you connect databases / servers to the internet and secure them poorly, you can count on them getting compromised quickly.
According to findings by Radoslaw Zdonczyk, Security Researcher at Trustwave SpiderLabs, there will be login attempts even before the systems’ IP addresses get listed by internet scanners like Shodan and BinaryEdge, and once that happens, their number will grow.
Hackers are ready to pounce
For his experiment, Zdonczyk deployed two MySQL and MariaDB servers and made them available on the default MySQL/MariaDB port (TCP/3306) with a fake root account and an easy-to-guess password.
He configured the root account with low (but not minimal) permissions and kept the default configuration, but enabled event logging. He also created a few standard and non standard databases with tables to make the honeypots resemble a production environment.
In the course of one month, he registered bot-driven login attempts from 24 unique IP addresses. “Some addresses simply disappeared after a successful bruteforce, and then, after some time [a] connection from new IP managed to log in at the first attempt,” he found, and deduced a link.
The bots did not bombard the servers with hundreds of thousands bruteforce attempts, making it obvious that the bot-wielding opportunistic attackers know that slowly checking popular passwords can result in them getting access to enough servers.
Don’t provide easily exploitable resources for attackers
What do the attackers do with that access?
According to Zdonczyk, they try to make sure that they will have permanent access by downloading a (plugin) backdoor and placing it in multiple locations, and attempt to hide malicious activity on the servers. They also try to grant all possible permissions to the root account and create new ones, as well as kill various processes to prepare the ground for a new attack.
“Although I didn’t observe any activity indicating that the attacker was downloading files, databases, or attempts to encrypt a drive (ransomware), the main goal of the attack was to take control of the server (partial or complete) and establish a CNC channel,” he noted.
What will the attackers use these servers for?
“[They] can be useful for performing further attacks, but as for the rest, we can only speculate,” Zdonczyk told Help Net Security.
“The list of possibilities can be endless, but the compromised server will most likely become another botnet peer, which can be used in DDoS attacks and other campaigns.”
Security advice for database administrators
This type of attack is certainly not a threat to well-administered databases, he noted. Unfortunately, there are always (too) many that aren’t.
“Service on the internet edge is always challenging with the use of virtualization and containerization technologies. I recommend using long, complex passwords (if possible, using certificates) and not obvious usernames (‘root’, ‘admin’). This should be a standard practice today,” he advised.
“In terms of the user/groups/feature/component permissions review – the most restricted, the better. Using database security audit scanners (e.g., AppDetectivePro) and VPN solutions (e.g., P2P, OpenVPN) is a wise choice. Compliance with CIS or STIG security standards is also recommended.”
When it comes to securing a database, the process depends on many factors: database size and purpose, deployment type, and so on, he added.
“Instead of listing specific plugins or configuration options, fortunately, the internet is full of good documents describing this topic. I recommend performing a good security audit. You need to perform an audit that will cover not only the database area but the entire organization.”
CISOs and database administrators can use this article to quantify the level of security of their databases and to identify steps to improve it further.