ANDROID APP “PROTECTION” - strazzere.com · ANDROID APP “PROTECTION ... (kiss-kiss / others)...

04.30.2015

ANDROID APP “PROTECTION”

TIM “DIFF” STRAZZERE - JON “JUSTIN CASE” SAWYER

Qualcomm Mobile Security Summit

• CTO of Applied Cybersecurity LLC

• Professional Exploit Troll

• Twitter Celebrity

• @jcase

• github.com/CunningLogic

• Research & Response Engineer @ Lookout

• Obfuscation Junkie

• Pretends to know as much as JCase

• @timstrazz

• github.com/strazzere

WHO ARE WE

JCASE DIFF

http://github.com/strazzere

More importantly - why should you care?

WHY ARE WE HERE

• Obfuscation is “magical”

• Quantifying the challenge is hard,mainly marketing material in Google results

• Good devs use it

• “Interesting” devs use it

• Bad devs use it

• Understanding apps is hard, let’s classify everything as bad and just blog!

“So good, even malware authors use us!”

Again - why should you care?

… WHY ARE WE HERE AT QUALCOMM?

• Malware… I mean “PHA”…

• Exploit devs

• Prevalence of Packers/Obfuscators

• OEMs making things “harder”

• Protecting the full ecosystem (or not?)

“So good, even malware authors use us!”

WHAT IS OUT THERE• Then -

• Dex Education 101 - Blackhat 2012 • Anti-decompilation tricks • Anti-analysis tricks • Demo/Release POC packer

• General Optimizers / Minimal Obfuscators

• A little bit after… • Integration of tricks, release of specific tools • One off tools targeting environments/toolsets

• Now - • Most anti-decompilation/analysis tricks fixed in mainstream tools

(baksmali, dex2jar, IDA Pro, radar) • Main stream commercial packers, protectors and obfuscates • Android Hacker Protection Level 0 - Defcon 2014

• android-unpacker (kiss-kiss / others) • Simplify

So - UPX and other stupid stuff?

PACKERS, PROTECTORS?

• Optimizers / Obfuscators • Good practice for debs • Removes dead code / debug code • Potentially encrypt / obfuscate / hide via reflection

public void onClick(DialogInterface arg7, int arg8) { try { Class.forName("java.lang.System").getMethod("exit", Integer.TYPE).invoke(null, Integer.valueOf(0)); return; } catch (Throwable throwable) { throw throwable.getCause(); } }

public void onClick(DialogInterface arg7, int arg8) { try { Class.forName(COn.ˊ(-‐COn.ˋ[0xC], COn.ˋ[0x12], -‐COn.ˋ[0x10])).getMethod(COn.ˊ(i1, i2, i2 | 6), Integer.TYPE) .invoke(null, Integer.valueOf(0)); return; } catch (Throwable throwable) { throw throwable.getCause(); } }



• “Protectors” • Classification similar to packers - manipulating “bad” code into workable

things post execution • Performs anti-analysis/emulator tricks

Stub application

Broken Code

1. Executed

Stub fixescode

Fixed Code

2. System/User events

3. Happy and normal



• Packers • Similar to UPX and others - launcher stub and unfolding main application

into memory • Performs anti-analysis/emulator tricks

Stub application

Hidden orEncrypted

actual code

1. Executed

Stub unpackscode

Stub application

Unpacked code

2. System/User events

3. Proxy via ClassPaths/etcto real code

SUMMARIES &PREVALENCE NOTES

OPTIMIZERS & OBFUSCATORS

Optimizers & Obfuscators

PROGUARD

• Recommended By Google forAndroid developers

• Optimizer

• Shrinker

• Obfuscator (barely)

• Cost: $FREE

• Bundled in Android SDK

• Most prevalent tool used in the wild

Java Code

javac

Java Class Files

proguard

Optimized/ShrunkClass Files

dx

classes.dex fileWhat we attackat the end


DEXGUARD

• Son of ProGuard

• Optimizer / Shrinker

• Obfuscator/Encryptor

• Cost: $650 - $1300

• Seemingly prevalent, “partial” leakin 2013 of ~200 licenses purchase…likely used much more

• Prevalent in “researcher” samples andsome malware cases

• Used in higher-profile malware samples

Java Code

javac

Java Class Files

dexguard

Optimized/Shrunk/ObfuscatedClass Files

dx



ALLATORI

• Optimizer

• Shrinker

• Obfuscator

• Watermarker

• Cost: $290

• Free Academic Version

• “Demo” version is prevalent specificallywith lower-grade malware-ish things

Java Code

javac

Java Class Files

Allatori

Optimized/Shrunk/ObfuscatedClass Files

dx



OBFUSCATOR LLVM

• Encrypter

• Obfuscator

• Cost: Free / FOSS

• PITA

• Made well known by TowlRoot, used in Chineseapplications and other rooting functionality apps < ~2k ITW

C code

clang llvm

elf lib / static

Bundled with APK

“PROTECTORS”

Protectors

APKPROTECT

• Chinese Protector

• Multiple iterations and rebrandings • DexCrypt

