Solving PIVAA part 3: Exploiting Broadcast Receiver ~(˘▾˘~) (day 56)

In this post, we are going to take a look at some of the bad practices for implementing broadcast receivers in the android applications. Before we got our hands dirty, we need to review some basic in the broadcast receiver and once it's done I will show you how to take advantage of this vulnerability

Background:

A broadcast receiver is considered as one of the four pillars components in the android application(Activity, Services, Broadcast Receiver, Content Provider). Its responsibility is to listen to all of the events inside the android device and if it's matches the current parameters inside the Broadcast Receiver it will trigger something in the application.

Example broadcast receiver can be taken from "low battery" warning if the battery is going low the broadcast receiver gets a notification from the android device through system event and because it matches with the parameter inside its function it will pop up a warning message that shows the battery is running low.

But how the attacker can abuse this mechanism?

simple! like any other android component, the broadcast receiver can be set to export it means any application inside the device can interact with it if the android developer is not careful with how they set the permission it can be abused by other malicious applications.

For demonstration, we are going to tackle PIVAA android application again (https://github.com/HTBridge/pivaa)

Exported Broadcast Receivers

The mobile application contains an exported receiver enabling other applications, including malicious ones, to send intents without restrictions. By default, Broadcast Receivers is exported in Android, as a result, any application will be able to send an intent to the Broadcast Receiver of the application. To define which applications can send intents to mobile application's Broadcast Receiver set relevant permissions in the Android Manifest file.

Getting your hands dirty:

First, let's do some reconnaissance on the application broadcast receiver using drozer.

running app.broadcast.info will show the broadcast receiver permission and from the result contained in the above figure it was set to null this means the function can be invoked by any application inside the device. We can also verify the result is true by checking the androidmanifest.xml

Let's dig deeper in the application we can analyze the broadcast receiver by going to the "VulnerableReceiver" class inside the handler directory like the below figure (if you want to get the source code you either can download from GitHub or use enjarify and Procyon decompiler)

open the file and there is an "onReceive" class that responsible to collect all of the broadcast send to the application.

there are two parameters that the class expect to get, first is location and data. the class get the value of the parameters using ".getStringExtra" from intent class. Once they get the two parameters the stringExtra variable that contains location will be used by the class to create a file:

FileOutputStream(StringExtra)

if there is an exception it will show a log.

after the class creates a file it will the content with a stringExtra2 variable that contains data along with the date object.

From the collected information that we got from the previous analysis, we can take advantage of this vulnerability to tamper with the file that was created by the application.

you can use drozer, adb or build your own application to exploit this component.

Let's start with drozer:

In the first try, I'm just going to put some random data and see what the application behaves when I put this data.

As the application gets the data it seems it caught an exception show that the location or file does not exist. But if you execute the above command the application will pop a text show the data that we insert. Okay let's try another input

Broadcast.html is the file that was created by the application I try to put the name of the file in the second try and as you can see it does not work, it looks like we need to provide a full path of the file

Cool, so we get the right input in the third try let's try to check the "broadcast.html" if we able to tamper the file

Another approach we can try is to use adb shell command and if we try execute the command below, we successfully again tamper the file again :)

You can take it to the next level by creating a malicious application that will tamper the file again.

using this code of kotlin, run it we can see from the figure below it successfully tamper the data again LOL. I make the application really simple this is just quick and dirty solution for this challenge.