X
Tech

Linux and botnets: It's not Linux's fault!

Linux is as secure as ever. The real security hole lies with some of Linux's administrators and users.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

I couldn't blame you, if -- based on recent headlines such as "Linux worm Darlloz targets Intel architecture to mine digital currency" and "Botnet of thousands of Linux servers pumps Windows desktop malware onto web" -- you thought Linux was as full of holes as Windows XP. If you take a closer look, you'll find that Linux isn't the problem. No, the real security hole lies with some of Linux's administrators and users.

it-security
If you let someone get at your login ID and password, it doesn't matter what operating system you're running. It's like leaving your front door unlocked. The crooks will walk into your home.

First, let's put these "Linux" security problems into context. Symantec claims that the Internet of Things worm Darlloz has infected 31,000 devices. In the other story, security researchers at anti-virus firm ESET claim that the Operation Windigo botnet, which uses the Cdorked Web server attack kit to assault Apache and other popular open-source Web servers and the Ebury SSH [Secure Shell] rootkit, has had a total of 26,000 infections since May 2013. By comparison, ZeroAccess, the Windows-based botnet that was the largest in the world , had contaminated almost 2 million computers before it was cut down in December 2013.

Even after ZeroAccess was removed, Fortinet reported that attacks were quickly back up to normal. The top 10 botnets are based on unpatched Windows and Windows-based applications.

So, in the big scheme of spreading malware, Linux is small potatoes. But is it really Linux's fault it even has infections in the tens of thousands? No.

With Darlloz, which tends to attack devices such as small office/home office (SOHO) Internet routers, it's one way of infection is to try 13 combinations of the default user names and passwords on a device. If the gadget's owner has done the bare minimal of security: Change the blasted default user ID and/or password, they can't be infected. That's it!

Symantec also suggests that users mitigate the problem with such security 101 tactics as applying security patches, updating the firmware, and blocking incoming Internet traffic on port 23 (telnet) and 80 (Web server) from the outside world. Gosh! Really? You think?!

The real bottom line remains, however, that to perfectly protect your devices from this attack all you need do is change either the default login or password. You don't even have to do both! Mind you, you should, but this "hack" is such a wimp you don't even need to do that.

As for Operation Windigo, it's more serious, but as ESET points out, Windigo did not use any new vulnerability to exploit Linux or Unix systems. No, it relied solely on stolen credentials. Logins and passwords could be stolen in two ways. In the first, an end user successfully logs into an already infected server with SSH. With the second, a user on an already compromised system logs on to another uninfected system.

How do you stop this in the first place? Easy. You make your users change their passwords and protect your SSH passwords like they were gold. Password authentication to access servers must be hardened with tactics such as two-factor authentication.

You can find out if you have Ebury and Cdorked on your server quite easily. For Ebury, simply run the command:

  • ssh -G

from your shell. A clean server will print to stderr, your terminal, with a message such as:

  • ssh: illegal option – G

and then a listing of ssh's correct usage. An infected server will only print the usage message.

Finding out if you have Cdorked is only a little more complicated. In this case, you use the command

  • curl -i http://myserver/favicon.iso | grep "Location:"

from your shell. Cdorked redirects requests to /favicon.iso to Google so it will return

  • Location: http://google.com

If your server is clean, it won't return anything or a different Location header.

ESET also details other ways to detect infections. If you do have a case, here's the bad news. You'll need to completely wipe your servers, rebuild them from scratch, and reset all user and administrator credentials from known clean machines. You'll also need to block users from resetting their passwords to their original ones.

Of course, if you'd been extra careful with your SSH logins and passwords in the first place, you wouldn't have to go through all this. For what it's worth, you're in good company if your machines fell prey to this. Both cPanel, the company behind the well-known Web hosting control panel program, in 2013 and the Linux Foundation in 2011 were successfully hit by ancestors of the current malware.

The moral of the story? If you hand the bad guys user ID and passwords, of course, you're going to get hacked. Linux, FreeBSD, Windows Server 2012 -- the operating system doesn't matter. If you leave your front door open, a crook will walk in. As security guru Bruce Schneier wisely said way back in 2000, "Security is a process, not a product."

Related Stories:

Editorial standards