7 ms·

AppleDoesntGiveAFuckAboutSecurity iTunes Evil Plugin Proof of Concept

85 points by mafuyu 13y ago

kalleboo 13y ago
Sounds more like AppleDoesntGiveAFuckAboutiTunesPlugins. I think from their POV, as long as apps installed through the Mac App Store are safe (through the sandbox), what code you install (such as full-priviledge unsigned code and iTunes plugins) is up to you. > The plugin folder is writable by current logged in user so a trojan dropper can easily load a malicious plugin A trojan could also replace the iTunes dock icon with a fake iTunes that does the same thing. Once you're running unsigned code on the machine, all bets are off.
- deleted 13y ago
  [deleted]
- Sanddancer 13y ago
  The problem here is that it's "just" a plugin. Think of the problem like malicious sites that target windows stating that you need to download a codec to view certain media. The casual user will not receive any sort of warning when they download it, and when itunes opens, they have the keys to the castle. Also, given that a lot of users use the same password for everything, getting the itunes user password means you have a good chance at snagging root at the same time.
  - kalleboo 13y ago
    I forgot about Windows, and cannot speak to it. On the Mac, iTunes plugins are generic ".bundle" files that don't open iTunes when double-clicked, and need to be manually installed via drag-and-drop into the appropriate folder. These .bundle files DO seem to circumvent the untrusted code warning dialog though, which I'd say is an actual vulnerability here.
  - nknighthb 13y ago
    Download what, exactly? Downloading the zip file linked to by the OP gives me a folder full of source code, not an "iTunes plugin". Even if it did give me a built plugin, I wouldn't have a clue what to do with it absent further instructions. This is a very poor demonstration of whatever they're trying to prove. The README says "Copy to ~/Library/iTunes/iTunes Plug-ins to install." So, they're expecting the "casual user" to copy a file to a hidden directory? Good luck with that. I did a quick search for iTunes plugins. They all seem to come in some sort of executable installer, thus being subject to the ordinary warnings. The OP even suggests as much, with "a trojan dropper can easily load a malicious plugin". How does that "trojan dropper" get on the system? This isn't a security hole, it's a wannabe scriptkiddy who wants to make noise.
    - Sanddancer 13y ago
      It's a proof of concept showing a flaw in a core, non-sandboxed application. Someone with better social engineering and/or or someone interested in targeting specific people could turn this into something rather nasty
      - nknighthb 13y ago
        No, it's demonstrating (poorly) the ordinary functionality of application plugins. The most iTunes could possibly do is display a warning dialog on unsigned plugins. Not a bad idea, perhaps, but its absence is hardly a flaw. You're already postulating sufficient social engineering that I can't believe the warning would stop anyone.
    - lstamour 13y ago
      So you're saying that a malicious iTunes visualizer plugin won't get installed and get past antivirus? Or maybe that your visualizer/screensaver plugins should have access to your credit cards? Worries the crap out of me, personally. :)
      - nknighthb 13y ago
        I'm saying once you download and run arbitrary native code, all bets are off. Hell, I just kind of assume any such code has full root access no matter what user it's started as, given the commonality of privilege escalation vulnerabilities.
sillysaurus2 13y ago
The plugin folder is writable by current logged in user so a trojan dropper can easily load a malicious plugin. Maybe I'm missing something, but if you allow for the fact that a virus is already on your system, then you've already lost. It'd be one thing if iTunes was allowing the equivalent of root escalation, but it doesn't sound like it's even doing that.
michaelhoffman 13y ago
This sounds like a "Other side of this airtight hatchway" security non-flaw. If you can convince a user to run arbitrary code, then it doesn't matter whether it's an iTunes plugin or something else. You're owned either way.
- judk 13y ago
  So.. If a user runs arbitrary HTML or JS in their browser, they are owned?
  - mitchty 13y ago
    Bit different than something that inherently has full access to the parent processes memory space like an iTunes plugin no?
    - rdtsc 13y ago
      At the technical level that is the mechanism that makes it possible. That does little to advance the point though. It is like saying "well exploits happened because in C you can write over the array boundary". Yes that is how some of them happen. But explaining the mechanism doesn't justify or solve the problem and it takes too low of a view. I guess one can ask whether : 1) Should plugins be allowed? 2) Should plugins run in the same memory space as parent process? There are other ways. Like how come a Google Chrome tab doesn't usually succeed in corrupting or blocking another chrome tab? hmm interesting. Maybe, setup a socketpair or sharedmemory or a message and mailbox system. 3) Should signing, verifying and vetting of these plugins be done differently?
      - teacup50 13y ago
        1) Yes, 2) Yes, 3) No. This is what makes a desktop computer useful. If you don't trust code, don't run untrusted code. I also recommend not aiming loaded weapons at your own foot.
        13y ago
