There’s no such thing as a Linux virus. Sure there isn’t. As long as there are stupid Linux users (lusers if you wish) the bofh will have to remove junk binaries every once in a while. Wether or not the user gets booted in the process it up to the level of financial compensation awarded for doing nothing. Yes, you’ve read that right. For doing absolutely nothing.
Anyways, since most of you will use some kind of GNU/Linux system for your end users you’ll find yourselves stuck in these kind of situations. Some end user has somehow managed to install old software, in my situation some PHP web app, with more holes in it than a heretic after a visit to the iron maiden. It gets sploited and you’re stuck with some binary doing stuff you don’t want it to do. In general there are four levels of things you can encounter.
The first level is pure scriptkiddie work. Easily detectable using top or ps. It’s usually a Bash, C or Perl script running a while(1) loop. Most of the time with a non-disclosing name like “crash”, “cpu_hogger”, “a.out” or “eatflamingdeath”. Remove the script and send the remaining process a SIGTERM. In other terms, kill will do.
The second level is a bit more tricky, but still quite trivial when you know where to look. The script actually has a function like serving a terminal session or some IRC stuff. This is also the most common level of stuff you’ll encounter. The catch is these things remain at the user level so you can easily just check ps’s output for anything hinky. Just a tip, init, and all the nifty [k*] processes should run as root. For a blackhat it’s easy to fool you, because argv[0] can be changed to display whatever he (is there any she blackhat? if there is, please drop me your rootkit) wishes. A simple strcpy() does the job. When you’ve found your prey it’s time to track and kill it. Check the symlink /proc/[pid]/exe for the full path to the executable. If you’re lucky, it points directly to the binary of some C app. Delete it and send a SIGHUP, or kill -9 to the process. If it’s an interpreter like /usr/bin/perl or something you can’t just kill all perl scripts. Correct me if I’m wrong but there’s no way to get the original argv from a process when it’s been overwritten by the app itself. So you’ll have to hijack the interpreter using a Bash wrapper like this:
mv /usr/bin/perl /usr/bin/perl.real
cat > /usr/bin/perl <<EOF
#!/bin/bash
env >> /tmp/perllog
echo $@ >> /tmp/perllog
/usr/bin/perl.real $@
EOF
chmod +x /usr/bin/perl
Now you can send the process you want to kill a SIGHUP. Tail the /tmp/perllog file to check who’s running perl and more importantly, the perl parameters. This method has some other (leeter) alternatives, but this has worked for me on several occasions. Don’t forget to clean up the mess you’ve made afterwards. Now you’ve got the path to the script causing your problems. Remove it, after reading it of course, there might be a fallback system, and send the remaining process it’s well deserved SIGHUP.
The third level is where it gets really tricky. Important system binaries have been tainted. Several rootkits have been know to do this. Before this can happen though, you must have made a mistake in your security. For this to work the blackhat had to have root access to your system. Shame on you! Another bummer about level three infection is that it’s almost undetectable. Some rootkits have been known to survive for years before they are found. There’s no real fix for this, because in this state you can’t trust ANY binary anymore. Maybe if chroot isn’t tainted you can bring in your own binary big guns to check the system binaries, one at the time, from your own trusted environment. But when a system is this infected the best thing you can do is move all operations to another clean server and fix this machine in quarantine. There are some ways to prevent this from happening. I prefer using rkhunter. It’s a simple but effective approach to the problem. It manages a table of md5 hashes of your system binaries. When a binary changes it’ll send you an email. It also checks for hidden files and some other common rootkit files.
The fourth level is even worse. The upper three levels consider only user space vulnerabilities. This is kernel space we’re talking about. It’s just not detectable. But be assured, it’s really hard to get malicious code to run in kernel space. There are two major ways these things can happen. First, and I’ve seen this a lot, you’ve left /usr/src/linux world writable and you build a new kernel out of the same source tree. Bad idea. When it happens it’s your own fault and you should take the blame. Or not, if you’re smart enough to bluff your way around your utter stupidity. The second way this happens, sometimes, is through tainted device drivers. But in either way, you should check and double check your sources before building any kernel space binaries. Luckily your lusers can’t, and hopefully won’t, touch kernel space with a 10 foot pole.
These are only some common tips. There’s a lot more to discover. The most important lesson to learn from this is prevention. You don’t have to clean up the mess when there’s no mess to begin with. The best solution is not to have any lusers at all, like on your own machines. But sometimes you’ll have to give them some liberties. Give them just enough in order for them to do their work. Nothing more. Let me say this again. Nothing more. I’m serious.
Tags: Support by jorrizza
No Comments »
