Category: Security

Fully disabling remote access to root on MariaDB

An OpenVAS vulnerability scan helped me recently identify a DB that had a 9.0 rating and was allowing remote access to the root account. Thankfully the DB was not accessible to the Internet, but the ease of lateral movement inside a server network couldn’t be allowed. So I went about responsibly mitigating this vulnerability, which I did not expect to have taken as long as it did. Turning off remote access should be easy, even thought I’m not a DBA, I felt confident this would not be that difficult. I read the free manual and didn’t not see any major challenges.

 

First off, I’m not a DBA, second this was the first install of mariaDB that I knowing was getting involved with. I don’t think the differences between MySQL are that significant, but I had to keep it in mind.

First step was to change the root password. At least make sure it wasn’t using the default password of password to log in. Seriously. I don’t know if this is set this way by mariaDB during installation, or was set by the application using the DB.

Changing the root password was insufficient. The scan still returned the vulnerability existed. Turns out I had only changed it for the localhost version of root. I was interested to learn and understand that different DB users can share the same login name, so long as their hosts are different.

So then I changed the password for 127.0.0.1, and and ::1 to account for the IPV6 change. This was still insufficient to stop the vulnerability from showing up.

I modified the my.cnf and still had no success.

I had to manually verify this existed, something I should have done earlier. It’s always possible for a vulnerability scan to show a false-positive, and every finding should be checked out before reporting it. All the verification necessary came from a different host with a simple command:

mysql -u root -h 10.20.30.xx -p

And I had root access to the DB application running on this host. And of course with MySQL access and root DB permissions, it wouldn’t be difficult or long for someone to take control of that server. This was getting frustrating. If the hashes in the mysql.user table were clearly showing that the password was changed, then what was I missing?

At this time I need to remember that I am not a DBA, and I had no clue that there was a “ghost” user in the system. I say ghost because the username actually had no value, but they could access the system from any IP address.

Thankfully I found this post https://dba.stackexchange.com/questions/4614/cannot-drop-anonymous-user-from-mysql-user. Suddenly I realized that this wasn’t as much of an issue with being able to log in as root, rather it was blocking anonymous access to the DB. Semantics? Part of me is curious if I could have logged in with a username of PapaJohn and had it work.

Quickly removing that user from the mysql.user table was all it took to mitigate that vulnerability.

DELETE FROM mysql.user WHERE user='' AND host='%';
FLUSH PRIVILEGES;

 

I did learn today that anonymous access exists on a default MySQL or MariaDB installation. I learned that there is a test DB created by default that needs removing also. An excellent writeup on how to clean a default installation can be found here: https://www.loginradius.com/blog/engineering/is-your-database-secured-think-again/.

I am grateful that this is solved, and I’m thankful I don’t have to scold the application developer for having done this. I am troubled however at a new installation being left open to the wild by default. This is a solid reminder that the need for highly trained engineers is greater than ever, for this inexcusable default configuration for MySQL will not be caught in many of the SMBs that I have traditionally supported. Only due to a vulnerability scan did this even get flagged for the customer, and only through persistence did it get mitigated. A highly trained DBA should have known this in-advance, and known to delete these items immediately after a fresh install. Sadly I think the MySQL and MariaDB communities are doing a disservice to SMBs that lack dedicated DBAs and trust in the communities to provide software that is secure enough to use.

 

So for anyone that needs to search why they can log into a MySQL DB server remotely using the root account and the default password, consider that it may have nothing to do with root at all. Disable anonymous access to the DB, and then worry about changing the password for root.

Commercialization of Facial Recognition will eliminate privacy for the future generations

Individual privacy in the face of artificial intelligence, biometric facial recognition, and big data is increasingly under threat of disappearance from our government, technology companies, and society’s own best intentions. Unnecessary government intrusion into the private lives of citizens in the United States is a right protected by law. Due to extra-governmental advancements in biometrics and facial recognition technology, circumvention of the law is being made possible. Often the desire for additional surveillance technology comes from society’s perceived need for additional security through detection and observation. Long-term implications on individual privacy and the negative consequences of privacy loss from forming a surveillance society will be most damaging to the children and grandchildren of today.

Read more