valisystem 13y ago
It seems that the only real issue is that it circumvents keychain, that would normally prompt before giving any protected value to unknown code (not signed or already prompted). So a plugin can access to protected data that iTune can fetch from keychain silently. I don't know if there is other ways to achieve that with local attacks, but it looks like a middle of the road issue. Quite serious, but also requires the target system to be already compromised.
mwfunk 13y ago
Am I missing something here? It sounds like all he's complaining about is that iTunes plugins don't execute in a separate address space from iTunes itself, which is hardly unusual for most applications that have a plugin architecture. Maybe I am missing something. The amount of hand wringing and hyperbole implies a much worse issue but I don't see what it is.
stcredzero 13y ago
From what I've seen, Apple is like any other company. A part of the company understands security. Another part thinks it understands security but only pays lip service to it and in reality doesn't understand security and considers it a pain.
rcarmo 13y ago
Weird. At least on Mail.app and Mavericks, plugins need to be properly code signed, etc. (I had to do that for https://github.com/rcarmo/HJKLPlugin https://github.com/rcarmo/HJKLPlugin to work in Mavericks)
- micro-ram 13y ago
  Yes, OP mentioned that it was fixed in Mavericks. Since Mavericks is free, I don't really see the problem. If you are running a < 2007 Mac you really don't care about security anyway.
pudquick 13y ago
People unfamiliar with the Apple ecosystem of products might not realize what a problem this is. It's not an attack in its own right, but a powerful step in a non-elevated attack against Apple products. If someone were to end up running malicious code (say, due to a recent Flash Player zero day code execution exploit ...), without the need for administrative rights, they could install this plugin into the iTunes environment for that same user. Why is this a problem? This plugin successfully MITM attacks an iTunes purchase and extracts your Apple ID and plaintext password. Network proxying at the machine level to attack SSL traffic would normally require admin rights. Now that the attacker has the Apple ID, they can: - Send a remote lock or wipe command to the user's Apple devices that are using Find My Mac/iPhone. - Log in to Messages and receive copies of everything sent to them / they say to everyone. (They will get email notification of a new device, mind you) - Potentially find out their home address, phone number, and real name information from the Apple service portal if they've ever taken in a device to be worked on (turning it into an identity theft attack of sorts) Etc. Just an FYI if you're not familiar with what an Apple ID does for the average Apple user. Mind you, without admin rights, fake alert software could also be installed on the Mac, prompting a user for credentials of some sort with a dialog specially crafted to imitate the real thing. The difference here, however, is that it is all legit dialogs. There are no crazy unknown processes listed on the machine that a more paranoid person might notice (once the iTunes plugin is dropped). The iTunes process itself has been made malicious. I, for one, will be changing ownership and permissions on the plugin folder on my machines to make it non-writeable without elevation.
- nknighthb 13y ago
  There are three Macs, five iPhones, and five iPads in active use in my family. Additional Macs, iOS, and iPod devices sit idle or have been given away. I am intimately familiar with the ecosystem. Anyone able to use this detail in an actual "attack" assuredly has many other avenues to carry out such an attack, and will continue to have such avenues unless and until Windows and Mac OS are at least as locked down as iOS.
  - pudquick 13y ago
    ... Nothing about this article or my comment said anything about security in iOS. I have no idea what your statement is about.
rahulcap 13y ago
This article should be renamed, "How I hacked iTunes to steal your credit card information (probably)", to get more votes on Hacker News.
iancarroll 13y ago
Why are you all justifying quite the security flaw? If Adobe Flash can be exploited if you click a button, should it not been patched?
anextio 13y ago
As others have said, if you've already convinced the user to run untrusted unsandboxed code then it doesn't matter whether it installs an iTunes plugin to do its dirty business. I have an even easier to implement attack - a menu bar-less app that shows an iTunes password window after using system APIs to bring iTunes to the front. Make up some excuse in the text for why it needs your password. You don't even have to mess around with breakpoints, most users will probably type their password - and you don't even have to wait until they buy something from iTunes!
_fG_ 13y ago
I am quite amazed how a few people are defending a broken model and arguing about "arbitrary code". Every single piece of code you download is arbitrary. Hell, even the operating system is. You have no idea of what really runs in your computer, you trust there is nothing malicious hidden in most apps. Trust, nothing more than that. So it's very easy to own all your Macs and steal financial information without a single suspicious prompt for higher privileges. If you think it's ok to have iTunes binary not writable by a normal user but then fully controlling it from a plugin then what can I say? I hope your data is not valuable ;-)
- kalleboo 13y ago
  > Every single piece of code you download is arbitrary. Apple's solution to this is the Mac App Store. If you can get an app into the Mac app store, and then break out of the Sandbox to install this iTunes plugin. THEN you have a post. iOS has been refreshingly malware-free using this model (even though there have been holes there as well obviously), and it's clear why they're bringing it to the Mac. > If you think it's ok to have iTunes binary not writable by a normal user but then fully controlling it from a plugin then what can I say? I agree that not having an unsigned code warning in iTunes for new plugins is a major oversight, and a break in the Apple Model. But with that in place, saying "but plugins can do anything in iTunes" is like saying "but a *.com-filtered Chrome extension can intercept all my passwords!". And guess what? Google are also limiting all the plugin extensions to their Web store...
  - _fG_ 13y ago
    Yeah, just look at what CoinThief does to Chrome ;-)

85 points by mafuyu 13y ago

Sounds more like AppleDoesntGiveAFuckAboutiTunesPlugins. I think from their POV, as long as apps installed through the Mac App Store are safe (through the sandbox), what code you install (such as full-priviledge unsigned code and iTunes plugins) is up to you. > The plugin folder is writable by current logged in user so a trojan dropper can easily load a malicious plugin A trojan could also replace the iTunes dock icon with a fake iTunes that does the same thing. Once you're running unsigned code on the machine, all bets are off.

deleted 13y ago
[deleted]
Sanddancer 13y ago
The problem here is that it's "just" a plugin. Think of the problem like malicious sites that target windows stating that you need to download a codec to view certain media. The casual user will not receive any sort of warning when they download it, and when itunes opens, they have the keys to the castle. Also, given that a lot of users use the same password for everything, getting the itunes user password means you have a good chance at snagging root at the same time.
- kalleboo 13y ago
  I forgot about Windows, and cannot speak to it. On the Mac, iTunes plugins are generic ".bundle" files that don't open iTunes when double-clicked, and need to be manually installed via drag-and-drop into the appropriate folder. These .bundle files DO seem to circumvent the untrusted code warning dialog though, which I'd say is an actual vulnerability here.
- nknighthb 13y ago
  Download what, exactly? Downloading the zip file linked to by the OP gives me a folder full of source code, not an "iTunes plugin". Even if it did give me a built plugin, I wouldn't have a clue what to do with it absent further instructions. This is a very poor demonstration of whatever they're trying to prove. The README says "Copy to ~/Library/iTunes/iTunes Plug-ins to install." So, they're expecting the "casual user" to copy a file to a hidden directory? Good luck with that. I did a quick search for iTunes plugins. They all seem to come in some sort of executable installer, thus being subject to the ordinary warnings. The OP even suggests as much, with "a trojan dropper can easily load a malicious plugin". How does that "trojan dropper" get on the system? This isn't a security hole, it's a wannabe scriptkiddy who wants to make noise.
  - Sanddancer 13y ago
    It's a proof of concept showing a flaw in a core, non-sandboxed application. Someone with better social engineering and/or or someone interested in targeting specific people could turn this into something rather nasty
    - nknighthb 13y ago
      No, it's demonstrating (poorly) the ordinary functionality of application plugins. The most iTunes could possibly do is display a warning dialog on unsigned plugins. Not a bad idea, perhaps, but its absence is hardly a flaw. You're already postulating sufficient social engineering that I can't believe the warning would stop anyone.
  - lstamour 13y ago
    So you're saying that a malicious iTunes visualizer plugin won't get installed and get past antivirus? Or maybe that your visualizer/screensaver plugins should have access to your credit cards? Worries the crap out of me, personally. :)
    - nknighthb 13y ago
      I'm saying once you download and run arbitrary native code, all bets are off. Hell, I just kind of assume any such code has full root access no matter what user it's started as, given the commonality of privilege escalation vulnerabilities.

