_files directory weirdness / possible Lupper infection?

Jim Miller · 11-17-2005, 04:39 PM

A bit of weirdness showed up on one of my machines, and I'm hoping that someone out there might have some insights:

Two days ago I was upgrading a machine from Fedora Core 2 to Fedora Core 4. Things went more or less well until today when I noticed a directory, /root/_files, that I didn't put there... It contains thirty files, all but one of which look like this:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /wp-images/smilies/icon_smile.gif was not found on this server.</p>
<hr>
<address>Apache/2.0.53 (Fedora) Server at www.ro0t.com Port 80</address>
</body></html>

(this one is named "icon_smile" in the directory). Some of the files describe the requested URL as being, e.g., /~jasonw/images/birthday.gif; "jasonw" means nothing to me. The one file that's not like this is a saved webpage from io2technology.com, which probably has nothing to do with anything. Googling the file names reveals that many refer to rather uninteresting bits of porn; together, the files look like a typical script kiddie collection. Ick. (But note that the files themselves aren't there; just these 404-type pages.)

So, now the question becomes where these came from. Possibly-relevant bits of information include:

* The files in question all have ownership of root/root.
* My concern about lupper comes from the fact that I did have awstats 6.1 on the machine (yes, shame on me; it has since been updated). However, the awstats.pl file had been behind an Apache authorization, so random attempts by a lupper worm to access awstats should fail.
* In fact, while there are lots of entries in my server log files showing >>attempts<< to get in with lupper (URLs with attempts to cd into /tmp and so on), none of them returned anything other than 404 or 401.
* I don't have WordPress or any of the other problematic Lupper-related applications on this machine.
* There's no evidence of the usual telltale signs of lupper -- nothing inappropriate in /tmp.
* The timestamp on all the files is Nov 15 at 12:41, which was just about the time that I was doing the upgrade. Perhaps somebody slipped in while during an incomplete part of the update?
* There are no unexpected entries in /etc/passwd or /etc/shadow.

I have since locked up ports 7111 and 7222 with iptables, but I'm still a little creeped out. Aside from keeping a close eye on this, does anyone have any recommendations for what to do here?

Thanks,
Jim Miller

unSpawn · 11-17-2005, 06:17 PM

* My concern about lupper comes from the fact that I did have awstats 6.1 on the machine (yes, shame on me
How long did you run the vulnerable stuff? What other services where running as publicly accessable at the time?

* In fact, while there are lots of entries in my server log files showing >>attempts<< to get in with lupper (URLs with attempts to cd into /tmp and so on), none of them returned anything other than 404 or 401.
None in proximity to Nov 15 at 12:41?

* The timestamp on all the files is Nov 15 at 12:41, which was just about the time that I was doing the upgrade. Perhaps somebody slipped in while during an incomplete part of the update?
It's a possibility. Hard to say w/o details.

Aside from keeping a close eye on this, does anyone have any recommendations for what to do here?
For now stop and then disable any publicly accessable services from starting up automagically until you have properly secured them. Enable logging in your firewall script and close your firewall for any inbound connections from the internet that aren't part of an established connection. For services you need publicly accessable (SSH for instance), for which all updates are in place, and are properly secured (not allowing privileged account logins), set up IP range restrictions (firewall, tcp wrappers) for where authorised ppl ssh in from.

Good to see you been checking things. If you've done the service stuff I'd check the system for files in other locations with the same creation time, any mysterious files in other known temp dirs, any suid binaries in unusual locations, any system logging you got (syslog, firewall), auth files (last, lastb) and any logfiles for services that where running at the time. If that turns up nothing I'd run rpm verify just to be sure. Unfortunately verify won't catch any files or changes outside of it's scope.

If that turns up nothing I'd proceed by adding some basic stuff to the bastion like install an IDS: Snort (or Prelude), a file integrity checker: Aide (or Samhain), a local rootkit/malware checker: Chkrootkit (and preferably Rootkit Hunter as well), a generic system checker: Tiger (or since you run RH-alike maybe LSAT (not the Mixter app: NSAT)) and a logfile filter: Logwatch. Next please fo some basic system hardening, see the LQ FAQ: Security references.