sb's home | kz.uni.cz Warez Doodz....

$Id: warez.html,v 1.4 2010/03/10 13:29:44 simonb Exp $


Warez Doodz....

For fun, I decided to play with my server and set up a really insecure FTP daemon, in order to see what would happen. OK, so I knew it'd basically be abused for warez, but that wasn't the point. Heres what I found....


Setting it up...

This server runs a secure ftpd. That's pretty much taken as standard, however I had to change some bits in order to make it look like I really didn't know what I was doing. First to go was the version string, and was replaced with something like:

 
[5:12pm]c0ke% ftp ftp://c0ke
Trying 212.69.230.120...
Connected to c0ke.kaizo.org.
220 c0ke.kaizo.org FTP server (Version wu-2.5.0(1) Tue Feb 31 13:37:00 GMT 1999) ready.
331 Guest login ok, send your email address as password.
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Type set to I.
250 CWD command successful.
ftp>

So, there we are. We running a pretty insecure version of Wu-FTPD. Nothing says lax security than that ;-)))

The more intelligent reader should note the `compile' date, a dead giveaway if ever there was one....

In addition to this, I played with different options for an `incoming' directory. These essentially revolved round:

So, we have a vulnerable FTP server with an incoming directory. Initially, I chmodded this 0777, but the warez doodz didn't come and play. I was gutted. I can only surmise from this that they don't like directories that all and sundry can read/write to, as their precious 0-day can be rm'd by a jealous group.

However, chmodding it to 1777 seemed to make things a bit better. Here's a sample from the logs of what you can expect to see when being probed for warez:

 
May 19 21:28:25 c0ke ftpd[2710]: ANONYMOUS FTP LOGIN FROM ADSLP34-NV-p181.adsl.netvision.net.il, guest@here.com
May 19 21:28:25 c0ke ftpd[2710]: mkdir pub/020519222915p
May 19 21:28:26 c0ke ftpd[2710]: mkdir incoming/020519222915p
May 19 21:28:26 c0ke ftpd[2710]: rmdir incoming/020519222916p

I've left the hostname in there. So sue me.

This is very bizarre, as all the security documents in the world will tell you to make an ~ftp/incoming directory 1777. This was probably true back in the day, when people actually took care in their work and the warez'z did things by hand. I wouldn't like to stake my future security on this hypothesis though!!!
As such, I'd probably recommend people make their incoming directory (if you need one!) modal 1733, which will allow people to rw to files, but not to do an `ls' in order to see what's actually there...

Essentially, this is an automated probe - I found some of these programs and had a play, they all work in different ways but basically all do the same thing, i.e. connect, mkdir, rmdir, nxt. The directory name is opined to be in the form of YYMMDDHHMMSSp.

There were loads of these over a few weeks. However, nobody had really uploaded any files. Then I started to see uploads like these:

 
May 19 17:25:19 c0ke ftpd[12548]: put /incoming/1mbtest.ptf = 1000000 bytes
May 19 17:25:23 c0ke ftpd[12548]: get /incoming/1mbtest.ptf = 1000000 bytes
May 19 17:25:26 c0ke ftpd[12548]: delete /incoming/1mbtest.ptf

This was interesting, and is seen a lot in warez abuses. They basically upload a file, get it and time the transfer rate, and then cleanup and leave. If you were running a vulnerable server, and you never checked your logs, you wouldn't even know this was happening....

Stage 2

So, I was sat around, waiting for my k-rad 0day, and then...nothing. Nobody came to play. Lots of people making directories, loads uploading 1mbtest files, but no one seriously abusing me. I was getting quite disappointed, till I suddenly decided to open up passive ftp - it was blocked by packet filtering, but man, once I opened those rules up we were warez'in away!

space.asp

I noted the following entry:

May 11 07:33:21 c0ke ftpd[20473]: put /incoming/space.asp = 2580 bytes
Which intrigued me - it was deleted pretty quickly, but in addition to this, I saw the following in a www request:
p5084396b.dip.t-dialin.net - - [11/May/2002:07:33:21 +0100] "GET /incoming/space.asp HTTP/1.1" 404 1026 "-" "-"

Interesting....Doing a quick google search returns the fact that this script allows people with a www browser to see how much disk space there is on the machine. This would of course be very useful, and would quickly give away the fact it was running on a MFS. Apart from the fact I'm not st00pid enough to do this on a Windows box ;-)))

You can see the sample output of the script here, and the actual script here. You'll need to view the source though as some browsers parse the data. Stupid...

Tagging...

When a directory is found to rw, the dudes will always come back to own you. This is when the `tagging' starts. Tagging is usually associated with graffiti, when an aspiring young artist writes his name in a piece of work or as a signature. You can see examples of groups tags at Grim's Page. The idea behind this is that if a server is `tagged', it would be rude to overwrite someone else's bargain find. Quite ironic really!!!!!!

Once it's been tagged, they will then start to create `hidden' directories. You can see the output of ls -lR here

For info, there was also someone uploading commercial software. As I'm kinda implicating myself legally in this, I quickly stopped that persons FTP session and added them to the custom firewall rules. Sorry Adobe, but I have about 8mb of an Illustrator ISO. The MP3's that were uploaded were what surprised me. These weren't you common-or-garden MP3's ; these were 192k bitrate and very high quality, complete with album covers in JPEG format and an .nfo file, and a .cue file for burning them directly onto a CD. Slick...

BTW, the MP3's were shit. I deleted them. I like decent music, this was like listening to Misery of Sound compilation albums...

Traffic Stats...

As you can see, the little buggers munched away at the bandwidth I have when they did this. Bear in mind that this box is relatively quiet, it's just a hobby box and most of us sleep at night ;-)

It's important to note that this is the uploading stuff. When the other cool krad dudes start to download stuff by the hundreds, ALL of your bandwidth will be munched up. This is clearly not a good thing (tm).

Lessons You Should have Learned!

OK, so there's some fairly simple points to gleam from here, and also some not-so-obvious conclusions.

Xencat also pointed out Quotas are a neat way of enforcing space requirements, either on the FTP servers (which some support) or even better at the FS level.

Allowing the FTP directories part of an executable area is the main problem. People usually need a way to upload web pages without an account. (Certainly ISPs do).

Don't let users (especially random ones) upload and be able to use CGI scripts.

The last comment I'll make is "Why have an FTP incoming Directory?". It really is that simple.

I originally suggested: If you must have one ensure it's modal 1733, otherwise you're in for a real treat....Also try and make it on a seperate partition, as you could find your HD's being filled up with use{ful,less} crap.

Solar Designer ( solar/at/openwall.com )also added the following:
Regarding incoming directories, if one is required, the best solution is support in an ftpd. The files would then not be readable back via FTP. 1733 doesn't really help because a subdirectory with different permissions may be created via FTP (unless that is also disallowed in ftpd configuration).

Oh, and if you're a sysadmin looking after an FTP server, read the following now!


Credits
$Id: warez.html,v 1.4 2010/03/10 13:29:44 simonb Exp $