Sunday, November 29, 2009

Compiling and running Windows programs on Linux

While the title of this post could make you wonder why you ever want to do this, there is actually a scenario where this comes handy. Let's say you downloaded exploit code or for instance the sample source code of the Database hackers handbook. In both cases you may encounter source code that requires a Windows development environment to compile. While Microsoft offers free express editions for many of their development tools, you still need a copy of Windows somewhere.

Last week I decided to try a different route with MinGW, which is a port of GCC that can be used to develop native Windows applications. If you want to use MinGW under Linux you have to build a cross compiler. Historically this has been a difficult task. On Gentoo Linux however there is a package named crossdev. Once installed this package automates the task of building a cross compiler. With the following command you can build a MinGW cross compiler:

$ sudo crossdev -t i686-mingw32

Building the cross compiler may take some time. Once installed the following command could be tried to compile one of the source code samples from the Database hackers handbook:

$ i686-mingw32-gcc C2_2.cpp -o dbsnmp.exe

However, you will receive receive several errors:
C2_2.cpp: In function ‘int StartWinsock()’:
C2_2.cpp:83: error: ‘isalpha’ was not declared in this scope
C2_2.cpp: In function ‘int QueryDBSNMP(int)’:
C2_2.cpp:128: error: ‘con’ was not declared in this scope
C2_2.cpp:128: error: ‘nect’ was not declared in this scope
C2_2.cpp:134: error: invalid conversion from ‘unsigned char*’ to ‘const char*’
C2_2.cpp:134: error:   initializing argument 2 of ‘int send(SOCKET, const char*, int, int)’
C2_2.cpp:135: error: invalid conversion from ‘unsigned char*’ to ‘char*’
C2_2.cpp:135: error:   initializing argument 2 of ‘int recv(SOCKET, char*, int, int)’
C2_2.cpp:142: error: ‘PrintResponse’ was not declared in this scope
C2_2.cpp:143: error: invalid conversion from ‘unsigned char*’ to ‘const char*’
C2_2.cpp:143: error:   initializing argument 2 of ‘int send(SOCKET, const char*, int, int)’
C2_2.cpp:144: error: invalid conversion from ‘unsigned char*’ to ‘char*’
C2_2.cpp:144: error:   initializing argument 2 of ‘int recv(SOCKET, char*, int, int)’
C2_2.cpp:152: error: invalid conversion from ‘unsigned char*’ to ‘const char*’
C2_2.cpp:152: error:   initializing argument 2 of ‘int send(SOCKET, const char*, int, int)’
C2_2.cpp:153: error: invalid conversion from ‘unsigned char*’ to ‘char*’
C2_2.cpp:153: error:   initializing argument 2 of ‘int recv(SOCKET, char*, int, int)’
C2_2.cpp:166: error: invalid conversion from ‘unsigned char*’ to ‘const char*’
C2_2.cpp:166: error:   initializing argument 2 of ‘int send(SOCKET, const char*, int, int)’
C2_2.cpp:167: error: invalid conversion from ‘unsigned char*’ to ‘char*’
C2_2.cpp:167: error:   initializing argument 2 of ‘int recv(SOCKET, char*, int, int)’

The error on line 83, about the isalpha function can be fixed by including ctype.h. The error about line 128 are caused by the extra minus sign in the connect function name. Script kiddie protection, who knows? The rest of the errors could be fixed by casting (char *) the send and receive buffers. Trying to compile again leaves us with one error:

C2_2.cpp:143: error: ‘PrintResponse’ was not declared in this scope

This error is caused by a missing declaration of the PrintResponse() function at the top of the source file. Once that error is fixed we encounter linking errors:
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x125): undefined reference to `_WSACleanup@0'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x158): undefined reference to `_WSAStartup@8'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x18d): undefined reference to `_WSACleanup@0'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x1b9): undefined reference to `_gethostbyname@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x20c): undefined reference to `_inet_addr@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x2cf): undefined reference to `_socket@12'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x30a): undefined reference to `_htons@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x32b): undefined reference to `_bind@12'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x343): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x368): undefined reference to `_htons@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x38d): undefined reference to `_connect@12'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x3a5): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x3e2): undefined reference to `_send@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x40d): undefined reference to `_recv@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x424): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x476): undefined reference to `_send@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x4a1): undefined reference to `_recv@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x4b8): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x50a): undefined reference to `_send@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x535): undefined reference to `_recv@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x54c): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x58b): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x5c3): undefined reference to `_send@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x5ee): undefined reference to `_recv@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x605): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x626): undefined reference to `_closesocket@4'
collect2: ld returned 1 exit status

