Here is a great write up by the guys over at Offensive Security. They managed to work the iTunes OS X exploit around and got it to work in Windows too. And for all of those wanting to use it, they did post the exploit at the bottom. Here is a little about how they got there.

Our new AWE course is about to go live for the first time, in BlackHat Vegas. We chose the most interesting exploitation cases we’ve encountered, and dove really deep into them. We had many exploits to choose from, some were too easy, and believe it or not, some were just too hard. This blog post is going to be a multipart post, describing our exploitation process of the recent iTunes overflow described here. This is possibly one of our most involved and interesting exploits to date.

An exploit for OSX was released and discussed here. Being naturally inquisitive, we checked to see if this exception would occur in Windows too, and indeed it was!

After attaching a debugger to the iTunes process, we noticed it was getting terminated after around 30 seconds. It looked like iTunes had anti-debugging features implemented. Fortunately, Immunity Debugger offers anti-debugging scripts which are useful for situations just like this. Invoking the !hidedebug command within ID allowed the debugger to continue running in hidden mode, bypassing our first hurdle.

Using the OSX exploit as a template, we attempted to crash iTunes several times, however the process would keep terminating with no opportunity for code redirection. After inspecting the call stack in one of the crash cases, we saw that one function was calling ZwTerminateProcess.

We assumed this was a stack protection mechanism. We placed a breakpoint there. This would halt ID just before the stack cookie check, allowing us to examine the vulnerable function in greater depth, and also to confirm our “stack protection” theory.

We soon realised that trying to approach the stack canary head on would be difficult. We attempted to increase the buffer length we were sending in order to get a SEH overflow, which would effectively bypass the canary protection. The Gods of buffer overflows were in our favour – and an SEH overwrite was achieved!

From here on, we expected things to get easier. Little did we know….

(Via Offensive Security)

I have a MacBook that I LOVE. To use it as a penetration testing platform I installed all kinds of software, but mostly just found myself using BackTrack. The only thing I hated was having to reboot to Backtrack to do packet injection, and a few other wireless tools. that is till I found this baby:

This is the Fonera by Fon. It is currently running for $29, but you can usually find some decent coupon codes, and you can also pair it up with a better antenna for better range.

So why on earth do you want this router, and how does this in any way correlate with packet injection? Well you have to start by flashing the ROM to put a different firmware on it. While not the easiest task in the world, pretty much all you have to do is follow directions. Here is the guide to put Legend firmware on the Fonera.

The Legend firmware comes with the Aircrack-ng suite of tools. Including a very special tool we will use called Airserv-ng. Best described by the guys that made it:

Airserv-ng is a wireless card server which allows multiple wireless application programs to independently use a wireless card via a client-server TCP network connection. All operating system and wireless card driver specific code is incorporated into the server. This eliminates the need for each wireless application to contain the complex wireless card and driver logic. It is also supports multiple operating systems.

This is allowing you to use the Fonera for it’s great wireless transceiver, and the host machine as the number cruncher. This allows a machine with no wireless connection, non-compatible, or virtual machine to use the Fonera as it was an internal card. Which works great for running BT4 in a VMWare session and injecting from there. Usage is given on the Airserv-ng page:

At this point you may use any of the aircrack-ng suite programs on the second system and specify “192.168.0.1:666” instead of the network interface. 192.168.0.1 is the IP address of the server system and 666 is the port number that the server is running on. Remember that 666 is the default port number.

On the second system, you would enter “airodump-ng 192.168.0.1:666” to start scaning all the networks. You may run aircrack-ng applications on as many other systems as you want by simply specifying “192.168.0.1:666” as the network interface.

Now I know what some of you are saying, “This is great, but not a useful mobile application.” Don’t worry baby bird, I have you taken care of, you really think I would leave you hanging like that? That’s not my style. (Thanks DT)

This 4 AA battery pack from Radio Shack, with the “L” size adapter, and even the crappy over priced batteries will set you back less than $10. So now you have a complete mobile solution for doing what ever you would like with wifi.

This should be all the info you need to complete this setup. If you get stuck anywhere, or have other questions, please post them in the comments area below and I will do my best to help you out.

Getting Vmware Tools VMHGFS working on BackTrack 4 Beta: “The stock Vmware Tools compile almost perfectly on BackTrack 4, with the exception of VMHGFS, which provides file sharing between the guest and host machine.

The compile error looks like this :

CC [M]  /tmp/vmware-config0/vmhgfs-only/module.oCC [M]  /tmp/vmware-config0/vmhgfs-only/page.o/tmp/vmware-config0/vmhgfs-only/page.c: In function ‘HgfsDoWriteBegin’:/tmp/vmware-config0/vmhgfs-only/page.c:763: warning: ISO C90 forbids mixed declarations and code/tmp/vmware-config0/vmhgfs-only/page.c: In function ‘HgfsWriteBegin’:/tmp/vmware-config0/vmhgfs-only/page.c:867: error: implicit declaration of function ‘__grab_cache_page’/tmp/vmware-config0/vmhgfs-only/page.c:867: warning: assignment makes pointer from integer without a castmake[2]: *** [/tmp/vmware-config0/vmhgfs-only/page.o] Error 1make[1]: *** [_module_/tmp/vmware-config0/vmhgfs-only] Error 2make[1]: Leaving directory `/usr/src/linux-source-2.6.28.1'make: *** [vmhgfs.ko] Error 2make: Leaving directory `/tmp/vmware-config0/vmhgfs-only'Unable to build the vmhgfs module.

A quick Google search brought me to a vmhgfs patch that fixes this compile error.
To fix this:

0) Extract kernel sources and build dependancy scripts!
1) Start the Vmware tools install
2) Copy the vmware tools to /tmp
3) Replace the vmhgfs package with the patched one and install vmware tools

root@bt# tar zxpf VMwareTools-7.9.3-159196.tar.gzroot@bt# cd vmware-tools-distrib/root@bt# cd lib/modules/source/root@bt# rm vmhgfs.tarroot@bt# wget www.offensive-security.com/vmhgfs.tarroot@bt# cd /tmp/vmware-tools-distrib/root@bt# ./vmware-install.pl

Don’t forget to enable file sharing in VMWare after installing the tools.

After a restarting the vmware-tools service (or a reboot), you should see your share with a ‘mount’ command.

root@bt# mount |grep hgfs

.host:/ on /mnt/hgfs type vmhgfs (rw,ttl=5)

root@bt# ls -l /mnt/hgfs/

total 1

drwxr-xr-x 1 501 dialout 204 2009-04-12 11:48 bt4

root@bt#

“

(Via Back|Track LiveCD Blog.)