This document summarizes Ron Munitz's presentation on Android security features and future vulnerabilities. It provides an overview of Android's security timeline and architecture. It then discusses past vulnerabilities like Stagefright and potential new avenues of attack in Android Marshmallow, such as issues with the fingerprint API, dynamic permission model, and app linking. The presentation speculates that future vulnerabilities may target certificate validation, media functions, and timing attacks against the keystore. It concludes by advertising Android security training classes.
FULL ENJOY - 9999218229 Call Girls in {Mahipalpur}| Delhi NCR
Voxxed Days Villnius 2015 - Burning Marshmallows
1. PSCG
Ron Munitz
Founder & CEO - The PSCG
ron@thepscg.com
Voxxed Days
Vilnius
18 September 2015
@ronubo
The slides are available online at:
thepscg.com/talks/
Burning
Marshmallows
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
● Senior Lecturer at Afeka College of Engineering and
Holon Institute of Technology
● Founder and (former) CTO of Nubo Software
○ The first Remote Android Workspace
● Always up for something new. Builder, Adviser.
● Building up on diverse engineering experience:
○ Distributed Fault Tolerant Avionic Systems
○ Highly distributed video routers
○ Real Time, Embedded, Server bringups
○ Operating Systems, very esoteric libraries, 0’s, 1’s and lots of them.
PSCG
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
● ...
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
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?
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 does 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.
18. 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
19. 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
20. 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 and
21. 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()
22. 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...
23. 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
24. 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 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.
25. Follow up:
● Android Security workshop
○ Public class in Tel-Aviv - October 18-20, 2015.
○ training@thepscg.com
○ Discount Code: VoxxedDays1809
● Private/Public classes in Lithuania?
○ Contact me - training@thepscg.com
