Top 10 mobile security risks - Khổng Văn Cường

1. TOP 10
MOBILE SECURITY RISKS
#SCB 2014
Presenter: Khong Van Cuong

2. AGENDA
• Introductions
• Mobile Threat Model
• OWASP Top 10 Mobile Risks
• Demo
• We have Q&A

3. INTRODUCTIONS
• The OWASP Mobile Security Project:
• Give developers and security teams the resources to build
and maintain secure mobile applications.
• Classify mobile security risks and provide
developmental controls to reduce their impact or
likelihood of exploitation.

4. MOBILE THREAT MODEL

5. MOBILE THREAT MODEL
Web
APPS
OS
Hardware
Coporate
Networks
Web Services
Websites
App Stores
Cloud Storage
SMS
Voice
Misc
- Carrie Network
- Local Network
(Wifi, VPN, etc)
Hardware
extensions

6. Improper Session Handling
Spoofing
Social Engineering
Weak Authorization
Weak Authentication
Malicious Application
Malicious QR code
Missing device Toll Fraud
Repudiation
Client side injection
Malware
Crashing Apps Push notification Flooding
Denial of Service
Excessive API Usage DDoS
Tampering
Carries network Breach
Modifying Local Data
Insecure Wifi network
Information
Reverse Engineering Apps
Disclosure Malware
Loss device
Backend Breach
Elevation of
Privilege
Sandbox Escape
Rooted/Jailbroken
Compormised Devices
Flawed
Authentication
Weak Authorization
Rootkits
Compromised
Credentials
Masks
Unauthorized
Purchases
Puss Apps
Remotely
6

7. TOP 10 RISKS

8. Top 10 Risks 2014 Updated
OWASP MOBILE TOP 10 RISKS
M1 – Weak
Server Site
Controls
M2 – Insecure
Data Storage
M3 – Insufficient
Tranport Layer
Proctection
M4 – Unitended
Data Leakage
M5 – Poor
Authorization and
Authentication
M6 – Broken
Cryptography
M7 – Client Side
Injection
M8 – Security
Decisions via
Untrusted inputs
M9 – Improper
Session Hijacking
M10 – Lack of
Binary Protections

9. M1 - WEAK SERVER SIDE CONTROLS
• The attack vectors correspond to the same attack vectors
available through the traditional OWASP Top Ten.
• Existing controls may need to be re-evaluated.
• We still can’t trust the client.

10. M1 - WEAK SERVER SIDE CONTROLS
End user
Web Application Backend
Attacker Attacker

11. M1 - WEAK SERVER SIDE CONTROLS
OWASP WEB TOP 10 - 2013 OWASP CLOUD TOP 10

12. M2 - INSECURE DATA STORAGE
• Confidentiality of data lost, credentials disclosed.
• Privacy violations, materials loss, Etc.
• Generally a result of:
• Lack of Data Protection method.
• Weak or global permissions.
• Not leveraging platform best-practices.

13. M2 - INSECURE DATA STORAGE (CONT)

14. M2 – PROOF OF CONCEPT
• Video.

15. M3 - INSUFFICIENT TRANSPORT LAYER
PROTECTION
• Complete lack of encryption for transmitted data.
• Weakly encrypted data in transit.
• Strong encryption, but ignoring security warnings:
• Ignoring certificate validation errors.
• Falling back to plain text after failures.

16. M3 - INSUFFICIENT TRANSPORT LAYER
PROTECTION

17. M3 - INSUFFICIENT TRANSPORT LAYER
PROTECTION

18. M4 – UNINTENDED DATA LEAKAGE
• Sensitive data ends up in unintended places:
• Browser Cookie Object, URL Caching.
• Copy/Paste Buffer Caching, Keyboard Press.
• Application Backgrounding, Logging (System, Crash)
• Temp directories.
• HTML5 Data Storage.
• What 3rd party libraries are doing with user data.

19. M4 – UNINTENDED DATA LEAKAGE (CONT)
Application Backgrounding
App Logging

20. M4 – UNINTENDED DATA LEAKAGE (CONT)