• “Appears” active

• Anti-debug / Anti-decompile

• Almost like a packer

• Cost: $Free - $Expensive (Site unfunctional)

• Prevelant use in China, lots (~100k+) of chargeware,trojans and weird things using this

Java Code

….

classes.dex file

desktop tool (?)

Stub application

Mangled Code

PACKERS

Packers

DEX2JARHOSER

• “POC” Packer

• Not viable for real use

• Appears defunct

• Near zero ITW samples

• Mimics “Dexception” attack from Dex Education 101

• Cost: Free (non-functional)

• Only ever used by researchers, < 10 samples ITW

Java Code

….

classes.dex file

Easiest attacksurface

Cloud Service

Stub application

Encrypted code(classes.dex)

Packers

PANGXIE

• Chinese Packer

• Anti-debug / Anti-tamper

• Packer itself appears to be repackaged itself ITW

• Appears to be defunct product

• Cost: ???

• Prevalence ITW very low < 300samples, mostly original gamesand broken “cracks”Lots of adware injected crap

Java Code

….

classes.dex file


???

Stub application


Packers

BANGCLE / SECNEO• Anti-debugging / Anti-tamper

• Anti-decompilation

• Anti-runtime injection

• Online only service • “APKs checked for malware before

packaging”

• Generically detected by some AVs due to risk

• Cost: ~$10k+

• “No one has done it before”

• Prevalence high in Asian countries,lots of SMS based malware and generic bad things Lots of adware and games ~100k+

Java Code

….

classes.dex file


App Approval&

Malware Check

Cloud Service

Stub application


Packers

NQPROTECT

• Anti-debugging



packaging” • Contains functionality to work in China only

• Cost: ???

• Used by many Adware, SMS based trojans andother Chinese based apps and games < ~2k apps

Java Code

….

classes.dex file


App Approval&

Malware Check

Cloud Service

Stub application


Packers

TENCENT PACKER

• Anti-debugging



packaging” • Only available in China

• Cost: ???

• Used by many SMS based trojans and other Chinese based apps and games < ~1k apps

Java Code

….

classes.dex file


App Approval&

Malware Check

Cloud Service

Stub application


Packers

NETON

• Anti-debugging


• Cost: ???

• Used by many Adware, SMS based trojans andother Chinese based apps and games < ~750 apps

Java Code

….

classes.dex file


App Approval&

Malware Check

Cloud Service

Stub application


Packers

LIAPP / MEDUSA

• Anti-debugging


• Aimed specifically for games

• Cost: ???

• Used by games - that’s pretty much itcombined < ~200 apps

Java Code

….

classes.dex file


App Approval&

Malware Check

Cloud Service

Stub application


OK, SO DO WE WORRY?

Don’t spend more time / money than your enemy does…

FIGHTING THESE TECHNIQUES

• Having systems in place helps, markers and identifiers

• Don’t poke the bears, less publicity means less variation (these slides, doh!) • Almost all are commercial tools, never fixed unless publicly broken or

high profile customer complains

• Relatively easy to get around, same rules as non-mobile protections

• Use better emulation environments/real devices gets around the main hurdles in dynamic analysis

• Out source the problem • github.com/strazzere/android-unpacking • unpack.cn • tweet it • drop it in #droidsec or #smali

http://github.com/strazzere/android-unpacking

http://unpack.cn

OEM / CHIPSETSIDE OF THE ECOSYSTEM

Not always normal app devs doing interesting things…

“GOOD GUYS TECHNIQUES”

• Turns out lots of people like to do crypto!

• Protecting ROMs / Preventing Modification (OEM brain child? Request from Carrier?)

• Attempting to evade people looking for root

• “Hide” sensitive data

“ALMOND” CRYPTO

Encrypted dex files!

LG G3 “ALMOND” CRYPTO

• Prevents System app modification

• Breaks Exposed/Substrate

• Needs to be decrypted separately

LGCover.apk classes.dex

Encrypted dex files!


• Modifications to PackageInstaller to accept crypto

• New shared library injected into every zygote

• New vector for bug hunting!

• Only meant for preloaded applications

• Circumventionpossible…

• Patching possible

• Sideload encrypting?

What’s the use?


• Everything is circumventable

• Doesn’t seem scalable, only updating outside of Google Play

• Each unique device firmware has a new key

• What is the purpose?

• Prevent system apk modification?

• Prevent ROMs?

• Why the new DRM?

FIRMWARE “UPDATING” VIA BACKDOORS

Original Vulnerability

FOTA / FOTABINDER

• Leaves socket open for root access

• Clear “backdoor” to allow updating

• Should never exist…

• Check for it added to CTS

Vulnerability Re-emerges

FOTA / FOTABINDER

• Not yet (ok, just now) publicly disclosedCVE-2015-2231

• Same style, shell, though gives you System UID

• Now with RC4 on socket communications and a new file name!

• New file/socket name evades CTS

• RC4 makes it… harder? no, no it doesn't

“Adapter for all major platforms”

Vulnerability Re-emerges

FOTA / FOTABINDER

• Interesting for the patching discussion…

