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 Microphoneo Camerao Touch screen (capacitance sensor array)o Fingerprint sensor o GPSo Accelerometero Digital compasso Powero 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• Physicalo Lunchtimeo Intrusive

• Connectivityo Cellular

• Data• SMS• Low-level GSM

o Bluetootho WiFio Wiredo 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 iPhoneo Disconnect iPhoneo 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 accesso directory traversalo 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 offloadingtraffic from the cell towers tolocal wifi when possible.

• Applying the 301 PermanentRedirect. Now redirects userstraffic even when not in closeproximity.

• Physicalo Lunchtimeo Intrusive

• Connectivityo Cellular

• Data• SMS• Low-level GSM

o WiFio Bluetootho Wiredo NFC

More Attack vectors• Content

o Fileso Applicationso Software updates

• Cloud Storage

Who owns our information?

• Government’s powerso Any data transmitted over the mobile network exposes this data to the

government via LI mechanisms.

• Phone provider’s powerso iOS updates delete data for jailbroken phoneso iOS and Android’s location recording scandalo Legal issues, technical non-issues

• Carrier/phone storeo 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 useo 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

• Sandboxingo Permissionso Isolation

• App stores verificationo Open or disclosed sourceo Apps must prove themselves secure

• It’s no longer enough to just be secureo Vendors must prove themselves trustworthyo Sometimes signed (BB/Symbian/iOS/Android..)o Some automated reviewo Some manual review

Example: iOS App Store• To use an application on your own iOS

device you must have a special Developer Accounto 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 incorporationBusiness licenseCertificate of FormationDBA (Doing Business As…)Fictitious name statementRegistration of trademarkCharter documentsPartnership papersReseller 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 callso “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 Sniffingo Monitor I/O, API callso “Fuzzing”

• Lots of innocent appspunished

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 Dalviko Java Java Byte Code Dalvik Byte Code

• Dalvik itself is no sandboxo Sandboxing at process levelo 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 installo 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 firmwareo Exploit vulnerability

• Needed foro Backupso Copying apps o Various advanced features

• Less effective with SELinuxo E.g., Samsung Knoxo … so users disable SELinux too

• Vendors detect and:o Void warrantyo 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 responsibilityo 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. Usabilityo 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 promptingo Only one type of exercise-time prompting –

“app wants to use your location”

• Every app is completely isolated from otherso 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. PCHarder:• 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 Maliciouso Runtime: TaintDroido Static (PiOS)