Monthly Archives: November 2006

Setting up networking in Qemu for using OpenNSM

Posted on by

Geek00L has created a OpenBSD 4.0 based QEMU image called OpenNSM which I decided to give a try. Getting the networking part to work with my Linux host was a bit of a puzzle, so i’m writing it down here. Most of the steps were taken from the unofficial qemu wiki page here, but not all of them were necesarry.

First of all, I had to use the QEMU version 0.8.2 from the QEMU website, because the 0.8.0 version from my Ubuntu Dapper workstation didn’t work. With the latter version the OpenBSD bootup would just hang at the message ‘clock: Unknown CMOS layout’.

For the networking to work, I needed to setup a bridge between the actual NIC and the tap interface that QEMU was going to talk to. First the tap:

modprobe tun
chmod a+rwx /dev/net/tun

Next the bridge setup on eth1. The tap was added to it later.

brctl addbr br0
ifconfig eth1 0.0.0.0 up
brctl addif br0 eth1

Added an IP Address to the bridge in the subnet connected to the eth1 NIC.

ifconfig br0 192.168.2.12

After this I setup the file /etc/qemu-ifup. This file is called by QEMU on startup to setup the tap networking.

#!/bin/sh
sudo /sbin/ifconfig $1 0.0.0.0 promisc up
sudo /usr/sbin/brctl addif br0 $1

Now I was ready to start the image:

qemu -hda OpenNSM.img -m 256 -net nic -net tap

Once the image was booted, I made the corrections described by Geek00L here. Finally, I ran /root/nsm-scripts/net-config.sh in the OpenBSD installation to setup the system with a unique IP Address. I chose 192.168.2.13. After this I could use networking from my OpenNSM installation 🙂

Detecting and blocking Phishing with Snort and ClamAV

Posted on by

ClamAV is a great Open Source virusscanner that can be used for detecting virusses from Snort or Snort_inline using the ClamAV preprocessor. However, by using the anti-phishing and anti-scam signatures by SaneSecurity, this combination can also be used to detect and block phishing and scam attempts. Here is how to set it up.

I’ve decided to run this on my gateway, which is a slow machine. Because I don’t want all my traffic to slow down to much, I’m not going to run the ClamAV defs, only the anti-phishing ones. The default location of the defs on my Debian Sarge system is /var/lib/clamav, so I’ve created a new directory called ‘/var/lib/clamav-phish’. Next I’ve downloaded the defs from SaneSecurity. After unzipping them and the defs were ready.

Next was setting up the clamav preprocessor. For this I used the config line in my snort config:

preprocessor clamav: ports 80, dbreload-time 3600, dbdir /var/lib/clamav-phish, action-drop, toclientonly

This line says that spp_clamav should look for traffic on port 80 that flows to the client. It should use the signatures in /var/lib/clamav-phish/ and it should drop the traffic if a phishing attempt is detected. It also checks once an hour to see if the defs in the directory have been updated, and reloads them if so.

William Metcalf pointed me to a site where you can test this setup. It’s called MillerSmiles.co.uk and it’s an anti-phishing site, with many examples on their site. Opening an example shows this in my snort_inline log:

11/12-18:44:29.581771 [**] [129:1:1] (spp_clamav) Virus Found: Html.Phishing.Bank.Gen636.Sanesecurity.06051701 [**] {TCP} 209.85.50.12:80 -> 192.168.1.2:34915

The site failed to open, so it works just fine!

Update on Snort_inline 2.6.0.2 development

Posted on by

I have spend the last week trying to find a very annoying bug that caused Snort_inline to go into 100% CPU on certain traffic. It kept working, only my P3 500Mhz home gateway slowed down to between 2kb/s and 25kb/s, while normally it handles the full 325kb/s for my DSL line at around 25% CPU.

Snort comes with a number of performance measurement options. In 2.6 –enable-perfprofiling was introduced. Also, –enable-profile builds Snort for use with gprof. Next to those you can use strace and ltrace with the -c option to see the ammount of time spend in the several functions.

I already knew the problem was related to my new Stream4 code, since running Snort_inline without the ‘stream4inline’ option made the problem go away. So my performance debugging and code reviews were focussed on that code. However, the performance statistics showed no functions that took large ammounts of time in Stream4.

Continue reading →

Rules for reported Tikiwiki vulnerabilities

Posted on by

Yesterday there was a mail to the bugtraq mailinglist about two types of vulnerabilties in Tikiwiki 1.9.5. The most serious is a claimed MySQL password disclosure through a special URI. The second is an XSS, also through an special URI. The message can be found here.

I wrote ‘claimed password disclosure’, because on the Tikiwiki server I run, I could not reproduce it. With that I mean the password disclosure, since I do see that Tikiwiki gives an error that reveals other information, most notably the location of the website on the local filesystem.

Anyway, since I’m running Tikiwiki I was eager to protect myself, so I started to write some rules.

XSS

Since I run ModSecurity on this server, I started with a rule for that:

SecFilterSelective REQUEST_URI “/tiki-featured_link.php?type” “chain,status:403,msg:’LOCAL tikiwiki featured link XSS attempt’,severity:6”
SecFilterSelective REQUEST_URI “/iframe>” log,deny,status:403

I did the same for Snort, and submitted it to the Bleeding Edge ruleset, see here.

Passwd/filesystem disclosure

This one is much harder to catch in a rule. The problem is in how Tikiwiki handles the sort_mode option in an URI. Only if the argument to sort_mode is valid (such as hits_asc or hits_desc for sorting on number of hits) the error is prevented. If the argument to sort_mode is empty or invalid then the disclosure condition triggers.

The only way I can think of to write rules for this is by adding some positive security filtering. In other words, create a rule that defines the valid arguments to sort_mode and drop anything else. Below is an example of one of the affected pages in Tikiwiki:

SecFilterSelective REQUEST_URI “tiki-listpages.php” chain
SecFilterSelective REQUEST_URI “sort_mode=(pageName|hits|lastModif|creator|user|version|
comment|flag|versions|links|backlinks|size)_(asc|desc)” pass,skip:2

SecFilterSelective REQUEST_URI “tiki-listpages.php” “chain,msg:’LOCAL tikiwiki listpages mysql passwd disclosure attempt’,severity:7”
SecFilterSelective REQUEST_URI “sort_mode=” log,deny,status:403

As you can see, here are two logical rules, each consisting of two chained rules. The first rule defines all the possible valid options to sort_mode and then has the action ‘pass,skip:2’. This says that this rule should not use the default action of deny and that the next two rules should be skipped. These next two rules drop every use of the sort_mode option, thus blocking the attack.

I have not yet looked at doing this in Snort. According to the advisory, there are 21 different vulnerable URI’s in Tikiwiki, which all have different arguments to sort_mode. So only 20 more to go! 😉