MySQL Servers Hijacked With Malware To Perform DDoS Attacks (symantec.com)

An anonymous reader writes with news of a malware campaign using hijacked MySQL servers to launch DDoS attacks. Symantec reports: "Attackers are compromising MySQL servers with the Chikdos malware to force them to conduct DDoS attacks against other targets. According to Symantec telemetry, the majority of the compromised servers are in India, followed by China, Brazil and the Netherlands, and are being used to launch attacks against an US hosting provider and a Chinese IP address."

Comments

Only infects Windows MySQL servers?

[Anonymous Coward]

So that's like what, three?

Re:Only infects Windows MySQL servers?

[JustAnotherOldGuy]

Seeing as how MySQL is the second most popular database system in the world, it might be more than that.

Re:Only infects Windows MySQL servers?

[Z00L00K]

And putting a database exposed to the net for addresses other than the intended clients is the second fault. If you have only local client software then the database shouldn't be exposed at all.

Re:Only infects Windows MySQL servers?

[Anonymous Coward]

Most all of which runs on not-Windows.

Re:Only infects Windows MySQL servers?

[Major Blud]

AC is right, this only seems to infect MySQL running on Windows systems:

http://www.symantec.com/connec...

It modifies registry entries that fool with Termial Services and other nasty stuff. You should be safe on Linux/BSD.

Re:Only infects Windows MySQL servers?

[budgenator]

"The Linux version was installed onto computers that had been compromised by a Secure Shell (SSH) dictionary attack."
One would hope that only a few sandbox machines and almost no production machines were affected, but weak passwords are more prevalent that we would like to admit.

Re:Only infects Windows MySQL servers?

[Culture20]

And most of the Linux ones have their firewalls blocking 3306. The trouble with WAMP configs is the installers often open 3306 by default on the Windows machines' firewalls, and they also don't auto-update for security patches. A double-whammy.

Re:Only infects Windows MySQL servers?

[Bengie]

Regardless of the local server's firewall, the network firewall should be blocking everything by default, especially for the servers.

Re:Only infects Windows MySQL servers?

[Culture20]

WAMP is usually installed on desktop/laptop computers instead of servers. Often as a developer's testbed. Unfortunately, also in less restrictive networks.

Re:Only infects Windows MySQL servers?

[greenfruitsalad]

that's a nice chart you've found there. i found the ranking a little disconnected from reality but then i looked at the "ranking method" and felt satisfied i was right.

all is still well with the world, sqlite is still 10x more popular than all the competitors combined.

Re:Only infects Windows MySQL servers?

[JustAnotherOldGuy]

all is still well with the world, sqlite is still 10x more popular than all the competitors combined.

"And artificial sweeteners were safe, WMDs were in Iraq and Anna Nicole married for love."

Re: Only infects Windows MySQL servers?

[Anonymous Coward]

You'd have to be pretty lax in general to run a Windows server ...

Windows Servers hijacked with Malware ..

[nickweller]

"The attackers initially injected a malicious user-defined function (Downloader.Chikdos) into servers" ref

How does this trijan get executed on the host system.

Re:Windows Servers hijacked with Malware ..

[Gr8Apes]

Apparently via some other method. For Linux, the Chikdos attack is via an ssh login bruteforce attack.... gee, if I can login via ssh and have root, I've already pwned the server, MySQL would be my toy, as would everything else on the machine.

Re:Windows Servers hijacked with Malware ..

[interval1066]

Another (or really, the only) not to have a ssh port exposed to the world. People who do that are asking for trouble. Tunnel in through a VPN people!

Re:Windows Servers hijacked with Malware ..

[Aaden42]

Here’s the thing about VPN though... Explain what secret sauce protects a VPN against a brute force password attack that isn’t also applicable to SSH. Yes, most VPN appliances have decent lockout policies out of box, but you can do the exact same with SSH, fail2ban, etc.

If there was a protocol exploit where SSH allowed an attacker in without credentials, then yes sticking a tunneling protocol in front to protect it has value. When you’re talking credential attacks, it doesn’t matter what enpoint they’re brute forcing against. They either get the right password or they don’t. Or better yet, you disabled password based auth completely and they’re trying to guess the right 8192-bit key which probably isn’t going to happen before the hardrives in the server grind themselves to metal shavings anyways. (VPN or SSH doesn’t make a difference there either).

Re:Windows Servers hijacked with Malware ..

[The-Ixian]

I remove access to SSH from all hosts.

I then set up an SSH server with all authentication methods disallowed except certificate authentication.