21. M5 – POOR AUTHORIZATION AND AUTHENTICATION
• Device authentication based on IMEI, IMSI, UUID is not
sufficient.
• Impact in wide range and depending on over-privileged
functionality executed.
• Privilege Escalation.
• Unthorized Access.
• Etc.

22. M6 – BROKEN CRYTOGRAPHY
• Two primary categories:
• Broken implementations using strong crypto libraries.
• Custom, easily defeated crypto implementations.
• Encoding != Encryption.
• Obfuscation != Encryption.
• Serialization != Encryption.
• Privilege escalation, circumvent business logic.

23. M6 – BROKEN CRYTOGRAPHY (CONT)
ldc literal_876:"TXlTM2NyM3RLM3k=” -> “MyS3cr3tK3y”
invokestatic byte[] decode( java.lang.String )
invokespecial_lib java.lang.String.<init> // pc=2
astore 8
private final byte[]
com.picuploader.BizProcess.SendRequest.routine_12998
(com.picuploader.BizProcess.SendRequest, byte[],
byte[] ); {
enter
new_lib net.rim.device.api.crypto.TripleDESKey

24. M7 – CLIENT SITE INJECTION
• Apps using browser libraries:
• Pure web apps.
• Hybrid web/native apps.
• Some familiar faces:
• XSS and HTML Injection.
• SQL Injection.
• New and exciting twists:
• Abusing phone dialer + SMS.
• Abusing in-app payments.
24

25. M7 – CLIENT SITE INJECTION (CONT)
• I’m vuln to XSS, and you?  Hmm, Not my mistake…

26. M7 – PROOF OF CONCEPT
• Mobile Trojan ??
The suspects are said to have
used websites like
soundfest.com.vn and
clickdi.com to distribute
malicious mobile
applications.
Once installed on smartphones,
the apps sent out SMS
messages to premium rate
numbers. For each message
that was sent, the device’s
owner was charged with 15,000
Vietnam Dong ($0.70 / €0.51).
4 Vietnamese Men Suspected of Installing SMS Trojans on 100,000
Phones Arrested
http://blog.hicubes.com/2014/05/4-vietnamese-men-suspected-of-installing-sms-trojans-
on-100000-phones-arrested.html

27. M7 – PROOF OF CONCEPT
• Video.

28. M8 – SECURITY DECISIONS VIA UNTRUSTED INPUTS
• Can be leveraged to bypass permissions and security
models.
• Similar but different depending on platform:
• iOS - Abusing URL Schemes.
• Android - Abusing Intents.
• Several attack vectors:
• Malicious apps.
• Client side injection.

29. M8 – SECURITY DECISIONS VIA UNTRUSTED INPUTS
(CONT)
• Ex: Skype iOS URL Schema Handling Issue:
HTML or script
injection via
app
Attacker
embeds iframe
<iframe
src="skype:12
3456?call"></if
rame>
Skype app
handles this
URL Scheme
Phone call is initated
without user consent

30. M9 – IMPROPER SESSION HANDLING
• Mobile app sessions are generally MUCH longer.
• Apps maintain sessions via:
• HTTP cookies
• OAuth tokens
• SSO authentication services
• Bad idea = using a Device Identifier as a session token.

31. M10 – LACK OF BINARY PROTECTIONS
• Almost app deployed without binary protection.
• App can be analyzed, reverse-engineered, modified by
Attacker.
• Attacker can modified, repacked and insert malware into
binary.
• Bypass security controls via binary.
• Etc.

32. BEST PRACTICES
• Do not hardcode sensitive information
• Do not store sensitive information locally
• Don’t store at easily readable location like memory card
• Encrypt the stored data
• Implement SSL

33. BEST PRACTICES
• Protect the webserver against application layer attacks
• Sanitize inputs, use prepared statements (protection
against client side injection)
• Implement Proper Authentication. Do not use UDID or
other hardware IDs for auth.
• Prefer encryption over encoding or obfuscation

35. THANKS FOR LISTENING
Have a good day!