If this wasn’t bad enough you can simply boot the system using the installation DVD and reset any administrator password, login and have instant access to the system keychain. So, well, using the system keychain for passwords to encrypted disks is not a great idea.

I therefore removed the articles referring to how to setup TrueCrypt with the keychain.

Unfortunately licensing issues prevent me from publishing my pre-compiled versions of TrueCrypt. So the next best thing I can do until there’s a new version of TrueCrypt that supports Snow Leopard, is to publish a “simple” do it your self guide.

In order to compile TrueCrypt for Mac OS X Snow Leopard you need the following:

1. XCode (it’s under the Optional folder on the Snow Leopard Install DVD)
2. macFUSE
3. TrueCrypt and wxWidgets source code
4. Header files from the RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) 2.20.
5. pkg-config
6. A patch that modifies the source code so it compiles under Snow Leopard.

Installing XCode

Install XCode from the Snow Leopard installation DVD. This should be pretty straight forward and hopefully does not need any further explanation.

Installing macFUSE

Download and install macFUSE from here: http://code.google.com/p/macfuse

Installing pkg-config

pkg-config can be installed either through MacPorts or through Fink. The difference is that MacPorts requires you to compile the source and Fink installs the binary version. I personally prefer Fink as it uses the debian package installer. Below you will find instructions for installing either through MacPorts. OR Fink. Don’t do both!

Installing pkg-config through Fink

1. Get and install Fink 0.9 from here: http://www.finkproject.org/download/index.php?phpLang=en
2. Install pkgconfig by issuing the following command:
   
   sudo apt-get update && sudo apt-get install pkgconfig

Installing pkg-config through MacPorts

1. Get and install MacPorts from here: http://www.macports.org/install.php
2. Install pkgconfig by issuing the following command:

   sudo port install pkgconfig

3. Restart the Terminal application

Getting the TrueCrypt and wxWidgets source code

Download the TrueCrypt source code (preferably the tar.gz version) from here: http://www.truecrypt.org/downloads2

Open up a new Terminal window and create a new directory from where you will build TrueCrypt eg. $HOME/src:

mkdir $HOME/src

Uncompress the downloaded file into the new directory:

cd $HOME/src; tar xvzf $HOME/Downloads/TrueCrypt\ 6.2a\ Source.tar.gz

TrueCrypt uses the wxWidgets cross platform GUI library and therefore needs it to compile. Get it here:
http://prdownloads.sourceforge.net/wxwindows/wxMac-2.8.10.tar.gz

Uncompress the wxMac-2.8.10.tar.gz file into the $HOME/src directory using the following command:

cd $HOME/src; tar xvzf $HOME/Downloads/wxMac-2.8.10.tar.gz

You should now have two directories in the $HOME/src directory truecrypt-6.2a-source and wxMac-2.8.10. You can verify this by running the following command:

ls $HOME/src

In order to compile TrueCrypt for Snow Leopard the source code has to be patched slightly. I have prepared a patch file that can be applied to the code automatically using the patch utility. Download the patch from here: http://patrik.cqure.net/files/truecrypt-snow-leopard.patch

Apply the patch by running the following command:

cd $HOME/src; patch -p0 < $HOME/Downloads/truecrypt-snow-leopard.patch

You should see the following output:

patching file truecrypt-6.2a-source/Main/FatalErrorHandler.cpp
patching file truecrypt-6.2a-source/Main/StringFormatter.h
patching file truecrypt-6.2a-source/Makefile
Hunk #1 succeeded at 145 with fuzz 2.

TrueCrypt also uses a number of header files from RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) 2.20. These have to be downloaded manually from here: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20. The files needed are pkcs11.h, pkcs11f.h and pkcs11t.h. They need to go into the directory $HOME/src/pkcs11. If your lazy you can run the following, which does this for you:

mkdir $HOME/src/pkcs11; cd $HOME/src/pkcs11; \
for f in pkcs11.h pkcs11f.h pkcs11t.h; do \
curl --no-epsv --ftp-pasv "ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/${f}" > ${f}; \
done

Ok, so now we are all set with the source code and can begin compiling.

Compiling TrueCrypt

First of all we need to point out where our RSA Security pkcs stuff is located. You do this by issuing the following command in the Terminal:

export PKCS11_INC=$HOME/src/pkcs11

Once this is done we can start to compile the wxWidgets by issuing the following command:

cd $HOME/src/truecrypt-6.2a-source; make WX_ROOT=$HOME/src/wxMac-2.8.10 wxbuild

Compilation will take time and at times look as if it has stopped. Be patient and disregard any WARNINGS or error messages that you may see (there may be quite a few with different information!) If all went well you should now have a directory called $HOME/src/truecrypt-6.2a-source/wxrelease with 355 items in it. You can verify this by issuing the following command:

ls $HOME/src/truecrypt-6.2a-source/wxrelease | wc -l

With the wxWidgets compiled we can now start compiling TrueCrypt by issuing the following command:

cd $HOME/src/truecrypt-6.2a-source; make WXSTATIC=1

Again, compiling TrueCrypt will take some time but it should not return any errors. If all goes well, which it should if you have followed the guide properly, you should end up with a TrueCrypt.app folder under the Main directory. You can test whether the application works or not by running the following command:

open $HOME/src/truecrypt-6.2a-source/Main/TrueCrypt.app/

If it starts, you’re all set and simply need to copy or move the application into /Applications as usual. From the Terminal you can do this by issuing the following command:

