All right, guys.
Broadcast receiver.
We have talked a little bit about them, but now let's find out what they are, how they work, and
most importantly, how to exploit them.
Alrighty, and let's have a look.
So those broadcast receivers on an Android system are pretty amazing.
It's some kind of notification system for your applications.
Let's say we've got a lot of applications running on our smartphone right now.
I mean, maybe we do not have to assume this because this is most of the time the case.
So we've got some mail, some calculator and also some music application.
We are now listening to some music within our music application and we are connecting some headphones
to our smartphone right now.
This is an event and the smartphone is receiving this event and it's broadcasting this event to every
application.
This is a broadcast message, so every application will be informed that some headphones has been connected
the email application, the calculator application, our music application and the SMS application.
Some of them might say, What the heck, I really don't care about this one and simply ignore this.
But our music application really takes care about this event because we can now react to this one.
If we are not connecting some headphones, we can react in the on receive method to this event.
So within the on receive method we are saying okay, if some headphones are being connected, then do
something.
We could for example, pause the music, we could lower the volume or we can we can tune it up to make
it heavily loud, which makes absolutely no sense.
But we could.
All right.
So this is in broadcast receiver in a nutshell.
An event happens on the smartphone.
The smartphone is informing every application about this event.
And within our application, we can react to this one in the on receive method.
Alrighty.
Okay.
Perfect.
The time window we have is, I guess about 5 seconds.
But don't quote me on this one.
After a certain amount of time, this this broadcast event is gone like it has never happened in newer
versions.
We can extend this time window because we can we can do asynchronous broadcast events.
But this is nothing we have to take care about as an attacker.
This is something the developer has to bother with.
So now might be the question what what other types of events are we having on our smartphone?
But the smartphone is informing every application about it.
Well, we've got tons of other events.
Another one would be, for example, if the battery is running low, this is the system event which
gets broadcasted to every application.
And this is also pretty important.
I mean, if you are now in developer and we have we have a huge stack in our application which has not
been saved and the smartphone is running low on battery.
We might want to save this right now because if the smartphone gets shut down, we might lose some information
in our application.
And this is something we definitely do not want to have.
So running low on battery is also an event which will be sent to every application.
Besides this, we've got lots of other things.
For example, if we are entering the airplane mode, if the Wi-Fi connection changes, if you're changing
the time zone in the smartphone, if you are connecting something via USB, if we are doing something
with the camera, if some package is being deployed on the smartphone, if you are dealing with Bluetooth.
So if we are having a pairing request things like this, so you can see there are a lot of broadcasts
out there.
So these are all system broadcast events.
But we can also define our own our own custom broadcast event so we can define our own sending and receiving
method and then we can use this to send out our own broadcast event.
I mean, other applications might not react to this one because they they do not know this custom event,
but this can be used to to exchange information between applications.
We will have a look into this one and custom broadcast receivers in in a moment.
For now, let's talk about all broadcasts first because this is also pretty important.
What are broadcast events have some sort of priority in there, which means let's say we've got these
these three applications, we've got our system, SMS application, we've got our own application which
wants to read SMS.
This is absolutely perfectly fine if the user gives the permission and we've gotten banking application
which is waiting for those ten numbers now we can define a certain priority for these applications.
I mean, this is being done by the developer.
So the developer is putting some priority into a certain file.
And the file we are talking about is the Android manifest example.
So here we are defining our own priority of our of our broadcast receiver.
Okay.
So now is the question, where is the difference?
Well, let's say an SMS arrives at the smartphone and this is also a broadcast event.
But this time right now, not all applications are being informed about this one, only the one with
the highest priority in this case, it's the system SMS application.
So at this point over here and now it has this tricky part in this application, which receives this
event first can make a decision if it wants to forward this event to all lower privileged application.
In this case, for example, our own application.
If it does, then we have now the decision to.
Forward it to the banking application or not, we can this line this event.
Then the banking application doesn't realize that an SMS has been received right now.
So this is how an order broadcast works.
We've gotten certain priority.
The developer is giving the priority by himself and then the application can make the decision to forward
this event to all lower privileged or not.
So this can be absolutely ridiculous.
And in the past it was because an Android 4.3.
Yes, it's super old I guess 2010 11 but there was a huge, huge vulnerability regarding to this one
because within Android 4.3, you could make an application and you can set the priority to 999, which
was higher than the system SMS application.
And nowadays this absolutely ridiculous part, if the smartphone is now receiving this SMS, the attacker
is having this SMS first, and the attacker can make the decision to inform the system SMS application
about this event so the attacker could this line this.
And then the smartphone is not showing any evidence that an SMS has been received right now.
There was no signal, no audio and no pop up regarding to this one.
And now imagine at the given time what what was possible?
I mean, the attacker could read an SMS and it could also make the decision to forward it.
Let's say we've gotten banking application and the banking application is waiting for foreign transaction
number in ten.
The attacker is receiving this time right now.
And then the attacker could make the decision if the banking application should receive this stun or
not.
I mean, absolutely ridiculous, right?
If the attacker has also compromised the banking account of this given person, then the attacker could
use this ton and the user even doesn't realize what's going on over here.
So the user might be ordering a second turn which the attacker could simply forwarded to the user.
And the user thinks something was strange, but now I've got my ton.
But this doesn't work anymore and the money has gone.
So this was an absolutely huge vulnerability which has been fixed in Android 4.4.
Those type of vulnerabilities might not occur that often anymore, at least for system applications,
but there can be pretty likely or cure in custom applications.
So if the custom application is setting an end priority in the middle US, an attacker might be able
to set an higher priority and then you can tamper around with this one.
I guess now it's limited to 100, but I'm also not 100% sure about this one.
At least it's not 999 anymore.
Okay, so far so good.
I guess we've gotten good feeling about broadcast events right now.
We know if an event happens on the smartphone, the smartphone is informing those applications about
this event.
It can be all it can be just in single application and we can have an order broadcast, which means
there's some kind of priority in this notification chain.
Alrighty.
Okay.
The main question right now might be, where do we have to look for those broadcast events?
So as an attacker, how do we find out which event this application is listening to?
For example, this mail application might not take care about some headphones being connected.
So where do we find this information?
And the answer is over here in the Android manifest XML, at least for Android applications till version
eight.
So in Android version eight, there was a huge change regarding through this progress and this did catch
me absolutely off guard.
So this was yeah, this was a little bit pain.
But don't worry, we are doing both.
We're doing the old approach which has been defined in the Android Manifest XML, and we are also doing
the new approach that you are well prepared for modern applications right now.
Alrighty.
Okay, perfect.
Let's just look into applications which which are lower than Android version eight.
Then we have to take a look into the Android manifest XML because here we have no the definition as
an receiver.
So we've got our receiver text within those receiver text.
We've got, for example, the Android name, my broadcast receiver.
So this is the Java class where this broadcast receiver has been defined.
If we are taking a look into this one, we will find the application code regarding to this broadcast
receiver.
Also the receiver method, which is the most important method if we are analyzing and broadcast receiver.
Alrighty.
Okay, perfect.
Next, we've got those intent feeders and these are pretty important in many ways.
The first important thing is having those content filters means we are having an implicit export through.
So this broadcast receiver is now being exported and of course it has to be exported because otherwise
it couldn't reach or receive those intents, so it wouldn't even recognize that an event has happened.
This is also the case by most or barely.
All broadcast receivers are being exported to the outside world, which might make them vulnerable to
attacks.
And this is why broadcast receivers are pretty important in our application and analysis.
So the intent filter is now exporting this broadcast receiver to the outside world that it can react
to those intents.
And it's listening into the smartphone and it's now waiting for those three actions we've got.
He bought lock boot completed and quick boot power on.
All of them are regarding to the booting process of the smartphone.
So when the smartphone has been finished booting, the smartphone is informing those applications which
are listening to this event about this process.
So the smartphone is sending one of them three, only two of them to those applications.
The question might be why be having three actions for only one single task?
And the answer for this one is manufacturers.
Manufacturers can define their own broadcast events.
And if we want to have an application which is compatible to many manufacturers, we have to include
all of them.
So there might be only one in ten, for example, this boot intent being sent out.
But yeah, it might depend on the on the manufacturer.
So as an attacker, we do not take care too much about this because this is also, again, the developer
part.
The developer has to make sure that this application is being compatible to other manufacturers and
has to take care about all these different intents.
Alrighty.
Okay.
We as an attacker, we simply look them up and then we know what this application is listening to.
All right.
And yeah, this is all.
So we are having the Java class, my broadcast receiver, we are having those intent filter, which
means our class is being exported and we are listening to three actions right now to those three.
Okay.
Beside those actions, we once again could have the following.
We could have category and also data included into this intent folder.
But most of the time we are simply just dealing with action.
So the action is the most important part over here.
OC Sending and receiving those intents can be also combined to permissions.
So within our application, if you want to listen to this intent, we need to have the permission in
our Android manifest receive boot completed because this is something the user needs to be informed
about it because this could be easily used in malicious application.
It doesn't mean if an application is using this permission that it is automatically being malicious.
But this is some kind of auto task to run our application after and system report.
So if we are having our attacking application, we do not need to wait until the user opens this app.
We could define and service which will be started when this broadcast event will be received and this
service is running silently in the background so the user doesn't realize that this application has
been started.
It's like running the auto task on an Windows system.
So every time you reboot the system, the other task is automatically starting or executing in program.
And also over here there can be absolute valid use cases, but of course this can be also used regarding
to malware and therefore we need to have this permission.
Another example would be regarding to incoming calls if you're not having this permission set in our
Android application, but would have the ability to tamper with this in broadcast events.
I mean, this would be absolutely hilarious, right?
So an attacker could make an application which is not requesting the calling permission, but could
tamper with this one.
Therefore, this is of course not possible.
We have to set this permission and then we can also receive and interact with those broadcast events
regarding to incoming outgoing calls.
Alrighty.
So far we keep in mind we've got our intent folder within the intent folder, we've got our actions
and these are those intense where we are listening to those intents can have certain permissions.
This could be system permissions, what could be also user permissions tied to them.
So if you want to use them, we have to request those permissions.
All right.
But this approach is unfortunately outdated to version eight.
So this is not working anymore.
You get some error, background execution is not allowed, and therefore we have to define it in the
Java code directly and it looks like this.
So within the Java code we've got now this registered receiver and this is taking two arguments.
The first one is the name, the name of the broadcast receiver we want to register.
In this case it's my broadcast.
The second parameter is an intent filter.
So the thing we have defined in the Android manifest would be now defined in the Java code.
So here we are providing as a parameter our action name in this case boot.
In case if you want to have more actions, of course we could apply more actions in there.
Then we've got our broadcast receiver, my broadcast, which is defining a new broadcast receiver and
then we've got again our own receiver method which is containing the code.
So this is now the new approach and we have to deal with a lot of things right now.
So the first one is the application needs to run because if the application is not running, then we
are not having our Java code registering our broadcast receiver.
So background execution is not being allowed anymore.
The second challenge is if you're using automated tools, they might not have been updated regarding
to this approach.
So if they try to identify broadcast receivers, they might simply take a look into the Android manifest
example, but not into the application code, which means we could miss some stuff and this is why we
are here.
Because here we will learn the backgrounds about this one and now we can deal with this on our own.
So in case if the automated tool is missing something, we can look it up manually, at least in the
reverse engineering section.
We will learn how to decompile applications and have a look into this application code.
And then we would be able to identify methods like registered receiver or on receive methods.
Alrighty.
Okay.
So if you're using automated tools, make sure that they are working with the newest approaches.
I mean, newest regarding to Android eight.
But yes, this might not be the case for all those tools out there right now and some of them might
not be even further developed.
So therefore, using automated tools, absolutely no problem.
But make sure that they are working correctly.
Alrighty.
Okay.
So now we know how to identify the broadcast receivers for and give an application.
We need to take a look into the Android manifest example or within the Java code directly to see which
actions has been defined, so to which actions this application is listening to.
Now, what's the question?
How can we exploit them?
And the answer for this one is it depends.
So if you're having a look into this one, triggering and broadcast receiver can be done by malicious
application running on the smartphone or it can be done by the ADB shell directly.
So for testing, the ADB shell is absolutely fine.
But regarding to in practical attack vector, I would assume it has to be malicious application because
if you have ADB access, you might not need to trigger and broadcast event.
All righty.
Okay.
So if you're triggering broadcast event, the question is what can go wrong?
One answer to this one is if we apply some sensitive information in our intent, so a broadcast event
will be sent by an intent, which means we can also apply data to this event like this one over here.
So we can we can put some strings into this broadcast event, and then this would be sent out to every
application an attacker can listen to this one and is receiving this this intent.
And in this case, the attacker could simply fetch the token which has been transferred via this broadcast
event.
So one thing we have to look for are sensitive information being stored in those intents.
I mean, we have seen this in the intent sniffing part.
This is exactly what we are having.
Also here, another problem could be within the permissions.
So the developers defining and custom permission, which is required by an application to receive or
send those broadcast events, we as an attacker could simply claim this permission if it has not been
proper secured.
It's only been proper secured if it's using protection level signature.
Everything else is is not in the control of the developer anymore.
We talk about this protection level signature in the signing section.
Then we will go through what this means.
So far, it's simply just means that both applications have to be signed with the same key, and this
is something the attacker cannot fake, so an attacker cannot spoof this permission.
So the attacker cannot simply claim that the attacking application has been signed with the same private
key.
This is not the case, and therefore the attacker could also not tamper around with those broadcast
events unless if the attacker has root privileges.
But then we are having some other problems.
Okay.
To sum this up, if the attacker does not have root privileges and the protection level is being signature,
then the attacker cannot interact with this broadcast receiver.
But if this is simply just an custom permission like this one over here, then the attacker can include
this permission into its own application.
And then the attacker would be able again to receive and send those broadcast events.
So the vulnerability could be the following.
The developer has included this custom permission into its own application and relies on this one that
no one else can claim.
This one over here.
So this is a misunderstanding that still happens nowadays.
This custom permission can be now claimed by an attacker.
It depends on the protection level.
Sometimes it's being set to dangerous, which means the user has to accept this.
But even then I wouldn't rely on that.
The user does realize what's going on over here and never gives the attacker permission to perform this
task.
If the attacker has now claimed this permission, the attacker can trigger this broadcast event and
cause the sensitive interaction.
For example, regarding to an alarm system, this arm or arm and system, or regarding to this one over
here, read out and sensitive token.
So the vulnerability depends on the application code of the developer.
And once again, we only have to take a look into the on receive method, then we will find out what
is being triggered and then we will also find out which which input is being used from this broadcast
event.
And so for example, if it's using some tokens stored in a string like this one over here.
All right.
Okay.
Last but not least, we could have something like local broadcast manager.
And this one is an broadcast event that only happens in the internal application.
So this doesn't reach the outside world.
It can be used to.
Exchange information between certain classes, activities, services, stuff like this.
So we can use broadcast events to exchange data within our application or to exchange data with other
applications outside our application context.
From our attacking point of view, we simply skip local broadcast manager because we cannot interact
with them from the outside world.
So these broadcast receivers are within the sandbox of this application.
We cannot interact with them.
Alrighty.
Okay.
So this was now a lot of theory and a lot of input to sum this up.
This will be this will be super quick.
All we need to know is the following.
The only method we can interact with is the on receive method.
And there we have to take a look into what we can do.
Having a broadcast receiver doesn't automatically mean is some kind of exploit or vulnerability in there.
If this on receive method is simply just printing out and hello world then we could trigger hello world.
But this is not a vulnerability.
We have to take a look at which code is being defined in the on receive method and we also have to take
care about the input this method is receiving.
We will do all of this in a practical example afterwards, so don't worry if it's now a little bit confusing.
All you need to know if you analyze, analyzing, broadcast receiver, have a look into the receiver
method, that's the only method you need to take care about.
All right.
Last but not least, to identify those broadcast receivers, we have to take a look into the Android
Manifest XML.
And if there is no broadcast receiver defined, it doesn't mean that this application is not using in
broadcast receiver.
We also have to take look into the Java code.
I mean, we can sum this up, have a look into the Java code, into the on receiver method.
This is all you need to do.
We will learn about reverse engineering an Android application in the reversing section so that we will
talk about the compiling and application, restoring the Java code, identifying the receiver method
and things like this.
Okay, this is all for this video.
So as already mentioned, it was a lot of theory, but we will sum this up with some practical example.
Then we will identify the broadcast receivers and we will also see how to trigger certain actions and
how to exploit mobility.
Alrighty.
Okay.
So I'm looking forward to see you there.