AppleDoesntGiveAFuckAboutSecurity iTunes Evil Plugin Proof of Concept

Oh this one has been into my head for so long that I finally decided to try and create the code for it. So let’s go!

What’s the background story?
In August *2011* I reported to Apple a security issue with iTunes. What happens is that iTunes plugins are loaded into iTunes process space so they have full control of iTunes. Evil plugins can do all kinds of things such as stealing iTunes passwords and credit card information, or patching some annoying features as I did with Disable m3u plugin.
This is part of Apple’s response:
After examining your report, we feel that this is an area for security hardening that we will consider for future updates.“.

Well, almost three years later and a few iTunes revisions nothing was done regarding this. The plugin folder is writable by current logged in user so a trojan dropper can easily load a malicious plugin. Or it can be used as communication channel for a RAT (Hacking Team, are you reading this?). And so on…

AppleDoesntGiveAFuckAboutSecurity is a quick PoC that installs a breakpoint on SSLWrite function and dumps the clear text buffer that is passed to it before being sent over SSL/TLS secur channel (veryyyy old trick, nothing new). A mini-debugger (exception handler) is installed to handle the breakpoint and dump the information. Of course this could have been done with function hooking but this code is more fun, even if it’s a very quick hack with hardcoded addresses. It is set to be used with latest iTunes available in Mavericks 10.9.1. If you want to play with other versions, just run iTunes under gdb and breakpoint on *SSLWrite. Give a look at the code, it’s pretty small and easy to understand.

When you do the sign in you can see a xml like this being transmitted:

<?xml version=”1.0″ encoding=”UTF-8″?>
<plist version=”1.0″>
<dict>
<key>appleId</key>
<string>abcdefg</string>
<key>attempt</key>
<integer>1</integer>
<key>createSession</key>
<string>true</string>
<key>guid</key>
<string>XXXXXXXXXXX</string>
<key>machineName</key>
<string>XXXXXXX</string>
<key>password</key>
<string>1234567890</string>
<key>why</key>
<string>signIn</string>
</dict>
</plist>

So it’s pretty easy to automate the dump of iTunes login information. Just find the plist and retrieve the fields. A trojan could force the sign out and then intercept the account. Credit card information can probably be stolen the same way. Or maybe interesting stuff from iOS backups? But hey, nobody uses iTunes, everyone went to iCloud, and this is just me being a jerk, right?

I have no idea what is happening inside Apple regarding security. They have very talented people there so it’s most probably a management issue. Or they are just waiting the same fate as Microsoft to change their position. SyScan’13 was almost a year ago and the vulnerabilities presented by Stefan Esser are still unpatched in all systems except Mavericks. Can’t understand this, and spare me the legacy/testing bullshit.

This release is dedicated to Jeffrey, from Apple Product Security Team. Hi Jeffrey!
Just a Friday late night rant :P.

Note: So it seems we have some “trolling” going around HackerNews. I particularly love the lame excuses of “if you run code you are toasted”. Well, this is just bullshit because you have no idea of what you are running most of the time – just see very recent example of CoinThief – and the AppStore and sandboxes are not what will save you (hello Jailbreaks, are you there?). There’s always an application you use outside the app store that can install an evil plugin (how many people verify the install process of apps that request adminstrator privileges?) or can modify quite a few apps in /Applications that aren’t root owned (Hitcon 2012 presentation).
Is this a complete ownage worm remote code execution jailbreak? No, but no one claimed that. It just shows how many small things can be exploited and how your Apple computer is not as safe as most assume. Hacking Team successfully sells one lame malware that is being used to spy upon many people in the world. How many of you have any idea if that is installed or not?

Have fun, and don’t do anything illegal ;-)
fG!

AppleDoesntGiveAFuckAboutSecurity.zip
SHA1(AppleDoesntGiveAFuckAboutSecurity.zip)= 2c872b7c39e6ef1f06f7d0422cb55b7dc7b899b4

14 thoughts on “AppleDoesntGiveAFuckAboutSecurity iTunes Evil Plugin Proof of Concept

    1. Which any normal application you run can do.
      AppStore sandboxed apps? What assures you they don’t contain sandbox escapes? Apple? LOL :-)

  1. While you have found a security issue, I would submit that if your machine is already powned to the point that a trojan dropper can put a bad plugin into your itunes plugin directory, then you are already owned, and have already lost, irrespective of this particular issue.

  2. What steps would you take to prevent this if you were Apple? Presumably if someone has permission to execute arbitrary code on your system, even as an unprivileged user account, you’re pretty screwed as it is. Are you saying that this is significant because iTunes cannot be modified under normal circumstances, but ~/Library/iTunes is? Could one not set up LD_PRELOAD on login to accomplish something similar?
    If you gave a fuck about security and developed iTunes, what would be your approach to solving this?

    1. Sandbox? XPC? Different process space for the plugins?
      What do visualizer plugins require? Data. Can be transmitted over to other process.
      Hey, they already do it in Safari, Preview and so on.
      Nothing new, other than lazyness.

  3. so if an actor can get someone to install a plugin in an application, the integrity of the application can be compromised? NO WONDER EVERYTHING IS SO FUCKED UP EVERYWHERE.

  4. Every time I sent the emails directly to Apple’s sec team, there’s always no response.

    Later I just sent them all directly to tcook@apple.com, got their reply every single time. :P

    (Still, they gave me those “We are looking into it”, “There is not security issues as we can see” kind of BS.)

    I wonder how they got their jobs. They think like typical developers, not hackers. No wonder they suck when it comes to security.

    1. They have good people in the security teams. I think it’s more a management issue than purely technical and/or talent.
      When a big worm hits them as it happened to MS they will change :-)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>