
AppleDoesntGiveAFuckAboutSecurity iTunes Evil Plugin Proof of Concept - mafuyu
http://reverse.put.as/2014/02/15/appledoesntgiveafuckaboutsecurity-itunes-evil-plugin-proof-of-concept/
======
pudquick
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.

~~~
lstamour
Changing ownership and permissions on the plugin folder won't help if an end
user wants the plugin. Suddenly all iTunes plugins can't be trusted, and
shouldn't have been installed in the past.

In fact, I now wonder how far that extends -- if I've plugins for Xcode
installed, should I worry about my developer account session in Preferences
which auto-downloads and can create signing keys for apps? It's a thought...

~~~
pudquick
In my situation, I've never used an iTunes plugin and see no need to
personally. So the solution helps me, but you're right that it's a stopgap
measure that's not universally applicable.

------
michaelhoffman
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
So.. If a user runs arbitrary HTML or JS in their browser, they are owned?

~~~
pfraze
The browser is unique for using the JS virtual machine to sandbox its executed
code. It's very different from running a downloaded executable.

~~~
rdtsc
The browser is not unique. There are other virtual machines out there. There
are slew of IPC mechanisms. OS facilities. Containers, virtualization, chroot
environments. Maybe they are not practical for this particular problem but
somehow saying browser is magic because it is using a scripting a language VM
isn't true in general.

Thinking about, heck, a browser can even execute downloadable executable as
well -- that is the PNaCl framework.

~~~
derefr
I think what the parent meant, was that the browser is unique in actually
having an attack surface (the JS VM sandbox) that has been hardened by
millions of people hitting it with arbitrary foreign code all day. Just
because something else on your system happens to be a virtual machine, does
not mean its security has been ascertained to nearly this extent.

I wouldn't expect, say, VMWare, or the OpenType rendering engine, to hold up
if millions of people were throwing arbitrary foreign code at them each day.
But people don't--the code these VMs see is mostly trusted code they either
created themselves, or got from a reputable source, and it's heavily the same
1000-2000 blobs.

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

~~~
Sanddancer
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.

~~~
nknighthb
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
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
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.

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

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

------
anextio
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!

------
sillysaurus2
_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.

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

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

------
iancarroll
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?

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

