Android Security model updates, and Android Security discussions [Description to be updated later]

1. PSCG
Ron Munitz
Founder & CEO - The PSCG
ron@thepscg.com
CodeMotion
Tel-Aviv
17 December 2015
@ronubo
The slides are available online at:
thepscg.com/talks/
Burning
Marshmallows

2. This work is licensed under the Creative Commons
Attribution-ShareAlike 4.0 International License.
To view a copy of this license, visit http://creativecommons.org/licenses/by-
sa/4.0/
© Copyright Ron Munitz 2015
PSCG

3. about://Ron Munitz
● Founder and CEO of the PSCG
○ The Premium Embedded/Android consulting and Training firm
● Android*, Linux*, Security* Trainer and Instructor
○ The PSCG, NewCircle and the Linux Foundation
○ For Q1 2016 training, Contact training@thepscg.com
● NIche Conference Organizer
○ MobSecCon, MobModCon, Voxxed Days Tel-Aviv
○ CFP is open. Follow me on Twitter and Google+ for announcements
( @ronubo , +RonMunitz )
● Working hard on the next huge thing…
Looking for co-founders!!!
○ Full Stack developer
○ Offensive Security experts (Mobile - huge advantage. Otherwise… Be
smart and serious and I’ll teach you what you need to know)
PSCG

4. Agenda
● Android Security features timeline
● PR stunts and Software Security faceoff
● Android Security Patching and Nexus Security Bulletin
● Introducing: Android 6.0 - Marshmallow
● Burning Marshmallows - Future PR stunts

5. Android Security Timeline
PSCG
Days of future past

6. Android Security Architecture
● Key Features
○ Robust security at the OS level through the Linux
kernel
○ Mandatory application sandbox for all applications
○ Secure interprocess communication
○ Application signing
○ Application-defined and user-granted permissions
○ SE Linux
○ Multi-User support, “work profiles”, “guest profiles”,...
○ FUSE for sdcard (permissions, encryption)
○ Trusted Execution Environment and HW support
PSCG

7. Android Security features timeline
● Permission System / Signature Systems
● JCE (BouncyCastle), OpenSSL
● Partial ASLR (“stagefright” → ICS!)
● Hardware Backed KeyStore
● Full ASLR (and later heap randomization and full PIE)
● SE Linux (first Permissive, then Enforcing)
● OTA Update System (e.g. Chromium)
● Full disk encryption, dm-crypt
● Trusted Boot support, dm-verity
● SE Linux - Full domain enforcement (important addition)
● Partial Permission Module (Burden on the developer...)
● Fingerprinting API,
● Keystore redesign
● ...

8. Popular “Victims”
PSCG
A pre Marshmallow candy barbeque
(or is it?)

9. Popular Attack Surfaces
● The AOSP builds on countless lines of code
○ Developed by Google and Partners
■ AOSP → OEM → Carrier chain of (mis)trust
○ “Borrowed”/Ported
● init services
○ If defined critical may lead to device reboot
○ If restarts other services - may lead to DoS
● Android services
○ Usually one service (server) serves multiple
components (clients) ⇒ DoS
● Separate code injection and privilege
escalation from DoS!

10. Don’t (blindly) believe the news
● StageFright sequences (by several vendors)
○ Fact: “Everyone” is fuzzing stagefright.
■ @see “Fuzzing the media framework in android”
by the Intel OTC, at ELC 2015
○ The mediaserver runs stagefright as the “media
backend”
○ If “everyone” fuzzes ⇒ at least someone succeeds
● Skia sequences
● gralloc sequences
● Kernel sequences...

11. Don’t (blindly) believe the news
● Fact: One of the Stagefright exploits was
severe because it could be triggered
remotely.
○ This is a huge deal.
○ If only...
● Fact: ASLR, PIE, DEP, SELinux,...
● Home exercise/Group bet:
○ Assuming an MMS costs $0.01. How many USD
would you spend on arbitrary remote code
execution?
○ Volunteers?
■ Regardless: Potential remote code execution ⇒ Critical severity

12. Don’t (blindly) believe the news
● Fact: One of the stagefright exploits resulted
in DoS attacks on the media server due to
heap overflow.
● This can lead to annoying behavior, and
more.
● Fact: mediaserver is not a privileged user.
Software components have bugs. It’s a part
of life.
● Opinion: If someone manages to exploit
those vulnerabilities, they probably deserve
a prize...

13. Yet, don’t avoid somewhat silent news
● A good attack is a low profile attack.
● An excellent attack is a zero-day attack
● Disclosure does not always help, and the
Android Ecosystem is not a great helper
○ AOSP → OEM → Carrier → (?) → User
● And when someone in the chain decides to
do something stupid within the chain -
someone else will take advantage
○ @see the “yearly” signature verification attacks
○ In fact, let’s have a quick look at a recent one

14. Silent but lethal news as per Sep 15
A great example which has not been published without
proportions and been recently patched at most, but not all
implementations is the Certifi-gate attack against RST
(Remote Support Tools):

15. Silent but lethal news as per Sep 15
● It turns out that RST such as TeamViewer, RSupport
and more, which were bundled in some popular device
ROMs from leading companies (LG, Samsung, Huawei
and more), had privileged access to elements such as
○ Screen Recording (Surface Flinger/Framebuffer)
○ Event Injection
○ Package Installation

