Transcript Architectural Issue in Practice

Architectural Issues in Practice:
Android Security
Sam Malek
Software Architecture
INF 221
Fall 2016
Android Security Model
• Based on Linux OS: stable and secure kernel trusted by many corporations
and security professionals.
• Linux kernel supports:
•
•
•
•
A user-based permissions model
Process isolation
Extensible mechanism for secure IPC
The ability to remove unnecessary and potentially insecure parts of the kernel
• The Application Sandbox
• Each App runs in a separate Linux process with a unique user ID (UID)
• Application Signing
• Every app must be signed by its developer
• Developer can specify in the manifest file that an App will share a UID with other
similarly-signed APKs – in this case, apps share a process
2
Android Security Model
• By default, applications cannot interact with each other and have
limited access to system resources
• Android provides
• Inter-Component Communication (ICC) mechanism
• Permission System
•
•
•
•
System permission
Custom permission
Permission guards in the code
Broadcast Intent permission
• Each permission has its own protection level
•
•
•
•
Normal: just ask
Dangerous: user must grant it to the app
Signature: granted only to apps with the same certificate
SignatureOrSystem: granted to the apps with the same certificate or the system apps
3
Android Permission System
• An app must request the permissions it needs to access the protected
features in the device (resources or protected components)
• For example, if an app needs to monitor incoming SMS messages, it
should specify that in the AndroidManifest.xml file as follows:
<uses-permission android:name="android.permission.RECEIVE_SMS"/>
• In Android 5 (API 22) or lower, the system asks the user to grant all
permissions at install time
• Starting from Android 6 (API 23) an app requests the permissions at
runtime, and the user can grant/revoke the permission at any time
4
Android Permission System
Install time permission system
Runtime permission system
5
Security implications of Android’s
architectural design
• Android grants permission at the app level
• Developers tend to ask for more permissions than required
• Previous study shows that 33% of the studied apps are over-privileged with 1 to 4 extra
permissions [3]
• Android advocates component-based development
• However, the current Android system is incapable of granting/revoking permission(s) at the
component level
• Thereby, almost all components are over-privileged
6
Security Attacks
• ICC Attacks
• Permission Re-Delegation Attack
• Attacks through Hidden Code
7
Security Attacks
• ICC Attacks
• Permission Re-Delegation Attack
• Attacks through Hidden Code
8
ICC Attacks
• ICC is a powerful mechanism that promotes collaboration and code
reuse among apps
• ICC is also an application attack surface
Intent-Based Attack
Unauthorized Intent Receipt
Broadcast
Theft
Activity
Hijacking
Service
Hijacking
Intent Spoofing
Pending
Intents
Malicious
Broadcast
Injection
Malicious
Activity
Launch
Malicious
Service
Launch
9
Vulnerable Android System
• We will use this vulnerable Android system to explain various ICC
attacks
Texting
MyWeather
MainActivity
LocUpdater
MsgComposer
SendMsg
Attacker
MainActivity
LocLeaker
Implicit Message-Based
Broadcast
Receiver
Content
Provider
Service
Activity
Android
App
Connector
Provided
Port
Required
Port
10
Vulnerable Android System
• The system is available on GitHub (https://github.com/mhammad2)
• You can “git” the apps and learn more about the various ICC attacks
11
Unauthorized Intent ICC Attack
• There are no guarantees that an implicit Intent will be received by the
intended recipient
• A malicious component can intercept the Intent by declaring an Intent filter
• The malicious component can then gain access to all the data in the
intercepted Intent
Intent-Based Attack
Unauthorized Intent Receipt
Broadcast
Theft
Activity
Hijacking
Service
Hijacking
Intent Spoofing
Pending
Intents
Malicious
Broadcast
Injection
Malicious
Activity
Launch
Malicious
Service
Launch
12
Unauthorized Intent Receipt
Broadcast Theft
• Broadcasts are vulnerable to passive eavesdropping and active denial
of service attack
• A malicious broadcast receiver intercepts an Intent or prevents it from
reaching other broadcast receivers
• 12% of apps are vulnerable to this attack [1]
13
Unauthorized Intent Receipt
Broadcast Theft – Passive Eavesdropping
• When a component, firstActivity in this example, sends an
unprotected broadcast Intent, the system sends the Intent to all
registered receivers
• An eavesdropper, receiver2 in this example, silently receives the
broadcast Intent
receiver1
firstActivity
sendBroadcast
<receiver
android:name=".receiver1"
android:enabled="true"
android:exported="true">
<intent-filter>
<action android:name="some_action"/>
</intent-filter>
</receiver>
System
receiver2
<receiver
android:name=".receiver2"
android:enabled="true"
android:exported="true">
<intent-filter>
<action android:name="some_action"/>
</intent-filter>
</receiver>
14
Unauthorized Intent Receipt
Broadcast Theft – DOS Attack
• An active attacker could launch a denial of service attack or data injection
attacks on a broadcast receiver
• Non-ordered broadcast Intents are sent to all registered receivers at the
same time
• One receiver cannot prevent others from receiving it, e.g., BATTERY_LOW
• Ordered broadcast Intents are delivered serially to broadcast receivers in
order of descending priority
• One receiver can prevent another receiver from receiving the Intent, e.g.,
ACTION_NEW_OUTGOING_CALL
15
Unauthorized Intent Receipt
Broadcast Theft – DOS Attack Example
callerActivity
sendOrderedBroadcast
<receiver
android:name=".receiver1"
android:enabled="true"
android:exported="true">
<intent-filter android:priority="100" >
<action android:name="some_action"/>
</intent-filter>
<receiver
android:name=”.parentingControl"
android:enabled="true"
android:exported="true">
<intent-filter android:priority=”1" >
<action android:name="some_action"/>
</intent-filter>
</receiver>
</receiver>
System
parenting
Control
receiver1
setResultData(null);
• setResultData is an API in the BroadcastReceiver class that allows the receiver to change the result data in the Intent before
forwarding it to the next receiver.
• Passing a null value to this API stops the Intent from being forwarded to the next receiver
16
Unauthorized Intent Receipt
Activity Hijacking
• Malicious Activity registers to receive another component’s implicit
Intent
• Malicious Activity is launched in place of the intended Activity
• The malicious Activity could:
• Read the data sent to another Activity
• The hijacker could spoof the expected Activity’s user interface to steal usersupplied data (i.e., phishing attack)
• 57% of apps are vulnerable to this attack [1]
17
Unauthorized Intent Receipt
Activity Hijacking - Example
• maliciousActivity listens to the same action that secondActivity listens to
• The system prompts the user to choose an app that can handle the
Intent
• If firstActivity is expecting a result, then maliciousActivity can return a
malicious response value (i.e., false response attack)
secondActivity
firstActivity
malicious
Activity
18
Unauthorized Intent Receipt
Service Hijacking
• Service hijacking occurs when a malicious Service receives an implicit
Intent intended for a legitimate Service
• When multiple Services can handle an Intent, Android selects one at
random
• Unlike Activity hijacking, Service hijacking is not apparent to the user
because no user interface is involved
• If the calling app binds to a malicious Service, then it can return
malicious data (i.e., false response attack)
• 3 % of apps are vulnerable to this attack [1]
19
Unauthorized Intent Receipt
Service Hijacking - Example
Attacker
MyWeather
Android System
Location
Service
MainActivity
LocUpdater
Service
Explicit
Intent
Implicit
Intent
Callback
LocLeaker
Activity
Transaction
20
Unauthorized Intent Receipt
Service Hijacking - Code
public class MainActivity extends AppCompatActivity implements LocationListener {
@Override
protected void onCreate(Bundle savedInstanceState) {
//register a callback
LocationManager locationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE);
locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 4000, 0, this);
}
@Override
public void onLocationChanged(Location location) {
Log.i("MyWeather", "start service with "+location.getLongitude());
Intent intent = new Intent();
intent.setAction(“UPDATE_LOCATION");
intent.putExtra("LONG", location.getLongitude());
intent.putExtra("LAT", location.getLatitude());
startService(intent);
}
…
public class LocationUpdater extends Service {
public int onStartCommand(Intent intent, int flags, int startId){
double longitude = intent.getDoubleExtra("LONG", 0);
double latitude = intent.getDoubleExtra("LAT", 0);
//fetch the weather forecast for this location
//update the database and/or the widget with the new location
Log.i("MyWEATHER", "location "+longitude+" "+latitude);
return START_STICKY;
}
public class LocationLeaker extends Service {
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
//get the location from the intent
double longitude = intent.getDoubleExtra("LONG", 0);
double latitude = intent.getDoubleExtra("LAT", 0);
Log.i("Attacker", "received the location "+longitude+" "
+latitude+" Thank you!");
…
21
Unauthorized Intent Receipt
Pending Intent Delegation Attack
• PendingIntent is a type of Intent with a target action that can be
performed at a later time by the holder of that Intent
• One App can send a PendingIntent to another app to perform the
action on behalf of the sender at a later time
• By giving a PendingIntent to another application, you are granting it
the right to perform the operation you have specified as if the other
application was yourself (with the same permissions and identity)
• CVE-2014-8609: in Android 4, addAccount method in the Settings app
does not properly create a PendingIntent, which allows an attacker to
use the System UID for broadcasting sensitive intents
22
Unauthorized Intent Receipt
Pending Intent Delegation Attack - Example
• firstActivity sends a PendingIntent
• maliciousService receives the
implicit Intent
• maliciousService uses the
PendingIntent to interact with the
SecondActivity, a protected
component with a custom
permission
Malicious App
Benign App
first
Activity
Explicit
Intent
malicious
Service
second
Activity
Pending
Intent
Transaction
Protected
Component
23
Insecure PendingIntent in the Settings app
private void addAccount(String accountType) {
Bundle addAccountOptions = new Bundle();
mPendingIntent = PendingIntent.getBroadcast(this, 0, new Intent(), 0);
addAccountOptions.putParcelable(KEY_CALLER_IDENTITY, mPendingIntent);
addAccountOptions.putBoolean(EXTRA_HAS_MULTIPLE_USERS,
Utils.hasMultipleUsers(this));
AccountManager.get(this).addAccount(
accountType,
null, /* authTokenType */
null, /* requiredFeatures */
addAccountOptions,
null,
mCallback,
null /* handler */);
mAddAccountCalled = true;
}
//AccountManager sends the PendingIntent to another app
Any app can register as account authenticator using this Intent filter. No
permission is required.
<intent-filter>
<action android:name="android.accounts.AccountAuthenticator" />
</intent-filter>
Malicious app can use the PendingIntent to send a phishing SMS message
public Bundle addAccount(…,Bundle options){
PendingIntent pendingIntent = (PendingIntent)options.getParcelable("pendingIntent");
Intent newIntent = new Intent();
newIntent.setAction("android.provider.Telephony.SMS_RECEIVED");
//filling phishing sms data
pendingIntent.send(mContext, 0, newIntent, null, null);
24
Intent Spoofing
Intent Spoofing ICC Attack
• A malicious attacker can launch an Intent spoofing attack by sending
an Intent to an exported component that is not expecting the Intent
from the sender component
• If the receiver takes an action with the received Intent, the attacker
can trigger a malicious action
Intent-Based Attack
Unauthorized Intent Receipt
Broadcast
Theft
Activity
Hijacking
Service
Hijacking
Intent Spoofing
Pending
Intents
Malicious
Broadcast
Injection
Malicious
Activity
Launch
Malicious
Service
25
Launch
Intent Spoofing
Malicious Broadcast Injection
• Malicious component sends an Intent, either explicit or implicit, to an
exported Broadcast Receiver
• The Broadcast Receiver blindly trusts an incoming broadcast Intent,
without checking the authenticity of the sender
• Broadcast Receivers that listen to system broadcast Intents are
particularly at risk
• These broadcast receivers operate in response to system actions without
checking to see if the system has sent the Intent
• 14% of apps are vulnerable to this attack [1]
26
Intent Spoofing
Malicious Broadcast Injection - Example
• packageInstalledReceiver receives a broadcast Intent from the system
whenever a new app installed
• Once packageInstalledReceiver receives the Intent, it starts
newPackageService to scan that app from viruses
• maliciousActivity can start packageInstalledReceiver using an explicit
Intent and provide a fake app’s name
malicious
Activity
packageInstalled
Receiver
newPackageServ
ice
27
Intent Spoofing
Malicious Activity Launch
• This attack is analogous to cross-site request forgeries (CSRF)
• Android App comprises many entry points. Any component can start
any exported Activity using explicit or implicit Intent
• The system loads the launched Activity’s user interface
• In addition to disrupting/annoying the user, the launched Activity
might:
• Update a stored data and change the app’s state
• Return sensitive data to the called component
• 12% of apps are vulnerable to this attack [1]
Malicious
Service
firstActivity
28
Intent Spoofing
Malicious Service Launch
• Similar to the previous attack, a malicious component can start or
bind to any exported Service and not protected with a permission
• The started/bound Service might leak sensitive information or corrupt
the app’s state
• 1% of apps are vulnerable to this attack [1]
29
Security Attacks
• ICC Attacks
• Permission Re-Delegation Attack
• Attacks through Hidden Code
30
Permission Re-Delegation Attack
(aka, confused deputy, privilege escalation)
• Application with permission(s) performs a privileged task for an application without
permission(s)
• SendMsg component (deputy) executes a privileged task (sends an SMS message) on behalf
of an unprivileged component, LocLeaker
• This attack allows the LocLeaker to leak location information to a premium number
Attacker
LocLeaker
Texting
SendMsg
Service
Explicit
Intent
Implicit
Intent
Callback
Transaction
Activity
31
Permission Re-Delegation Attack - Example
Intent i = new Intent();
i.setAction(“SEND_SMS");
i.putExtra("PHONE_NUMBER", premiumNumber);
i.putExtra("TEXT_MSG", "longitude:"+longitude+", latitude:"+latitude);
startService(i);
public class SendMsg extends Service {
@Override
public int onStartCommand(Intent intent, int flags, int startId){
//if (checkCallingPermission("edu.uci.seal.action.SEND_SMS")== //
PackageManager.PERMISSION_GRANTED) {
String phoneNumber = intent.getStringExtra("PHONE_NUMBER");
String areaCode = phoneNumber.substring(0,3);
String msg = intent.getStringExtra("TEXT_MSG");
Log.i("TEXTING", "Send a message to "+phoneNumber+" text: "+msg);
SmsManager smsManager = SmsManager.getDefault();
smsManager.sendTextMessage(phoneNumber, null, msg, null, null);
//}
return START_STICKY;
}
}
32
Security Attacks
• ICC Attacks
• Permission Re-Delegation Attack
• Attacks through Hidden Code
33
Attacks through Hidden Code
• Malware authors tend to hide their malicious code to:
• Prevent automated analysis tools from properly vetting apps
• Bypass the antivirus products
• There are many ways to hide the code
• Code encryption
• Reflection
• Dynamic class loading
34
Dynamic class loading
• Android framework allows apps to load code from external sources at
runtime
• Developers of benign apps use this feature for legitimate reasons
• Instrumentation to collect data during beta testing from users
• Common library: multiple apps use the same library which can be installed on the
device as a separate APK file to reduce storage space
• Library update: many apps bundle various libraries for additional functionality, e.g.
ad libraries. Libraries use this feature for self-updating.
• Loading add-ons in the app: SMS apps that load design themes or game apps that
install additional levels
35
Attacks using dynamic class loading
1. Code injection attacks against benign apps
•
•
•
•
Android system does not check the integrity of the downloaded class files
Oftentimes developers don’t check the integrity of the installed codes
Attackers can inject a malicious code and replace the expected legitimate code
16% of the top apps are using this feature in an insecure way [1]
2. Executing another app’s code
• createPackageContext(pkg, flags) API is an Android API that returns a lightweight
context object for a given app’s package name
• Apps built from the same developer use this feature
• Malicious app can use the class loader from the returned Context object to execute
another app’s code
• For this attack to work you need to disable the security checking by passing
CONTEXT_INCLUDE_CODE and CONTEXT_IGNORE_SECURITY flags
3. Hiding malicious behavior
36
Hiding malicious behavior
• Malware authors use this feature to bypass Google Bouncer, an
internal Google testing tool for vetting apps
• DexClassLoader API is an Android API that loads classes from JAR or
APK file
• The JAR or APK files should contain a classes.dex file
• The JAR or APK files can be downloaded from any source including SD card
and internet
• A malicious app can use this API to dynamically load code at runtime
37
Dynamic class loading - Example
Android System
System
Service
Explicit
Intent
Implicit
Intent
ClassLoader classLoader = context.getClassLoader();
DexClassLoader dcl = new DexClassLoader(dexPath,
libraryPath, classLoader);
Class c = dcl.loadClass("className");
Method m = c.getMethod("methodName", params);
FunGame
LevelUp
Transaction
Loaded
Service
Dynamically
Loaded
Dynamic
Broadcast
Receiver
Dynamic
Receiver
Service
optimizedDir,
m.invoke(object, args);
BroadcastReceiver dynamicReceiver(){
BroadcastReceiver receiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
//forward the action and the intent's payload
}
};
IntentFilter iFilter = new IntentFilter();
iFilter.addAction("android.intent.action.BATTERY_LOW");
iFilter.addAction("android.intent.action.ACTION_POWER_CONNECTED");
iFilter.addAction("android.intent.action.PACKAGE_ADDED");
iFilter.addAction("android.intent.action.PACKAGE_REMOVED");
iFilter.addAction("android.intent.action.NEW_OUTGOING_CALL");
iFilter.addAction("android.intent.action.SCREEN_OFF");
iFilter.addAction("android.intent.action.SCREEN_ON");
iFilter.addAction("android.provider.Telephony.SMS_RECEIVED");
iFilter.addAction("android.net.wifi.WIFI_STATE_CHANGED");
registerReceiver(receiver, iFilter);
return receiver;
}
38
Security Guidelines
• Use explicit Intents when possible
• Protect any sensitive component with a permission
• Limit the exposure of the component
• Use LocalBroadcastManager API to send broadcast Intents within an app
• Use broadcast Intent permission, sendBroadcast(intent, receiverPermission)
• Validate the received Intent before using it
• Check the permission/identity of the caller’s component
39
References
• [1] Chin, et al. Analyzing Inter-Application Communication in
Android (Links to an external site.). International Conference on
Mobile Systems, Applications, and Services, Washington DC, June
2011
• [2] Hardy, Norm. "The Confused Deputy:(or why capabilities might
have been invented)." ACM SIGOPS Operating Systems Review 22.4
(1988): 36-38
• [3] Felt, Adrienne Porter, et al. "Android permissions
demystified." Proceedings of the 18th ACM conference on Computer
and communications security. ACM, 2011.
40