Potential DoS Vulnerability with Android System

By S G -
I had reported a potential flaw in the Android system that could be used to perform DOS (Denial-of-Service) on an Android Phone. The issue was caused by a poor programming assumption which could have been avoided with a good programming 101 course.

I had developed a tool called c-ray to help me with quick and dirty pentest and analysis of android applications and system. I stumbled on the issue while playing around with android core system and c-ray application.

The issue was caused by an input validation error caused by assumption of the developer. An intent to "android.accounts.GrantCredentialsPermission" class of android core system results in system crash and reboot of the system. Further analysis and reasons below.



For the normal user - Steps to reproduce the problem:

(Advanced users with knowledge of Android SDK and platform proceed to next section.)

- Launch C-Ray
- type "android" in the text box
- Choose "Package Name" radio button
- Click "Manual Scan"





Manual Scan feature lists all activities, services and receivers associated with an application - in this case the android core system.

Click the "android.accounts.GrantCredentialsPermission" from the manual scan list and continue with default action.

CLick "Yes". The system will freeze for a moment and then reboot with your usual boot screen image/logo.

For Advanced Users:



An input validation error was uncovered in the "android.accounts.GrantCredentialsPermissionActivity" activity of android system. The "android.accounts.GrantCredentialsPermissionActivity" activity is an unprotected public component of the android system and can be initiated by sending an intent with appropriate input data (a.k.a intent extras). However it was observed that the "android.accounts.GrantCredentialsPermissionActivity" does not validate incoming intents to check if the intent has extras.

A malicious app can send an intent to the activity as shown below and cause the android system to crash with NullPointerException:

Intent i = new Intent();
i.setClassName("android", "android.accounts.GrantCredentialsPermissionActivity");
i.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(i);

This forces the system to reboot.
A malicious app can incorporate this vulnerability along with an SMSReceiver and BootReceiver Broadcast receivers to trigger a system reboot and force the system to keep rebooting. I was able to write a POC app which starts the reboot cycle upon receipt of an sms and force the system to reboot continuously, every time it comes back up.

The time duration between reboots is quite small (depending on device used) and does not allow the user to uninstall the application from settings. On a production device with stock/non-rooted build the only way to stop the reboot process would ideally be restoring the device to factory settings and wiping data partition.

Potential Fix:

Change GrantCredentialsPermissionActivity implementation to check whether extras retrieved from the intent is NULL or not:
   final Bundle extras = getIntent().getExtras();
mAccount = extras.getParcelable(EXTRAS_ACCOUNT);


Status:
This issue was reported first in Android core system running on 2.3.4. Google had responded immediately and informed me that they have fixed the issue. At the time of writing this blog,the issue was still at large even on Nexus S running 2.3.6 & 2.3.7.
The real question is: How long before this issue will be fixed on multiple fragmented releases by multiple vendors.

Popular posts from this blog

iPhone's Persistent Connection to Apple

By S G -
I recently noticed that iOS MDM servers have the ability to connect to phones and initiate checkins even when a device is connected to WiFi. Packet analysis showed absolutely no communication between Apple PUSH service or MDM servers with the phone. On the contrary, the transaction was always magically initiated by the iOS device. How could this happen? As we know, iOS devices have 2 NIC's - one for WiFi and the other for 3G communication. On further analysis, I was able to observe that even though the device switched over to the WiFi network, the 3G network interface of the device was still active in the background and maintained a persisten connection to apple PUSH servers at port 5223 . Hence, whenever Apple or MDM servers wanted to send a PUSH notification, the notification was sent over 3G and in response the device responds back over WiFi. A simple netstat on the device reveals the following: netstat -a tcp4 0 0 10.XXX.XXX.XXX.4XXXX nk11p01st-courie.5223 ESTABLISHED The 3G/E...
Read more

Gmail Session Management Vulnerability (Mobile Browsers)

By -
Mobile browsers and applications are gaining wide spread populrity with the evolution of iPhone, Android and other mobile platforms. Security has always played the catch-up game with evolution of technology. It was recently observed that gmail sessions opened using mobile browsers such as safari and Android webkit fails to invalidate the session id when a user logs outs. When a user logs out of gmail, the user is redirected to the login page and asked to re-enter the credentials. Though the end user sees a login page and cannot access inbox unless signed in again, the server session associated with the users login remains active at the server side and becomes an orphaned session. This flaw can be leveraged by an attacker to compromise a victims gmail account.
Read more