Securely Deploying Android Devices
Angel Alonso-Parrizas
22th March 2011
About me and this project
• Angel Alonso-Parrizas – [email protected]– 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?