sillysaurus2 13y ago

The plugin folder is writable by current logged in user so a trojan dropper can easily load a malicious plugin. Maybe I'm missing something, but if you allow for the fact that a virus is already on your system, then you've already lost. It'd be one thing if iTunes was allowing the equivalent of root escalation, but it doesn't sound like it's even doing that.

michaelhoffman 13y ago

This sounds like a "Other side of this airtight hatchway" security non-flaw. If you can convince a user to run arbitrary code, then it doesn't matter whether it's an iTunes plugin or something else. You're owned either way.

judk 13y ago
So.. If a user runs arbitrary HTML or JS in their browser, they are owned?
- mitchty 13y ago
  Bit different than something that inherently has full access to the parent processes memory space like an iTunes plugin no?
  - rdtsc 13y ago
    At the technical level that is the mechanism that makes it possible. That does little to advance the point though. It is like saying "well exploits happened because in C you can write over the array boundary". Yes that is how some of them happen. But explaining the mechanism doesn't justify or solve the problem and it takes too low of a view. I guess one can ask whether : 1) Should plugins be allowed? 2) Should plugins run in the same memory space as parent process? There are other ways. Like how come a Google Chrome tab doesn't usually succeed in corrupting or blocking another chrome tab? hmm interesting. Maybe, setup a socketpair or sharedmemory or a message and mailbox system. 3) Should signing, verifying and vetting of these plugins be done differently?
    - teacup50 13y ago
      1) Yes, 2) Yes, 3) No. This is what makes a desktop computer useful. If you don't trust code, don't run untrusted code. I also recommend not aiming loaded weapons at your own foot.
      - 13y ago

valisystem 13y ago

It seems that the only real issue is that it circumvents keychain, that would normally prompt before giving any protected value to unknown code (not signed or already prompted). So a plugin can access to protected data that iTune can fetch from keychain silently. I don't know if there is other ways to achieve that with local attacks, but it looks like a middle of the road issue. Quite serious, but also requires the target system to be already compromised.

mwfunk 13y ago

Am I missing something here? It sounds like all he's complaining about is that iTunes plugins don't execute in a separate address space from iTunes itself, which is hardly unusual for most applications that have a plugin architecture. Maybe I am missing something. The amount of hand wringing and hyperbole implies a much worse issue but I don't see what it is.

stcredzero 13y ago

From what I've seen, Apple is like any other company. A part of the company understands security. Another part thinks it understands security but only pays lip service to it and in reality doesn't understand security and considers it a pain.

rcarmo 13y ago

