iPhone tethering in OS 3.0
Yesterday I decided I would try out the new OS 3.0 beta 1. I've been looking forward to having tethering in my iPhone very much, since I'm often traveling and working at the same time. Buying an extra device for laptop internet (like a UMTS USB dongle) doesn't seem right, since I'm already paying for unlimited data access with my iPhone subscription. After having heard some reports of people in NL who got tethering to work with T-Mobile, I decided it was time.
To get to the tethering, one must go through these steps:
- Register your iPhone's UUID with apple
- Get the OS 3.0 beta firmware image
- Install the iPhone SDK or at least the USB System Components package that comes with it
- Change the carrier information on you iPhone by uploading a modified IPCC file
I'm registered as an Apple developer since the company where I work is starting to build iPhone apps. So, getting the device registered and downloading the OS 3.0 beta image and SDK was easy.
Upgrading to the new image is done by clicking the "Check for Update" button in iTunes while the Option key is pressed. This allows you to select a firmware image to update to. By selecting the 3.0 image, the device is upgraded. Then the SDK story. I already have the iPhone 2.2 SDK, since I've started writing iPhone apps. For tethering to work however, you need the 3.0 SDK or a part of it. I first installed the pkg that only contains the necessary drivers for USB tethering (the whole SDK is a 2.15 GB download). This file can be found here. Later, when tethering didn't work, I installed the whole SDK, and when it still didn't work, I installed the small PKG again. It finally worked 
Then, you need an IPCC file. For T-Mobile NL, you can find such a file in this excellent post. It didn't work for me though, I downloaded this file (thanks to Wiebel).
At first, iTunes and my iPhone would crash when I plugged the iPhone in with tethering enabled. After re-installing the PKG with drivers again, this problem was fixed. Tethering via bluetooth worked after using Wiebel's IPCC file. So, now it works both via bluetooth and USB!
Visim – website visitor simulator
Today I uploaded some code I wrote for my bachelor thesis to Google Code as an open source project. My bachelor thesis was about creating a scalable architecture for heavy-duty web apps. I created such an architecture, and validated it on a prototype. To see what effect changes to the system had on its capacity, I wrote a tool that measures how many users can be served by the system. This tool is now public under the name "visim".
To measure how many users a system can serve, I used the following steps:
- Set requirements on response times (like 500ms for 90% of the requests, 1 sec for 98% of the request etc)
- Run the tool with these requirements for a low number of users
- Increase the number of users until the requirements aren't met anymore
Then you can make changes to the system and re-run the tool to see if it still serves the same amount of users, or perhaps more.
The project is at http://code.google.com/p/visim
nschaind updated
In my previous post I wrote about my new tool, nschaind (http://code.google.com/p/nschaind). It detects if a querying dns resolver is vulnerable to cache poisoning according to VU#252735. It's now been updated to also include VU#927905, BIND 8 cache poisoning vulnerability. BIND 8 has the same kind of weakness in its PRNG, although it has a different PRNG from BIND 9. Amit Klein discovered this vulnerability after discovering the one in BIND 9. These two vulnerabilities form the basis for Dan Kaminsky's now famous DNS flaw (VU#800113).
Anyway, the tool has been updated to detect weak BIND 8 and 9 resolvers, so go and check it out!
Bind cache poisoning scanner
As a part of my master on computer security, I've written a tool that detects if a certain resolver is vulnerable to cache poisoning according to CVE-2007-2926. This vulnerability report from 2007 describes a bad practice of bind, that wasn't fixed until July 2008, when Dan Kaminsky came out with his famous DNS vulnerability.
It comes down to this: bind versions up to 9.4.1 use a fixed source port for queries. This source port is determined at startup. Furthermore, they employ a bad PRNG for query IDs. This leads to predictability of the next query ID. One can exploit these two vulnerabilities together to send a resolver false DNS information, since all of the packet can be constructed and sent before a real server could: cache poisoning.
I found this whole thing very interesting, and decided that it would be nice to write a tool that could detect if a certain resolver was vulnerable to this vulnerability or not. In order to be vulnerable, a server would have a) the same source port for multiple requests and b) have predictable query IDs. To detect this, I followed the path Amit Klein described in his path: CNAME chaining. The tool acts as a DNS server. When a resolver sends a request for an A or MX record, it answers with a CNAME record within the domain, triggering another query from the resolver. And then, it does that again and again, up to 10 times. In these 10 times, the tool can determine if the source port was the same all the time, and if any of the IDs was predictable. Only when a query ID is even can the tool predict a range of 10 possible next query IDs (again, Amit Klein's approach).
The tool accepts MX requests. This is because most resolvers do not accept queries from outside their own network. To make them query your domain, one of the possible tricks is interact with the website of your target to find and make it send you email. To send you email, the resolver will perform an MX lookup, exposing it's resolver IP to you, and creating a possibility for fingerprinting. If the resolver is open to the world, you can use a tool like fpdns to fingerprint it further.
I used this project to learn C, so don't expect too much of the programming. The source is here, as a Google Code project. Of course, it's intended for legal penetration testing and research only!
A sample of the output:
chris$ sudo ./nschaind -c lab2.6core.net -f masteen.6core.net -m mail Chaining daemon listening on 0.0.0.0:53 ------------------------------ A mail.lab2.6core.net. ? 192.168.1.2:45682,18216 chaining (1) A chain00.lab2.6core.net. ? 192.168.1.2:45682,25421 chaining (2) A chain01.lab2.6core.net. ? 192.168.1.2:45682,33129 chaining (3) A chain02.lab2.6core.net. ? 192.168.1.2:45682,3140 chaining (4) A chain03.lab2.6core.net. ? 192.168.1.2:45682,34338 (p) chaining (5) A chain04.lab2.6core.net. ? 192.168.1.2:45682,41383 chaining (6) A chain05.lab2.6core.net. ? 192.168.1.2:45682,63194 chaining (7) A chain06.lab2.6core.net. ? 192.168.1.2:45682,31597 (p) chaining (8) A chain07.lab2.6core.net. ? 192.168.1.2:45682,64114 chaining (9) A chain08.lab2.6core.net. ? 192.168.1.2:45682,64825 (p) chaining (10) A chain09.lab2.6core.net. ? 192.168.1.2:45682,51181 answering (10) Target 192.168.1.2 correct prediction count: 3, different source ports: 1 TARGET IS VULNERABLE
Server setup part 4: Networking
This is part 4 of the series on my new server setup with Ubuntu and Xen.
- Part 1: Overview and OS
- Part 2: Disk setup (RAID, LVM)
- Part 3: Xen and domU setup
- Part 4: Networking setup
- Part 5: Intrusion Detection (IDS) setup (coming soon)
Networking and Xen
As for networking, this is a bit different from the normal situation. My colo provider (Coloclue, great joint) is located in multiple datacenters in Amsterdam. They have an IP range for every datacenter, the machines in datacenter 1 will get IPs from a different range than those in datacenter 2. However, if one needs more than one IP address, as I do for my virtual machines, they will assign IP addresses from another range that is not datacenter specific. So, my dom0 has an IP address specific to the datacenter from range A, and the domUs will have IPs from range B. Furthermore, these IPs from range B are routed as /32s, so there is no loss due to network and broadcast addresses.
For dom0, there is no problem. I just configured eth0 with an IP address, the appropriate netmask for the datacenter range, and the default gateway. For domUs however, the story is different. Bridged networking, which is default in Xen, doesn't work now. We'll have to switch to routed mode. In bridged mode, Xen creates a bridge device on dom0, and a number of ethernet devices on top of that. The bridge forwards packets to the ethernet devices at layer 2. With routing however, packets are forwarded on IP level, layer 3. Dom0 will act as a router for the domUs.
Server setup part 3: Xen and DomU’s
This is part 3 of the series on my new server setup with Ubuntu and Xen.
- Part 1: Overview and OS
- Part 2: Disk setup (RAID, LVM)
- Part 3: Xen and domU setup
- Part 4: Networking setup
- Part 5: Intrusion Detection (IDS) setup (coming soon)
Xen and domU's
Setting up Xen on Ubuntu Server is pretty straightforward:
aptitude install ubuntu-xen-server
This meta-package will install all you need. After a reboot, you should be running Xen. Then, for the domU machines. They can be installed using xen-create-image, but I chose the manual setup since I had too much customization to do (in fact, I was too lazy to find out how to do this with xen-create-image). So:
mount /dev/vg0/core-root /mnt debootstrap hardy /mnt http://nl.archive.ubuntu.com/ubuntu
This installes Ubuntu Hardy into the domU. After this initial setup, it is important to edit the following files to reflect your network settings:
/mnt/etc/hostname /mnt/etc/network/interfaces /mnt/etc/resolv.conf /mnt/etc/apt/sources.list
And make the modules for the current kernel available to the domU:
cp -R /lib/modules/`uname -r` /mnt/lib/modules/
Now we can create a xen config file. Mine looks like this: