Smoothwall in a heterogeneous network

Smoothwall is a Linux based UTM appliance, combining a firewall, web proxy and content filter. I have recently implemented Smoothwall for a customer, this implementation included Single Sign On (SSO) support for both Mac OS X and Windows. I didn’t find any good documentation on SSO with Smoothwall for both Mac OS X and Windows so I’ve written up my notes.

Windows has for a long time had SSO support via NTLM, meaning that Windows can (fairly) securely and transparently log in to other systems that are joined to the same Active Directory controller. This is done with a ticket based challenge/response authentication process built into Active Directory.

Mac OS X has had support for Kerberos SSO via Kerberos tickets to various systems since 10.3, it has been through a number of revisions and changes over the years. However it’s not until Mac OS X 10.6.8 that support for Kerberos authentication to web-proxies like the guardian filter in Smoothwall was introduced.

This is the final piece in the puzzle for this customer and now both Apple Macs and Windows desktops “just work” automatically authenticating with Kerberos tickets.

Kerberos SSO requires slightly more careful configuration than NTLM. The main thing to make sure about is that you are accessing the proxy via it’s fully quallified name, ie proxy.example.com not just proxy or it’s IP address.

In this case the customer uses a proxy.pac file, which also needs to contain the proxy server’s full name. Smoothwall includes an option to enable this but it didn’t seem to work in this case so I just made my own simple .pac file and uploaded it.

The configuration on the clients was simple just set the network proxy settings to URL auto-configuration and point it at http://proxy.example.com/proxy.pac

I think Apple are telling the truth about DROPOUTJEEP

When I first listened to Jacob “@ioerror” Applebaum talk from the 30c3 conference in Berlin I was impressed with the number and variety of different tools the NSA was using to monitor and spy on everything. One tool I was especially interested in being an iOS user was DROPOUTJEEP, sold as allowing full access with a 100% success rate in attacking iPhones but only with physical access.
dropoutjeep catalog pageThe physical access part and Apple’s flat denial got me thinking and combined with some practical knowledge about how iOS security works I am fairly sure I understand what DROPOUTJEEP is. I have broken into iOS devices to recover data and pictures for people, it’s simple for older iPhones if you have physical access.
The earlier iPhones (before the 4S) have bootloader flaws allowing an attack on the phone before the iOS kernel boots and the kernel security kicks in. This type of attack allows the injection of a custom ramdisk image containing unsigned code. I used a ramdisk and injection tool that was assembled from an open source iOS exploit and includes an ssh server, and tools to brute force crack an iPhone PIN code using the iPhone’s own crypto hardware to accelerate the process.
The DROPOUTJEEP catalogue page is from 2008, when the iPhone 3G was the new thing, check out the timeline on Wikipedia. Most people who had an iPhone at this time remember the Limera1n jailbreak, which at it’s core is a boot loader attack. This same boot loader flaw is still unpatched even after nearly 4 years. The Limera1n attack works on the iPhone 3G onwards and there are earlier boot loader attacks too. The SHAtter boot loader attack, while never used in a jailbreak was much discussed.These types of bootloader attacks allowing the upload of custom root disks, give full hardware, disk and keybag access ie total ownage. Once your ramdisk is loaded you can just mount the internal storage and extract the data or use additional exploits to install custom malware. Full disk encryption is only a recent development, ie iPhone 3GS onwards ref: http://support.apple.com/kb/HT4175DROPOUTJEEP’s need for physical access tallies to my mind with a boot loader attack. Boot loader attacks are simple, reliable and quick so perfect for an NSA black bag job.

All this is not to say that Apple can’t push remote code to an iOS device, remember Apple has the signing keys and can sign any code they like. There are reports from the early days of iMessage that Apple pushed custom remote code to a stolen iPhone to disable iMessage.

So I think that Apple are telling the truth about DROPOUTJEEP, but that is not to say they don’t cooperate in other ways when warrants or national security letters are involved.

fw_printenv config for AllWinner devices

The u-boot suite of tools has a very handy tool allowing you to work with the u-boot environment from Linux user space. There are two complications with this on the Allwinner SoCs, first the version of the u-boot tools that Debian ships don’t support the mmc card.

You’ll need an up to date version of u-boot git tree either directly from denx or the linux-sunxi project. Downloading and setting up the git u-boot tree is well documented so I’m not going to cover it here, but the fw_printenv tool isn’t built by default so you need to build it.

make env

The fw_printenv tool is found in the tools/env directory, copy it somewhere useful.

sudo install -m 755 tools/env/fw_printenv /usr/local/bin/

To write to the u-boot environment you also need to create a symlink from fw_printenv to fw_setenv.

sudo ln -s /usr/local/bin/fw_printenv /usr/local/bin/fw_setenv

The second problem is making a working configuration file. The configuration file only needs a single line in it to tell fw_printenv where to look (the offset from the start of the device) for the u-boot environment and how big it is. The complication is they need to be in bytes and given in hex, to calculate the offset and size I used the sd layout from the sunxi wiki and a bit of maths in bc to convert it to hex.

To calculate the offset, multiply the number (1088) of blocks by the block size (512 bytes) and then convert it to base16 (ie hex)

echo "obase=16; 1088*512 "| bc

To calculate the size of the u-boot environment repeat the process but this time with the number (128) of blocks by the block size (1024 bytes) and again convert it to base16.

echo "obase=16; 128*1024 "| bc

Finally put the numbers we have calculated in to the configuration file /etc/fw_env.config

# Device to access      offset          env size
/dev/mmcblk0            0x88000         0x20000

You should now be able to run fw_printenv and get your environment printed out, if the error “Warning: Bad CRC, using default environment” then your u-boot setup is different and you shouldn’t use fw_setenv.