So pretty sure one of my boxes has been owned. Just wanted some advise on what to do next. Obviously, i'll need to nuke the fecker and start over but it would be really nice to find out how they got in as its a CentOS 4.3 which is bang up to date.
So i found:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 7052 apache 25 0 27320 5348 8 R 99.0 0.5 736:52 0 uselib24
[root@box tmp]# netstat -lnp |more Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN 3012/rpc.statd tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN 3138/xinetd tcp 0 0 0.0.0.0:66 0.0.0.0:* LISTEN 3124/sshd tcp 0 0 0.0.0.0:9865 0.0.0.0:* LISTEN 7031/bindz tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 14534/mysqld tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2993/portmap tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 7031/bindz tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN 3138/xinetd tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 3578/vsftpd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 10707/sendmail: acc tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 7031/bindz
Bindz.... hmm. telnetting to the port gave me a root shell - nice. My firewall scripts should block that port but i don't know if they're working now :(
contents of /var/tmp was:
-rwxrwxr-x 1 apache apache 19429 Jan 10 16:20 bindz -rw-r--r-- 1 apache apache 2100 Jan 8 21:32 dc.txt -rwxrwxr-x 1 apache apache 479843 Aug 3 2005 uselib24
dc.txt started:
#!/usr/bin/perl use IO::Socket; #IRAN HACKERS SABOTAGE Connect Back Shell #code by:LorD #We Are :LorD-C0d3r-NT #Email:LorD@ihsteam.com # #lord@SlackwareLinux:/home/programing$ perl dc.pl #--== ConnectBack Backdoor Shell vs 1.0 by LorD of IRAN HACKERS SABOTAGE ==-- # #Usage: dc.pl [Host] [Port] # #Ex: dc.pl 127.0.0.1 2121 #lord@SlackwareLinux:/home/programing$ perl dc.pl 127.0.0.1 2121 #--== ConnectBack Backdoor Shell vs 1.0 by LorD of IRAN HACKERS SABOTAGE ==-- # #[*] Resolving HostName #[*] Connecting... 127.0.0.1 #[*] Spawning Shell #[*] Connected to remote host
i might e-mail him and thank him.
So what next?
Hi,
Well thats telling. So do you have chkroot-kit installed? Although you know you've got to have a root-kit on there. Anyway, it may help narrow your search of the directories and the changes within.
-rickp
On 5/3/06, Nick list@everywhereinternet.com wrote:
So pretty sure one of my boxes has been owned. Just wanted some advise on what to do next. Obviously, i'll need to nuke the fecker and start over but it would be really nice to find out how they got in as its a CentOS 4.3 which is bang up to date.
So i found:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 7052 apache 25 0 27320 5348 8 R 99.0 0.5 736:52 0 uselib24
[root@box tmp]# netstat -lnp |more Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN 3012/rpc.statd tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN 3138/xinetd tcp 0 0 0.0.0.0:66 0.0.0.0:* LISTEN 3124/sshd tcp 0 0 0.0.0.0:9865 0.0.0.0:* LISTEN 7031/bindz tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 14534/mysqld tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2993/portmap tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 7031/bindz tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN 3138/xinetd tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 3578/vsftpd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 10707/sendmail: acc tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 7031/bindz
Bindz.... hmm. telnetting to the port gave me a root shell - nice. My firewall scripts should block that port but i don't know if they're working now :(
contents of /var/tmp was:
-rwxrwxr-x 1 apache apache 19429 Jan 10 16:20 bindz -rw-r--r-- 1 apache apache 2100 Jan 8 21:32 dc.txt -rwxrwxr-x 1 apache apache 479843 Aug 3 2005 uselib24
dc.txt started:
#!/usr/bin/perl use IO::Socket; #IRAN HACKERS SABOTAGE Connect Back Shell #code by:LorD #We Are :LorD-C0d3r-NT #Email:LorD@ihsteam.com # #lord@SlackwareLinux:/home/programing$ perl dc.pl
#--== ConnectBack Backdoor Shell vs 1.0 by LorD of IRAN HACKERS SABOTAGE
# #Usage: dc.pl [Host] [Port] # #Ex: dc.pl 127.0.0.1 2121 #lord@SlackwareLinux:/home/programing$ perl dc.pl 127.0.0.1 2121
#--== ConnectBack Backdoor Shell vs 1.0 by LorD of IRAN HACKERS SABOTAGE
# #[*] Resolving HostName #[*] Connecting... 127.0.0.1 #[*] Spawning Shell #[*] Connected to remote host
i might e-mail him and thank him.
So what next?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Rick Philbrick wrote:
Hi,
Well thats telling. So do you have chkroot-kit installed? Although you know you've got to have a root-kit on there. Anyway, it may help narrow your search of the directories and the changes within.
-rickp
Well i quarantined the files and then ran rkhunter and chkrootkit and both came back ok. Not going to risk not starting over on the box but if i can't tell how they got in then I'm not stopping it happening again. It could of course have something to do with one of the webapps the box runs (forum software)...
Also i found my iptables script wasn't blocking port 80 and port 21 outbound.... school boy error.
Nick wrote:
Rick Philbrick wrote:
Hi,
Well thats telling. So do you have chkroot-kit installed? Although you know you've got to have a root-kit on there. Anyway, it may help narrow your search of the directories and the changes within.
-rickp
Well i quarantined the files and then ran rkhunter and chkrootkit and both came back ok. Not going to risk not starting over on the box but if i can't tell how they got in then I'm not stopping it happening again. It could of course have something to do with one of the webapps the box runs (forum software)...
Also i found my iptables script wasn't blocking port 80 and port 21 outbound.... school boy error.
Hi -
I'm guessing that this happened by an overly friendly webapp, since the processes are in fact running under the 'apache' username. I think that if I were doing this - and I had a clue - I'd run this application under a less conspicuous username.
You probably knew that. Couldn't hurt to throw that out, eh?
Thanks -dant
On May 4, 2006, at 1:37 AM, Nick wrote:
Rick Philbrick wrote:
Hi,
Well thats telling. So do you have chkroot-kit installed? Although you know you've got to have a root-kit on there. Anyway, it may help narrow your search of the directories and the changes within.
-rickp
Well i quarantined the files and then ran rkhunter and chkrootkit and both came back ok. Not going to risk not starting over on the box but if i can't tell how they got in then I'm not stopping it happening again. It could of course have something to do with one of the webapps the box runs (forum software)...
You used trusted binaries when running chkrootkit, right?
-- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
A little hint that's helped me identify what happened before:
Use grep to look for things like "telnet" and "wget" in the httpd logs. Since it doesn't exactly look like you've been rooted, these are probably intact and available.
May be obvious, but it may also have been missed....
-Ben
On Wednesday 03 May 2006 22:37, Nick wrote:
Rick Philbrick wrote:
Hi,
Well thats telling. So do you have chkroot-kit installed? Although you know you've got to have a root-kit on there. Anyway, it may help narrow your search of the directories and the changes within.
-rickp
Well i quarantined the files and then ran rkhunter and chkrootkit and both came back ok. Not going to risk not starting over on the box but if i can't tell how they got in then I'm not stopping it happening again. It could of course have something to do with one of the webapps the box runs (forum software)...
Also i found my iptables script wasn't blocking port 80 and port 21 outbound.... school boy error.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Nick wrote on Thu, 04 May 2006 14:43:20 +1000:
Bindz.... hmm. telnetting to the port gave me a root shell
A shell, not necessarily a root shell. It's running with apache user rights it seems.
-rwxrwxr-x 1 apache apache 19429 Jan 10 16:20 bindz -rw-r--r-- 1 apache apache 2100 Jan 8 21:32 dc.txt -rwxrwxr-x 1 apache apache 479843 Aug 3 2005 uselib24
You should suspect some php app or at least a web-based intrusion. Break-ins this way usually don't get the intruder a root shell. And what they are up for most often is distribution space for "warez/videoz". They don't "waste time" with owning the machine in a better way. Stop that stuff from running, firewall it more tightly and then look around. I haven't seen a hack on one of my clients computers for two years now, so I'm not familiar with what gets used today. Google for those apps you found and you may find quite a few information what they replace. If it's not in those directories, anyway, including another instance of the exploit that helped to get in - for re-use on the next machine ... Try to find out when the intrusion happened, there may be logs for "bindz" or other apps or the creation data of some file may reveal this. Then check your apache logs around that date.
If it's a good rootkit it's hard to get rid of it. Well, you said you want to nuke it, anyway, good :-) If it's not a rootkit then you might think about getting rid of the stuff because only some basic apps got replaced. f.i. ls, ps, lsof, netstat and such, what you would use to look around and identify files/processes that shouldn't be there. Since your netstat shows the intruder it's obviously not been replaced or not working correctly and nothing may have happened yet after the break-in. If you have a second machine with same OS you can start by comparing (size, date, crc) and then replacing (even if they compare ok) (if you replace first, you don't have a chance to find what got replaced) some of these apps. Then compare again.
Kai
Kai Schaetzl wrote:
Nick wrote on Thu, 04 May 2006 14:43:20 +1000:
Bindz.... hmm. telnetting to the port gave me a root shell
You should suspect some php app or at least a web-based intrusion. Break-ins this way usually don't get the intruder a root shell. And what
Yeppers. From interest, was the box selinuxed up Nick? Because AIUI that should have said no to running shells from Apache.
-Andy
-
Andy Green -
Benjamin Smith -
dan.trainor -
Jason Dixon -
Kai Schaetzl -
Nick -
Rick Philbrick