The document discusses mobile security and vulnerabilities. It begins with an introduction of the speaker, Dr. Ir. Stefaan Seys, and the agenda. It then covers topics like the relative security of Android, iOS, and Windows mobile platforms. Specific issues discussed include Android's challenges with updates, data storage vulnerabilities, jailbreaking/rooting risks, and threats involving insufficient transport layer protection and insecure data storage. Examples of past mobile vulnerabilities like Stagefright are provided.

1. Mobile Security
Dr. Ir. Stefaan Seys, Senior Security Expert
ZIONSECURITY

2. Agenda of today
 20u30-21u45: Presentation
 21u45-22u00: Pauze
 22u00-23u00: Hands-on + challenge

3. Who am I?
 Stefaan Seys
 Security Expert at ZIONSECURITY
 Researcher -> postdoc -> PwC -> postdoc -> zion
 Expertise:
 Cryptography
 Security protocols (IPSEC, TLS, etc.)
 Code review
 Security testing (web/infrastructure/IoT)
 Mobile apps
 Ethical hacking
 Electronics tinkering (arduino, etc.)
COSIC

4. On Vulnerabilities and Malware
4

5. 5
Android vs iOS vs Windows 8.1
Windows 8.1 (Feb. 2016)

6. 6
Android vs iOS vs Windows 8.1
Android (Feb. 2016)

7. 7
Android vs iOS vs Windows 8.1
iOS (Feb. 2016)

8. 8
Android vs iOS vs Windows 8.1
203 in 4 years
808 in 10 years
187 in 8 years

9. Android’s Achilles Heel (updates/patches)
9
 Android installs depend on three parties
 Google (developer)
 OEM (personalization phase 1)
 Carrier (personalization phase 2)
 Short shelf-life of devices (e.g., new Galaxy S every
year)
 Meaning short support/no updates by OEM/Carrier
 Resulting in millions of devices with known
vulnerabilities
 Gingerbread/ICS still out there

10. Android Adoption Rate
10

11. iOS Adoption Rate
11

12. # vulnerabilities as provided by NIST (NVD)

13. Android 2015: stagefright
13
 Bug in the multimedia library libStageFright
 Library was there since Android 2.2
 > 900 million devices theoretically vulnerable
 Since Android 4.0, ASLR (Address Space Layout
Randomization) is implemented, making exploit very
difficult
 Big fuss, but no known exploits in the wild…

14. Black Hat London - June 2015
14
 NowSecure releases details of huge Samsung
vulnerability
 > 600 million Samsung devices vulnerable, including the
latest (at the time) Galaxy S6
 Samsung was notified in December 2014
 Samsung provided patch early 2015, but unknown which
carriers are pushing the patch
 Impact: Complete system take over, including remote
 Access sensors and resources like GPS, camera and
microphone
 Install malicious apps without the user knowing
 Tamper with how other apps work or how the phone works
 Eavesdrop on incoming/outgoing messages or voice calls
 Attempt to access sensitive personal data like pictures and text
messages

15. What went wrong?
15
 Samsung installs its own Swift Keyboard. This
cannot be uninstalled by the user.
 The Swift Keyboard app runs as System user
(virtually root)
 Installation of additional lanuage is over HTTP
GET http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/az_AZ.zip
 Using a rogue WiFi AP, DNS hijacking or ARP
poisoning, fool the Swift app to download your
“language” file
 The Keyboard app writes the zip file using its System
user account on the file system...

16. From file access to code execution
16
 At installation time, DEX files are extracted from the
APK and stored in a cache directory
 Look for a default application that is automatically
launched at boot and is owned by System
<action android:name="android.intent.action.BOOT_COMPLETED" />
 Generate shell code or whatever you want, compile
it and place the DEX file in the “language” zip file
 Solve some small checks by the OS (date and
CRC32)
 Have the user add or update a certain language (OS
can also trigger this automatically) to the Swift
Keyboard

17. Many vulnerabilities !=
a lot of malware
17

18. Malware families
18
 Far more “malware” for Android than for iOS
 Virtually no malware uses any vulnerability
 they just ask for the permissions they need
 or they only work on rooted or jailbroken device
 Due to the lack of distribution channel for malware