Weird. At least on Mail.app and Mavericks, plugins need to be properly code signed, etc. (I had to do that for https://github.com/rcarmo/HJKLPlugin https://github.com/rcarmo/HJKLPlugin to work in Mavericks)

micro-ram 13y ago
Yes, OP mentioned that it was fixed in Mavericks. Since Mavericks is free, I don't really see the problem. If you are running a < 2007 Mac you really don't care about security anyway.

pudquick 13y ago

People unfamiliar with the Apple ecosystem of products might not realize what a problem this is. It's not an attack in its own right, but a powerful step in a non-elevated attack against Apple products. If someone were to end up running malicious code (say, due to a recent Flash Player zero day code execution exploit ...), without the need for administrative rights, they could install this plugin into the iTunes environment for that same user. Why is this a problem? This plugin successfully MITM attacks an iTunes purchase and extracts your Apple ID and plaintext password. Network proxying at the machine level to attack SSL traffic would normally require admin rights. Now that the attacker has the Apple ID, they can: - Send a remote lock or wipe command to the user's Apple devices that are using Find My Mac/iPhone. - Log in to Messages and receive copies of everything sent to them / they say to everyone. (They will get email notification of a new device, mind you) - Potentially find out their home address, phone number, and real name information from the Apple service portal if they've ever taken in a device to be worked on (turning it into an identity theft attack of sorts) Etc. Just an FYI if you're not familiar with what an Apple ID does for the average Apple user. Mind you, without admin rights, fake alert software could also be installed on the Mac, prompting a user for credentials of some sort with a dialog specially crafted to imitate the real thing. The difference here, however, is that it is all legit dialogs. There are no crazy unknown processes listed on the machine that a more paranoid person might notice (once the iTunes plugin is dropped). The iTunes process itself has been made malicious. I, for one, will be changing ownership and permissions on the plugin folder on my machines to make it non-writeable without elevation.

nknighthb 13y ago
There are three Macs, five iPhones, and five iPads in active use in my family. Additional Macs, iOS, and iPod devices sit idle or have been given away. I am intimately familiar with the ecosystem. Anyone able to use this detail in an actual "attack" assuredly has many other avenues to carry out such an attack, and will continue to have such avenues unless and until Windows and Mac OS are at least as locked down as iOS.
- pudquick 13y ago
  ... Nothing about this article or my comment said anything about security in iOS. I have no idea what your statement is about.

rahulcap 13y ago

This article should be renamed, "How I hacked iTunes to steal your credit card information (probably)", to get more votes on Hacker News.

iancarroll 13y ago

Why are you all justifying quite the security flaw? If Adobe Flash can be exploited if you click a button, should it not been patched?

anextio 13y ago

As others have said, if you've already convinced the user to run untrusted unsandboxed code then it doesn't matter whether it installs an iTunes plugin to do its dirty business. I have an even easier to implement attack - a menu bar-less app that shows an iTunes password window after using system APIs to bring iTunes to the front. Make up some excuse in the text for why it needs your password. You don't even have to mess around with breakpoints, most users will probably type their password - and you don't even have to wait until they buy something from iTunes!

_fG_ 13y ago

I am quite amazed how a few people are defending a broken model and arguing about "arbitrary code". Every single piece of code you download is arbitrary. Hell, even the operating system is. You have no idea of what really runs in your computer, you trust there is nothing malicious hidden in most apps. Trust, nothing more than that. So it's very easy to own all your Macs and steal financial information without a single suspicious prompt for higher privileges. If you think it's ok to have iTunes binary not writable by a normal user but then fully controlling it from a plugin then what can I say? I hope your data is not valuable ;-)

kalleboo 13y ago
> Every single piece of code you download is arbitrary. Apple's solution to this is the Mac App Store. If you can get an app into the Mac app store, and then break out of the Sandbox to install this iTunes plugin. THEN you have a post. iOS has been refreshingly malware-free using this model (even though there have been holes there as well obviously), and it's clear why they're bringing it to the Mac. > If you think it's ok to have iTunes binary not writable by a normal user but then fully controlling it from a plugin then what can I say? I agree that not having an unsigned code warning in iTunes for new plugins is a major oversight, and a break in the Apple Model. But with that in place, saying "but plugins can do anything in iTunes" is like saying "but a *.com-filtered Chrome extension can intercept all my passwords!". And guess what? Google are also limiting all the plugin extensions to their Web store...
- _fG_ 13y ago
  Yeah, just look at what CoinThief does to Chrome ;-)