• Evading CTS checks for vulnerabilities

• Lots of devices (Blu + others) not locked to OEMs or Carriers

• Who can enforce patching on these devices?

• Provided by Adups firmware upgrade - claims to be working with;

HIDING YOUR DIRTY LAUNDRY

If we obfuscate our vulnerabilities, surely no one will find them?

DISTURBING TRENDS

• Obfuscation may reduce memory usage

• Obfuscation makes analysis more costly

• Obfuscation deters some hackers

This code does not actually contain vulnerabilities, sorry to disappoint you.

If we obfuscate our vulnerabilities, surely no one will find them?

DISTURBING TRENDS

• In house analysis becomes more costly

• “Bad guys” only need to find one bug

• “Good guys” need to find all the bugs

• Selective obfuscation paints a target

• Useless, without proper configuration

This code does not actually contain vulnerabilities, sorry to disappoint you.

Backdoors need deadbolts too

ENTOURAGE EDGE

• Disabling USB debugging is silly

• Local “encryption” doesn’t work

• Debugging features are a risk

• ro.secure=1 is important

Psst, the password is 89985b36B7906bFfF

2013, Many vulnerabilities exposed through dialer codes in Android devices

DIALER CODES

• ZTE Avail

• Dialing *983*7668# exposes vulnerabilities

• Can dial with intents

• Leaves /system writable

• Exposed a symlink attack to gain root

• Quickly fixed by ZTE in 2012

2015, OEMs still using dialer codes to enable diagnostic/debugging features

DIALER CODES

• Fewer diagnostic dialer codes

• Less blatant vulnerabilities

• Still accessible from other apps

• Now with obfuscation!

ZTE ZMax, one of the more secure prepaid devices

Common advice to developers, is to write key portions of code as a native library

NATIVE != OBFUSCATION

ZTE ZMax, some dialer codes processed through a native library

String encryption is obnoxious, and slows my automated analysis :(

NATIVE OBFUSCATION

Well hello to you too!

• Analysis of native code is more costly

• Fewer people analyze native android code

• Not all dialer codes are plaintext now

• Nice greeting from ZTE, they expected us!

Native libraries can be reversed, and exploited as well

NATIVE IS NOT THE SOLUTION

• Very simple string obfuscation

• Offset each byte of the dialer code with code length

• Hides dialer codes from a simple grep

• Does not prevent analysis

• Requires developer to now maintain two sets of code

Consider the costs, is it worth doing?


• Obfuscation easily reversed

• Few benefits

• Increased code complexity

• Increased memory usage

• Barely slows us

• Doesn’t stop us

So many codes, so little time :(


• 101 Obfuscated dialer codes uncovered

• What do they do? I don’t know!

• Any vulnerabilities? I don’t plan to check!

No vulnerabilities associated with these codes are known

One password please

PROTOCOL OBFUSCATION

• Multi-purposed daemon running as root

• Comm. over Unix or TCP socket

• All communication is encrypted

• Encryption key is different per device

• Key is derived from ESN/MEID/IMEI

This vulnerability was fixed in 2014

One password please


• Client is not obfuscated

• Standard AES encryption

• Password not in client


One password please


• Server willingly provides encryption key when nicely asked


One password please


• Encrypted Command: 73F333C103CE37F223B8741166861BFFCDA559CD44D9159DDBB7E16FDE653DBEEF0B2479AD146D615164513A8B6F152EA45FAF356A0F3EC7A40E30A1078DB80E94862B0BE164017EF9FDFF02DBF61CEC5A93B8AA7011F3E8A09B763B1B162B8C7086588B217E293AB1A8FBAD20BC7A27

• Plaintext Command: :DMD:CPFILE:/data/data/:../system/password.key:/data/data/com.test.test1:../../../sdcard/password.key

• Read/Write to any file, with just the internet permission


The darkside has cookies

COMMERCIAL TOOL OBFUSCATION

• Custom hardware

• PC side software

• Device side software

• Blackmail

• Theft

• Hacking

The darkside has cookies

COMMERCIAL TOOL OBFUSCATION

• Highly packed PC software, makes analysis difficult (Themida etc)

• Custom hardware, requires additional skills to analyze

• Easier to just dump USB traffic, ignore PC side software

04.30.2015

THANKS!TIM “DIFF” STRAZZERE JON “JUSTIN CASE” SAWYER

Qualcomm Mobile Security Summit

@TIMSTRAZZ @JCASE

Join us on Freenode on #droidsec

Good people to follow on twitter forAndroid/reversing/malware/hacking information;

@jduck @Fuzion24 @Gunther_AR @caleb_fenton @thomas_cannon@droidsec @marcwrogers @osxreverser @cryptax @pof @quine

@0xroot @Xylitol @djbliss @saurik @collinrm @snare#MalwareMustDie

ANDROID APP “PROTECTION” - strazzere.com · ANDROID APP “PROTECTION ... (kiss-kiss / others)...

Documents

Transcript of ANDROID APP “PROTECTION” - strazzere.com · ANDROID APP “PROTECTION ... (kiss-kiss / others)...