16. Silent but lethal news as per Sep 15
● It also turns out that these RST’s enabled “trusted”
applications to take advantage of these permissions, by
using them as a (confused?) deputy, while the
applications would be an “extension”.
● What is trust?
○ Apparently, comparing an X509 certificate serial
number to a hard-coded value, comparing a
certificate “HashCode” to a hardcoded value etc…
● Given that, one could just build a “trusted” “extension” to
the RST, that would have full device control, without
ever asking for any permission.
● Great.

17. Getting the latest news
● In the last year, the Android team has started
a monthly security pathcing cycle
○ @see About→ Phone→ Security Patch Level
● Most insights/changelogs/CVE) can be seen
in https://source.android.com/security/bulletin/index.html
● The patch levels are (obviously) applied only
to the Nexus phones at the released dates.
○ The rest is up to the OEM’s good will
● Classified into 4 severity levels:
○ Critical, High, Moderate, Low

18. Understanding Android Security Bulletin
ratings
The severity of a bug generally reflects the potential harm that could occur if a bug was
successfully exploited. Use the following criteria to determine the severity:
Critical
● Remote privileged code execution (execution at a privilege level that third-party apps cannot obtain)
● Local permanent device compromise (device cannot be repaired without re-flashing the entire operating
system, such as a verified boot or Trusted Execution Environment/TEE compromise)
● Remote permanent denial of service (inoperability, either completely permanent or requiring re-flashing the
device)
High
● Remote unprivileged code execution (execution at a privilege level that third-party apps can obtain through
installation)
● Local access to system/signature-level permission data or capabilities without permission
● Local permanent denial-of-service (inoperability, either completely permanent or requiring re-flashing the
device)
● Remote temporary denial-of-service (remote hang or reboot)
Moderate
● Access to "dangerous" level permission data or capabilities without permission with an app installed on the
device
● Local temporary denial-of-service (can be resolved only through a factory reset)
Low
● Access to "normal" level permission capabilities without permission with an app installed on the device
● Local temporary denial-of-service (can be resolved by booting the device into Safe Mode and removing the
problem application)

19. Marshmallow Additions
PSCG

20. Marshmallow Additions
● FingerPrinting API
○ Biometric ID’s anyone?
○ Trusted Execution Environment implementation
■ @see attacks on ARM TrustZone..
○ What if the device has no TEE?
■ Prone to forensics…
● Dynamic Permission API
○ Basically a good thing. Finally catches up with iOS
dynamic permission model
○ Drawback: Will break applications. Not because it is
a bad things. But because of application developers
○ Mitigation: SDL, Captain Hindsight

21. Marshmallow Additions
● Keystore API redesign
● Keystore HAL redesign/additions
○ keymaster v. 1.0 - First signs of maturity?
● Symmetric key cryptography support at (HW
backed) keystores
○ This has been out for a while.
○ But on a platform hidden API (@hide)
○ Now available for all!
● Enable timed authentication
○ Introducing the gatekeeper HAL

22. Marshmallow Additions
● APK Validation changes
○ Following various notorious APK signing bugs (Master
Key etc.).
○ If a file is declared in the manifest but not present in
the APK itself ⇒ APK is considered corrupt
● Android for Work
○ Behavior is still evolving (for better? worse?)
○ Examples: Automatic System updates
○ Runtime Permission policy for all applications
○ Data usage tracking.
○ Most changes are Android. Not Google Play services.
● External Storage Encryption, App Linking,

23. Dynamic Permission API
Target API < 23 Target API >= 23
Device API < 23 No change (shocking, isn’t it?) Use Build.VERSION.SDK_INT switch.
Device API >= 23 No change on installation (all
permissions granted)
Permission can be revoked -
may break apps. The device
will warn the user about it.
Full dynamic permission model.
Make sure you check for SDK_INT ,
and always checkSelfPermission() ,
[shouldShowPermissionRationale()],
and requestPermission() when
relevant.
Then, handle the user’s choice on
onRequestPermissionResults()

24. Dynamic Permission API
● Long story short:
Target API Level 23 ⇒ Application
developer needs to be aware of dynamic
permissions
● Device Level 23 ⇒ End User needs to be
aware of the consequences of disabling
permissions for older SDK level apps.
● It’s quite obvious researchers will
celebrate this significant behavior
change...

25. Ahead Of Time Compiling (ART)
● Marshmallow provides ART as the default
(and only unless specifically configured) run
time.
● It seems that the OAT files are still “Lollipop
compliant” ⇒ Trivially reversible due to:
● A full mapping from Native code to DEX bytecode
● A full mapping from both to Java functions.
● So you can apply the same techniques for .dex
file decompiling.
● @see my upcoming Android Reverse Engineering
Lab

26. Speculations
● The most dominant attacks we’ll hear of will
be in the categories of:
○ Certificate validation, self Certificate Chain validation
○ Everything under the AOSP /external/
■ Home exercise: Can you play with toybox?
○ Everything media, graphics, binder, native related
○ Application breaking
○ Fingerprint stealing (if and when)
○ Bad SE Linux policies (unlikely for the “serious”
vendors, but hey, Android fragmentation…)
○ Timing attacks against the new Keystore API’s
● Or maybe we will hear of nothing. But
attackers/researchers will definitely try.

27. Follow up:
● Android Security workshop
○ Public class in Tel-Aviv - January 24-28, 2015.
○ training@thepscg.com
○ Discount Code: CodeMotionTLV1711
● On-Site/Public classes anywhere??
○ Contact me - training@thepscg.com
● MobSecCon and MobModCon
○ http://thepscg.com/events/mobmodcon
○ http://thepscg.com/events/mobseccon
○ CFP is now open!

28. Thank You
PSCG
Consulting/Training requests:
ron@thepscg.com