Exploiting Android - Draft v1.pptx Why are we so interested in Android?   The App market is like the wild, wild, west. Open, accessible, unrestricted.   No need to coerce a user to download your app and install it from a remote website.   Permission based security model is new and puts the average consumer in charge of the critical security decision making process.  Apps are not adequately reviewed before being placed on the market for public consumption. Android Marketplace (The biggest W@r3Z site in the world) (Besides third party markets…) Permission Model  Users are prompted with a permission list that is at best vaguely described, even in SDK documentation. “READ_PHONE_STATE - Allows read only access to phone state.” Might be better to say: “…is a permission that grants the application to read your unique cell phone serial, phone number, SIM card serial number, and much more!” Impersonation  Apps vendors are not validated.  Malicious developers can publish apps that masquerade as legitimate products.   Jon Oberheide provided an entertaining example. (RootStrap - Twilight) Risks to Android Users  Malware  Autorun  WiFi   Phishing  Rootkits  Botnet Node  Network Traversal   Jailbreaking Malware  Don’t believe everything you read. In the press. It’s not that bad. At least for the Android Market…  Android malware is advancing in sophistication much faster that on previous computing platforms.   Introducing “Trend Trojans”. Malware - Protecting yourself   Things to look for when selecting apps for your mobile device: ◦ Has the app been on the market for more than 90 days? ◦ Does the app have decent ratings? ◦ Developers a well known and respected? ◦ What permissions is the app asking for? Autorun  Apps run without being “Clicked”.  Apps can be invoked from automated system events.  Since security apps typically scan post install due to framework limitations this leaves a window open for attackers to exploit. WiFi Hazards   Many apps do not encrypt your data beforing rifling them to backend servers.   Most public access WiFi AP(s) are not encrypted.   Even the phone is not in use many apps auto-sync in the background.   Hackers can hijack your app accounts! ◦  See FaceSniff WiFi Hazards – Protecting Yourself  Uncheck connect when within range features.  Disable any other auto connect functionality. App Phishing   Rogue apps can masquerade as legitimate apps you trust.   App waits for activity (UI Element) of interest to spawn.   Phishing app will then overlay it’s own interface, tricking the user into entering sensitive information into the phishing app. Think “clickjacking” for Droid App Phishing - Demo App Phising – Protecting Yourself   Exercise caution when granting apps these permissions: ◦ READ_LOGS ◦ GET_TASKS   Phish apps will usually be unable to populate the fake login screen with *saved* credentials. Rootkits   Proof-of-Concepts have been around for a while, see: ◦ DEFCON 18 Spiderlabs Android Rootkit   None currently reported in the markets. At the moment we’ve only seen them coupled with 0day for targeted attacks.   Apps can utilize jail break exploits to gain root privileges and install them. Rookits –Protecting Yourself  No recommendations at this time.  Rootkit on your mobile == you SOL Botnet  A few proof of concepts frameworks have circulated in the last several months.   Imagine an army of mobile phones configured to listen to background noise, translate to text and target keywords, perform voiceprints, all why tracking an individuals every move with a live video feed. Enter Mobile Echelon. Botnet – Protecting Yourself  Usually deployed from malware.   Exercise caution when installing apps (as discussed in prior malware section). Traversal Physical Boundaries   Interesting attack variation supplied by mobile computing platforms.  Compromised mobiles can be used to attack each network that the mobile gains access to. Traversal Physical Boundaries – Protecting Yourself   Disable “connect when within range” features   Exercise caution when installing apps.   Consider installing a firewall app. Hackers fail to plan for security products.   Checkout Anti app from Itz. Metasploit for Android ;) Jailbreaking   Su apps default to implicitly allow current and future process attempts for root escalation.   Majority of jailbreak users trust shell (bin/ sh).   Malicious apps can simply invoke the shell from their app and “su” to root without prompting user. Jailbreaking – Protecting yourself  Don’t jailbreak your phone until a better escalation solution is available.  When asked to approval an app for escalation uncheck the “remember” checkbox. . eking»Android y ote / #- AZ ~=s 2 ,2* _— ~~ o°™= — fe 8 ae -. ~ - _ » al fon . — a “ we @e * * red cee & t'< we A _ - eS . “~~ ". : e - = _ Pe ne — os : wis See y * =x. “»¥ ~~. — ee b jee To) & +o * enn — *. ”~ *« fendi @ + ewe ~ Tr ot emer « _ ~ we tad _ ky -—_ Se an LC ow ma bh momma le ‘ « \ =A 16 eet aad 0 , = ' ' Your Toolkit   DEX2JAR – Convert compiled DEX object code to a JAR that can be decompiled with JAD.   APKTOOL – Disassembler and binary xml translator built in. Produces Jasmin like syntax that can be reviewed by your favorite editor. Also supports apk rebuilding.   DED (http://siis.cse.psu.edu/ded/) – Decompiler for Android DEX that while requires a little more setup but provides much more reliable results than other decompilers. Your Toolkit - cont  Source Insight – Industry favorite code analyzer. You can create custom SMALI/ JASMIN parsers to visually render your code as your desire.  010 Editor – Fantastic hex editor. Also supports templates.   IDA – The only tool for examining machine code. Cough up the cash, you need it ;) Your Toolkit - cont  Ubuntu 64bit Install ◦ You’ll need this to build your own source so you can hack with symbols.  Android Prebuilt binaries ◦ gdbserver ◦  tcpdump ◦  strace ◦ Busybox ◦ bash ◦ valgrind Things to look for…  Android Permissions  Activity Reuse  SQL Injection  XML Injection   Package Name Trust   Traversing Webviews   Info Leaks Android Permissions   Requested permissions offer us a valuable first stab at an attack surface area assessment, e.g.: ◦  READ_LOGS – What happens when malicious log entries are injected into the system logs? ◦  INTERNET – MITM/Leak Potential ◦  RECEIVE_SMS  Can they app be exploited with a text message? Norton Security 2.2.0.305   Feature allows “buddy” to remotely lock, locate, and wipe your phone in case of theft. Requires origin phone number and password.   SMS Message Syntax: cmd password, e.g. ◦  “lock SecretPassword” ◦  “locate SecretPassword” ◦  …   SMS origin is easily spoofed (if buddy system worked as intended). Norton Security - Cont   Buddy verification is broken, anyone can issue remote commands.   No password strength guideline and phone.   Limit for failed SMS authorization failures is not in place.   User is not warned of failed attempts. Activity Reuse   Exported app Activities can be invoked by external app: ◦ Activity exported by declaring the “android:export” attribute on the Activity ◦ Activity applied an Intent filter (“intent-filter”). ◦ Activities that do not utilize either of these are traditionally considered private and are not accessible. Privateer Labs performed a review of 618 apps that contained a total of 3592 Activities. Activities Survey Exported Activities Requiring Permissions Total Activities Unprotected Activities This yielded 2176 Activities that do not enforce permissions and are publicly accessible. Activity Reuse in Skype  Reported earlier this year. We can make phone calls without the needed permission! SQL Injection  Android developers are recommended to use the parameterized query options to mitigate the risk of SQL Injection.  …Although many developers build string queries via the execSQL() method. XML Injection   Preferred by new developers (vs SQLite)  App developers rarely sanitize XML input.  Began researching potential for XML injection when I found an example in one of my apps… We all make mistakes ;) XML Injection - Cont   Input sources typically user supplied and therefor should not be trusted.  Android SharedPrefs properly encode problem characters  Validation   Test values were pushed to app.  App was installed onto the Android phone.   Then pulled and examined to verify the lack of secondary encoding on special values XML Injection Multiple key fields in the app manifest do not filter special characters: XML Validation – Android SDK  Reported to Android Security team.  Since reporting a new SDK has been published that does not allow characters used in XML injection, e.g. ‘>’ to be supplied in ApplicationManifest fields.  Attackers can still add these fields using other means…  Package Name Trust   Two package names cannot exist on the market at the same time.   Don’t assume that package names can be trusted.   Packages are sometimes deployed by vendor and not placed on the market.   Packages name may be available on another (third party) market. Package Name Trust  HeroLED  ◦ https://market.android.com/details? id=com.mclaughlin.HeroLED&rdid=com.mclaug hlin.HeroLED&rdot=1&pli=1  Advanced Task Killer has a feature to ignore “trusted” packages when displaying the task list to the user. Package Name Trust   If we were evil we would have published names of every possible app we could think off so we could “squat” them.  Android package squatting… to be continued. Traversing Webviews  Rich content apps relying on web views.  Separate store than the browser.   Prevents browser based XSS, CSRF, etc…   These remote app web views can be accessed. Traversing Webviews  BROWSABLE Traversing Webviews - Cont   In this scenario “schemehandler” is an activity that receives the browse intent and acts on it. Often this is simply a Web View request containing data supplied by the user. E.g.: httpx://user?add=