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!
Only because people don't know about Firebird.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
Well, Apache, PHP and MySQL run just fine in Windows. Many people run Linux on servers, but Winows on Developer desktops (which then have Apache, php and mysql installed).
---- join dshield.org Distributed Intrusion Detec
Do you realize how much of a pain it was to get postgres working on Windows until fairly recently?
Actually we have seen this before with MySQL in the beginning of 2003:
SELECT INTO outfile was buggy up to 3.23.55
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.
Exactly. There are something like seven developer systems running Windows that have MySQL and a web server on them for webapp development in the section I work for. Then, later, the webapp gets uploaded to a Solaris machine where the users actually use it.
I also have MySQL on my home Windows machine, since that's what my hosting provider offers. So I do some basic testing on Apache on Windows with MySQL as the database backend.
You are in a maze of twisty little relative jumps, all alike.
I use mysql at the web shop I work for. The reason is that we're in the process of moving a legacy ASP application to LAMP, and running both PHP and ASP on the same box was SUPPOSED to be a timesaver by smoothing over the transition. I was against this idea from the beginning, arguing that mysql and php on windows were a underdeveloped compared to the linux/unix versions. Now I have a nice 'I told you so' that the managers can understand.
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.
90% of tasks can be handled by the free MSDE install.. there's a 2GB limit, but a lot of tasks simply don't need that kind of size.
MySql is expensive too (300 per client, unless you want to GPL all your software).
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.
>Who'd use MySQL on Windows though ?
As per ISC (SANS) thousands of machines have it.
"A "bot", exploiting vulnerable MySQL installs on Windows systems, has been spotted. It infected a few thousand systems so far."
Non-Windows installations are not vulnerible.
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?
"City hall" in German is "Rathaus" Kinda explains a few things......
The only reason I left it alone in the old PHPTriad package was that was how MySQL themselves ship the setup. The official MYSQL binaries have (unless it's changed very recently) *no* password on the root account unless you deliberately go and change it.
Even today, I get constant complaints because I secure the root account, even though I ask them to supply the password.
The Glass is Too Big: My Take on Things
This is from MySQL 3.23.58 on LinuxSo, yes it is case INsensitive. (But I can't really do anything to prove your sanity)
Linux passwords are scrambled, but the root user can read the scrambled password file. The first part of the scrambled password ($1$, eight letters/digits, $) is the "salt". The same plaintext password and the same salt will always produce the same scrambled password. The password scrambling algorithm is a standard C library function, so almost every programme uses it, not just the login validator.
/etc/shadow into a .htpasswd {apache password file; used to password-protect directories} or something similar, it'll Just Work.
.htpasswd file when it is installed, and it uses root's UNIX password. Note you still have to supply PHPMyAdmin with a MySQL username and password. By default, MySQL has a user called "root" with no password who is only allowed to login locally. This is considered secure enough for most applications.
Upshot: if you copy a scrambled password from one user to another, or out of
MySQL actually uses a different password hashing algorithm, unless you tweaked the source, but I think the parent is talking about PHPMyAdmin. This creates a standard
NB: it's generally a very bad idea to use the same password for login and database. One dodgy web hosting company I have experienced actually did this. The MySQL username and password have to be in your user directory somewhere, in plaintext, and they have to be world-readable so the Apache daemon can see them. Upshot: any user can see any other user's database username and password. {This is why the root/no password combination isn't so insecure as it looks.} Ordinarily, the PHP {or Perl or Python} interpreter gets them first, and the user only ever sees the output from the interpreter; but you can pay for an account with the same company, determine the directory structure reasonably easily, and use a simple PHP, Perl, Python or Bash script to traverse other users' directories looking for passwords. If the database username and password is the same as the UNIX password then you can have much fun, since these passwords are also good for FTP, POP3 and SSH.
Je fume. Tu fumes. Nous fûmes!
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.
I'm doing an audit of a 2000 machine and discover that it appears to have MySQL installed and is running a service for it. Which weirded me out, because I DEFINITELY don't run MySQL, I'm a POSTGRES guy.
It appears that some adware that had dropped itself on the machine had downloaded and installed it for me (one of my users is an idiot).
THEN the worm was able to load itself onto my machine.
Make sure to check all your machines, not just the ones that should have SQL running on them.
you have to use 'binary' for case sensitive searches.
mysql> create table name ( name char(10) );
Query OK, 0 rows affected (0.05 sec)
mysql> insert into name ( name ) values ('Forrest');
Query OK, 1 row affected (0.00 sec)
mysql> select * from name where binary name = 'forrest';
Empty set (0.01 sec)
mysql> select * from name where binary name = 'Forrest';
+---------+
| name |
+---------+
| Forrest |
+---------+
> I consider it a flaw in mysql. They basically
> turned a database server into a shell account by
> allowing:
> 1. Blobs to be inserted into a table. (No checking)
* Assuming you connect with a username, password and hostmask matching what you've allowed to log in.
* Have access to CREATE a table
* Have access to INSERT into said table
> 2. Contents of tables to be written to disk (No checking)
You need the FILE privilege GRANTed to be able to write *anything* to disk, and there are checks so that you cannot overwrite or append to existing files.
It also requires the mysqld process to have write access to the file system (running as root or a a service account of some kind)
> 3. Starting (just written from the DB) files to be executed at will.
For this to work you need to have access to create UDFs and also to execute said UDFs.
D'oh! Didn't realize I had it open. At least I'm on Linux and don't have a blatantly obvious root password. PostgreSQL installed with IP off by default; I guess MySQL didn't. I don't even rememeber why MySQL's installed...some php toy I guess. PostreSQL and MSSQL ports are already blocked even though I don't have MSSQL.
Time to update the firewall (dedicated and local), MySQL config and revisit password strength. Maybe I should finally go to a deny by default policy....
PostgreSQL won't run under the root account, specifically to avoid being exploited in this way.
PostgreSQL 1, MySQL 0.