Isolated: iOS Apps in the Sandbox
Apple’s method of isolation provides a
measure of security: iOS only identifies the ‘root’ and ‘mobile’ user levels.
Apps in a sandbox run on the ‘mobile’ level with limited rights: they may
neither access other apps, nor change the kernel or start privileged processes
that can’t be ended by iOS at any point to clear out memory. Because iOS
developers use the programming language Objective C, apps are susceptible to buffer
overflows and similar problems. Apple uses the NX (No Execute) memory
protection technology built into its ARM processors, which makes such attacks
difficult. In the case of a successful attack, the attacker would be able to
take over an application. He would then obtain access to all the interfaces of
the app, potentially including its network connections, access to the phone’s
address book and calendar, device number (IMEI), telephone number, photos,
videos, music and browser history. Even the device’s microphone and camera
could secretly be tapped. The user needs to consent when an application wants
to send messages or make calls. Only the email client cannot be accessed by
apps directly. Apple has not provided any information about the extent to which
apps and permissions are locked down.
The App Store is essentially a
firewall for the iOS. However, jailbreaking creates breaches in the firewall.
Circumventing the iPhone’s usage restrictions effectively cancels Apple’s
ability to secure your apps’ certifications using the sandbox principle. As a
result, apps can be installed from non-secure sources such as the app store
Cydia as well as unsafe ones that promise free pirated apps. iOS becomes
entirely at the mercy of viruses because any app could be altered to hide
malware within it, and this would give it unhindered access to the entire
system. Sometimes, a jailbreak can be even more dangerous: the iPhone worm iKee
attacks devices whose SSH control panel passwords have not been changed from
the default. It then spreads through Wi-Fi connections.
Open
App Stores: Cydia (L) is an
alternative App Store for jailbroken iPhones, but the apps on offer here are
not tested. Malware can easily spread via illegal shops like Hackulous (R).
This is impossible on Android. You can
carry out a jailbreak or ‘root’ the system, but it is not as risky as with iOS
because even a rooted device asks for certificates. The practice of process
isolation remains in effect – at least partly. This is because at the time of
rooting, the so-called Superuser shell, which warns the system against critical
actions like user account control requests, is in the system directory.
Malware therefore has to make its way
into sensitive system areas and ask prior permission of the user. Digital
certificates under Android are more susceptible, though. They don’t control the
sources of the apps because the system is designed to allow easy access to apps
from different sources. The certificates therefore only prevent hackers from
infecting known applications and spreading them under the same names. This
verifies that an app is clean, but is in practice a poor protection method
because every Android developer who does not operate in the official market can
issue certificates at his own discretion. You can therefore often find malware
on the Internet which resembles the original applications.
Important: Check App Authorisations
Android’s rights management system
offers a better protection option: Developers must enter the desired
authorizations in the file ‘AndroidManifest.xml’. The system invokes this file
before the installation and requests you to confirm the authorizations. Risky
features such as unhindered access to the SMS application can also be included
in this. However, you must not simply accept all security permission prompts
without checking them – almost all viruses are disguised as common, ordinary
apps. As far as safety is concerned, Android’s openness is its biggest
drawback. What is also annoying is that the authorization system doesn’t allow
fine-grained control. It is always all or nothing for the user. Google chose
this approach in order to make applications easier to develop and distribute.
Once an app is introduced in the
system, even Android viruses general have only limited rights. Each application
runs with a separate user identification in an isolated environment, the Dalvik
Virtual Machine. Therefore, even malicious applications can neither access the
Linux kernel nor the other apps. Thanks to this segregation, a normal Trojan
actually has no chance to read the data of a banking app, for example. However,
Android apps can find out which other apps are installed on the system and also
when these apps processes start. A smart virus could thus wait for a known
banking app to start and then set up a manipulated page using the login screen
of the bank. In this way, it can phish for your user data. This risk it not
posed in iOS – here, on app cannot see what another is doing. Such attacks are
only theoretical, but the threat is poised to become real soon enough.
In order to remove Android malware you
only need to uninstall it (or its host program). Unlike PC viruses, these
generally cannot spread by themselves – the isolation method takes care of that.
It is up to Google to delete apps installed through the Android Marketplace via
its own remote access capabilities. An example of a more dangerous type of
malware is the Trojan DroidDream, which was detected Android market. It
simultaneously uses two root exploits to gain administrator rights. As a
result, the malicious apps did not require any regular authorizations. After
the installation, DroidDream had a free hand; it could even install other
malicious code without any problem. After that, it contacted a C&C server
and sent it the phone’s IMEI number. Google has closed both security loopholes
with Android 2.3, but the previous versions are unchanged and not protected.
Security suites for mobile phones
If the kernel has been compromised
prior to the installation of the security tool, it won’t be able to fix the
problem. Such tools run only with restricted rights in separate service
environments, so they won’t be aware of older exploits. Security suites can
however interface with the installation of new viruses. They depend mainly on
signature detection, as in case of PCs. They examine all code for known signs
of malware. Proactive methods are difficult to implement under Android because
the line between a just very curious and a distinctly malicious app is cannot
always be identified clearly. A few manufacturers like F-Secure and Symantec
still try to provide preventive protection. ‘We have automatic checking for all
the free apps in the Android market for malicious software’, says Stefan
Wesche, security expert with Symantec. Many security programs also offer
functions beyond virus scanning. If you would like to be able to protect your
data in the event that you lose you smartphone, you can use these security
suites to locate the device through GPS, and make it lock itself, ring an
alarm, or wipe itself out. There is no traditional malware scanner for iOS,
because the system is considered to be secure as long as Apple thoroughly tests
the programs that are in the App Store. Nevertheless, you can still find special
browsers, such as Smart Surfing from Trend Micro, which is supposed to provide
better protection against phishing websites by blocking known malicious pages.
Even if you have Android, you do not need to worry as long as you check the
authorizations of the apps before installation. However, if Google continues to
allow malware in the Android market, then a major threat could soon be in the
wild.
