ITunes Exploitation Case Study

Author: Matteo Memelli

When masochism just isn’t enough

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….

(to be continued next week …)

Our working exploit can be found here .