2015-01-03

#malware for #iOS #2014

news.cyb/sec/malware for iOS:
1.3: summary:
. some might say Wirelurker is no big deal
since it requires the mac user to install
an untrusted enterprise app:
moral of the story, reap what you sew;
don't trust any apps
unless you can trust its source;
right?
. but did you know that one mistake
could rewrite your other iOS apps?
in the name of user friendliness,
iOS security could be better,
and zdziarski.com has some suggestions .

11.14: web:
threatpost.com:
The enterprise app program
allows iOS application developers
to distribute signed iOS apps
without first uploading to the Apple App Store
where Apple can inspect it for malware .

marcoramilli.blogspot.com:
WireLurker targets OSX and iOS devices;
It is only the second known malware family
that attacks iOS devices through a
connection with an OS X computer .
It is the first malware to automate
generation of malicious iOS applications,
through binary file replacement;
It is the first known malware that can
infect installed iOS applications
similar to a traditional virus;
It is the first in-the-wild malware
to install third-party applications
on non-jailbroken iOS devices
through enterprise provisioning .

zdziarski.com`What can Apple do?
Apps that aren't signed by Apple
(enterprise provisioned apps)
need to jump out with a warning:
"this app is not inspected by Apple!"
Access Controls for Pair Records:
. malware on a mac OS X desktop
can abuse the pairing records
to install malware on an iOS device.
. see the iOS Backdoors paper:
any application on a user's desktop
can access the pairing record
and have completely trusted privileges
with any paired iOS devices .
. Apple should manage access to
"Trusted Pairing Relationships" with devices
the same way it manages access permissions
for contacts and geolocation.
An app should have to ask for permission
to access this privileged data.
This would allow only user-ok'd apps
to use the iOS device.
code-signing not pinned:
Apple currently has no mechanism to
pin a bundle id (e.g. com.facebook.*)
to a specific developer certificate .
This means that anyone can delete
the signature from an app,
modify the app’s binary, then re-sign it
with their own certificate;
so, one bad app can infect other apps .
In addition to pinned code-signing,
Apple could pin network access:
so that specific websites could be used
only by apps with similar bundle identifiers.
For example, mylibrary.facebook.com
would be allowed network access only to
apps identified as com.facebook.myapp
and thus developed by facebook.com .

No comments: