introduction to information security · •to use an application on your own ios device you must...
TRANSCRIPT
Introduction to InfoSec –
Smartphone Security (R13)
Nir Krakowski (nirkrako at post.tau.ac.il)
Itamar Gilad (infosec15 at modprobe.net)
Slide Credit: Eran Tromer/TAU, Dan Boneh/Stanford, Roei Schuster/TAU
Smartphone • Motivation
• Attack vectors and examples from the wild
• Application Stores
• Updates regime
• Security models
Capabilities • Sensors:
o Microphone
o Camera
o Touch screen (capacitance sensor array)
o Fingerprint sensor
o GPS
o Accelerometer
o Digital compass
o Power
o Proximity sensor
Data • Phone calls
• SMSs
• Contacts
• Pictures & videos taken
• E-mails
• Credentials (social networks, email accounts)
• More credentials (password reminders)
• Calendar (events, meetings…)
• Bank accounts, stock exchange...
• Browser history
• Location history
• Phone number, IMEI
• …
Attack vectors • Physical
o Lunchtime
o Intrusive
• Connectivity o Cellular
• Data
• SMS
• Low-level GSM
o Bluetooth
o WiFi
o Wired
o NFC
iPhone Charger Exploit • Blackhat ’13 Billy Lau, Yeongjin Jang, Chengyu Song
/ Georgia Tech
• They were able to uninstall Facebook, and then
install a fake Facebook application instead asking
for Facebook credentials
• Similar malware installation was shown on CSI Cyber
S01E09
SMS Fuzzing • By fuzzing various fields (including application
ports, DCS, PID, etc…) researchers managed
to:
o Crash/DoS iPhone
o Disconnect iPhone
o Lock your SIM card
on Android "Fuzzing the Phone in your
Phone", BH USA '09,
Mulliner
Bluetooth/OBEX Vulnerability (‘09, Alberto Moreno Talbado)
• Applies to HTC Smartphones running
Windows Mobile 6/6.1
• Bluetooth attack enables full file
system access o directory traversal
o download files (incl. contacts, mail…)
o upload files (“trojan.exe” to \Windows\Startup)
Bluetooth Vulnerability (cont.)
• “Users worried about
the vulnerability should
avoid pairing their phones
with an untrusted handset
or computer. They may also
want to delete any devices
that are already paired with
their phones”
• In July 2011, published again about OBEX vulnerability this time in HTC
Android device.
301 Permanent Redirect
• ’13 Adi Sharabani / Skycure
301 Permanent Redirect
WifiGate + Permanent Redirection
• ’13 Adi Sharabani / Skycure
• Mobile phones automatically reconnect to Wifi
networks they already know by SSID.
• Mobile Network Carriers include their own Wifi
Configurations for offloading
traffic from the cell towers to
local wifi when possible.
• Applying the 301 Permanent
Redirect. Now redirects users
traffic even when not in close
proximity.
• Physical o Lunchtime
o Intrusive
• Connectivity o Cellular
• Data
• SMS
• Low-level GSM
o WiFi
o Bluetooth
o Wired
o NFC
More Attack vectors • Content
o Files
o Applications
o Software updates
• Cloud Storage
Who owns our information?
• Government’s powers o Any data transmitted over the mobile network exposes this data to the
government via LI mechanisms.
• Phone provider’s powers o iOS updates delete data for jailbroken phones
o iOS and Android’s location recording scandal
o Legal issues, technical non-issues
• Carrier/phone store o Carrier IQ analytics software collected data from over 140 million devices.
Android Security Updates • From the Android Security FAQ:
o “The manufacturer of each device is responsible
for distributing software upgrades for it, including
security fixes. Many devices will update
themselves automatically with software
downloaded "over the air", while some devices
require the user to upgrade them manually.”
o De facto updates?
o Long Term Support ?
“App Attack” • Apps may need to have access to sensitive
information (call history, bank account, etc..).
• Some apps don’t need it (e.g. Angry Birds).
• Calls for a special security mechanism – or does it?
• You needn’t be Microsoft/Adobe to build one that
people will use o New, unexploited, easy-to-implement ideas.
o App Stores – more equal exposure, easy to access.
"App Attack", Mahhaffey & Herring
Advertisement SDKs • 3rd party (Actually, 4th party) components piggy-
backed on an application.
• Developers don’t know the code inside their own
application.
• SDKs will always want to perform targeted
marketing…
Application Security Models
• Sandboxing o Permissions
o Isolation
• App stores verification o Open or disclosed source
o Apps must prove themselves secure
• It’s no longer enough to just be secure
o Vendors must prove themselves trustworthy
o Sometimes signed (BB/Symbian/iOS/Android..)
o Some automated review
o Some manual review
Example: iOS App Store
• To use an application on your own iOS
device you must have a special
Developer Account o You yourself have to be approved
• Costs 99$
• Takes time
o Still does not mean you can get it on the App Store.
Apple developer program enrollment
Dear Troy Hakala,
We are currently in the process of
reviewing your iPhone Developer Program
enrollment information.
Please fax one of the following forms of
identity for your business based on your
company form. To assist with this process,
please ensure your business documents
match your Enrollment information.
…
Please include your main company
corporate telephone number with your
faxed documents.
…
…
Articles of incorporation
Business license
Certificate of Formation
DBA (Doing Business As…)
Fictitious name statement
Registration of trademark
Charter documents
Partnership papers
Reseller or vendor license
…
Thank you,
iPhone Developer Program
Example: iOS App Store (cont.)
• “Let us see for ourselves”. o Can’t get an app on App Store without verifying it.
o Not 100% effective. Pulled back:
• Flashlight kid
• Aurora Faint – contact list, 20M
downloads
• MogoRoad – Sent phone numbers, customers got
commercial calls
o “Polymorphic” apps (change at runtime)
o 10K apps submitted per week, 10% of rejections related to
malware
"iPhone Privacy", Seriot
App Store review process
(guessed)
• Static analysis looking
for particular strings,
API calls etc..
• Dynamic analysis o Sniffing
o Monitor I/O, API calls
o “Fuzzing”
• Lots of innocent apps
punished
Malware Survey [Felt Finifter Chin Hanna Wagner 2011]
• Analyzed 48 malware pieces
(Android, iOS, Symbian), 4 root exploits
• 61% collect info
• 52% send premium SMS
• Credential theft, SEO, SMS spam,
ransom
mobilemalware.pdf
Android Application Security Model
• Applications run in a virtual
machine called Dalvik o Java Java Byte Code Dalvik Byte Code
• Dalvik itself is no sandbox o Sandboxing at process level
o Each app process has a distinct UID, GID, and
belongs to some groups.
• “Permissions” declared statically
Android app permissions: example
(Example by David William Wood)
List of permissions in Android API: https://developer.android.com/reference/android/Manifest.permission.html
Android Security User Experience
• First, obvious problem: users treat
permission prompting similar to
browser pop-up warnings. o They just don’t care. “Want to get hello kitty
wallpapers now.”
Android Application Security Model (cont.)
• How does Android enforce permissions?
• Enforcement mechanisms: o OS kernel level (files, I/O…)
• Some behavior inherited from Linux
• The kernel is patched in some places so that process group
list is checked in some system calls. This is similar to Linux
capabilities (only for non-root processes, and with no one
reference monitor).
o Inter-Component Communication level
• Google’s own implementation
o Recently: SELinux (Mandatory Access Controls)
“Understanding Android Security”
Enck, Ongtang & McDaniel
Security Expressiveness • Microphone AND web access == permission
to record you and send it home?
• User can’t add/remove permissions after
install
o Permissions are absolute upon granting. An app
can’t request one-time permission for specific
operations.
Analyzing Inter-process Communication in Android
[Chin Felt Greenwood Wagner 2011 ]
• Characterize types of IPC
vulnerabilities: o Unauthorized Intent Receipt:
• Broadcast Theft
• Activity Hijacking
• Service Hijacking
o Intent Spoofing:
• Malicious Broadcast Injection
• Malicious Activity Launch
• Malicious Service Launch
• For each – specify how it can happen, how
to avoid it. o Avoidance complexity varies.
intents-mobisys11.pdf
Analyzing Inter-process Communication in Android
[Chin Felt Greenwood Wagner 2011 ]
• ComDroid: Analyzed 100 applications to identify suspicious IPC implementation (e.g. not declaring permissions to use a broadcast receiver..). Outputted warnings.
• Manually examined 20 applications for: o Vulnerabilities (e.g. sensitive information
exposure)
o Spoofing Vulnerabilities (security depends on user’s choices in activity intent-resolution dialog)
o Unintentional bugs (ignoring good code convention)
Results
• Results show that the Android permission system is
confusing to developers, and they misuse it.
Jailbreaking / rooting • Give application “root” permissions
• Method: o Flash firmware
o Exploit vulnerability
• Needed for o Backups
o Copying apps
o Various advanced features
• Less effective with SELinux o E.g., Samsung Knox
o … so users disable SELinux too
• Vendors detect and: o Void warranty
o Prevent security updates
Android Application Security Model - Conclusions
• IPC and shared resources (logs, internet) are
a major security issue.
• Protection of application and user is the
developer’s responsibility o Any form of ICC/shared resources should be carefully
examined.
o In real life, this does not happen. Many apps expose their (and your) secret information through these mechanisms.
This includes Android’s built-in applications (e.g. browser).
Android’s Application Security Model – Conclusions (cont.) • Protection of user’s data is his own responsibility
o Security vs. Usability
o Users don’t understand security concerns
• What does CLEAR_APP_CACHE permission mean?
• Android’s permission model lacks important
expressiveness
• Android’s Open-Market App Security Model is an
extreme and unique choice.
iOS Application Security Model
• Permissions: o No pre-install user prompting
o Only one type of exercise-time prompting – “app
wants to use your location”
• Every app is completely isolated from
others o If an IPC hack exists, it will probably not be “Apple-
Approved”
• Hidden APIs exist.
Caught by App Genome Project
(cont.) • Lots of simple apps
(wallpaper/flashllight etc.)
• Accessing IMEI, IMSI,
Phone number…
• AND internet…
• Some don’t hide that
they do.
Easier:
• Remote control (uninstall)
• Jail
• Finer-grained permissions
• Single user
• More uniform hardware
• Biometrics
• “Clean slate”
Mobile vs. PC Harder:
• Input
• Output
• Patience
• Sensitivity
What can the platform can do about it?
• Encryption
• Virtualization
• Fine-grained permissions
• Fine-grain protection domains
• Information flow control o Inadvertant (logs)
o Hard to analyze (app interaction)
o Malicious
o Runtime: TaintDroid
o Static (PiOS)