All these functions are part of winsock library on Windows. What we need to do now is locate winsock.h on the local file system (use the one in the mingw directory, when multiple are found) and add the following options to our compile command:


$ i686-mingw32-gcc C2_2.cpp -o dbsnmp.exe -L/usr/i686-mingw32/usr/include/ -lws2_32

Finally our source compiled and linked and now we can run it with wine:
$ wine dbsnmp.exe



    Oracle DBSNMP Tool

    C:\>dbsnmp.exe host status|stop

    David Litchfield
    davidl@ngssoftware.com
    4th June 2004

Yeah, a running program at last!

Monday, November 23, 2009

Building your own ethernet tap for just over 25 euros

Recently I was looking for a solution to place an IDS in front of my firewall and monitor my internet connection. This way I would be able to detect all attacks, even the ones that get blocked by my firewall. My ADSL modem is in bridging mode and my firewall has the external IP address of the connection. I have a Siemens modem and although the embedded XSH shell is not very well documented it does not seem like it has a SPAN port feature like some of the Speedtouch ADSL modems, which are also commonly used for broadband connections in the Netherlands.

While I could have run Snort on my firewall, I decided I wanted to have a separate system for monitoring. I looked at buying a 100Mbit tap of the shelve, but those are still too expensive for home use. I searched the internet to see if it would be possible to build my own. Several people already succeeded in building their own, so I decided to give it a shot.

In order to build a tap for 10/100Mbit you need four ethernet ports. Two to connect both hosts and two ports which will receive a copy of either the sent (TX) or receive (RX) pair of wires from the ethernet cable. So each tap port will receive only half of the connection, as shown in the diagram below, which used to be on the Snort website:

This means that the tap ports can only receive traffic, and will not be able to send out any network traffic. This will prevent you from creating dangerous loop holes bypassing your firewall.

I made a small shopping list and tried to get the supplies at the local computer or electronic shops. Many examples use ethernet mounting wall systems with four ports, but those are hard to get in the shops. I ended up taking a different route and I bought two ethernet cat 5e surface mounting wall boxes at the local computer shop. Once you take of the plastic covers you end up with to metal boxes as shown below:


When the covers are taken of you can see the punch through blades for the individual wires, which allow you to do the wiring without soldering. I carefully stripped 15 cm of ethernet cable and took the twisted wire pairs out. Following the coloring diagram above I wired the wire pairs through the punch through blades with a screw driver. It is important to keep the wire pairs twisted, in order to minimize interference. The picture below shows the end result:


Although the wiring does not look too clean in the picture, it turns out it works very well for over a week now, without any interface errors on the firewall. The ethernet tap cost me just over 25 euros and a few hours to build.

The last step is to combine both tap ports into one virtual interface on the monitoring system, which will see the complete traffic flow in both directions. This can be done by using the interface bonding option (CONFIG_BONDING) of the Linux kernel. On Gentoo systems the following configuration in /etc/init.d/net allows the virtual bond interface at boot time:

slaves_bond0="eth0 eth1 "
config_bond0=( "null" )
config_eth0=( "null" )
config_eth1=( "null" )
RC_NEED_bond0="net.eth0 neth.eth1"

Of course the proper symlinks need to be in place in /etc/init.d/ for all network interfaces that must be started at boot time. Tests with tcpdump and wireshark on the bond0 interface show the complete traffic flow between the systems. Next step is to install Sguil on the monitoring system!

Monday, July 13, 2009

PF based NAT firewall quirk

It's been a while since my last post, but today I decided to finish a post that I started some time ago, but never finished. It's about a configuration issue with the PF firewall when using NAT for the systems behind the firewall. All the examples you will find on the net define the following rule for NAT-ing internal traffic before it is send to the internet:

# NAT inside -> outside
nat on $ext_if from !($ext_if) to any -> ($ext_if)

This may a look a bit cryptic at first sight, but this basically performs NAT on the external interface for packets which have an ip source address, which is not equal (exclamation mark) to the dynamic ip address (denoted by the parentheses) of the external interface. This rule only performs the NAT and does not let the network packets actually flow through the firewall. We need two more rules. One to let the traffic in on the internal interface and one to let the traffic go out on the external interface:

# allow internal lan to access the Internet
pass quick from $int_lan to any

# allow packets out
pass out quick on $ext_if

These rules are not very strict and basicly allow all outgoing traphic, but even if we replace them with stricter ones, something odd happens. In the past I have used iptables a lot and there you have the concept of chains, namely INPUT, OUTPUT and FORWARD. The INPUT and OUTPUT chain are for the local machine or firewall and the FORWARD chain along with the PREROUTING and POSTROUTING chains are for the systems behind the firewall and NAT.

