Android Hacking Village

ANDROID HACKING VILLAGE ANKUR | MRIGESH | ANANT

WHOAMI

TOPICS Day 1 : Basics Day 2 : Advanced • Android Architecture • Operating System Overview • File system Overview • Security Model • Malware Analysis and Design • Exploits survey • Common malware samples • Detection, prevention and cure • Developer Overview • Application Components • Application Structure • The SDK and Android Tools • Developing a basic application • ROM cooking • Rooting basics • Simple Mods • Mid-range Mods • Hardcode Cooking • Intro to PenTesting • Setting up the environment • Advanced Pentesting and Forensics • Black Box PT • Reverse Engineering • Memory Analysis

Android Arrives • Android Inc. founded in 2003 in Palo Alto, California by Andy Rubin, Rich Miner, Nick Sears and Chris White. • Acquired in August 2005 by Google Inc. Key employees retained. • Design continued on a Linux powered mobile device. Marketed by Google to carriers as a flexible and easily upgradable OS. • On November 5, 2007, a consortium of mobile operators, software companies commercialization companies, semiconductor companies and handset manufacturers formed the Open Handset Consortium, with the stated aim of developing open standards for mobile devices. • On the same day, they released their first product …. • …. Android.

Android – An Introduction • A software stack for mobile devices. • Linux-based kernel. • Middleware, libraries and APIs in C. • Java-based application framework. • Custom Dalvik virtual machine with a JIT Java compiler. • Applications coded primarily in Java.

Android – An Introduction

ANDROID ARCHITECTURE (FILESYSTEM OVERVIEW) •Android Devices generally contain the following mounts / ro The root. Cannot be accessed in normal scenarios. /system ro Contains the core binaries and enforced APKs /data rw Contains installed packages /proc rw /mnt/sdcard rw SD Card mount location /mnt/sdcard/asec rw Secure storage for APKs on SD Card

ANDROID ARCHITECTURE (FILESYSTEM OVERVIEW) • Some important folders on a typical Android device: /system/app ro /system/framework ro /data/app rw /data/data rw /sdcard/asec rw

Android - Security Model – The Good • Traditional Access Control Idle-time/ one-click phone locking • Isolation (Sandboxing) Every application runs within its own VM, and each VM is in a unique Linux process. No process can access the resources of any other process. • Permissions based access control (Application-defined and user-granted) Developer configured whitelist for accessing Android and 3rd party resources. Can also enforce permissions preventing unauthorized components from executing app. • Application Provenance Applications signed using a X509 digital certificate. $25 charge for uploading app onto Android market. • The Kill Switch Allows remote kill, uninstall and data cleanup

Android - Security Model – The Bad • No hardware-based encryption • No non-executable memory area • Limited Developer Accountability • Poor Code Obfuscation options • Applications can easily be ‘trojanized’ • Difficult environment for anti-virii • Long Patch cycle • Recovery/Boot process • Security enforcement reliant on end-users

Android - Security Model – Updates • 2.2 (Froyo) • Built-in remote wipe capability. • Built-in 4-digit-pin and alphanumeric password options for enterprise security. • Enterprise security additions like remote-wipe, device admin and password protect. • 2.3 (Gingerbread) • In certain architectures (ARMv6), Android supports non-executable pages by default including non-executable stack and heap using an eXecute Never bit. • 3.0 (Honeycomb) • Android after 3.0 provides full filesystem encryption • 4.0 (Ice Cream Sandwich) • Introduced face-unlock • Introduced WiFi Direct as well as data sharing via NFC using Android Beam.

Android Applications - An Introduction • Android installables are known as Application File Packages (APKs) • ZIP-formatted packages based on the jar file format • An APK is a collection of components. The components share certain resources. • These include a Linux process, a JVM, SQLite DBs, Shared Preferences, a File Space… • An APK also contains a store of other non-code resources

Android Applications - Structure

