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
5. 4
Follow known methodologies and guidelines:
⢠OWASP Web Top 10
⢠Cloud Top 10
⢠Web Services Top 10
MITIGATION
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...
75. 22
Simple tables enumeration in
sqlite:
dz> run app.provider.query
[URI] âselection â1=1) union
select 1,2,tbl_name from
sqlite_master where (1=1â
76. 22
Simple tables enumeration in
sqlite:
dz> run app.provider.query
[URI] âselection â1=1) union
select 1,2,tbl_name from
sqlite_master where (1=1â
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