Securely Deploying Android Devices

Angel Alonso-Parrizas

22th March 2011

About me and this project

• Angel Alonso-Parrizas – parrizas@gmail.com– Security Engineer @ Verizon Zurich team

– MSc, BSc, MSSF, GCIH, GCIA, GCFW, GCFA, GSEC, GSNA, CISSP, CISA, CISM

– 8 years working in different security roles and companies

– http://www.angelalonso.eu | http://twitter.com/Angelill0

• The project– Practicum for the Master in Security and Forensic at Dublin City University

http://www.uv.es/parrizas/alonsoparrizas-android-thesis.pdf

– GIAC GCIH Gold Paper http://www.sans.org/reading_room/whitepapers/sysadmin/securely-deploying-android-devices_33799

• The idea– Need vs security

– Android smartphones aligned with security policies/standards

Agenda

• Android model and threats– Android architecture

– Linux model / permissions

– Some example of recent threats

• Improving security in different areas– Communications channel

– Access control

– Software policy

– Password policy

– Remote access control

– Additional security layers

– Hardening the stack and the Operating System

• Conclusions

Android Model

• Applications– Linux UID model

– File permissions

• Libraries & VM– Dalvik VM isolation

– SSL

• Kernel 2.6– Drivers

– Devices (eg: bluetooth)

Permissions

• Open repositories: Market, Appbrain..

• Developer decides the permissions– AndroidManifest.xml

• User install the application– Install the application (up to the user!)

– Do all the user read ?

– Do all the user understand ?

– Low granularity (everything or nothing)

• Any security issues?– Repository vs malware

– Developers vs bad guys

– End user is not a security expert

<manifest xmlns:android="http://schemas.android.com/apk/res/android"                package="com.example.android.home">    <uses-permission android:name="android.permission.CALL_PHONE"/>    <uses-permission android:name="android.permission.GET_TASKS"/>    <uses-permission android:name="android.permission.READ_CONTACTS"/>    <uses-permission android:name="android.permission.SET_WALLPAPER

Some examples of threats

• Catching AuthTokens in the Wild, The Insecurity of Google's ClientLogin Protocol [13/05/2011]

– Steal authentication tokens through open WiFi in some Google Applications

– Impersonate the user and even steal his Google account– Application not properly build and lack of encryption in critical tasks

• DroimDreamLight / DroidDream [30/05/2011]– Typical malware (nothing new so far)– 30k -120k users affected (not too bad)– Steal information, install software..

• Android.Nickspy [27/07/2011]– Trojan horse– What else can we expect? Umm.. Something recording our

conversation?, yes we can!– …and sending the stolen information through a TCP connection

The lab

• HTC Desire

• SDK Toolkit (Linux, Mac or windows)

• WiFi connection

• 3G card with Internet access

• Some security tools– iptables

– OpenVPN

– SSH

• Dedicated Linux server – Virtual Private Server (VPS)

Communications channels

VPN

Netfilter / DROPDefault route =

tun0

Netfilter / Policies on demand

1. Encryption of traffic2. Drop traffic in the smartphone3. Traffic policy in the VPS (eg: user)4. Analysis of the traffic in the VPS

Communication channel

Access control

• Android user has access to control the phone– USB is used to manage the software – USB is used to access the shell – full access to the system– USB must be disable– Just remove permission on the adbd daemon (/sbin/adbd)

• SSH access should be given to Security Administrator– Dropbear is your friend (SSHD version for embedded system)– Use keys instead of password– The authorized host is the VPS endpoint– SSH only allowed through VPN interface (tun0)

Software Policy

• Only authorized software must run on the device– Follow the internal policies / standards

– Mitigate the risk of infected software

• Baselines for each user / role– Some users might need special software for their role

• Remove unnecessary software– Remove Market

– Change permission of the container for each application

• Applications must be able to be installed remotely – No need of physical access

– Use SCP to upload the APK file

– Change the permissions of the /system/bin/pm

– Install the application

– Revoke the permissions

SD Card and Bluetooth

• SD Card – FAT file system

– Lack of encryption

– Model of permission is broken

– Some attacks can use the SD card to execute code and hijack

– Umount the /mnt/sdcard on booting time

• Bluetooth– To be or not to be, that’s the question!

– Functionality vs Security, that’s the question!

– Disable /dev/ttyHS0 and /dev/ttyMSM0

Password Policy

• Password policy aligned with company policies

• Google Apps for business– Centralize policy management

– Enforce the policy

– Password complexity

– Number of characters

– Expiration date

– Number of old password

– Wipe threshold

• Device Policy application (agent)

Remote control and additional security controls

• Locate remotely through GPS

• Google Apps for business– GPS + Google Maps

– Remote wipping

– Remote Lock

• Autowipe– Remote wipe through text message

– Wipe if the SIM card is swapped

• Antivirus– AVG for mobile

– Scan applications

– Web filters in real time

Hardening of the Operating system while booting

• Remove unnecessary binaries– irssi, netcat, tcpdump…

• Set properly the permissions– root rw-------

• Harden the TCP/ IP stack

• Boot process in Android– Ramdisk is a problem

– But.. /data/local/userinit.sh

• Customize scripts– userinit.sh, removesotware.sh, iptables.sh

– Easily adaptable to different environment

Conclusions

• Improved the security in different Areas

• Implemented a security channel

• Filter and analyze the traffic

• Reduced the risk of unauthorized software

• Aligned with corporate policies

• Setup a central point to manage

• Added additional security controls / layers

• Deployed customizable scripts

Questions?