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.
Authors: Marco Lux, Pedro Umbelino
Browsing the code, you can get an idea about its purpose:
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:
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.
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.
For the audience to play, test and execute the vulnerability we provide the following tools:
- Test application “CRT-Kolme” (includes CVE-2013-6272 and CVE-2014-N/A)
- Exploits to use with drozer
- Manual drozer testing commandlines
You can download “Curesec Research Team – Kolme (Callmeh)” at
Source Code: http://www.curesec.com/data/CRT-Kolme.7z
After installation just click on the Curesec Logo and the testscreen will appear:
Choose the SDK you want to test. If your phone is vulnerable, it will call the number 31337:
In this section we provide a description to exploit the CVE-2013-6272 issue provided exploits for drozer.
Drozer Commandline Foo
Hangup an ongoing call or conduct a phone call:
In order to make the codes work, you can use the following command:
The usual # symbol for the MMI codes has to be replaced by %23 to work properly.
FAQ1. 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?
|10/24/2013||Initial Report of CVE-2013-6272 by Curesec||Curesec|
|10/24/2013||Forwarded to the dedicated Team by Google|
|11/11/2013||Engineers working on the issue|
|17/01/2014||Engineers still working on the issue|
|23/01/2014||Issue is reported to be patched and integrated the next two weeks.|
|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)