Android Applications – The SDK • Includes a vast array of development tools. • The officially supported IDE is Eclipse using the Android Development Tools Plugin. *You may also use any text editor along with various command-line tools to build and debug apps as well as connect to an emulator/device. • ADT includes a suite of tools that can be easily integrated with Eclipse’s IDE. Some important ones are.: • adb • android • DDMS • emulator • logcat • ProGuard • ADT controls synchronizes all the above tools with as many devices (real/virtual) as you can connect to.

Android Applications – Building a sample app [THE COMPONENTS] • Activities • UI component for one focused task. • Usually a single screen in your app. • Stack-based lifecycle • Services • Long-lived worker code. No UI. • Can be connected to using Binder. • Intents • Mechanism for IPC. • Defined using an Action/data pair • Intent Filters • Describes what intents a comonent can handle • Registers activities/services/receivers. • Broadcast Receivers • Responds to broadcast intents • Must be declared in manifest/code • Content Providers • Manages Persistent Data • Publishes it to other apps • Shared Preferences • Persistent data stored as name-value pairs • Uses-Permissions • Describes permissions used by your app • Permissions • Restricts access to your components

Android Applications – Building a sample app [GUI BUILDING] • Layouts are defined in XML (similar to Swing) • In Android, we implement the Activity interface in Java. • We need to overwrite a single function, i.e. onCreate() • XML layouts are later expanded into Java to generate a UI. • This is done using setContentView(Reference.to.the.XML.file) • Any controls defined in your XML layouts can be referred to in Java by their ids using the findViewById() function. • For each view, a set of event listeners and responders can be defined.

Android Applications – Building a sample app [COMMON ERRORS] • Build path error. • AAPT unable to parse • Invalid Imports • Component unimplemented in manifest • Attempting to access without taking the required permissions • Expired debug certificate

Mobile Application Penetration Testing Web Application Testing Mobile Testing Application/Business Logic not present locally. App stored in the device. No database present locally. Except cookies,cache App do store some data in device to increase the performance. All apps run in browsers Need to install emulators for each platform Reversing not Applicable Applicable as installable is inside the device itself. Read more

Android – Setting Up a PT Lab o Setting up the environment o Using proxy tools o Using Echomirage o Using Autoproxy o Android Debugging tools o adb o Ddms o Reversing Android Apps o apktool, baksmali, dex2jar

TOPICS Day 1 : Basics Day 2 : Advanced • Android Architecture • Operating System Overview • File system Overview • Security Model • Malware Analysis and Design • Exploits survey • Common malware samples • Detection, prevention and cure • Developer Overview • Application Components • Application Structure • The SDK and Android Tools • Developing a basic application • ROM cooking • Rooting basics • Simple Mods • Mid-range Mods • Hardcode Cooking • Intro to PenTesting • Setting up the environment • Advanced Pentesting and Forensics • Black Box PT • Reverse Engineering • Memory Analysis

Android Threat Model THREATS • Remotely Infect via Market/Browser VULNERABILITIES • Insecure storage • Privilege escalation attacks • Insecure IPCs • User tracking • Insecure component starting • Data stealing • Insecure WebKit • Resource misuse MALWARE FOR THE FUTURE Botnet Capabilities Application Harvesting Key Loggers

Android Malware facts •Reports say that chances of an android phone being compromised is 2.5 times more than any other platform. •Count of new Android-specific malware moved to number one, with J2ME (Java Micro Edition), coming in second while suffering only a third as many malware.

Android Malware •Increase in for-profit mobile malware, including simple SMS-sending Trojans and complex Trojans that use exploits to compromise smartphones •Mobile threats already take advantage of exploits, employ botnet functionality, and even use rootkit features for stealth and permanence. •Maliciously modified apps are still a popular vector for infecting devices: Modify a legitimate app or game and users will download and install malware on their smartphones by themselves.

Android- Popular Malware Apps Falling DownSuper SoloSuper History EditorSuper RingtoneMaker SupersexPositions HotSexyVideos FallingBallDodge Scientific Calculator APPUninstaller Funny Paint AdvancedCurrencyConverter Guitar EraserPhoto Chess Falldown Dice Roller Spider Man

