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
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
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!
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
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
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
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
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
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
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
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?
In this project, 50 smartphones were intentionally
lost in cities around the U.S. and in Canada. The phones were prepared with a
contact list, an app called \online banking", les named \salaries" and \saved
passwords", an email account, personal photos, and more. Additionally, the
phones were loaded with logging software so that Symantec could keep track of
all activities. The study came to the result that 96 percent of all smartphones
were accessed by their nders. 89 percent of the nders accessed personal data,
and 83 percent accessed corporate data. For example, 43 percent clicked on the
online banking app, 53 percent clicked on the salaries le, 60 percent checked
personal emails, and 72 percent checked personal photos.
First, the fingerprint of the enroled user is photographed with 2400 dpi resolution. The resulting image is then cleaned up, inverted and laser printed with 1200 dpi onto transparent sheet with a thick toner setting. Finally, pink latex milk or white woodglue is smeared into the pattern created by the toner onto the transparent sheet. After it cures, the thin latex sheet is lifted from the sheet, breathed on to make it a tiny bit moist and then placed onto the sensor to unlock the phone. This process has been used with minor refinements and variations against the vast majority of fingerprint sensors on the market.
For example: screenshots, caching, auto generated stack traces, etc.
Local authentication check only.
Less authentication factors (no hardware token).
Passwords stored in the “remember me function” (instead of device specific random token).
Bad authorization: user scope not well established, access without auth., etc.
Attack vector: any input to the Application (user, thief or malicious app)
Typically the results of wrong assumptions about where a certain input is coming from.
When IPC entries are not strictly validated and authenticated, and their input is used to make a critical decision.
