pr Smartphone Security Malware Exercise

Transcription

1 Technische Universität Darmstadt Fachbereich Informatik Fachgebiet Systemsicherheit Prof. Dr.-Ing. Ahmad-Reza Sadeghi pr Smartphone Security Winter term 2012/2013 M.Sc. Sven Bugiel Version 1.1 (October 27, 2012)

2 1 Development environment In this lab we use the Eclipse IDE. 1. Open Eclipse 2. On the bottom right you see Android development specific tools such as Logcat, Emulator control etc. Figure 1: Android development specific tools 3. In the top right corner you can switch to DDMS, the debugging view for Android if required. 4. Further, in the Menu Bar, you see two new entries: (a) for the Android SDK Manager (b) for the Android AVD (Android Virtual Device) Manager Figure 2: Android Menu Bar entries 5. Open the AVD Manager and start the device for platform version 2.2. Check the Wipe user data option! 6. You can observe the log output in the LogCat tool in eclipse or open a new shell and use the adb (Android Debug Bridge): $ adb logcat For a full list of the adb features (e.g., emulator control), please refer to the adb help page. 7. Once the device has been fully booted, add some contacts via the Contacts app. You can find the Contacts app by opening the Android Launcher (cf. Figure 3), then Contacts, and then using the Menu button of the device to get to Add Contact Figure 3: Android Launcher button 8. Now start the second device with platform version Once this second device has booted, go to the SMS ( Messaging ) app and send a test SMS to the first emulator device. The phone number of each device equals the number (e.g., 5554) in the title bar of the emulator window. 10. To end emulators, simply close their windows, no special shutdown procedure is required. 2

3 2 Over-privileged Apps / Botnet First, we will have a look at an overprivileged app, which misuses its privileges to harm the user s privacy and security. To this end, a very simple app is provided, MaliciousApp, which further connects to a very simple botnet controller, AttackController. 1. Open the MaliciousApp project in Eclipse and inspect the code: (a) which permissions does it use? (AndroidManifest.xml) (b) how does it operate? (e.g. handlemsg function in MaliciousAppActivity) (c) what is the purpose of the SMSListener class? (check the receiver tag in the manifest file) 2. Now, start the AttackController. A runnable JAR file can be found in the home directory: $ java -jar AttackController.jar Listening Start the 2.2 AVD without wiping user data, in order to preserve contacts, SMS, etc., and after it has booted, install and run the MaliciousApp by right-clicking on the project in the PackageExplorer and choosing Run as Android Application 4. When the app starts, you should see that the controller receives one connection and you are able to issue commands to the app. Check the source code of the app to find out which commands. Try some of the following: retrieve contacts data retrieve the list of SMS and read some SMS (of course there must be some SMS stored on the device) send with the second device (4.0.3) an SMS to the infect device and check that the controller retrieved this SMS in real-time. Alternatively, you can send the SMS with the Android tools in Eclipse or with the adb. 5. This attack resembles the Geinimi trojan attack, which extended apps with malicious functionality and modified their manifests to request the necessary permissions for the malicious code to function. What could be the reason why such malware is successful? Can you ad-hoc think of countermeasures to mitigate such attacks? 3 Confused deputy attacks Next, we will look at some simple, known confused deputy attacks on Android Terminate any emulator and the controller from task Open the ConfusedDeputy project 3. Launch the Android 2.2 emulator and run the ConfusedDeputy app on it 4. First, try the Toggle GPS attack. To verify that the attack works, compare the status of Launcher Settings Location & security Use GPS satellites before and after toggling. You can also add the Power Control widget to the desktop and see its GPS button change its status by the attack. 5. Next, try the Download file attack. This causes the Browser to start and download an APK file provided by a HTTP server on the host machine to the SDCard. To verify that the file was downloaded, press the Check file button. 6. Investigate how the sample attacks work (use to check out the vulnerability report mentioned in the source code). 3

