JRRZZ blog

We all do stupid things sometimes. I’ve just deleted the contents of my /bin/ directory. Luckily we’ve got the Debian package manager to save the day. Because it has super cow powers. Mooh!

Okay, with a lost /bin/ directory we haven’t got our shell anymore so we’ll have to boot using a Debian rescue image. I’ve used bootp to boot my machine into Debian rescue, but you can use any medium your machine can boot from. I’ve tarred a working /bin/ directory from another box into an archive and put it back, so the machine could be used again. I’ve used wget for this, but some kind of USB storage device will also work. Make sure the donor box is running the same architecture you’re using.

Now we can boot back into our broken Debian system. But we’re not quite there yet. These binaries in /bin/ might be Slackware or Gentoo binaries, who knows. Well, you, but you still might miss some binaries. We want all of our own Debian binaries back. Here’s a quick three-line solution how to refill your /bin/ (or any other directory for that matter) with Debian’s files. You can replace /bin with any directory you’d like, and dpkg will restore it for you.

cd /tmp
for package in `dpkg -S /bin |awk -F”:” ‘{print $1}’`; do aptitude download `echo $package | sed -e ’s/\,//’`; done
dpkg -i *.deb

Tomorrow: how to make dpkg order a pizza for you while doing the laundry.

Tags: Support by jorrizza
1 Comment »

By popular demand: mailman has arrived. Projects using wasda.nl’s services can now email me to get a fancy mailing list to spam their guts out.

If you’ve never worked with mailing lists before, that’s your problem. I’m not here to explain the basics. There are plenty of howtos around if you really need help. If you’re lucky you can find a project member who can explain the usage to you. There’s only one rule I really don’t like to see broken. Keep the conversation readable. Don’t requote signatures, adhere the double-dash signature standard, keep replies below the questions and strip out unnecessary quoted content.

Mail to PROJECTNAME-subscribe[AT]lists.wasda.nl to join a mailing list. The archives are being hosted at http://lists.wasda.nl/pipermail/PROJECTNAME/.

Tags: Support by jorrizza
No Comments »

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 »

It seems more and more people are using GNU/Linux these days. Good! Our friends over at the Fontys University of Professional Education (grin) don’t really support that. Here’s a short instruction how to connect to the wireless network using any Debian like distro. I (of course) use Debian GNU/Linux. This should also work for Ubuntu, *MEPIS and Knoppix related projects.

Yes, this entire howto focuses on the command line. All the commands in the nifty boxes should be entered in a root terminal. Use su or sudo bash to become root.

First, we need to check if your wireless card is detected and working properly. Install the wireless tools to play around with your wireless config.

apt-get update
apt-get install wireless-tools

Now, you can check wether your network card is detected.

iwconfig

If all the devices have “no wireless extensions” you should install your wireless driver. Since that’s not the focus of this howto we’ll skip that part. Of course you’re free to contact me if you can’t get your card to work. Now we’ve got the wireless card up and running you can make a little victory dance because from now on it’s plain sailing ’till the end.

The next part: WPA support. Well, the Fontys network doesn’t really use WPA encryption but randomly distributed WEP using 8021X. But we still need the WPA support software to decode and handle 8021X requests.

apt-get install wpasupplicant

This software needs some configuration. Use your favourite editor to edit it. If you don’t know, use nano.

nano /etc/wpa_supplicant/wpa_supplicant.conf

Be sure the following lines are present:

ctrl_interface=/var/run/wpa_supplicant

network={
        ssid="fontys"
        key_mgmt=IEEE8021X
        eap=PEAP
        phase2="auth=MSCHAPV2"
        identity="PCN@student.fontys.nl"
        password="PASS"
}

Be sure to change PCN and PASS to the proper values. Now we can test it. This will generate a lot of output so make sure a lot of people are watching. It just looks cool. Be sure to change IFACE to the interface not telling you it has “no wireless extensions” from the iwconfig output. You may want to change the -D parameter from wext to that of your wireless driver. This one is the most common though. Check man wpa_supplicant what options you’ve got.

wpa_supplicant -dd -i IFACE -D wext -c /etc/wpa_supplicant/wpa_supplicant.conf

We’re almost there! Now we need to get an IP address to browse the internet. Again, change IFACE to the proper interface. You should also open a new terminal to do this, because wpa_supplicant needs to keep running.

dhclient IFACE

If everything went well you should be able to browse the internet. If not, double check your configuration.

We’re not completely done yet. Of course you don’t want to run that silly command every time you want to read your mail or watch national geographic videos. Luckily there is a way to include this system into the global networking system. Edit the following file:

nano /etc/network/interfaces

And add the following lines (and delete the lines already present for your interface). I’m not going to tell you you should replace IFACE with your interface a third time. Oh wait…

iface IFACE inet dhcp
       wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

What this does is hooking the wpasupplicant subsystem into the ifup/ifdown calls. Every time some other system brings up your wireless card it’ll automatically start searching for the fontys network. One other system that uses this method is ACPI. So when your laptop goes to sleep and wakes up again, it’ll connect to the nearest network using our config.

Neat eh? Now all you need is doing this (insert IFACE joke here):

ifup IFACE

every time you want to use your wireless driver. No worries, even this is automated by most network managers. So if you’re using Ubuntu or MEPIS you’re really done now, I guess.

You can also add some more networks to /etc/wpa_supplicant/wpa_supplicant.conf if you want to. Debian offers some examples in /usr/share/doc/wpasupplicant/examples/. Check your distro documentation where you can find yours. If you add the contents of some of those files to wpa_supplicant.conf and edit it to match your home network config you can even put your laptop to sleep downloading stuff and continue the download at home.

Next: exploiting the weak security of the fontys network to gain access to your school results. Yes, it’s possible!

Tags: Support by jorrizza
No Comments »

One of our machines runs VHCS with packages from apt.scunc.org. The VHCS package depends on proftpd-mysql. After the previous proftpd update proftpd started to create (partially) defunct processes and was eating system resources we needed for other purposes. Luckily the problem was fixed in the last proftpd update. Or wasn’t it?

We found out we couldn’t update our proftpd package because proftpd-mysql was kicked from the Debian repository. If proftpd-mysql was removed, VHCS would go with it. So here’s our solution to the problem: create our own bogus proftpd-mysql package. You can get it here. Just install it using dpkg -i proftpd-mysql_9.9.9-1_${ARCH}.deb. Hey, it’s dirty but it sure works!

Tags: Support by jorrizza
1 Comment »