Let’s give OBAD a run
Last time we discussed about various tools for analysis, setting up the app to be debugged in jdb, identifying anti-emulator code, hacking and compiling AOSP code and then running the emulator with our modified system image to bypass antivm check. So now that you can bypass the anti vm checks, if you run OBAD in the emulator you would see it asking for enabling it as a DeviceAdmin
OBAD asking device admin permission
So it uses the label “System” for itself and if the user denies the request, it will keep asking for it. Once it is activated as a device admin, launcher icon disappears and it does not even appear as a device admin in the Device Admin list that can be seen via Settings -> Security -> Device Administrators.
After enabling as device admin, access app launcher is no longer present
The figure above shows that there is no app launcher icon visible for OBAD, and that is why in our previous post we mentioned that you have to manually launch the activity as we don’t see a launcher icon for it. If you go and take a list of device administrators for the emulator/device you would not see it there either. The picture below shows how you would expect to see it listed as a Device Administrator
Device admin list does show OBAD as an admin in non vulnerable Android
Here is what you would see in vulnerable Android (more about the vulnerability later)
Where did OBAD go?
So we don’t have a launcher icon, and we don’t have it in the device administrator’s list, may be our AV product detected it and deleted it? Let’s check it in the apps list (Settings -> apps), and you will find it there and perhaps we can then uninstall it from there, can you? Let’s take a look at the image below:
Cannot uninstall OBAD after making it a device admin
The uninstall button is disabled, but one might say ‘Hey! wait a second, I am better than this I can use the “adb uninstall“ command, and if you try that then you will fail and if you look at logcat output you will learn the following:
We can’t deactivate the device admin from Settings menu as it is not even listed as a device administrator and hence we can’t uninstall it. Let’s analyze how it does all this.
How to avoid process being killed due to Activity Not Responding (ANR)
In my previous blog entry for analyzing OBAD, we showed how one can trace methods entered and exited, after dealing with the AntiVM check, if you try to trace methods again you would see your process being killed and you will the following in logcat output
Here is how you can patch Android code to avoid it:
How did the launcher icon disappear?
I traced method entries as I described in my last post, and use the following exclude command in jdb to avoid tracing standard java code but still trace the methods invoked by reflection.
I noticed a call to android.app.ApplicationPackageManager.setComponentEnabledSetting being done via reflection, which can be examined further in jdb by setting a breakpoint.
Why don’t we see the OBAD listed as a Device Administrator?
If you are trying this with one of the latest build of Android, you would notice that OBAD is actually listed as a device administrator, the reason is that this vulnerability has already been fixed. To understand the vulnerability we can simply look at patch logs and analyze the patches, I think it would be more interesting to take a look at it without seeing the patch. So what code gets executed when you open up Settings -> Security -> Device Administrators? You can open it up and then take a look at the output from logcat from event buffer you would see:
So this tells us where to start looking for the code that lists device administrators, we can search for it onandroidxref and find Settings.java and there you will find use of R.id.security_settings, if you search for it you will find it in settings_headers.xml as:
So let’s take a look at com.android.settings.SecuritySettings, you will see it creating device admin preference category as:
If you track KEY_DEVICE_ADMIN_CATEGORY you will get to security_settings_misc.xml and see
So next step is to get to DeviceAdminSettings, browsing around you would get to updateList (note: I am taking you to an unpatched version of updateList) and you will notice that for something to be displayed in the device administrator list it must meet the following conditions:
1. Should be in the list returned by:
2. Should be visible or active:
With some trivial debugging you would realize that OBAD device admin component is not being returned byqueryBroadcastReceivers and further debugging would eventually lead you to manifest file of OBAD saying:
Notice the use of com.strain.admin.DEVICE_ADMIN_ENABLED, the developer docs say thatDeviceAdministrator components should register to receiveandroid.app.action.DEVICE_ADMIN_ENABLED, but the bad guys don’t have to listen to that and they don’t and this is how they hide their device admin. As it is not registered to receive such broadcasts, it does not appear when receivers of it are retrieved in updateList (discussed above).
Looking around a bit I found something interesting that I will share in my next post soon (hopefully within two weeks) so stay tuned and think about this: you give a friend keys to your kingdom/palace/house and he gives his to you, but what you have given him was fake.
Until next time stay safe.
No comments:
Post a Comment