Android- Popular Malware Ò The Android/DrdDream infected over 50+ apps in google market. Included root exploits and installed one more application in system/app. It uses DES to encrypt the data it sends to the attacker. Ò The Android/DroidKungFu family is similar to Android/DrdDream; it also uses a pair of root exploits to maintain itself on a device.The exploits are actually identical to those used by the Android/DrdDream except they have been encrypted with AES. These variants can also load URLs and install additional software and updates.

Android- Exploits Ò KillingInTheNameOf Affected Android <= 2.2 É Remapped Android property space to writable É Vulnerability in Ashmem implementation É Applications having permissions to change shared properties. É Toggled ro.secure property to 0 É ADB Daemon now runs as root É Physical local root through ADB shell É

Android- Exploits Ò RageAgainstTheCage É Affected Android <= 2.2 ADBd initially runs as root and use setuid() to move to uid shell Ð If NPROC resource limit is reached for uid shell, Ð setuid() from uid root to uid shell will fail Ð If setuid() fails, ADBd continues running as root Ð If ADBd runs as root, ADB shell also runs as root Ð É Fork()’s processes as shell user until NPROC is reached Ð Restart ADBd (bringing uid shell to NPROC-1) and fork()again (as uid shell) right before ADBd (as uid root) tries to setuid() back to uid shell, setuid() fails, Rage wins

ROM AND ROOT ANKUR | MRIGESH | ANANT

AGENDA Custom v/s stock Ò Types of Modding Ò É Simple Mod : GUI element modding + automated É Mid level mod : decompiling, reversing. É Hard Core : cross compiling, drivers modding Rooting Fundamental’s Ò How Exploits Work Ò

CUSTOM ROM V/S STOCK ROM Stock Rom are build for generic usage and large masses, they are non rooted by default. Ò Custom ROMs Ò É can have variants like Gaming ROM Ð Battery Saver Ð Overclocking, Undervolting etc. Ð Bleeding edge É Pre-Rooted É

SIMPLE MODDING Ò Removing unnecessary /system/app More free space. É Faster system (low ram consumption) É Ò Adding general usage applications as system app. É Disadvantage : your updates will take dual space. Removing/replacing av files, animation etc Ò Changing the GUI elements. Ò

Simple Modding DEMO TIME

MID LEVEL MODDING This is where we start getting serious J Ò Application decompiling and reversing to modify default behavior of application. Ò Application will include CORE Applications also. Ò Focus area’s Ò É /system/app É /system/framework

Mid Level Mod DEMO TIME

HARD CORE MOD This is where we start getting serious J Ò Application decompiling and reversing to modify default behavior of application. Ò Application will include CORE Applications also. Ò Focus area’s Ò É /system/app É /system/framework

Simple Modding DEMO TIME

HOW ROOTING WORKS Ò Simplest Allow user to have root access Temporary and É Permanent É Temporary root, Exploit an application gain root access Ò Permanent make abover condition permenent by installing a backdoorr Ò SU and SUPERUSER.apk Ò Review su source code Ò

Questions?

CONTACT US Ò Anant Srivastava Email – anant@anantshri.info Blog – http://anantshri.info Ò Ankur Bhargava Email – ankurbhargava87@gmail.com Blog – http://www.hakers.info Ò Mrigesh Email – me@mrigesh.com

Appendix : Androidisms & the Component Model • Binder à Component Framework • Ashmem à Anonymous Shared Memory • Activity àUI • Pmem à Physical Memory Allocation • Service à Background Processing • ROM à Refers to /system folder • Content Providers à Data Sharing • Stock ROM à Pre-installed Android OS • Broadcast Receivers à Listener • Custom ROMà Unauthorized Modded OS • Intents à IPC/ICC • Rooting à a • Manifest àMetadata • ADBà a • Permissions à Ensures authorization • API Levels à Separate Android Versions