Transcript Security in Mobile Operating System

Mobile Security
NSF Workshop on Mobile Security
June 27, 2014
1
Pillars of Mobile Operating System (OS) Security
• Traditional Access Control
– Seek to protect devices using techniques such as passwords and idletime screen locking.
• Encryption
– conceal data on the device to address device loss or theft.
• Application Provenance
– Stamp each application with identity of its author and made it tamper
resistant (e.g., digital signature). A consumer/user can decide to use or
not to use the application based on the identity of the author.
• Application Security
– limits applications ability to access sensitive data or systems on a
device.
– Permissions-based access control: grants set of permissions to each
application
2
Traditional Access Control
Apple iOS
• iOS provides traditional access control security options which include
password configuration options such as strength of passcode, maximum
number of failed login attempts, password expiration, and password
update frequency.
Android
• Android provides password configuration options, which are similar
with iOS.
3
Effectiveness of Traditional Access Control
Apple’s iOS
• The access control feature of the iOS provides a reasonable level of
security for the devices data in the event of loss or theft.
• The iOS is comparable to traditional windows-based desktops in this
scenario.
Android
• The password policy system is sufficient to protect devices against
novice attacks.
4
Encryption
Apple iOS
• The iOS uses a hardware accelerated AES-256 encryption to encrypt all
data stored in the flash memory of the device.
• The iOS protects specific additional data items, such as email using an
additional layer of encryption.
• Within 10 seconds of the device locking, the decryption keys for files in
device are discarded.
Android
• Earlier versions of android contain no encryption capability. A simple
jailbreak of an android phone, or theft of device’s SD card can lead to
significant loss of data.
• Android 3.0+ provides full file system encryption using device
password to protect the encryption key.
5
Application Provenance
Apple iOS
• Developers register with Apple company and pay annual license fees before
releasing applications (apps) to users of iPhone, iPod, or iPad.
• Developers are required to “digitally sign” each app with an apple-issued
digital certificate before its release. This signing process prevents tampering
of published apps and ties developers’ identity with assurance of their apps.
• If an app is found malicious, the app is removed from the app store, but no
automated mechanism has been implemented to remove the app from devices.
Android
•
•
•
•
Android OS only installs and runs apps that have been properly signed with a
digital certificate.
Developers do not need not apply a digital certificate from Google and they can
use self-generated certificates.
Malware can be distributed by authors using anonymous digital certificate, and
Google has no way to track back to the author.
However, Google requires a $25 fee paid by credit card in order to put an app
on Android market, which allows Google to associate the payee with the digital
certificate, reducing changes of distribution of malicious apps. It assumes that
they use their own credit card.
6
Effectiveness Application Provenance
Apple iOS
• Apple’s approach is effective as
– The developer must register and pay to obtain a signing certificate
from apple, which makes it easy to trace and identify if any malicious
activities are performed.
– Every application is tested before submission to the app store.
– Apple’s code signing model prevents tampering with published apps.
Android
• Since no single authority evaluates or verifies all Android apps,
attackers are more likely to release attacks without worrying of being
caught.
7
Application (App) Security
Apple iOS
• iOS operating system isolates each app from other apps on the system.
• The apps are not allowed to modify or view each other’s data, or even
know existence of other apps. They cannot access the OS kernel, nor
install privileged driver’s or obtain root level administrator access to
the device.
• The apps are also isolated from the phone’s SMS, emails and email
attachments.
Android
• Like iOS, Android employs a strong isolation system. It not only
isolates apps from each other but also prevents apps from accessing or
modifying the OS kernel, ensuring the app doesn’t get admin control
over a device.
8
Effectiveness of Application (App) Security
Apple iOS
• The iOS denies access under all circumstances to many of the device’s
sensitive subsystems.
• This increases the security of iOS based devices since it relieves the
user from security decision-making process.
• But it potentially limits the utility of certain classes of iOS apps.
Android
• The Android permission system relies on the user to make all policy
decisions and decide whether an apps requested combination of
permission is safe or not.
9
Examples of Isolation in Bring Your Own
Devices (BYOD)
Blackberry Balance
• Allows organizations to create isolation between personal and work
environments on a device.
• Keeps personal applications, files and network separate from the work
environment.
• When Balance is enabled, workspace is automatically encrypted,
leaving personal environment unencrypted.
Windows Phone 8 - Unified Extensible Firmware
Interface
• It is used for secure boot so that devices do not load rooted or
unauthorized system images.
• The data between apps are shared in the cloud and not on the device.
10
Security Strength
11
Android Architecture
Application
provenance
App security
Permissionbased access
control
Inter-process
communication
Process Isolation
Android Security Design
Security goals
• Protect user data
• Protect system resources (hardware, software)
Foundations of Android Security
1. Process and application Isolation by Linux Kernel
2. System-built and user-defined permissions
3. Secure inter-process communication
4. Application provenance
1. Process Security from Linux Kernel
• Each component assumes that the components below
are properly secured.
• Linux kernel is responsible sandboxing application
– Mutually distrusting principals
– Default access to only its own data
• Process isolation
– All code above the Linux Kernel is restricted by the
Application Sandbox
– Each application is sandboxed to run on its own
process
• All libraries and applications run within their own
sandboxes.
Android process isolation
• The process isolation prevents process A from
accessing process B’s CPU, memory resources, and
devices such as telephony, GPS, and bluetooth.
• The apps can only talk to other apps through
Intents (message) , Inter-process Communication, or
ContentProviders (data storage).
• To escape the sandbox, permissions are needed.
2. Android Application Security
(Application framework)
• Almost all Android applications are written in the Java and run
in the Dalvik virtual machine.
.java -> .class -> .jar -> .dex
Android application deployed in a single .apk file.
• Permissions are the core concepts in the Android security to
control the access from one application component to
another.
• The AndroidManifest.xml file is the configuration file of
Android application.
– It instructs system what to do with activities, services,
broadcast receivers, and content providers in an
application.
– It declares permissions.
– Without user’s consent, an application will not be
installed.
AndroidManifest.xml
• Each application can declare the required permissions
• If a public component doesn’t explicitly declare any access permission,
Android permits any application to access it.
<?xml version="1.0" encoding="utf-8"?>
<manifest . . . >
<application . . . >
<activity android:name="com.example.project.myActivity"
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
...
</activity>
<activity> ….. </activity>
<uses-permission android:name="android.permission.SEND_SMS" />
<uses-permission android:name="android.permission.INTERNET" /> . . .
</application>
</manifest>
3. Security for Inter-Process Communication
• Core components of an application — activities,
services, and broadcast receivers — can send/receive
messages, called intents.
• Intents (explicit & implicit) can
– Start Activities
– Start, stop, and bind Services
– Broadcast information to Broadcast Receivers
• To receive Intents, component must be declared in
the AndroidManifest.xml
Intents
• Intent: notification from one process to another
– Implicit: can be received by anyone
Intent intent = new Intent(Intent.ACTION_VIEW,
Uri.parse("http://www.example.com"));
startActivity(intent);
– Explicit: has one specific recipient and indicate exactly
which activity class
Intent intent = new Intent(this, ActivityABC.class);
i.putExtra("Value", "This value for ActivityABC");
startActivity(intent);
Intent Filters
• To inform the system which implicit intents they can
handle, activities, services, and broadcast receivers
can have one or more intent filters.
• Each filter describes a capability of the component,
a set of intents that the component is willing to
receive.
• It selects intents of a desired type, while filtering out
unwanted intents
Security Risks in Android’s Inter-Process
Communication
• Type 1: If the sender does not correctly specify recipient (can
send to anyone), attackers can intercept messages and lead to
attacks such as Broadcast theft, activity and service hijacking.
• Type 2: If a component does not restrict from whom it can
receive messages (can receive from anyone), attacker can
inject code. The attack can result in data corruption, code
injection, malicious broadcast injection, malicious activity
launch, malicious service launch.
Recommendations for Inter-Process
Communication
•
•
•
•
•
Use caution with implicit Intents
Use explicit Intents to send private data
Returned results should be checked for authenticity
Always assign a least permission to a application
Users have to grant explicit permission to third-party
applications requesting use of cost sensitive APIs
including Telephony, messaging, networking, in-app
billing, etc.
4. Application Provenance
• Android requires every application to be signed with
its developer’s private key.
• It is self-signed. Why self signing? Market ties
identity to developer account.
• Therefore, no application is trusted.
• After a signed application is installed on the phone,
the system is able to use its signature information to
distinguish it from other application.
Cont.
• All .apk files must be signed with a certificate
– identifies the author of the application.
– does not need to be signed by a certificate authority
• Allows the system to grant or deny applications
– access to signature-level permissions
– request to be given the same Linux identity as another
application.
• If the public key matches the key used to sign any other
APK, the new APK may request to share a UID with the
other APK.
Security threat #1 Trojan Horse Example
(1)
•
•
•
•
•
Vicky, a top-level manager
A file Market on the new products release
John, subordinate of Vicky
A file called “Stolen”
An application with two hidden operations
– Read operation on file Market
– Write operation on file Stolen
25
Security threat #1 Trojan Horse Example
(2)
Trojan Code
26
Security threat #1 Trojan Horse Example (3)
Trojan Code
27
Hands-on Lab #3
• Hide Trojan Horse in tic-tac-toe Game
• Permissions
– READ_CONTACTS
– WRITE_CONTACTS
– RECEIVE_BOOT_COMPLETED (The attack begins
when the phone starts. )
• Attack actions
– Read contacts from a phone
– Delete all contact information
28
Security threat #2: Mobile Malware (1)
Malicious logic
Mobile Trojan
5556
5554
29
Security threat #2: Mobile Malware (2)
Malicious logic
Victim 5554 infected by Mobile Trojan
Mobile Trojan
5554 sends a short MSG to 5556
30
Security threat #2: Mobile Malware (3)
Malicious logic
Receiver of Victim replies to 5554
Mobile Trojan
Nothing happened at Victim 5554
31
Security threat #2: Mobile Malware (4)
Malicious logic
Mobile Malware Defense
• use a "ContentObserver" to listen to any actions on the
internal database of Android.
32
Hands-on Lab #4
• Start two emulators
– 5554:Test
– 5556:Test2
• Infect 5554:Test
• Send message to 5556:Test2 through victim
5554:Test
33
Security threat #3: Injection
• Injection attacks trick an application into including
unintended commands in the data send to an interpreter.
• Interpreters
– Interpret strings as commands.
– Ex: SQL, shell (cmd.exe, bash), LDAP, XPath
• Key Idea
– Input data from the application is executed as
code by the interpreter.
Security threat #3: SQL Injection
1.
2.
3.
4.
5.
6.
App sends form to user.
Attacker submits form with SQL
exploit data.
Application builds string with
exploit data.
Application sends SQL query to
DB.
DB executes query, including
exploit, sends data back to
application.
Application returns data to user.
Attacker
Form
User
Pass ‘ or 1=1--
Firewall
Web Server
DB Server
Security threat #3: SQL Injection
Example (1)
Unauthorized Access Attempt:
password = ’ or 1=1 --
SQL statement becomes:
select count(*) from users where username = ‘user’
and password = ‘’ or 1=1 -Checks if password is empty OR 1=1, which is always
true, permitting access.
Security threat #3: SQL Injection
Example (2)
User ID: ` OR ``=`` -Password: abc
Because anything after the -- will be ignored,
the injection will work even without any
specific injection into the password predicate.
SQL Injection Countermeasures: Prepared
Queries (1)
• bound parameters, which are supported by
essentially all database programming interfaces.
• In this technique, an SQL statement string is created
with placeholders - a question mark for each
parameter - and it’s compiled ("prepared", in SQL
parlance) into an internal form. Later, this prepared
query is "executed" with a list of parameters.
Example in Perl:
$sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;");
$sth->execute($email);
$email is the data obtained from the user's form, and it is passed as positional
parameter #1 (the first question mark), and at no point do the contents of this
variable have anything to do with SQL statement parsing. Quotes, semicolons,
backslashes, SQL comment notation - none of this has any impact, because it's
"just data". There simply is nothing to subvert, so the application is be largely
immune to SQL injection attacks.
SQL Injection Countermeasures: Prepared
Queries (2)
• bound parameters in Java
Insecure version
Statement s = connection.createStatement(); ResultSet rs =
s.executeQuery("SELECT email FROM member WHERE name = " + formField);
// *boom*
Secure version
PreparedStatement ps = connection.prepareStatement( "SELECT email FROM
member WHERE name = ?");
ps.setString(1, formField);
ResultSet rs = ps.executeQuery();
There also may be some performance benefits if this prepared query is
reused multiple times (it only has to be parsed once), but this is minor
compared to the enormous security benefits. This is probably the single
most important step one can take to secure a web application.
Hands-on #5
• Inject SQLite Database of Android
• Attacks:
– 1’ or ‘1’=‘1
– 1’ or username not null
• Countermeasures
String m_argv[] = {m_id};
cursor=db.rawQuery("SELECT * FROM usertable WHERE _id= ?
",m_argv );
40