PF does not have that concept and the rules above will also allow all outgoing traffic initiated from the firewall itself! This is probably not what we intended here and is caused by the NAT rule that translates the source ip address of the packets that are about to leave the firewall. Since the source ip address is already translated before the last pass out rule is hit, this rules is not able to differentiate local generated traffic from NAT-ed traffic and will allow all traffic to leave the firewall. So is there a way to prevent this? Luckily there is an option with PF to tag a packet, which labels a packet with a tag that can be read by other rules and acted upon. This way we can differentiate traffic that flows through a NAT rule and traffic that does not.

Let me show you how this works in practice. First we tag packets on the NAT rule:

# NAT inside -> outside
nat on $ext_if from !($ext_if) to any tag NAT -> ($ext_if)

Next we pass out only tagged traffic on the external interface:

# allow NAT-ed packets out
pass out quick on $ext_if tagged NAT

Keep an eye out for this pitfall when performing security reviews on PF rulesets, because I have seen many examples on the internet without the tag option.

Wednesday, April 15, 2009

Nessus 4.0.0 Gentoo ebuilds

Today I've updated my Gentoo Nessus ebuilds to the just released version 4. Since the official maintainer of the Nessus ebuilds for Gentoo is very slow with updating, I've submitted the updated packages to the sec-tools overlay. At the moment they are not available yet, but I expect them to become available very soon.

If you can't wait you can also grab the ebuilds for both the server and the client from this Gentoo bug report. Unlike the previous versions this version of the service package does not include any plugins anymore. So in order to do something usefull with it you have to register either a Professional or Home feed at Tenable and fetch the newest plugins once installed.

Please let me know if you encounter any problems and leave a comment here or at bug id 265555.

Tuesday, April 7, 2009

Channel 13, now you see it, now you don't

This is just a quick blog post about scanning for wireless Wi-Fi networks. As you might know, in the US only 11 channels are allowed for the B/G band, but outside the US we have a few more channels. Here in the Netherlands also channel 12 and 13 are being used and Japan uses channel 14 as well.

When we scan for wireless networks with for instance airodump-ng using a default Linux installation, we might not directly notice that we are commonly scanning only 11 channels. Access points, ad-hoc networks and clients might show up on channels above 11 depending on your geographic location and the distance to these networks and clients. However, the trouble starts when you actually try to connect to these networks on channels 12, 13 or even 14 using iwconfig, wpa_supplicant or GNOME NetworkManager. Suddenly you are not able to connect, although you detected the network before. How is this possible? This caused by overlapping channels, which is described in this wikipedia article and I quote the relevant section below:

"There are 14 channels designated in the 2.4 GHz range spaced 5 MHz apart (with the exception of a 12 MHz spacing before Channel 14). As the protocol requires 25 MHz of channel separation, adjacent channels overlap and will interfere with each other."

This means there are only three non overlapping channels, namely 1, 6 and 11. The following picture shows the overlap of the other channels (courtesy of the same wikipedia article):



This explains why we detect channels in monitor mode we can't consequently connect to. How can this be fixed? First of all, you need the proper wireless card, because most cards have only the allowed channels enabled for the region they are sold. For some cards other channels can be enabled by hacking the firmware, but that's outside the scope of this blog posting. It also depends on which driver or Linux IEEE 802.11 networking stack the wireless card is using. Many cards use the mac80211 networking stack, which uses a kernel module named cfg80211. This module has the option to set the regdomain using the ieee_regdom variable. This variable accepts currently the values US (default), EU and JP. To enable the correct regdomain at boot time for most Linux distributions the following line should be added to the file /etc/modules.d/cfg80211:

options cfg80211 ieee_regdom=EU

Atheros chipset based wireless cards who use the madwifi-ng drivers need to follow a different procedure, because these drivers use their own hal (hardware abstraction layer) instead of the generic mac80211 layer.

Kismet users should also enable the channels they want to scan for in the kismet.conf configuration file (defaultchannels option).

Saturday, February 7, 2009

Welcome to my shiny new blog

Hi,
Welcome to my shiny new blog! A long time idea, but finally realised in 2009. This blog will contain tips, tricks, research and observations about penetration testing and security in general.

For those who are wondering what stoked means, urban dictionary has a nice definition:

"stoked" - adjective - to be "stoked" is to be completely and intensely enthusiastic, exhilirated, or excited about something. those who are stoked all of the time know this; being stoked is the epitome of all being. when one is stoked, there is no limit to what one can do.

The term is commonly associated with surfing, which is also a hobby of me.