3. 3
• Applies to the backend services
• Not mobile specific per se (i.e. OWASP Top 10)
• We still can’t trust the client
4. 3
• Applies to the backend services
• Not mobile specific per se (i.e. OWASP Top 10)
• We still can’t trust the client
The technical impact of this vulnerability
corresponds to the technical impact of the
associated vulnerability (e.g. loss of
Confidentiality, Integrity and/or
Availability).
IMPACT
6. 5
Sensitive data left unprotected
• Data left unencrypted
• Caching data not intended for long-term storage
• Weak permissions
• It applies to locally stored data + cloud synced
7. 5
IMPACT
Sensitive data left unprotected
• Data left unencrypted
• Caching data not intended for long-term storage
• Weak permissions
• It applies to locally stored data + cloud synced
Credentials disclosed
Loss of Confidentiality
Privacy violations
Non-compliance
15. 7
MITIGATION
Store ONLY what is absolutely required
Never use public storage areas in plaintext (i.e. SD card)
16. 7
MITIGATION
Store ONLY what is absolutely required
Never use public storage areas in plaintext (i.e. SD card)
Use secure containers and platform provided file encryption
APIs/libraries (e.g. setStorageEncryption or javax.crypto)
17. 7
MITIGATION
Store ONLY what is absolutely required
Never use public storage areas in plaintext (i.e. SD card)
Use secure containers and platform provided file encryption
APIs/libraries (e.g. setStorageEncryption or javax.crypto)
Do not grant files world readable or world writeable
permissions (i.e. avoid MODE_WORLD_READABLE unless
explicitly required for information sharing between apps)
18. 8
Mobile applications frequently do not protect network
traffic
They may use SSL/TLS during authentication but not
elsewhere
19. 8
Mobile applications frequently do not protect network
traffic
They may use SSL/TLS during authentication but not
elsewhere
IMPACT
Loss of Confidentiality and Integrity (i.e. MITM attacks)
Incident response costs $$$
Possible legal issues (e.g. violation of ISO/PCI
requirements)
25. 10
Use End-to-End encryption between browser and web
server (HTTPS) ► SSL/TLS
Use Certificate/Key Pinning!
MITIGATION
26. 10
Use End-to-End encryption between browser and web
server (HTTPS) ► SSL/TLS
Use Certificate/Key Pinning!
Pinning is the process of associating a host with their expected
*{X509 certificate || public key}. Once a certificate or public key is
known or seen for a host, the certificate or public key is associated or
'pinned' to the host. <…>
The pre-existing relationship between the user and an organization
helps make better security related decisions.
No longer needs to depend on others (not DNS nor CAs) when making
security decisions relating to a peer's identity!
MITIGATION
27. 10
Sensitive data ends up in unintended places
o Web caches
o Keystroke logging
o Screenshots (e.g. iOS backgrounding)
o Logs (system, crash)
o Temp directories
28. 10
IMPACT
Sensitive data ends up in unintended places
o Web caches
o Keystroke logging
o Screenshots (e.g. iOS backgrounding)
o Logs (system, crash)
o Temp directories
Credentials disclosed
Loss of Confidentiality
Privacy violations
Non-compliance
38. 13
MITIGATION
Never log sensitive data to system logs
Remove sensitive data before screenshots are
taken
39. 13
MITIGATION
Never log sensitive data to system logs
Remove sensitive data before screenshots are
taken
Disable keystroke logging per field
40. 13
MITIGATION
Never log sensitive data to system logs
Remove sensitive data before screenshots are
taken
Disable keystroke logging per field
Observe which files are accessed, created, written
by your app before releasing in PROD
41. 14
Auth* users upon fixed identifiers (IMSI, IMEI,
UUID) is not safe enough!
They persist after factory restore & full wipe!
(only few ME permits to change them and its illegal)
42. 14
Auth* users upon fixed identifiers (IMSI, IMEI,
UUID) is not safe enough!
They persist after factory restore & full wipe!
(only few ME permits to change them and its illegal)
IMPACT
Unauthorized Access
Privilege Escalation
Loss of confidentiality
48. 16
MITIGATION
• Developers should assume all client-side auth* checks
can be bypassed by malicious {users,apps}
• Auth* checks must be re-enforced on the server-side
whenever possible
49. 16
MITIGATION
• Developers should assume all client-side auth* checks
can be bypassed by malicious {users,apps}
• Auth* checks must be re-enforced on the server-side
whenever possible
• Never use immutable HW identifiers (IMSI, IMEI, UUID)
as sole authenticator
50. 16
MITIGATION
• Developers should assume all client-side auth* checks
can be bypassed by malicious {users,apps}
• Auth* checks must be re-enforced on the server-side
whenever possible
• Never use immutable HW identifiers (IMSI, IMEI, UUID)
as sole authenticator
• In case of offline usage is needed:
o Perform local auth* checks within the mobile app's code;
o Implement local integrity controls within their code to
detect any unauthorized code changes.
51. 17
Rely custom crypto implementations
◦ (Encode || Serialize || Obfuscate) != Encrypt
Use of Insecure and/or Deprecated Algorithms
Bad implementation of existing strong libraries
52. 17
Rely custom crypto implementations
◦ (Encode || Serialize || Obfuscate) != Encrypt
Use of Insecure and/or Deprecated Algorithms
Bad implementation of existing strong libraries
IMPACT
Privilege escalation
Loss of confidentiality
Bypass business logic
67. 20
MITIGATION
Do NOT try DIY Crypto! (you are not Schneier, at most
Caesar…)
Rely on existing strong libraries
68. 20
MITIGATION
Do NOT try DIY Crypto! (you are not Schneier, at most
Caesar…)
Rely on existing strong libraries
Implement properly those strong libraries
69. 21
Android applications are downloaded and run “client side”.
The code for the app actually resides on the user’s device.
Attackers could load simple text-based attacks that exploit
the syntax of the targeted interpreter (e.g. XSS, SQL
Injection, Local File Inclusion, etc.)
70. 21
Android applications are downloaded and run “client side”.
The code for the app actually resides on the user’s device.
Attackers could load simple text-based attacks that exploit
the syntax of the targeted interpreter (e.g. XSS, SQL
Injection, Local File Inclusion, etc.)
IMPACT
Privilege escalation
Loss of confidentiality
Loss of integrity
Bypass business logic
Imagine, you can...
81. 25
Relying on files, settings, network resources or
other inputs which may be modified:
• iOS- Abusing URL Schemes (e.g. skype URI
calls)
• Android- Abusing Intents
82. 25
Relying on files, settings, network resources or
other inputs which may be modified:
• iOS- Abusing URL Schemes (e.g. skype URI
calls)
• Android- Abusing Intents
IMPACT
Consuming paid resources
Data exfiltration
Privilege escalation
91. 27
Validate all inputs
Prompt the user for additional
authorization before allowing actions
MITIGATION
92. 28
Mobile Apps’ sessions are usually longer for reliability
They may maintain sessions through:
oHTTP Cookies
oOauth
oStored passwords
oUnique tokens
93. 28
Mobile Apps’ sessions are usually longer for reliability
They may maintain sessions through:
oHTTP Cookies
oOauth
oStored passwords
oUnique tokens
IMPACT
User impersonation
Privilege escalation
Loss of confidentiality
Fraudulent transactions
94. 29
Failure to invalidate sessions on the backend
Lack of adequate timeout protection
Failure to properly rotate cookies
Insecure token creation
96. 30
Force users to re-authenticate periodically or after
sensitive actions
MITIGATION
97. 30
Force users to re-authenticate periodically or after
sensitive actions
Allow revocation of device/password in the event
of a lost/stolen device
MITIGATION
98. 30
Force users to re-authenticate periodically or after
sensitive actions
Allow revocation of device/password in the event
of a lost/stolen device
Use high entropy & strong known token
generation methods
MITIGATION
99. 30
Force users to re-authenticate periodically or after
sensitive actions
Allow revocation of device/password in the event
of a lost/stolen device
Use high entropy & strong known token
generation methods
Store and transmit session tokens securely
MITIGATION
100. 31
Fact: The majority of mobile apps do not prevent
reverse engineering!
Typically, an attacker will analyze and reverse
engineer a mobile app's code, then exploit it for
Fun&Profit.
101. 31
Fact: The majority of mobile apps do not prevent
reverse engineering!
Typically, an attacker will analyze and reverse
engineer a mobile app's code, then exploit it for
Fun&Profit.
IMPACT
Intellectual property infringement
Bypass business logic
Fraudulent actions
Loss of integrity & confidentiality
107. 33
Implement root detection controls: (w/ root, dumb users,
give malwares the rights to execute malicious code)
MITIGATION
108. 33
Implement root detection controls: (w/ root, dumb users,
give malwares the rights to execute malicious code)
o In Android check for {test-keys, OTA certificates, several
known rooted apk's, SU binaries} and attempt SU command
directly.
MITIGATION
109. 33
Implement root detection controls: (w/ root, dumb users,
give malwares the rights to execute malicious code)
o In Android check for {test-keys, OTA certificates, several
known rooted apk's, SU binaries} and attempt SU command
directly.
o In iOS apply: {Jailbreak Detection, Checksum, Certificate
Pinning Controls, Debugger Detection} Controls.
MITIGATION
110. 33
Implement root detection controls: (w/ root, dumb users,
give malwares the rights to execute malicious code)
o In Android check for {test-keys, OTA certificates, several
known rooted apk's, SU binaries} and attempt SU command
directly.
o In iOS apply: {Jailbreak Detection, Checksum, Certificate
Pinning Controls, Debugger Detection} Controls.
• Slow down reverse engineering process.
Obfuscate your code!
(ProGuard, DashO, DexGuard, etc.)
MITIGATION