cp -R $HOME/src/truecrypt-6.2a-source/Main/TrueCrypt.app /Applications

Good luck!

When running with a different MAC address, the address should be changed both using ifconfig and then set as parameter when starting airbase-ng with the -a switch.  Thanks again Hirte!

All in all I am very pleased with the setup, as it behaves consistantly now (knowing the needed tweaks to get it running). I believe it performs as well as running an AP with the madwifi-ng karma kernel patches from digininja. Well, except for one thing. When changing the MAC address of the wifi card it doesn’t really do such a good job anymore. For some reason most clients fail to associate, some still do but theres a considerable drop in the number of connecting clients.

I have tried to change the MAC using both ifconfig and simply specifying the -a option to airbase-ng. Sniffing the traffic using another wifi card shows a lot of probe requests and responses being re-sent, but no requests to associate. From my initial checks I do not see any difference in the requests or responses apart from the “Frame check sequence” and the MAC of-course. But then again, I haven’t put that much time into it.

ANY insight into why this happens, and if I am missing something REALLY obvious would be great. I will file a bugreport in the aircrack-ng TRAC system once I collect and clean the relevant packet traces.

What remains in order to get a good solid environment running is a better wifi card with a lot better transmit power, which I’ve ordered from the UK today. Hopefully it will be here by monday so me and my friend can do some more tests over a beer or two.

For starters I (once more) ripped apart my USB adapter and de-soldered my external antenna cable and found a better spot for it. The new re-fitted antenna works a lot better now and actually picks up quite a few new networks (and clients of course).

Another change I made was to switch the wireless drivers to the ones available from the git kernel sources which for the moment seem to work better than the previous ones.

I still believe in the airbase-ng concept of a user-mode AP which works with many different chipsets and not that dependent of driver patches. However, in order to switch away from the madwifi-patches it has to work atleast as good as they do and with a USB wifi-interface.

Once I get things running I’ll post my setup here. If someone already has done so, please drop me a line with your setup including hardware

As a friend told me about the airbase-ng project I though I would give it a shot…

Having tried airbase-ng with both the built-in Atheros chipset and with numerous USB rt73 based wifi-interfaces I was still not satisfied with the result. Even though I got airbase-ng working (at least sometimes) it would not let clients associate to the wifi-network to the extent that the “karma” madwifi-ng driver patches do. In spots were the patched madwifi drivers were picking up and letting 10 clients associate, airbase-ng would pick up and associate one and only list direct and broadcast probes from the others. Having limited time to debug the software in order to understand the reason for this I stuck to the madwifi-ng “karma” patches.

A good set of “karma” madwifi-ng patches are available from www.digininja.org and can be downloaded here:
http://www.digininja.org/files/karma-madwifi-0.9.4-3379.patch

These patches make it possible to activate and inactivate the “karma” behaviour by using iwpriv and therefore do not interfere as much with the driver as other patches have been doing in the past.

In order to install them to the eee a subversion snapshot of the madwifi-ng drivers, supporting the chipset in the eee must be downloaded. A subversion snasphot of the madwifi-ng driver can be downloaded from here:
http://snapshots.madwifi.org/madwifi-hal-0.10.5.6/madwifi-hal-0.10.5.6-r3835-20080801.tar.gz

As the patches come for another subversion version than the one were downloading a couple of hunks will fail when applying the patch. In order to address these failed hunks I am supplying an additional patch which has to be applied after this first one to correct the failed hunks. This patch can be found here:
http://www.cqure.net/files/001-madwifi-hal-0.10.5.6-r3835-20080801-digininja-fixup.patch

These are the steps i took to install the patched driver to the eee PC:

wget http://snapshots.madwifi.org/madwifi-hal-0.10.5.6/madwifi-hal-0.10.5.6-r3835-20080801.tar.gz
tar xvzf madwifi-hal-0.10.5.6-r3835-20080801.tar.gz
cd madwifi-hal-0.10.5.6-r3835-20080801/
wget http://www.digininja.org/files/karma-madwifi-0.9.4-3379.patch
patch -p1 < karma-madwifi-0.9.4-3379.patch
wget http://www.cqure.net/files/001-madwifi-hal-0.10.5.6-r3835-20080801-digininja-fixup.patch
patch -p1 < 001-madwifi-hal-0.10.5.6-r3835-20080801-digininja-fixup.patch
make
sudo make install

I held yet another speech on SQL injection and yet again overestimated my ability to deliver slides at a pace of 0.78 minutes per slide. Skipping through a few of them gave me just the little time I needed to finish up with a short demo

After a few requests for the presentation I decided to put it online together with the small DNS server and samle code I used to demonstrate the DNS-channeling parts.

The DNS server has a brief help describing each parameter. Basically in order to try it out, it needs to be run on either:

• An authorative DNS in the zone against which we are tunneling our queries. Please note that in the event of a zone having multiple DNS servers assigned to it, all queries will NOT end up at the same resolver.
• On the host assigned as the DNS server on the victim DB server

When starting the dns_server.pl script a zone for which it answer queries needs to be specified. This is done with the “-q” option. In my cheat sheet I am using the zone inj.cqure.net and therefore need to start the DNS server like this:  ./dns_server.pl -q inj.cqure.net

A zip-file containing the PDF presentation, a subset of the cheat sheet I used and my small DNS server is available for download from here.

Feel free to drop me a line if you have any questions.

“The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security “visible,” so that people and organizations can make informed decisions about application security risks.”