Dear all:
This is off-topic, except in the sense that it involves the ftp server where
I maintain the Mlucas software for mersenne testing Unix clients.
My ftp server has suffered its first (to my knowledge) hacker penetration.
I think I stopped the attack before any serious damage was done, but
thought I'd recap what happened and ask the sysadmins out there for
advice as to how best prevent this sort of thing in the future.
I've already contacted the local FBI field office, but this sort of thing
(I'm not exactly eBay here :) may not be high on their priorities list.
Summary: this morning I noticed a lot of ftp traffic on my server (not in
itself unusual), and at the same time that one of my jobs had crashed
while attempting to write to disk due to a full filesystem. After eliminating
all the obvious candidates (large core files and such), I started a detailed
account of disk usage for various directories, and found that the directory
containing my public ftp archive was several hundred MB larger than it
was 24 hours ago. After some more sleuthing, I found that someone had
logged on via anonymous ftp, created a directory with a name consisting
of several blank spaces in /usr/users/ftp/pub, and was busily uploading
hacker-sounding files into the new directory. I immediately halted network
services and changed the ownership of the blank dir from 'ftp' to 'root.' I
haven't deleted the directory in question, since there may be clues as to
the source and nature of the attach in there.
I think someone may have been trying to turn my server into a "zombie"
such as in the recent denial-of-service attacks on several popular websites.
Here's where my checks of disk usage first turned up the anomaly:
# du -rsk /usr/users/ftp/pub/*
284260 /usr/users/ftp/pub/ <==this wasn't there yesterday...
7050 /usr/users/ftp/pub/alpha_docs
1416 /usr/users/ftp/pub/amd_docs
1503 /usr/users/ftp/pub/archived
87 /usr/users/ftp/pub/c_translations
1200 /usr/users/ftp/pub/ia64_docs
431 /usr/users/ftp/pub/ibm_docs
21759 /usr/users/ftp/pub/mayer
3704 /usr/users/ftp/pub/mips_docs
5440 /usr/users/ftp/pub/powerpc_docs
149 /usr/users/ftp/pub/spec98
168 /usr/users/ftp/pub/transmeta_docs
104 /usr/users/ftp/pub/usgov_docs
This shows the blank-named dir created by the hacker, with owner = 'ftp':
# cd /usr/users/ftp/pub/
# ls -l
total 104
drwxr-xr-x 3 ftp users 8192 Feb 26 22:38 <==directory name
= 3 spaces
drwxr-xr-x 2 mayer users 8192 Feb 27 03:10 alpha_docs
drwxr-xr-x 2 root users 8192 Feb 27 03:10 amd_docs
drwxr-xr-x 2 mayer users 8192 Nov 26 02:38 archived
drwxr-xr-x 2 mayer users 8192 Jun 2 1998 c_translations
drwxr-xr-x 2 mayer users 8192 Feb 27 03:10 ia64_docs
drwxr-xr-x 2 root users 8192 Feb 27 03:10 ibm_docs
drwxr-xr-x 6 mayer users 8192 Feb 27 01:20 mayer
drwxr-xr-x 4 mayer users 8192 Mar 31 1999 mips_docs
drwxr-xr-x 3 mayer users 8192 May 4 1999 powerpc_docs
drwxr-xr-x 3 mayer users 8192 Apr 19 1999 spec98
drwxr-xr-x 2 root users 8192 Feb 27 03:10 transmeta_docs
drwxr-xr-x 2 root users 8192 Feb 27 03:10 usgov_docs
The blank dirname is designed to make it harder to see what's in there,
so one needs to do something to avoid directly entering a blank dirname,
like
# ls -l /usr/users/ftp/pub/*
/usr/users/ftp/pub/ :
total 8
drwxr-xr-x 3 ftp users 8192 Feb 26 22:38 4_mboca
Within the directory 4_mboca was another directory named 'by_hitekfraud',
containing the following goodies Mr. hacker uploaded:
# ls -l
total 168
drwxr-xr-x 2 ftp users 8192 Feb 27 10:23 AutoBot.v1.1.Cracked-DQF
drwxr-xr-x 2 ftp users 8192 Feb 27 11:36 BEATMANIA_DA-SCAR
drwxr-xr-x 2 ftp users 8192 Feb 27 02:49 Invictus-CLS
drwxr-xr-x 2 ftp users 8192 Feb 27 10:14
Invictus_Manual_REPACK_FTFdOCs
drwxr-xr-x 2 ftp users 8192 Feb 27 02:47 Invictus_music
drwxr-xr-x 2 ftp users 8192 Feb 27 10:11
Revenant.Patch.1.2-FLTDOX
drwxr-xr-x 2 ftp users 8192 Feb 27 01:08 boa.bite.3d-razor
drwxr-xr-x 2 ftp users 8192 Feb 27 01:08
boa.bite.3d.trainer-paradigm
drwxr-xr-x 2 ftp users 8192 Feb 27 02:24
easycert_easy_nt_server_4_v4.0_win9xnt_incl_keymaker-ucf
drwxr-xr-x 2 ftp users 8192 Feb 27 02:24
flashfxp.v1.2.build.475.with.keygen--core
drwxr-xr-x 2 ftp users 8192 Feb 27 02:24
flashfxp.v1.2.keygen.and.blacklist.checker.only--core
drwxr-xr-x 2 ftp users 8192 Feb 27 02:25
invisible_secrets_v2.0_incl_keygen-ucf
drwxr-xr-x 2 ftp users 8192 Feb 27 02:29
novell.netware.v5.0.unlimited.connection.licenses-dod
drwxr-xr-x 2 ftp users 8192 Feb 27 02:46 pba.bowling.2-cls
drwxr-xr-x 2 ftp users 8192 Feb 26 22:45 red.thunder-minime
drwxr-xr-x 2 ftp users 8192 Feb 27 02:26
s.m.a.r.t.disk.monitor.v1.08.cracked-repack-xcrypt
drwxr-xr-x 2 ftp users 8192 Feb 27 01:14
serv-u.ftp.v2.5d.incl.keygen--laxity--tno
drwxr-xr-x 2 ftp users 8192 Feb 27 01:14
sygate.3.11.560.unlimited.users--mfd
drwxr-xr-x 2 ftp users 8192 Feb 27 00:50
total.annihilation.kingdoms.iron.plague-origin
drwxr-xr-x 2 ftp users 8192 Feb 27 01:10
transcender.c.plus.plus.cert.distributed.v6.0.win9xnt.incl.keymaker-core
drwxr-xr-x 2 ftp users 8192 Feb 26 23:17
visual.flight.designer.2000-precise
So my question to the sysadmins out there is: what's the best way to avoid
this sort of thing, without installing a firewall and while still permitting
ftp access?
In re-reading the DEC Unix manpage for ftpd, it seems to me the weakest
link is the guideline for the ~ftp/pub directory, which the manpage
says to make owned by ftp and writeable by anyone. I've changed it
to be owned by root and unwriteable except by root, but that may
not be an option for folks who maintain public ftp archives that
multiple users must be able to write to.
Sorry for the temporary Unix-ification of this list, but I hope this
may help some other ftp archive maintainers amongst the GIMPS crowd
make their own systems safer from this kind of attack.
-ernst
OK, now that I've done my little public service, don't I get to smooch with
some Angelina-Jolie-looking hacker babe? :)
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
