Android Application Security
•
4 likes•1,223 views
This document discusses program security for Android apps. It begins with an introduction of the speaker and covers topics like Android architecture, app threat models, app components like activities and intents, data storage security, cryptography, injection attacks, and reverse engineering defenses. The document provides examples of real security issues from apps like LinkedIn and Pandora and offers tips to defend against various threats like improper data handling, insecure communication, and client-side injection.
Report
Share
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
Similar to Android Application Security
Similar to Android Application Security (20)
Recently uploaded
Recently uploaded (20)
Android Application Security
- 1. Program Security of Android APP C.K.Chen 2014.09.02
- 2. Who am I • 陳仲寬 – 交通大學網路安全實驗室博士生 – 資安公司講師及顧問 • 經歷 – 全國大專軟體設計競賽第二名 – 2014台灣駭客年會講師 – 2014HITCON CTF BambooFox團隊世界第九名 – 多次參與國內外駭客競賽
- 3. Outline • Some news about android app security • Android Architecture • Android APP threat model • Android APP architecture and basic concept • OWASP TOP 10
- 4. •
- 5. •
- 6. Secure Program • These problem is not about Android system or malicious app • VulnerabiliKes made by programmer – Wide range of users – Best backdoor for aMacker
- 8. Android APP Threat Model •
- 10. Manifest • Manifest files are the technique for describing the contents of an applicaKon package (i.e., resource file) • Each Android applicaKon has a special AndroidManifest.xml file (included in the .apk package) – describes the contained components • components cannot execute unless they are listed – specifies rules for “auto-‐resoluKon” – specifies access rules – describes runKme dependencies – opKonal runKme libraries – required system permissions
- 11. •
- 12. Intent • AcKviKes, Services, and Broadcast Receivers are acKvated through intents. • What is an Intent? – Message (Bundle of informaKon) – Facility for late run-‐Kme binding between components – Passive data structure describing an operaKon to be Performed – DescripKon of something that has happened and is being announced
- 13. OWASP Top 10 Mobile Risks •
- 14. Server Site Communicate • M1: Weak Server Side Controls M5: Poor AuthorizaKon and AuthenKcaKon M9-‐ Improper Session Handling • Must app need server for cloud storage or computaKon power • Client must be authenKcated carefully – Any input from network may be spoofed and therefore untrusted – All data that is inpuMed into the applicaKon either directly or indirectly by an outside source needs to be properly validated
- 15. 15 AuthenKcaKon • Part mobile, part architecture • Some apps rely solely on immutable, potenKally compromised values (IMEI, IMSI, UUID) • Hardware idenKfiers persist across data wipes and factory resets • Adding contextual informaKon is useful, but not foolproof
- 16. 16 Server Site Communicate • Mobile app sessions are generally MUCH longer • Why? Convenience and usability • Apps maintain sessions via • HTTP cookies • OAuth tokens • SSO authenKcaKon services • Bad idea= using a device idenKfier as a session token Impact • Privilege escalaKon • Unauthorized access • Circumvent licensing and payments
- 17. 17 Server Site Communicate tIPS • Don’t be afraid to make users re-‐ authenKcate every so oden • Or at least set the Kmeout • Ensure that tokens can be revoked quickly in the event of a lost/stolen device • UKlize high entropy, tested token generaKon resources • Not use determinisKc token generator
- 18. Google ClientLogin • AuthorizaKon header sent over HTTP • When users connected via wifi, apps automaKcally sent the token in an aMempt to automaKcally synchronize data from server • Sniff this value, impersonate the user
- 19. IPC as AMack Vector • M8, Security Decisions Via Untrusted Inputs • Android IPC is mainly through Intent • It is possible that an AcKvity can receive data from an Intent that was tampered by an aMacker. – Sending data with a format or a value that a programmer is not expecKng – Bypass authenKcaKon, inject aMacker’s code
- 20. Intent • It is possible that an AcKvity can receive data from an Intent that was tampered by an aMacker. – Sending data with a format or a value that a programmer is not expecKng – Bypass authenKcaKon, inject aMacker’s code
- 21. AcKvity • When using AcKviKes that are only used within the applicaKon (Private AcKvity), – Explicit Intents to the class may be forged – Configure AcKviKes as private
- 22. CVE-‐2013-‐6272 • The aMacker can send the forge intent – Make phone call – Kill current phone call
- 23. IPC AMack PrevenKon • Carefully set content filter • AcKvity access control
- 24. Data Storage • M2: Insecure Data Storage M4: Unintended Data Leakage • SensiKve data led unprotected • Applies to locally stored data + cloud synced • Generally a result of: • Not encrypKng data • Caching data not intended for long-‐term storage • Weak or global permissions • Not leveraging plamorm best-‐pracKces
- 25. Data Manage by Android System •
- 26. Data Manage by APP • we must be aware that a smartphone not only contains informaKon on the user, but of other people too.
- 27. EVERNOTE • Caches some files on the device
- 28. MyFitnessPal • Android app stores sensiKve data on the device (SQLITE Database)
- 29. Data Storage • Minimize the data stored in external storage • Leave every things in storage in cypher text • Clean unused data
- 30. Using Cryptography • M3: Insufficient Transport Layer ProtecKon M6: Broken Cryptography • Complete lack of encrypKon for transmiMed data • Yes, this unfortunately happens o#en • Weakly encrypted data in transit • Strong encrypKon, but ignoring security warnings • Ignoring cerKficate validaKon errors • Falling back to plain text ader failures
- 31. LinkedIn • SSL only for authenKcaKon ! • Session tokens and data sent over HTTP
- 32. Pandora • RegistraKon over HTTP ! • User name/Password and RegistraKon info sent over clear text
- 33. Cryptography • CommunicaKon though encrypted tunnel • Argument used for Cryptography FuncKon • Take care about Warning message of Cryptography tools
- 34. SQL/Command InjecKon • M7. Client Side InjecKon • Server Site/Client Site InjecKon
- 35. Client Site InjecKon • Apps using browser libraries • Pure web apps • Hybrid web/naKve apps • Some familiar faces • XSS and HTML InjecKon • SQL InjecKon • New and exciKng twists • Abusing phone dialer + SMS • Abusing in-‐app payments
- 36. 36 Client Site InjecKon • Garden Variety XSS…. With access to:
- 37. 37 Client Site InjecKon Preven)on Tips • SaniKze or escape untrusted data before rendering or execuKng it • Use prepared statements for database calls…concatenaKon is sKll bad, and always will be bad • Minimize the sensiKve naKve capabiliKes Ked to hybrid web funcKonality Control# Descrip/on 6.3 Pay parKcular aMenKon to validaKng all data received from and sent to non-‐trusted third party apps before processing 10.1-‐10. 5 Carefully check any runKme interpretaKon of code for errors
- 38. Reverse Engineering • M10: Lack of Binary ProtecKons • While android app is inform of Dalvik bytecode – More easy to reverse to Java code – More informaKon are provided • Leak sensiKve informaKon • More easy for aMacker to exploit
- 39. Tip Defense Reverse Engineering • Turn off debug message • Use Obfuscated Tool • Not use hardcode secret
- 40. Source Code Analysis • Find the potenKal bug in the program – Structure – Data Flow – Type Inference – SemanKc analysis – PaMerm
- 41. Tools • ForKfy SCA • PMD • Checkstyle • FindBugs • JLint
- 42. Summary • Some news about app security • Android Arch – APP Threat – APP Architecture – Basic Concept • OWASP TOP 10 – Real case – Tips
- 43. Q&A