MySQL 0-day info

[S3cur|ty4ng31]

Im trying to find information about the new 0-day MySQL exploit thats starting to grow in the wild. I would appreciate any links, code, or packet captures you might have.

Also if you are running MySQL upgrading might not help at this time. So your best bet would be to move the SQL port to something other than the standard 3306 or harden your security mechanisms on who is allowed to connect on that port.


-- fyi --
Before you decide to flame me, I will use this information to create snort sigs which I will then release back to the community, which I have done in the past.
-- end fyi--

**edit
well after searching I found this here so if you have any more info than this that would be great

http://www.antionline.com/showthread...hreadid=265605

[ric-o]

It's not a 0-day sploit...it just takes advantage of weak passwords. Check out below quotes taken from the Internet Storm Center (http://isc.incidents.org )

The bot uses the "MySQL UDF Dynamic Library Exploit". In order to launch the exploit, the bot first has to authenticate to mysql as 'root' user. A long list of passwords is included with the bot, and the bot will brute force the password.

Mitigation
This bot does not use any vulnerability in mysql. The fundamental weakness it uses is a week 'root' account. The following mitigation methods will prevent exploitation:

/edit:
doesnt look like they have snort sigs yet but you can create one probably easily from the info they provide.
enjoy

[Tiger Shark]

Further mitigation is to restrict root to local login only if the MySQL is on a publicly accessible server. I can't tell you how 'cos I'm not that well versed in My SQL but I do use it on internal, hardened boxes.... So the threat got my interest but then lost it somewhat when i realized my password isn't crackable from a list that an exploit might carry....

[jonathans_daddy]

Got my interest too at first. My passwords would never show up in a list either. But neither is port 3306 traffic allowed in through firewall. Oh well... at least there was something to make the day interesting even if only for a few minutes.

[sec_ware]

Hi

No comments on the "exploit" at this point, but for those who
are interested, a brief explanation of the access control strategy
of mysql.

Essentially, there are two steps:

- Connection verification

The client host, username and password are verified. These information
are stored in the table user at the database mysql. The password is
stored as a hash (16 or 41 byte). In order to allow the subnet
216.239.57.0-216.239.57.255 for the user the_creator, an entry like
"Host=216.239.57.% , User=the_creator, ..." has to be created.

- Request verification

Any operation, performed by a host/user-pair can be allowed/disallowed.
Additional reading[1].

I always recommend the minimal action principle, in the sense:
"One user to create, another user to delete." What do you think?
And never ever allow "%" as host. ("%" is a wildcard). There always
are ways to access the db from anywhere on the world.

Cheers


[1] http://dev.mysql.com/doc/mysql/en/privilege-system.html

[chsh]

I guess it just goes to show that everyone infected has THREE fatal flaws in their administration:
1. They're too stupid to keep their database servers off the 'net.
2. They're too stupid to use complex passwords
3. They're too stupid to keep their installations up to date.

MySQL has an advisory up about it now: http://dev.mysql.com/tech-resources/...ity_alert.html

[Tiger Shark]

I guess it just goes to show that everyone infected has THREE fatal flaws in their administration

I think that comment applies to 99% of all infections with any kind of exploit.... Points 2 & 3 especially.....