Upload
-
View
415
Download
5
Embed Size (px)
DESCRIPTION
Describe the common vuln of android app
Citation preview
Program Security of Android APP
C.K.Chen 2014.09.02
Who am I
• 陳仲寬 – 交通大學網路安全實驗室博士生 – 資安公司講師及顧問
• 經歷 – 全國大專軟體設計競賽第二名 – 2014台灣駭客年會講師 – 2014HITCON CTF BambooFox團隊世界第九名 – 多次參與國內外駭客競賽
Outline
• Some news about android app security • Android Architecture • Android APP threat model • Android APP architecture and basic concept • OWASP TOP 10
•
•
Secure Program
• These problem is not about Android system or malicious app
• VulnerabiliKes made by programmer – Wide range of users – Best backdoor for aMacker
Android Architecture
Android APP Threat Model
•
Android APP Architecture
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
•
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
OWASP Top 10 Mobile Risks
•
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
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
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
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
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
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
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
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
CVE-‐2013-‐6272
• The aMacker can send the forge intent – Make phone call – Kill current phone call
IPC AMack PrevenKon
• Carefully set content filter
• AcKvity access control
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
Data Manage by Android System
•
Data Manage by APP
• we must be aware that a smartphone not only contains informaKon on the user, but of other people too.
EVERNOTE
• Caches some files on the device
MyFitnessPal
• Android app stores sensiKve data on the device (SQLITE Database)
Data Storage
• Minimize the data stored in external storage • Leave every things in storage in cypher text • Clean unused data
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
• SSL only for authenKcaKon ! • Session tokens and data sent over HTTP
Pandora
• RegistraKon over HTTP ! • User name/Password and RegistraKon info sent over clear text
Cryptography
• CommunicaKon though encrypted tunnel • Argument used for Cryptography FuncKon • Take care about Warning message of Cryptography tools
SQL/Command InjecKon
• M7. Client Side InjecKon • Server Site/Client Site InjecKon
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
Client Site InjecKon
• Garden Variety XSS….
With access to:
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
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
Tip Defense Reverse Engineering
• Turn off debug message • Use Obfuscated Tool • Not use hardcode secret
Source Code Analysis
• Find the potenKal bug in the program – Structure – Data Flow – Type Inference – SemanKc analysis – PaMerm
Tools
• ForKfy SCA • PMD • Checkstyle • FindBugs • JLint
Summary
• Some news about app security • Android Arch – APP Threat – APP Architecture – Basic Concept
• OWASP TOP 10 – Real case – Tips
Q&A