8

A little background: We've just had our PBX system hacked. The server itself seems secure (no logged unauthorised console access - SSH etc), but somehow the hackers have managed to inject a new admin user into the PBX software (FreePBX, backed by MySQL). Apache logs imply that the hackers managed to add the user without using the web interface (or any exploit in the web interface).

Now, I have since discovered that MySQL was running without a root password (!!) and openly bound to the external IP address (Obviously, I have locked this down now). However, the only root level user in MySQL was 'root'@'localhost' and 'root'@'127.0.0.1', both of which should only have been accessible locally.

So, my question is this:

Is there a way of spoofing a connection to MySQL so that it will allow connection to the 'root'@'localhost' user from a remote IP address, WITHOUT running any other exploit locally?

For reference, the box is Centos 5 (Linux 2.6.10) running Mysql 5.0.95.

TFk
  • 83
  • 1
  • 4
  • Would be better suited to ServerFault - offtopic here. – kapa Jul 18 '12 at 10:31
  • I wasn't sure - my personal feeling was that as it's less about server configuration/administration problems and more about trying to exploit a potential bug in MySQL that it might fit better here. Apologies if people think I'm on the wrong site/section for this. – TFk Jul 18 '12 at 10:47
  • 2
    Actually, it probably belongs in http://security.stackexchange.com/ –  Jul 18 '12 at 11:20
  • 1
    You say "the only root level user was root@localhost", however, were there other users? You don't need a root level user to add a record. Also, you should look for vulnerabilities in FreePBX like [this one](http://www.offensive-security.com/vulndev/freepbx-exploit-phone-home/). – Marcus Adams Jul 18 '12 at 13:17
  • The exploit in your link has been patched in my FreePBX version, but yes, I agree that FreePBX vulnerabilities are the most likely entry point, except I can't find anything in my Apache access logs consistent with any of the (unpatched) known vulnerabilities. Good point with other users - the only other user in the db was asterisk, which has a (non-default) password. If this was the entry point, then this again points at a (possibly unreleased) FreePBX vulnerability. The "no root password" just seemed such a large hole, compared to a new undocumented FreePBX exploit. Hence, my question/post. – TFk Jul 18 '12 at 14:41

3 Answers3

2

The name root is created by default and is very well known. The literal value root does not have any significance in the MySQL privilege system. Hence there is no requirement to continue with the user name root.

You should change root user name to something else so that outside world will not be able to identify (guess) it easily, this will reduce hacking attempts.

For example: If you have a user as root@localhost which is quite known to everyone hence hackers will try to connect it, you should change it to something specific like admin_db_name@localhost for better security.

Monitor a status variable called Aborted_connects periodically to know Refused connection to your MySQL server, it should be 0 after Flush status; command and should not increase further.

show status like 'Aborted_connects';

Mahesh Patil
  • 121
  • 3
2

Does "no logged unauthorised access" include fail login attemps? If not, it could be CVE 2012-2122.

[...] when running in certain environments with certain implementations of the memcmp function, (MySQL) allows remote attackers to bypass authentication by repeatedly authenticating with the same incorrect password, which eventually causes a token comparison to succeed due to an improperly-checked return value.

samuirai
  • 141
  • 1
  • 3
  • My "no logged unauthorised access" was woefully ambiguous - I meant that no attacker had managed to get console access to the server (e.g. over SSH). Also, it appears that Centos builds aren't affected (), but certainly the kind of thing I've been looking for. – TFk Jul 18 '12 at 12:10
1

No.

MySQL will never log you in to a user with the localhost or 127.0.0.1 host specification if you aren't coming from the local system. Note that this also covers the auth bypass vulnerability, CVE 2012-2122; the password comparison might be tricked, but the host comparison is not.

You'd need something on the system to proxy off of to "trick" the source host checking. Something like phpmyadmin, or a load balancer like HAProxy running in front of the MySQL TCP port come to mind.

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • That's what I suspected, which means, as bad a blank root password is, it probably wasn't the exploit. Always good to get informed opinions - Many thanks. – TFk Jul 19 '12 at 10:34