Android Malware in Practice II

Android Malware
in Practice
Part 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
High Risk Android Permissions
android.permission.SEND_SMS / RECEIVE_SMS
android.permission.READ_CONTACTS / WRITE_CONTACTS android.
android.permission.CHANGE_WIFI_STATE /
List built-in permissions
$ pm list permissions -f
Sourced from Google IO 2012 and
• 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
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
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
• 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 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
• 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
Android Filesystem Layout
[email protected] ~ $ adb shell mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /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,
Android Filesystem Layout
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
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)
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
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
• The su-binary can be found within the AOSP source tree
Google IO:
Genome project

similar documents