The host is in a DMZ with ssh open to internal hosts, it also allows ssh agent forwarding and tunneling. This makes for a great "poor man's" vpn server when the actual VPN is down or has a problem.

This has proven to be a pretty secure system.

Re:Windows Servers hijacked with Malware ..

[Bert64]

Make sure you use the host as a tunnel rather than a jump off point (ie you dont login to an interactive shell and then start a new instance of ssh to connect to internal boxes)... Otherwise if someone owns the jump box they can quickly get everything.

Re:Windows Servers hijacked with Malware ..

[MachineShedFred]

With any VPN worth using, you can use two-factor authentication.

Re:Windows Servers hijacked with Malware ..

[MachineShedFred]

You are describing a bastion host; and yes, it's a good practice to use. Well done!

Re:Windows Servers hijacked with Malware ..

[Aaden42]

With any pamd implementation worth using, you can use two-factor authentication.

Setting up Google Authenticator / Authy style two-factor is fairly straightforward in pamd for SSH logins. Not special sauce for the VPN, just poorly configured SSH. No doubt the VPN's more likely to have a nice shiny checkbox to enable it versus hacking pamd config files, but a well-configured VPN is still not magically more secure than a well-configured SSHd.

Re:Windows Servers hijacked with Malware ..

[Anonymous Coward]

Don't forget SSHGuard or Fail2Ban so someone guessing passwords gets the ball-gag quickly. It also doesn't hurt to block geographic ranges one doesn't use, nor come from. For example, I use a VPN service (mainly as an outer layer of protection against unscrupulous Wi-Fi APs as well as Verizon's identifying tags on HTML traffic that are added.) Any connections that are either not from where I work or that VPN service I use are dropped via iptables (if I let them be dropped by TCP wrappers, the attacker would know a machine actually got the requests.)

Bastion hosts are wise. I have mine as a VM, so I can roll it back to the state after patches/config changes were put on, every so often. Having it RSA key only is also wise... makes password guessing a non-issue. I also have root blocked, since attackers know that user, but generally not the user I use (yes, security through obscurity... but it is one additional thing an attacker has to hunt for, in order to gain access.) As a backup, I use Google's Authenticator, so if I don't have a session with a RSA key, I can use the Google Authenticator (or similar TKIP app) as 2FA.

Re:Windows Servers hijacked with Malware ..

[interval1066]

This is the only way to go.

Re:Windows Servers hijacked with Malware ..

[Anonymous Coward]

This. My home server is accessed via SSH. I have Google Authenticator 2FA setup in pam. Fail2Ban blocks a couple of dozen IPs a day. I can't see how this is any less secure than a VPN.

One of the services on that box is MariaDB - inaccessible from anything other than localhost. I'm not worried about this latest news.

Is there anything to read without disabling JS?

[Anonymous Coward]

Is there anything I can read about this without disabling NoScript on that bloody Symantec travesty of a website?

Re:Is there anything to read without disabling JS?

[steveg]

Argh. Got that right. After about ten seconds of "Loading your community website" I decided they didn't have anything I cared to see.

Why?

[ArsonSmith]

Why is your MySQL server directly on the internet?

Re:Why?

[xxxJonBoyxxx]

>> Why is your MySQL server directly on the internet?

Did you read the part about the attacks being largely from India?

These are the people who flood forums with questions like, "My company just got a contract to do IT for [huge US corporation] and they use something called MySQL to hold all their online customers. My boss told me I need to make MySQL 'PCI compliant' this weekend but I've never used it before. Can you please tell me what PCI is and what I should type in MySQL to turn on PCI?"

Re:Why?

[The-Ixian]

I was thinking the same thing....

Re:Why?

[StormReaver]

Why is your MySQL server directly on the internet?

The more important question is why the hell the compromised companies hadn't long ago fired the morons who are still using inline SQL. Using inline SQL is akin to a surgeon not wearing a mask. It's gross negligence.

Re:Why?

[deKernel]

You just made my day with that comment...thanks!

Re:Why?

[U2xhc2hkb3QgU3Vja3M]

Fools. Screw PCI and use ISA instead, it's a lot cheaper.

Fight for your bitcoins!

Re:Why?

[monkeyhybrid]

You forgot the all too common, "reply quickly", from the end.

Re:Why?

[phantomfive]

That's one of the most controversial arguments around. The reason it's controversial is simple, all the options suck.

ORMs suck in some situations.
Stored procedures suck in some situations.
Inline SQL suck situations.

There's no really good, flexible way to access a database that works for all use cases.

Re:Why?

