�ݺ�ߣ

MobSecCon 2015 - Burning Marshmallows

● MobSecCon is all about Mobile Security!
● Agenda in numbers:
○ 5 technical talks
○ 1 technical panel
○ 1 awesome sponsor (thank you!)
○ 0% biased
● Coming up soon:
○ Mobile Modders Summit
○ MobSecCon #2
■ Adding Fraud Analysis track
○ email ron@thepscg.com for updates, or/and follow
me on twitter/Google+
Welcome to MobSecCon #1!

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

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

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

Agenda
● Android Security features timeline
● PR stunts and Software Security faceoff
● Introducing: Android 6.0 Marshmallow
● Burning Marshmallows - Future PR stunts

Android Security Timeline
PSCG

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

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
● ...

Popular Attack Surfaces
● The AOSP builds on countless lines of code
○ Developed by Google and Partners
■ (@see Certifi-gate talk at 16:50
○ “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!

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

● 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?

● 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...

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

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

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()

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...

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.

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…)
● Or maybe we will hear of nothing. But
attackers/researchers will definitely try.

Follow up:
● Mobile Modders Summit Tel-Aviv
○ A gathering of Android, iOS, Tizen, Windows
platform builders.
○ Professor X is calling: Let’s find them all.
○ Coming up November 2015 - Stay tuned!
● Android Security workshop
○ Public class in Tel-Aviv - October 18-20, 2015.
○ training@thepscg.com
○ Discount Code: MobSecCon#1

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

�ݺ�ߣ

MobSecCon 2015 - Burning Marshmallows

More Related Content

MobSecCon 2015 - Burning Marshmallows