Slashdot Mirror
Worm Hits Windows Machines Running MySQL
UnderAttack writes "A report on the Australian whirlpool forum suggest that a worm is currently taking out MySQL servers running on Windows. We have seen this happen with MSSQL before (not just 'Slammer', but also SQLSnake that used SA accounts without password). The SANS Internet Storm Center suggests that a
rise in port 3306 scans can be attributed to the new worm, and is asking for observations to help figure this out. It appears the worm creates a file called 'spoolcll.exe'."
What is the SANS institute?
The SANS (SysAdmin, Audit, Network, Security) Institute provides information security training and certification. For more information, visit www.sans.org
What's an SA account?
The system administrator (SA) account is similar to the DBO except it is of the entire server. It has the same access and permissions as the DBO on all the databases in the server.
DBO account???
The DBO User Account The database owner (DBO) is the administrator for the database. It has full access to all operations and rights.
SQL Snake is an Internet worm, that scans for open Microsoft SQL 7 (MSSQL) and 2000 servers - which run on TCP Port 1433 by default. The worm attempts to log into the System Administrator (SA) account with no password. If successful, the worm downloads and hides some files and grabs system configuration and account names.
Before the MySQL bashers start, it should be noted that this is not a problem with MySQL.
From the article:
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:
Strong Password: Select a strong password, in particular for the 'root' account.
Restricted root account: Connections for any account can be limited to certain hosts in MySQL. This is in particular important for 'root'. If possible, 'root' should only be allowed to connect from the local host. MySQL will also allow you to force connections to use mysql's own SSL connection option.
Apply firewall rules: MySQL servers should not be exposed to the "wild outside". Block port 3306 and only allow access from selected hosts that require such access. Again, the use of ssh forwarding or SSL is highly recommended.
A hole in a program that communicates to the database and is accessable from the outside world would be a much more serious flaw I would imagine.
Game! - Where the stick is mightier than the sword!
My test server was compromised at 18:50 yesterday.
e r/venc/data/w32.spybot.worm.html'>w32.Spybot.worm.
When I got back to my machine at 19:20, I cleaned it down and found out what was happening.
All firewall logs etc and have archived the executable and dll files dropped.
One into the mysql data folder (app_result.dll), and the executable spoolcll.exe was dropped into windows.
Only now that I've gone into the archive folder has Norton picked it up and archived it (it had shutdown/ran the QConsole.exe NAV application to ensure Norton didn't find it, or it just wasn't in the definitions yesterday).
Its been detected as a href='http://securityresponse.symantec.com/avcent
liqbase
In linux by default in a lot of distributions being able to connect from network is disabled in mysql, or sets root password as php password, so the risk of that kind of worm (well, for systems that don't have even a basic firewall configured) is pretty low.
99.99% of people who run MySQL run it on the same machine as their webserver that queries it. Most people don't actually do queries across the network to the database server.
Just run MySQL with --skip-networking at startup (skip-networking in my.cnf), to disable MySQL from listening on port 3306. I know on most systems, its probably the default, but in almost all of the cases, its completely unnecessary.
And also, validate your input !! Don't just assume that whatever is passed on the URI field of a browser, is going to be correct. Check it. Then check it again.
Ok folks. This is a bot, and it uses weak root passwords to gain entry to MySQL. From there, it loads a BLOB in a table with a payload DLL, which it then writes to disk and loads as a MySQL UDF. The UDF is called, which creates the bot and the system is compromised.
0 5/01/batten-the-hatches-mysql-targeting-bot-on-the -loose/
Damage appears to be low as it is more spyware than anything, and you are only at risk if you A) Have not firewalled the MySQL Port, B) Have a root account that is allowed to login from anywhere, not just localhost, and C) Have a weak root password.
So, the fix is this:
A) Firewall port 3306
B) Remove the root@% account, only allow root@localhost
C) Set a strong password
I have more info at http://www.openwin.org/mike/index.php/archives/20
Open the Administrative Tools/Services app.
Find the "Event Monitor" service.
Open the Properties for this service.
You cannot pause or stop this service, so set the General/Startup Type to Disabled.
On the Recovery tab, set all 3 failure actions to Take No Actions.
Reboot.
Since the service didn't start, spoolcll.exe is not running.
Delete it (or whatever).
But, do not delete the service, as its existence will prevent new copies of the virus from activating.
Well, to spread it specifically uses weak default/unset DB admin passwords and MySQL running as a system or admin level task with write access to everything. Once the worm is in your server as the db admin password, it uses the db admin's ability to load a dll into mysql to allow it to perform actions outside of mysql.
See the details on this for information about what exactly is happening. There are plenty of DLLs on windows laying around that do all sorts of stuff, once you define a function call in MySQL to use a dll that allows you to execute whatever you want on the system, you win.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Good lord, are you kidding? I would assume any reasonable organization that was accessing their database over a network would keep the webserver on a DMZ and the database server behind a firewall that's tightened up and only allows access to the database from the DMZ. Isn't this, uh, kinda obvious? And, of course, if the database and the webserver are on the same box, *why* is remote access enabled at all?
Read the article. It's not exploting a security hole in MySQL. It's exploiting MySQL installations that:
a) Are not firewalled to the world (who'd make a DB accessible directly to the Internet?)
b) Allow root/admin connections from the outside.
c) Have weak root/admin passwords.
You can chalk this one up to careless admins - something I'm sure PostgreSQL is not immune to either.