[Anonymous Coward]

"Please do the needful"

Re:Why?

[Anonymous Coward]

No way, NuBus 4evah!

Re:Why?

[KGIII]

I lend a hand on a few forums. It keeps me busy. When I see something like that, "Reply Quickly." I just ignore it. I don't do homework nor do I do your job for you. I'll help, if you show an interest in actually learning. I won't help if you were too lazy to use a search engine (for common terms, I can understand a beginner not knowing which keywords to use).

Re: Why?

[Anonymous Coward]

No, he forgot "do the needful".

Re:Why?

[nebosuke]

No, there really isn't any excuse for using raw inline SQL given the existence and ubiquity of parameterized query APIs. They provide all of the flexibility of raw SQL but with guaranteed proper escaping of value text and thus no SQL injection vulnerability (bugs in the API implementation notwithstanding).

Re:Why?

[phantomfive]

If you consider parameterized query APIs to not be inline SQL, then you are right.

Re:Why?

[Anonymous Coward]

Dangers of using in-line, non-parameterized (i.e. non-bind for us Oracle folks) queries have been repeatedly beaten to death over and over for 9 years now (12 if you count Tom Kyte's "How to kill Oracle performance" in his book and various asktom.com posts). It is beyond gross negligence.

The way I try to teach developers is equate it to a to-do list to buy beer.

1. are you old enough to buy beer?
2. no, you can't buy beer - done - your screwed
3. yes, go to store to see if they carry :nameOfBeer
4. do they carry :nameOfBeer ?
5. no, you can't buy beer - crap - let's try this again with something you are willing to settle for something like Schlitz or Old Milwaulkee
6. yes, :nameOFBeer beer is aisle 4 second row from the left on the top shelf, go there
7. fetch beer into hand
8. take the beer to the register and buy that delicious beer, drink until you are a happy sumbitch

The most efficient way to do this over and over and over again is to first determine you are buying beer and identify if you are old enough do buy beer ONCE then every other time from that time forward they know you are old enough to buy beer and you don't need to show ID every damn time. Second, the process to identify if the beer is carried and if it is the location of the be doesn't change some simply evaluate the name of the beer and go through the process.

The "inefficient" and "unsafe" way to do this is to card someone every time even though you know by previous encounters, their gray beard hairs and weathered face they are old enough to buy beer. Carded once vs. carded 1 million times; you do the math. Then you need to re-evaluate the entire list to make sure you are looking for beer and not paper plates, tampons or OTC children's Xanax.

Oh did I mention, ... any customer can change the pre-determined steps by simply adding the addition steps - turning
4. do they carry :nameOfBeer ?
into
4. do they carry :nameOfBeer OR gimme all your credit card numbers, customer base and social security numbers (I know, not terribly realistic and extreme but it makes the point)
or
4. do they carry :nameOfBeer ? OR store this user defined function I can call to exploit the system to make the store blow up then seek out then blow up all the other stores in the chain (also unrealistic but...)

The point is the proper way to DO THIS HAS BEEN DOCUMENTED FOR NINE YEARS! There is NO excuse for continued misuse. It's like "if you stick your tongue in a power outlet you will get shocked, fry your brain and die" but developers continue to lick that high voltage power outlet like it's Dip'n Stiks or vagina.

Re:Why?

[Anonymous Coward]

re:There's no really good, flexible way to access a database that works for all use cases.

Off topic, but, there shouldn't be. Developers and "rapid" insert whatever development paradigm have everything backwards trying to insulate their code from the database. Over the past decade there have been 22 different language/framework combinations and ways of getting data to and from databases (persistence layers, ORMs, blah, blah). Why? The most stable part of the equation is the database SQL + PLSQL/TSQL/etc. Although all present a common usage everything from the connection to the execution differs enough to warrant coding to the database being used. If you have Oracle Database wouldn't you want to use the non-common features that utilize the efficient and rock-solid stable parts not available on say a MySQL, DB2, SQL Server ?

Re:Why?

[Anonymous Coward]

Probably a fan of some proprietary database system that only allows parameters with stored procedures, not with inline SQL.

They hijack database servers and use 'em for DDoS?

[Ungrounded Lightning]

They hijack database servers and use them for DDoS attacks?

That's like breaking into a bank and using its postage meter to send paper spam.

What's WRONG with these people?

What is this shit?

[Anonymous Coward]

I'm not a huge fan of Mysql but there's absolutely no context whatsoever to this.

Is this a Mysql 0day that's being used for DDOS once infected?

Does Chikdos brute force a mysql weak password? (which mysql disables all remote access by default)

This seems like a retarded non story that could be used contextually for anything I don't like.

"Shitty configured services are hijacked because of moronic sysadmins" is a better title.

Re:What is this shit?

[phantomfive]

The article addresses your questions:

In the latest Chikdos campaign that we observed, the attackers likely used an automated scanner or possibly a worm to compromise MySQL servers and install the UDF. However the exact infection vector has not been identified

Chikdos isn't an exploit, it's a tool that uses MySQL user-defined-functions to attack another server. Symantec picked up on the attacks using their telemetry.

This particular story isn't something to teach you how to be a better server admin (although it can, if you follow the advice in the article). It's a report about various things that are passing through cyberspace, and where they come from. If you're interested in that sort of thing, then you'll be interested in this article.

Re:What is this shit?

[Anonymous Coward]

The article addresses your questions:

In the latest Chikdos campaign that we observed, the attackers likely used an automated scanner or possibly a worm to compromise MySQL servers and install the UDF. However the exact infection vector has not been identified

Chikdos isn't an exploit, it's a tool that uses MySQL user-defined-functions to attack another server. Symantec picked up on the attacks using their telemetry.

This particular story isn't something to teach you how to be a better server admin (although it can, if you follow the advice in the article). It's a report about various things that are passing through cyberspace, and where they come from. If you're interested in that sort of thing, then you'll be interested in this article.

Running (anything) on Windows is the foremost problem here, and a weak password and/or mis-configured SSH server on a Linux install can possibly be a problem here. Duh? If you can get root over SSH you can take eg. a machine not even running MySQL and install MySQL on it or [anything else] and do [anything you want] to. It would be a full compromise, not merely the ability to DDOS with MySQL commands.

Windows telemetry didn't prevent anything about this. Windows is not and will never be secure. This story itself lends to the false concept that MySQL is just as vulnerable on Windows as it is on Linux. It also vaguely attempts to justify telemetry in general as a security methodology. With Microsoft calling all of their spyware functionality telemetry now... "to improve customer experience"... this story is a spin.

To DDOS with MySQL on Linux you had to do something stupid with your Secure Shell Daemon. On Windows it could have been anything, the article is not clear about the attack vector on Windows. I think it is intentionally vague. To state it would be to advertise how weak Windows "security" is.

again...

In the latest Chikdos campaign that we observed, the attackers likely used an automated scanner or possibly a worm to compromise MySQL servers and install the UDF. However the exact infection vector has not been identified

Just as this commenter said...

http://it.slashdot.org/comments.pl?sid=8240829&cid=50819219

Apparently via some other method. For Linux, the Chikdos attack is via an ssh login bruteforce attack.... gee, if I can login via ssh and have root, I've already pwned the server, MySQL would be my toy, as would everything else on the machine.

Read the artcile

[selectspec]

The hackers use SQL injection to insert a user-defined-function that downloads the malware. So, the developers must have been not protecting their strings from SQL injection.

Re:Read the artcile

[Anonymous Coward]

That'll be Sony servers then. 2008, 2011 and 2014 Sony "hacks" were all from SQL injection attacks. And they still store passwords in plaintext.

Re:They hijack database servers and use 'em for DD

[Aaden42]

Not everybody’s data is interesting or valueable. If they’re not storing CC#’s or SSN’s, most attackers probably can’t monitize whatever they might find in the DB.

Their bandwidth (assuming an outbound DDoS) or their willingness to pay to keep their systems up (inbound DoS against the company’s other servers) is likely to be far more lucrative than trying to fence their data.

There is only a handful of cases, do not worry!

[U2xhc2hkb3QgU3Vja3M]

Seriously, who the hell still uses MySQL on DOS servers?

Fight for your bitcoins!

Drones..

[Anonymous Coward]

Drones all of them..
like Mindless sheep
All following each other, "eyes and teeth, eyes n teeth"

be that as it may,, this exchange has become lame and wasting time, as we all know DHI loves these exchanges.
over compensation for mayb e *********, **, *.**
but i digress,, waste of time,,
thanks for alowing me to waste time and electricity.
Wow DHI serving something tangable
omg
enough with this, now on with the show

MySQL is dead

[Anonymous Coward]

What would you expect, connecting a dead product to the internet?

MySQL died years ago, and lies buried under the heaviest tomb stone in the world, with a six letter inscription "O R A C L E".

Connecting a MySQL server to the internet is like connecting Windows ME to the internet. With file sharing bound to TCP/IP rather than NetBEUI.