Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Securely Deploying Android Device - ISSA (Ireland)


Published on

Presentation given at ISSA Ireland about how to deploy Android in a secure fashion

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Securely Deploying Android Device - ISSA (Ireland)

  1. 1. Securely Deploying Android Devices Angel Alonso-Parrizas22th March 2011
  2. 2. About me and this project• Angel Alonso-Parrizas – – 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 – |• The project – Practicum for the Master in Security and Forensic at Dublin City University – GIAC GCIH Gold Paper deploying-android-devices_33799• The idea – Need vs security – Android smartphones aligned with security policies/standards
  3. 3. 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
  4. 4. Android Model• Applications – Linux UID model – File permissions• Libraries & VM – Dalvik VM isolation – SSL• Kernel 2.6 – Drivers – Devices (eg: bluetooth)
  5. 5. 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 ? <manifest xmlns:android=" – Low granularity (everything or nothing) /res/android"• Any security issues? package=""> <uses-permission – Repository vs malware android:name="android.permission.CALL_PHONE"/ > – Developers vs bad guys <uses-permission android:name="android.permission.GET_TASKS"/> – End user is not a security expert <uses-permission android:name="android.permission.READ_CONTACT S"/> <uses-permission android:name="android.permission.SET_WALLPAPE R
  6. 6. Some examples of threats• Catching AuthTokens in the Wild, The Insecurity of Googles 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
  7. 7. 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)
  8. 8. Communication channels Communications channel N Netfilter / Policies on demand VP 1. Encryption of traffic 2. Drop traffic in the smartphone 3. Traffic policy in the VPS (eg: user) 4. Analysis of the traffic in the VPS Netfilter / DROPDefault route = tun0
  9. 9. 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)
  10. 10. 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
  11. 11. 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
  12. 12. 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)
  13. 13. 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
  14. 14. 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/• Customize scripts –,, – Easily adaptable to different environment
  15. 15. 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
  16. 16. Questions?