Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Worms Security The Internet

Worm Hits Windows Machines Running MySQL 367

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'."
This discussion has been archived. No new comments can be posted.

Worm Hits Windows Machines Running MySQL

Comments Filter:
  • by sanityspeech ( 823537 ) on Thursday January 27, 2005 @12:29PM (#11493090) Journal
    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.

  • by Mad Merlin ( 837387 ) on Thursday January 27, 2005 @12:30PM (#11493106) Homepage
    How often does your database have to talk directly to the outside world? The port should be closed to the outside world most of the time.

    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.

  • Re:Windows (Score:4, Informative)

    by Directrix1 ( 157787 ) on Thursday January 27, 2005 @12:32PM (#11493147)
    Only because people don't know about Firebird.
  • Re:Windows (Score:4, Informative)

    by UnderAttack ( 311872 ) * on Thursday January 27, 2005 @12:32PM (#11493148) Homepage
    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).
  • What? (Score:2, Informative)

    by Anonymous Coward on Thursday January 27, 2005 @12:33PM (#11493150)
    Do you realize how much of a pain it was to get postgres working on Windows until fairly recently?
  • by enoraM ( 749327 ) * on Thursday January 27, 2005 @12:33PM (#11493155)
    Actually we have seen this before with MySQL in the beginning of 2003:

    SELECT INTO outfile was buggy up to 3.23.55
  • I got hit (Score:5, Informative)

    by LiquidCoooled ( 634315 ) on Thursday January 27, 2005 @12:33PM (#11493161) Homepage Journal
    My test server was compromised at 18:50 yesterday.
    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/avcente r/venc/data/w32.spybot.worm.html'>w32.Spybot.worm.

  • Re:Windows (Score:5, Informative)

    by gmuslera ( 3436 ) on Thursday January 27, 2005 @12:35PM (#11493187) Homepage Journal
    I'll bet that the worm takes advantage of default installation of MySQL made by PHPTriad [sourceforge.net] or another "easy" way to install under windows mysql along with i.e. php and apache for this case

    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.

  • Re:Windows (Score:4, Informative)

    by _xeno_ ( 155264 ) on Thursday January 27, 2005 @12:38PM (#11493235) Homepage Journal

    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.

  • Re:Windows (Score:2, Informative)

    by weopenlatest ( 748393 ) on Thursday January 27, 2005 @12:39PM (#11493250)
    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.
  • by hacker ( 14635 ) <hacker@gnu-designs.com> on Thursday January 27, 2005 @12:43PM (#11493300)

    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.

  • Some info (Score:5, Informative)

    by Squeebee ( 719115 ) <squeebee@[ ]il.com ['gma' in gap]> on Thursday January 27, 2005 @12:46PM (#11493328)
    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.

    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/200 5/01/batten-the-hatches-mysql-targeting-bot-on-the -loose/
  • temporary fix (Score:5, Informative)

    by greechneb ( 574646 ) on Thursday January 27, 2005 @12:47PM (#11493340) Journal

    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.
  • Re:Windows (Score:4, Informative)

    by Tony Hoyle ( 11698 ) <tmh@nodomain.org> on Thursday January 27, 2005 @12:55PM (#11493462) Homepage
    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).
  • Re:I don't get it (Score:5, Informative)

    by Qzukk ( 229616 ) on Thursday January 27, 2005 @12:57PM (#11493486) Journal
    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 [securiteam.com] 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.
  • Re:Windows (Score:1, Informative)

    by Anonymous Coward on Thursday January 27, 2005 @01:05PM (#11493570)
    >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."
  • by Squeebee ( 719115 ) <squeebee@[ ]il.com ['gma' in gap]> on Thursday January 27, 2005 @01:07PM (#11493584)
    Non-Windows installations are not vulnerible.
  • by Abcd1234 ( 188840 ) on Thursday January 27, 2005 @01:17PM (#11493715) Homepage
    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?
  • Re:Windows (Score:4, Informative)

    by cbiltcliffe ( 186293 ) on Thursday January 27, 2005 @01:38PM (#11493971) Homepage Journal
    MySql is expensive too (300 per client, unless you want to GPL all your software).
    No, $300 per server, and you don't have to GPL anything unless you redistribute it with the freely downloaded MySQL.
  • by LetterJ ( 3524 ) <j@wynia.org> on Thursday January 27, 2005 @01:48PM (#11494093) Homepage
    I rewrote PHPTriad, securing the default password for root and did so 3 years ago. The new product is Sokkit [sokkit.net]. However, Sourceforge won't let me take PHPTriad down, point to the new commercial version or in any way indicate the project has been shut down.

    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.

  • Re:Windows (Score:2, Informative)

    by forrestt ( 267374 ) on Thursday January 27, 2005 @01:51PM (#11494126) Homepage Journal
    Or maybe it was Linux.... I could swear the reason I dismissed it was over that... maybe I'm just crazy.

    This is from MySQL 3.23.58 on Linux
    mysql> select firstName from person where firstName = "Forrest";
    +-----------+
    | firstName |
    +-----------+
    | Forrest |
    +-----------+
    1 row in set (0.00 sec)

    mysql> select firstName from person where firstName = "forrest";
    +-----------+
    | firstName |
    +-----------+
    | Forrest |
    +-----------+
    1 row in set (0.00 sec)
    So, yes it is case INsensitive. (But I can't really do anything to prove your sanity) :)
  • Re:Windows (Score:4, Informative)

    by ajs318 ( 655362 ) <sd_resp2@earthsh ... .co.uk minus bsd> on Thursday January 27, 2005 @01:52PM (#11494137)
    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.

    Upshot: if you copy a scrambled password from one user to another, or out of /etc/shadow into a .htpasswd {apache password file; used to password-protect directories} or something similar, it'll Just Work.

    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 .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.

    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.
  • by Naikrovek ( 667 ) <jjohnson.psg@com> on Thursday January 27, 2005 @01:52PM (#11494138)
    It doesn't. You have to configure it to allow non-localhost connections.
  • Re:That's why... (Score:4, Informative)

    by Anonymous Coward on Thursday January 27, 2005 @01:59PM (#11494240)
    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.
  • How I Found This (Score:1, Informative)

    by Anonymous Coward on Thursday January 27, 2005 @02:35PM (#11494694)
    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.
  • Re:Windows (Score:2, Informative)

    by Neil Blender ( 555885 ) <neilblender@gmail.com> on Thursday January 27, 2005 @03:01PM (#11495017)
    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 |
    +---------+
  • Re:Clarity (Score:1, Informative)

    by Anonymous Coward on Thursday January 27, 2005 @03:22PM (#11495249)
    > 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.
  • by Anonymous Coward on Thursday January 27, 2005 @03:24PM (#11495276)
    Extremely easy to do using ipsec (on Windows XP & 2000), allow me to demonstrate:

    ipsec -w REG -p "filter" -r "MySQL" -f *+0:3306:TCP -n BLOCK
    ipsec -w REG -p "filter" -x

    Bam; all outside connections are now dropped.

    Enjoy.

    (Note: You might have to use ipseccmd or some other quirky name.)
  • by MyHair ( 589485 ) on Thursday January 27, 2005 @04:18PM (#11495837) Journal
    Jan 27 09:57:27 (fakehostname) mysqld[338]: refused connect from 217.224.(#).(#)

    Jan 27 09:57:47 (fakehostname) last message repeated 21 times
    (A few more like this were in the log.)

    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....
  • by wolrahnaes ( 632574 ) <sean.seanharlow@info> on Thursday January 27, 2005 @06:02PM (#11497243) Homepage Journal
    "so disabling networking is not really viable on Windows is it?"

    I don't know about other services, but MySQL on Win32 supports named pipes, and can use those instead of TCP/IP. It even asks in the installer if you want to disable networking.
  • Re:That's why... (Score:1, Informative)

    by Anonymous Coward on Thursday January 27, 2005 @07:56PM (#11498579)
    PostgreSQL won't run under the root account, specifically to avoid being exploited in this way.

    PostgreSQL 1, MySQL 0.

And it should be the law: If you use the word `paradigm' without knowing what the dictionary says it means, you go to jail. No exceptions. -- David Jones

Working...