4 7. Briefly explain how the browser was triggered to download the file and why is not trivial to prevent this attack. 8. Open the android-froyo project and open the only bookmark for this project. This bookmark will open the SettingsAppWidgetProvider class, which is the confused deputy in case of the Toggle GPS attack. Can you explain the vulnerability at this point? 4 Collusion Attack Now, we will look at how apps can collude via covert channels similar to the ideas presented in the SoundComber attack. 1. Terminate any emulator from the previous task. 2. Launch the Android 2.2 AVD with wiping the user data 3. Install the de_zuloo_mosel_contacthcreceiver and de_zuloo_mosel_hr apps, which are the receivers of the cover channels and do not provide an Activity (i.e., they do not show up in the launcher) 4. Now install the HCActivity app 5. Send a short message such as "Hello" using (a) the Audio (b) and the Airplane Mode channels 6. Observe the communication process with adb logcat 7. Can you think about counter-measures to mitigate such attacks? 5 Root exploits Last, we will use exploit code (rage-against-the-cage) in order to escalate the app s privileges. 1. Terminate all emulators from the previous task 2. Open the RunNative project 3. Which permissions does the app possess? 4. The entry point to the code is the oncreate function. From there analyze the control flow of the app and make a high-level sketch of its functionality. 5. Launch the Android 2.2 AVD 6. Send some SMS to the device using, e.g., the emulator control, the second (4.0.3) AVD, or via $ adb emu sms send <number> <text> 7. Next, run the RunNative app and check the log for the rooted message: D/RunNative( 477): R00ted 4

5 8. The app terminates itself after the rooting. Now restart the app using the launcher on the device (the app is called hijack). Observe the log for its behavior. Most probably, the second execution will crash as well after some time. 9. Verify that (a) the app could access the SMS database via the API despite the fact that it does not hold the necessary permission. What could be the reason? Hint: Also investigate the checkpermission function of the ActivityManagerService class in the android-froyo project (LeftStrg+LeftShift+R helps you finding the class) (b) the app has installed the Evil.apk that it carried in its assets. This app has no Activity, hence does not show up in the launcher, but can be found via the Settings Applications Manage Applications. The source code of Evil.apk is provided in Eclipse, check what it does (or could do). 10. Instead of carrying the exploit code and the APK as assets, could this app without any permissions retrieve this payload from somewhere else and hence circumvent, e.g., anti-virus scanners on the mobile device? 6 Optional: Fix the Toggle GPS vulnerability We now implement a quick fix for the Toggle GPS attack from task 3. The fundamental problem to tackle is, that BroadcastReceivers on Android can not implement themselves a fine-grained access control based on intent provenance within the receivers. The reason is an indirect call chain, meaning, that broadcast intents seem as to be originating from the Android system server (UID 1000) from the receivers point of view. Thus, in order fix this problem, we will add a (static) policy-driven access control to the broadcast subsystem. Alternative methods could be the tagging of Intents with their sender UID or building IPC call chains (c.f. Quire framework in the lecture slides). 1. Open the ActivityManagerService class in the android-froyo project. Hint: LeftStrg+LeftShift+T helps you finding it. 2. Extend the broadcastintent function with the following code just before the first synchronized: if((intent.getcomponent()!=null?intent.getcomponent().getclassname().equals("com.android. settings.widget.settingsappwidgetprovider"):false) && intent.hascategory(intent.category_alternative) && (Binder.getCallingUid()!=1000)) throw new SecurityException("Toggle GPS forbidden this way!"); 3. Now we will rebuild the system and boot the modified version: $ cd ~/android-froyo $ source build/envsetup.sh $ lunch 1 $ make -j3 $ out/host/linux-x86/bin/emulator -sysdir out/target/product/generic/ \ -system out/target/product/generic/system.img \ -ramdisk out/target/product/generic/ramdisk.img \ -data out/target/product/generic/userdata.img \ -kernel prebuilt/android-arm/kernel/kernel-qemu \ -sdcard sdcard.img 4. Export the CallDeputy APK by right-clicking on the project, then Android Tools Export Signed Application Package with the following information: Location of existing keystore: /home/android-lab/android_keystore 5

6 Password keystore: android-lab Alias: evil inc. Password key: android-lab Destination APK: /home/android-lab/calldeputy.apk 5. Possibly wait until the emulator has booted and install the CallDeputy.apk: $ cd $ adb install CallDeputy.apk 2153 KB/s (39923 bytes in 0.018s) pkg: /data/local/tmp/calldeputy.apk Success 6. Verify that toggling GPS with the ConfusedDeputy app results in a crash, because the new security exception is unhandled (see also the logcat). 6