The document discusses various mobile application security vulnerabilities. It covers topics like insecure data storage, lack of encryption for network traffic, authentication issues, insecure session management, and risks from unintended data exposure. Mitigation strategies are provided for each vulnerability, which generally involve following secure coding best practices, leveraging encryption properly, validating all inputs, and deploying defenses in depth with checks on both the client and server sides.

1. Luca Bongiorni
10th September 2015

2. 2

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

8. 6

9. 6

10. 6

11. 6

12. 6

13. 7
MITIGATION

14. 7
MITIGATION
 Store ONLY what is absolutely required

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)

20. 9

21. 9

22. 9

23. 10
MITIGATION

24. 10
Use End-to-End encryption between browser and web
server (HTTPS) ► SSL/TLS
MITIGATION

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

29. 11
Logs

30. 11
Logs

31. 11
Logs

32. 11
Logs

33. 12

34. 12
Clipboard

35. 12
ScreenshotsClipboard

36. 13
MITIGATION

37. 13
MITIGATION
 Never log sensitive data to system logs

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

43. 15
Full Video: https://www.youtube.com/watch?v=kqo1o71lbvk
Dropbox plist file with pincode.

44. 15
Full Video: https://www.youtube.com/watch?v=kqo1o71lbvk
Dropbox plist file with pincode.

45. 15
Full Video: https://www.youtube.com/watch?v=kqo1o71lbvk
Dropbox plist file with pincode.

46. 16
MITIGATION

47. 16
MITIGATION
• Developers should assume all client-side auth* checks
can be bypassed by malicious {users,apps}

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

53. 18

54. 18

55. 18

56. 18
dGVjaGNpdHk=

57. 18
dGVjaGNpdHk= Base64(“techcity”)

58. 18
dGVjaGNpdHk= Base64(“techcity”)
pc7ciMcRj…

59. 18
dGVjaGNpdHk= Base64(“techcity”)
pc7ciMcRj… Base64(“¥Î܈Ljˆˆñóc..”)?!?

60. 19

61. 19

62. 19

63. 19

64. 19

65. 20
MITIGATION

66. 20
MITIGATION
Do NOT try DIY Crypto! (you are not Schneier, at most
Caesar…)

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...

71. 22

72. 22

73. 22

74. 22
Simple tables enumeration in
sqlite:

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”

77. 23

78. 24
MITIGATION

79. 24
MITIGATION

80. 24
MITIGATION
 Sanitize untrusted data before rendering or executing it!
 Use prepared statements for database calls!

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

83. 26

84. 26
.
..
<iframe
src="tel://1408555555?call"></ifr
ame>
….
<iframe
src="skype://1408555555?call">
</iframe>
…
..
.
Malicious Web Page

85. 26
.
..
<iframe
src="tel://1408555555?call"></ifr
ame>
….
<iframe
src="skype://1408555555?call">
</iframe>
…
..
.
Malicious Web Page iOS Safari

86. 26
.
..
<iframe
src="tel://1408555555?call"></ifr
ame>
….
<iframe
src="skype://1408555555?call">
</iframe>
…
..
.
Malicious Web Page iOS Safari

87. 26
.
..
<iframe
src="tel://1408555555?call"></ifr
ame>
….
<iframe
src="skype://1408555555?call">
</iframe>
…
..
.
Malicious Web Page iOS Safari
Skype

88. 26
.
..
<iframe
src="tel://1408555555?call"></ifr
ame>
….
<iframe
src="skype://1408555555?call">
</iframe>
…
..
.
Malicious Web Page iOS Safari
Skype

89. 27
MITIGATION

90. 27
 Validate all inputs
MITIGATION

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

95. 30
MITIGATION

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

102. 32

103. 32

104. 32

105. 32
Is it enough?
We will see in the Workshop!

106. 33
MITIGATION

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

111. 34
• https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Proje
ct_-_Top_Ten_Mobile_Risks
• https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
• https://github.com/dineshshetty/Android-InsecureBankv2
• https://www.owasp.org/index.php/Technical_Risks_of_Reverse_Engineeri
ng_and_Unauthorized_Code_Modification
• https://www.youtube.com/watch?v=Zy1AAKBBaZk
• http://www.slideshare.net/iazza/dcm-final-23052013fullycensored
• http://software-security.sans.org/blog/2010/11/08/insecure-handling-url-
schemes-apples-ios/
• http://centralgeekhub.com/sql-injection-in-android-apps/
• https://blog.netspi.com/android-root-detection-techniques/

112. 35