Let me start this with some sort of disclaimer. I do not support/condone stealing credit card information, logins, and other personal information. Disclosing security issues is always a double edge sword and a tricky problem with some politics in the mix. This problem was reported almost 3 months ago to Apple. It’s still not fixed after, at least, two iTunes releases. I perfectly understand the business side of fixing bugs and how business most of the times must come first (I have experience in critical environments where these type of problems can cost a lot of money and bad publicity).
But it also seems that governments and so on are exploiting security issues to do all kind of stuff on citizens. This is another interesting case (Google translate it). 3 months is more than enough to take a damn decision on this issue. If not, I maybe did a mistake. Live & learn 
So let’s start it…
The following problem seems like a pretty “lame” security issue with iTunes. I came across with it when one reader posted a comment about creating an iTunes plugin to have the same m3u removal functionality I did in my loader (original post here). My idea was to patch iTunes memory on the fly and remove the new m3u thing. To my surprise, this is a pretty easy thing to do with a plugin! Plugins are loaded into iTunes memory space (they are bundles/libraries) and can have total control over its memory. How? By using mach_task_self to acquire a port right (we don’t need any special/elevated permissions since the plugin shares the same permissions of iTunes) and then use mach_vm_write to patch whatever we want.
So how can we use this for devilish things? Well, we can capture those iTunes logins and credit card information. One alternative is to patch and redirect the code that asks for this information, another one is to make the plugin a small debugger, installing a breakpoint into the interesting place and retrieving the information. Or we could maybe steal information from iTunes backups and upload it somewhere?
It’s not the easiest attack vector but it’s a damn easy one. If we have governments sponsoring backdoors installation then any vector is a good vector.
I did not created the PoC for stealing the iTunes account information. I found where to intercept that information and stopped there. Not interested in creating such thing. I will release the code for the m3u removal plugin (maybe tomorrow). Just need to clean some things – last time I used it was 3 months ago.
And that’s it! A simple security issue by design. Now go patch it Apple, close the damn holes
Have fun,
fG!
Update:
Here’s the code. Check VisualPluginHandler in iTunesPlugIn.cpp, which handles the events (iTunes will be patched when plugin is loaded, unpatched if configuration is called, and patched again if show visualizer is called). The juice of the patching is located at hack.cpp. The mach-o headers information is grabbed from memory because of ASLR in Lion. Final step is to find the cstrings location and patch it.
I haven’t tested this with 64bits iTunes. Based on sample code provided by Apple’s Technical Note 2016. Some unnecessary code is still present and plugin could be improved by adding a configuration panel to enable/disable it. Maybe one of these days
Disable_m3u_v0.1.zip
SHA256(Disable_m3u_v0.1.zip)= 7583d483ecba7dff93b958245e6801000251938a4f87e2dc71c58a4d9a7ee739
