Android Malware in Practice Part II. Demo Recap SMSBypasser Here we hijacked the SMS text and sent...

Post on 16-Dec-2015

215 views 3 download

Transcript of Android Malware in Practice Part II. Demo Recap SMSBypasser Here we hijacked the SMS text and sent...

Android Malwarein PracticePart II

Demo Recap• SMSBypasser• Here we hijacked the SMS text and sent it to our website• This application could filter sms when required

• MaliciousSDcardScanner• No significant security permissions were required to gain access

to the sdcard location • Security exploit?

• Swift Key-logger• Simply piggy backing and altering some one else's malware• http://

www.android-app-development.ie/blog/2013/03/06/inserting-keyloggercode-in-android-swiftkey-using-apktool/

High Risk Android Permissionsandroid.permission.SEND_SMS / RECEIVE_SMSandroid.permission.SYSTEM_ALERT_WINDOWandroid.permission.READ_CONTACTS / WRITE_CONTACTS android.permission.READ_CALENDAR / WRITE_CALENDARandroid.permission.CALL_PHONEandroid.permission.READ_LOGSandroid.permission.ACCESS_FINE_LOCATIONandroid.permission.GET_TASKSandroid.permission.RECEIVE_BOOT_COMPLETEDandroid.permission.CHANGE_WIFI_STATEcom.android.browser.permission.READ_HISTORY_BOOKMARKS /WRITE_HISTORY_BOOKMARKS

List built-in permissions$ pm list permissions -f

Sourced from Google IO 2012 and marakana.com

Thoughts…• We have based our attacks using knowledge of the android

stack using the Android framework• These attacks are relatively simple yet effective to a naive user

• Would AntiVirus or Google Bouncer detect these malicious apps?

Corporate Migration• BYOD (Bring Your Own Device) means that smartphones are

now being accepted into a protected internal network• Consider how we might mitigate malware and how companies

attempt to refute such malware from their platforms/environment

Malware Detection and Prevention• Static analysis of an applications code can provide insight into

its intentions• Antivirus software carries out static analysis of applications

and protects against files that match binary signatures• This type of protection is often inadequate!

Malware Detection and Prevention• Rootkits are also difficult to discover depending on the

sophistication of the attack• Rootkits which attack the kernel memory are able to advise

other application with a tainted view of the system, hence disguising itself cleverly

Reactive• Most reactive approaches to application protection requires a

runtime overhead to be incurred• Overhead is a significant design consideration especially when

targeting mobile devices

strace• strace is a unix base tool that allow following of all system call

made by an application• Tracing the steps we can often see the system call along with

arguments passed

https://github.com/adetaylor/strace-android

Volatility• Deep memory analysis of the dalvik machine provides

application information associate with its runtime• For example we can snoop an application and determine if data

being sent is malware by reading into a intent and deciphering if it has a malicious payload or target

• Links• https://code.google.com/p/volatility/ • http://

www.504ensics.com/android-application-dalvikmemory-analysis-the-chuli-malware/

Android Filesystem Layout(Recap)

visitor@UOA283090 ~ $ adb shell mountrootfs / rootfs ro,relatime 0 0tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0devpts /dev/pts devpts rw,relatime,mode=600 0 0proc /proc proc rw,relatime 0 0sysfs /sys sysfs rw,relatime 0 0none /acct cgroup rw,relatime,cpuacct 0 0tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0none /dev/cpuctl cgroup rw,relatime,cpu 0 0/dev/block/mmcblk0p9 /system ext4 ro,noatime,barrier=1,data=ordered 0 0/dev/block/mmcblk0p12 /data ext4 rw,nosuid,nodev,noatime,barrier=1,journal_async_commit,data=ordered,noauto_da_alloc,discard 0 0/dev/block/mmcblk0p8 /cache ext4 rw,nosuid,nodev,noatime,barrier=1,journal_async_commit,data=ordered 0 0/dev/block/mmcblk0p3 /efs ext4 rw,nosuid,nodev,noatime,barrier=1,journal_async_commit,data=ordered 0 0/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0/dev/fuse /mnt/sdcard fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,..../dev/block/vold/179:17 /mnt/extSdCard vfat rw,dirsync,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1023,...

Android Filesystem Layout(Recap)

The mounts of interest

/ - root of the filesystem hierarchy/system - the ROM that holds all system binaries and files/data - RW location for user applications/cache - transient data space for user applications/efs - phone specific information like IMEI number/mnt/sdcard - fat32 filesystem with no inbuilt security

Android Open Source Project• Android Open Source Project is a commitment from Google to

freely provide the Android source code to developers• Developers can download a vanilla based version of Android

(eg Jelly Bean) using repo (git wrapper application)• Developers can then customise the software to fit the

requirements of their targeted hardware and audience

http://source.android.com/

Rooting the device• Why root a device?• develop new features• update to latest software (OS)• provide security fixes• remove bloatware• get superuser access to hardware

• (overclocking)• some applications require full access

• (backup software, AV?)

Rooting how?• Attacking the OS• Carry out an exploit to grant one time root access

• Remount '/system' as Read/Write• Provide a mechanism to easily gain future root access

One time Exploits• Here we briefly review some of the one time exploits required

to gain initial root access

• ueventd - similar to udev (CVE-2009-1185)• vold (CVE-2011-1823)• rageagainstthecage(CVE-2010-EASY)• Zimperlich (similar to CVE-2010-EASY)• Ashmem (CVE-2011-1149)• suid on /proc/pid/mem (CVE-2012-0056)

Allowing for future root access (I)• Once the exploit has successfully given access we need to set

the system up so that we can change to root privileges on demand

Remount /system$ mount -o remount,rw /dev/null /system

Allowing for future root access (II)• We can either• Create a copy of the shell binary as su and place setuid

permissions to allow users to run as root• or• Cross compile and build your own su binary, then place in

/system/bin/• The su-binary can be found within the AOSP source tree

References• Android: http://developer.android.com/index.html • Google IO: https://sites.google.com/site/io/ • Marakana: http://marakana.com/training/android/ • Genome project http://www.malgenomeproject.org/

Questions?