This week’s topic was mobile security. Mobile devices are ubiquitous now, but once were a niche technology. The beginning of the lecture covered the evolution of mobile devices, from a $4000 cell phone with 30 minutes of talk time from 1984 to current Android and iOS devices. The stats from the lecture showed that Android share has been growing and has ~40% market share while iOS has ~20%. This was surprising because I thought that the marketshare for both would be larger. This may be because the statistics are dated and reflect international subscribers. A post on statista.com shows that in the United States today, 54% of smartphone users are on Android and 44% are on iOS.
Another point that was made in lecture was how different the mobile platforms are from each other. Exploits are limited to one platform since the kernel, programming language, executable file format, and app compiled code is different. Each mobile OS also has its own security features. Android marketplace automates application review while iOS has manual approval for the Apple store. Likewise, Android apps are self-signed while iOS apps have vendor-controlled signing.
It’s also possible to bypass system security features on each platform. iOS devices can be jailbroken, which opens security backdoors. Jailbreaking an iOS device allows it to run software not authorized by Apple. Similarly, Android devices can be rooted, which means gaining root privileges so that the user can run privileged actions, such as removing pre-installed applications or bypassing restrictions from carriers and manufacturers.
We also went over a brief history of mobile exploits. Two of the first malware exploits, Epoc.Fake and SymbOS.Cabir used bluetooth for distribution. This is interesting to me because bluetooth is not a technology that we think about too much in our day to day, especially when these exploited came out in 2000 and 2004, and they spread with relatively close physical proximity like a biological virus. Most of the time, when you think of a computer virus or malware, you think of it coming from the internet. Who would have thought, back then, that your phone could “catch a cold” from neighboring “sick” mobile devices. But it wasn’t until 2007 that mobile malware was actually used for financial gain by the writers. SymbOS.Viver would send text messages from infected devices to premium numbers and collect the fees incurred by the infected users.
One of the biggest Android exploits was DroidDream. Apps were repackaged with this exploit and uploaded to the Android Market. It attempted to root the device using two publicly discussed exploits, “exploid” and “rageagainstthiscage”. Once rooted, it installed its APK in the system files, masquerading as sqlite.db, and started downloading additional applications. This was the discovered exploit on the Android Marketplace and had between 50K and 200K installs in four days. In order to reverse the damage done by this malware, the applications found to contain this exploit were remotely removed the software from affected devices. This required automatic download of an “Android Market Security Tool” app. Funnily enough, malware authors took advantage of this and repackaged this app with malicious code in an exploit named BgServ.
In the static analysis lab we were given two files to examine. One of the ways we can get information about the malware is by taking an md5sum of the suspect file and then look it up on Virus Total. The links to download the files were broken, but I was able to look up the hash and find the following match. It is the FakePlayer malware.
Above is a screenshot from VirusTotal for the FakePlayer details page. The first suspicious detail is that the application has permissions to send text messages. It is unlikely that a media player would need to have texting permissions. But even more suspicious is that the ONLY permission that the application needs is SEND_SMS. Additionally, the certificate for the app is issued by Android Debug, which is the default certificate created by the build tools and insecure.
We can also look at the .smali file and perform static analysis. The .smali file is a mix between the DEX file and the Java source. We can follow the logic and structure of the Android application here. We can modify the smali file, recompile the application with the same APK tools used to decompile, regenerate the APK file, sign it, and run it again – so reverse engineering is possible.
For the dynamic analysis portion of the lab, we used Android Device manager – an Android emulator to examine the malware samples. We can log the network traffic into a pcap file and use Wireshark to analyze the network traffic. We opened two instances of Android emulators, and added one phone as a contact of the other. Then, we fired up the malware program. After launching the malware application on the first Android instance, the second Android instance received a text message shaming the first user for downloading a pirated app.
Ben Jones CS 373 Blog 