for iOS
 Apple Store vetting more strict than Google Play
 Android open to other stores
Vs only 1-3
for IOS!

19. OWASP Top 10 Mobile Risks
19

20. Mobile Application Threat Model
20
Victim
App
Maliciou
s App
External storage
Internal storage
Shared Preferences
Content Provider
Native Libraries / OS
User
3rd party services
Our web services

21. Mobile Threat Model

22. OWASP Mobile Top 10 Risks 2014

23. OWASP TOP10 2014
23
Top of the list:
M1: Weak Server Side Controls
Victim
App
Malicio
us App
External storage
Internal storage
Shared Preferences
Content Provider
Native Libraries / OS
User
3rd party services
Our web services

24. M1- Weak Server Side Controls

25. Discovery
25
Public APIs are designed to be used by ‘external’
parties
 Documentation
 API descriptors in standard formats
 URI-style: Swagger, RAML, API-Blueprint, I/O Docs, etc.
 SOAP: WSDL/XML-Schema
 Hypermedia: JSON-LD, Siren, Hydra, etc.
 This obviously helps in the discovery phase 

26. Swagger example
26
"paths": {
"/pet/{petId}": {
"delete": {
"tags": ["pet"],
"summary": "Deletes a pet",
"description": "",
"operationId": "deletePet",
"produces": ["application/json", "application/xml"],
"security": [{
"petstore_auth": ["write:pets", "read:pets"]
}]
"parameters": [{
"name": "petId",
"in": "path",
"description": "Pet id to delete",
"required": true,
"type": "integer",
"format": "int64"
}],
. . .
Attack point
HTTP method, how does it handle
unspecified methods?
OAUTH 2: which implementation?,
known vulnerabilities? How does it
validate tokens?
Scopes?
Is access validated? Link between user
and petId? Are IDs random? Injection?
XSS?
What if we do not set the “petId”? What
if we do not give an int? Or > int64 max
size?

27. “Classic Discovery” in case the API is secret
27
What about just keeping your API secret?
 Local Proxy or network sniffer
 Guess / brute-force APIs
 http://api.*.com/api/v?/*.json

28. Public API with a secret API key…
28
March 2014
Issue was already reported to them in 2010...

29. Story
29
 Install the official Android App
 Use local proxy to intercept traffic
 Start App, enter garbage at login page (over HTTP!)
 GET
/handler.php?CritickerKey=xxxxx&Function=UserSignin&UserName=asdf
asdf&
Password=6d2dedb5b9e02d466a8d98b4c4398b1d
 The Criticker API has a call to get the list of users!
 GET handler.php?CritickerKey=xxxxx&Function=AccountUsers
 And a call to request the current password! In
plaintext! Of any user! Without authentication - zucht
 GET
handler.php?CritickerKey=xxxxx&Function=LookupPassword&UserId=xxx
xx

30. What did they do wrong?
30
 They created an API with “useless”, dangerous and
documented features
 Call to get list of all users?
 Call to get password of a any user?
 Passwords are stored in plain text on the server
 They use plain HTTP (no SSL)
 Their one and only “API key” is sent over the
network with every call

31. OWASP TOP10 2014
31
M2: Insecure Data Storage
Victim
App
Malicio
us App
External storage
Internal storage
Shared Preferences
Content Provider
Native Libraries / OS
User
3rd party services
Our web services

32. People are Curious Creatures
32
 From a 2011 study [McAfee, Ponemom Inst., 4]
 140,000 out of 3.3M (4.1%) of smart phones were lost or
stolen in 1 year
 10,000 were recovered
 47% lost at home or hotel room, 29% while in transit
 Smartphone Honey Stick Project [Symantec, 2012, 5]
 50 `prepped’ smartphone intentionally ‘lost’ in various
cities in US
 96% were accessed by the finders, about 85% checked data on
phone
 43% opened the ‘online banking’ app
 53% opened the ‘salaries’ file
 60% checked personal mail
 72% opened photos

33. ARM SoC
Locked BootLoader
33
 Actual implementation depends on OEM
 “Unlocking capabilities” also depend on OEM
 Samsung ships mostly unlockable
 HTC supports official unlocking (voids warranty)
 LG ships unlocked, but no default flashing support
 Motorola tends to be locked tight (requires exploit)
 Apple not a big fan of unlocking bootloaders
Hash(root PK)
INIT
IMAGE
Signature
Cert. chain
SYSTEM
IMAGE
Signature
Cert. chain

34. iOS System Software Authorization
34
 In general you an install ‘whatever OS you want’ on
an Android device by unlocking the bootloader
 Apple is trying very hard to force users to always run
the latest iOS version available
 System Software Authorization makes downgrading
very hard
 Apple’s update servers generate personalized and
digitally signed firmware images;
 The mobile device bootloader will only accept signed
update images with his unique device ID

35. Separate process
Unique UID
Android Application Sandboxing
35
 Every Android App
 Runs in its own process
 Has its own Dalvik VM (ART) instance
 Is assigned a unique Linux user ID
ART
(Core Libs)
App 1
Separate process
Unique UID
ART
(Core Libs)
App 2
Linux Kernel

36. Android UID’s
36

37. Separate process
root
DO NOT ROOT/JAILBREAK your phone
37
 Virtually all sandboxing is removed when you root or
jailbreak your phone!
 All applications run with the user “root”
 SSH access with root shell (iOS)
Dalvik VM
(Core Libs)
App 1
Separate process
root
Dalvik VM
(Core Libs)
App 2

38. Why Do Users Jailbreak?
 Full access to the OS and file system
 Install applications and themes not approved by
Apple (via installers like Cydia)
 Tether their iOS device to bypass carrier restrictions
 Bypass Apple policy
 Install applications without paying

39. Android Permissions
39
 Access to low-level resources
(network, phone calls, SMS, etc.)
is enforced through user and
group permissions at kernel level
 Higher level permissions
(Contacts list, etc.) restricted by
the Android Runtime
 App developers need to specify
the required permissions

40. Prevent Data Theft (Android)
40
 Your data is only protected against trivial methods
when
1. screen lock is enabled (properly), and
2. ADB debugging is disabled, and
3. the bootloader is locked
 Unfortunately
 Some phones come with an unlocked
bootloader (e.g., Sprint Galaxy S4)
 Screen lock has its limits
 Lock Screen bugs, Viber bug, ...
 Screen lock used < 50% [4]

41. But the Attacker has Physical Access…
41
“Given physical access, your data is only as secure as
your attacker is lazy or ignorant”
 “Not motivated”:
 You are lucky, your data is safe.
 “Motivated but not very skilled”:
 RIFF Box and others (pre-programmed JTAG debuggers)
 “Motivated and skilled”:
 Nothing to prevent data theft…

42. What about disk encryption?
42
 Only protects the data at rest.
 Operates at the lowest layers of OS
 Does not protect data from one App to another
 Does not replace applications specific protection of
config files, etc.!
Apple adds a File Data Protection layer that
encrypts on a per-file basis. The keys itself are
kept in a Secure Element and releasing the keys
depends on the Protection Class of the file.
The per-file keys are encrypted with one System
Key.

43. FROST
43
Can only be used with an unlocked
bootloader (unlocking bootloader will
erase RAM)!

44. Android Physical Access Attack Tree
44
ADB enabled
Use tool like odin3 to
unlock the bootloader
Locked
bootloader?
Screenlock?

Brute force
password
“Root” the phone and
dump flash using ADB
or
Install recovery image
to dump flashNo trivial
attack vector
Use JTAG or other
means to dump flash
No Yes
Yes No
No Yes
File system
encryption?

No Yes

45. iOS Physical Access Attack Tree
45
SSH access
Access through SSH
Jailbroken?
Screenlock?

Brute force
password
Use JTAG or other
means to dump flash
No Yes
Yes No
Yes No

Yes
No trivial
attack vector
X

46. Apple vs FBI (Feb 2016)
46
 In December 2015, 14 people were shot in San
Bernardino, California
 The FBI recovered an iPhone, and it’s screen is locked
 It is not rooted, no SSH
 So now they have a court order against Apple to help
them, why?
 Possibly 10 wrong attempts will erase the System Key
 The delay after 9 attempts is 1 hour
 So 4 pin is on average 5000 attempts = 200 days
 So they ask Apple to build an “update” that will remove
the erasure of the System key, remove the delay and
allow input through the lightning interface

47. What about fingerprint security
47
 What is your right hand index finger?
IIS
Arch Whorl Loop Accidental

48. Fingerprint matching
48
 Ridge thinning & extraction
 Minutiae (bifurcation, end point) detection
 Ridge based alignment & overlaying
IIS

49. Apple/Samsung Fingerprint Security
49
 Fake Biometric
 Days after release, German CCC demonstrated that it is
possible to make a fake finger (variation of existing
attack)

50. OWASP TOP10 2014
50
M3: Insufficient Transport Layer Protection
Victim
App
Malicio
us App
External storage
Internal storage
Shared Preferences
Content Provider
Native Libraries / OS
User
3rd party services
Our web services

51. SSL’s Role
51
SSL – The Good
 Secures the actual client authentication; as majority of
web authentication is based on passwords/tokens
 Compatible with vast amount of clients and servers
 ‘Easy’ to set up (hard to do right)
 Removes crypto burden from application developers

52. SSL’s Role
52
SSL – The Bad
 Compatibility -> Complexity -> Vulnerabilities
 For APIs it is also mostly the only crypto layer
 If broken -> huge impact
 “But we are using SSL…”: it does not magically make
your site secure…
 If used with server side certs only, client side authentication is
not in scope
 Transport layer security -> does not prevent many application
layer problems (injection, XSS, etc.)

53. M3- Insufficient Transport Layer Protection
53
Certificate pinning
 Browsers are used to connect to large amount of
different sites and hosts
 PKI needed to verify all SSL certificates in the world
using just a limited set of root certificates
 Mobile Apps typically only connect to a couple of
web services that are known on before hand
 -> makes it possible to embed the certificate in the
App itself

54. M3- Insufficient Transport Layer Protection
2011 Real World Example: Google ClientLogin
Authentication Protocol
Applications can use Google APIs through a token
that is valid for 2 weeks…
• Many applications, including Google Calendar, send
this authorization token over HTTP
• When users connected via wifi, apps automatically
sent the token in an attempt to automatically
synchronize data from server
• Sniff this value, impersonate the user
• http://www.uni-ulm.de/in/mi/mitarbeiter/koenings/catching-authtokens.html

55. OWASP TOP10 2014
55
M4: Unintended Data Leakage
Victim
App
Malicio
us App
External storage
Internal storage
Shared Preferences
Content Provider
Native Libraries / OS
User
3rd party services
Our web services

56. M4- Side Channel Data Leakage
Logging
5
Screenshots

57. OWASP TOP10 2014
57
M5: Poor Authorization and Authentication
M9: Improper Session Handling
Victim
App
Malicio
us App
External storage
Internal storage
Shared Preferences
Content Provider
Native Libraries / OS
User
3rd party services
Our web services

58. M5- Poor Authorization and Authentication
 Apparently it is ’not done’ to ask users to enter their
credentials more than once in a mobile app
 Worst case: username/pwd stored on phone’s local
storage
 Slighly better: hash stored and keychain used for IOS
 Even better: temporary (OAUTH) token stored
 Using local authentication to unlock an app and then
have the app login to the back-end is not
secure…but it happens a lot

59. Secret API with docs in error message
59
 Basic authentication (over SSL, no cert pinning)
 With static fixed username/password for all users
(embedded in App)
 Only ‘authentication’ is the userID
 This userID is sequential (not random)
 Returns a help file if you send a wrong API request

60. Google Wallet (fixed)
60
 Google Wallet uses the NFC chip in Nexus phones
 The NFC chip has a smartcard built in that contains
a Mastercard number
 First users attaches a pre-paid mastercard to Google
Wallet
 User buys new phone, factory resets old phone and
sells it
 Buyer install Google Wallet App and…automatically
gets access to the prepaid card of previous owner
 Authentication based only on (very secure)
smartcard id and not on the Google account…

61. Username / password ?
61
Apple Celebrity photo hack
 Hidden API to find your phone
 https://fmipmobile.icloud.com/fmipservice/device/
<apple_id>/initClient
 Basic Authentication through SSL tunnel
<apple_id> : <password>
 So far so good…
 Server does not limit the number of attempts…
 Same password for all you i-things on Apple (iCloud)

62. OWASP TOP10 2014
62
M10: Lack of Binary Protections
Victim
App
Malicio
us App
External storage
Internal storage
Shared Preferences
Content Provider
Native Libraries / OS
User
3rd party services
Our web services

63. M10 Lack of Binary Protection
63
 IOS Applications are hard to reverse and make life
difficult for pentesters 
 Android Applications are trivial to reverse and return
very readable code
 HTML, CSS, and JavaScript (i.e. cordova) based
frameworks offer very good reversibility…

64. Code Obfuscation
64
 Android build system includes support for ProGuard
 removes unused code
 renaming classes, fields, and methods
 Makes reverse engineering more difficult
 Smaller .apk files
 Why use it? Because .apk -> source is trivial....
package a;
public class a
{
static String a = "Hello";
static void a() {
System.out.println(a);
}
public static void main(String[] args) {
a();
}
}

65. Android App Reverse Engineering
65
 Tool chain to obtain code from any app in Android
apk dex source
Get apk from
phone (“root”)
unzip
jar
dex2jar JD-GUI
Extract dex from
apk package
Translate
dex to jar
Decompile
bytecode to source

66. M10 Lack of Binary Protection
Prevention Tips
66
 Obfuscate your code for production builds
 Know the limitations of obfuscators
 String constants may not be obfuscated, if they are this is
reversible…
 Try to keep “important” business logic on the server

67. Questions
67
Thank you!
?Homework:
M6 Broken Crypto
M7 Client Side Injection
M8 Security Decisions via Untrusted Inputs

68. 68

69. Demo
69
 http://stefapb79.seventynine.axc.nl/pwk.apk

70. Challenge
70
 Somebody installed an obfuscated PHP script on my
web server…
http://stefapb79.seventynine.axc.nl/zion_backdoor.txt
http://stefapb79.seventynine.axc.nl/zion_backdoor.php
 Challenge is in 2 parts
1. Unobfuscate the script. So show the actual PHP code.
2. Find out how to actually use and log in to the running
backdoor on my server and find the hidden Movie
Character on my server

71. Demo
71

72. Demo
72

73. OWASP TOP10 2014
73
M6: Broken Cryptography
Victim
App
Malicio
us App
External storage
Internal storage
Shared Preferences
Content Provider
Native Libraries / OS
User
3rd party services
Our web services

74. M6- Broken Cryptography
• Encoding != encryption
• Obfuscation != encryption
• Serialization != encryption
• Encryption != Data authentication
• Designing your own cipher != a good idea

75. OWASP TOP10 2014
75
M7: Client Side Injection
Victim
App
Malicio
us App
External storage
Internal storage
Shared Preferences
Content Provider
Native Libraries / OS
User
3rd party services
Our web services

76. M7- Client Side Injection
 Garden Variety XSS…. With access to:

77. A billion LOLs
77
 Craft malicious input that targets specific message
parser, implementation weakness, etc.
 Vulnerable parser will recursively replace &lol9;
 Resulting in a billion ‘lol’s; taking up 3GByte of RAM
<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ELEMENT lolz (#PCDATA)>
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

78. OWASP TOP10 2014
78
M8: Security Decisions Via Untrusted Inputs
Victim
App
Malicio
us App
External storage
Internal storage
Shared Preferences
Content Provider
Native Libraries / OS
User
3rd party services
Our web services

79. M8- Security Decisions Via Untrusted Inputs
 Can be leveraged to bypass
permissions and security models
 When IPC entries are not strictly
validated and authenticated, and
their input is used to make a critical
decision
• iOS- Abusing URL Schemes
• Android- Abusing Intents
• Several attack vectors
• Malicious apps
• Client side injection
Impact
• Consuming paid
resources
• Data exfiltration
• Privilege escalation

80. M8- Security Decisions Via Untrusted Inputs
Typically the results of wrong assumptions about
where a certain input is coming from
Skype iOS URL Scheme Handling Issue (fixed):

81. M8- Security Decisions Via Untrusted Inputs
81
 Server sending JSON config to App
{
“allow_rooted” : “true”,
“role” : “user”,
“age” : 14,
“enable_debuggin” : false
}
How do you ensure this message comes from the
server?