Last but not least, content provider.
And then we have finished our four key components of an Android application.
Then we know everything in an Android manifest.
Amazing.
Right?
So let's have a look into this one.
And content provider is simply providing content, as the name suggests in most cases or nearly all
cases, we are talking about databases, for example, contacts in a smartphone.
These are being stored in a database.
And we have an content provider for this database, which means we can interact with them via an content
URI, this one over here.
And the first part is simply just the prefix which signals the smartphone or the application that we
are dealing with in content provider.
So we are having content code on slash slash.
This is, by the way, an excellent keyword if you reverse engineer Android applications.
So if you search for this keyword, you may be able to identify those content providers pretty easily.
All right.
Next, we've got the authority and this is simply just a unique identifier for our content provider.
So we cannot have multiple content providers with the same name.
Let's imagine we are having com android contacts several times on our smartphone.
We would know which one we want to call.
Therefore, this name needs to be unique and therefore in common approach simply using the package identifier
for this unique name.
But it's simply just name.
It doesn't mean anything.
All right.
After this one, we've got the table entry.
So this is in this case, the contacts table.
And last but not least, we've got the slash tool, which means we are getting the second entry or the
second row of this table all in once.
It would mean we're having the following Here's our contacts database and we are now selecting the second
entry out of this out of this database.
So in this case, Peter Smith phone and the email address.
The question is now how can we interact with those content provider?
Because if you remember, content providers are being excluded from intents.
So we cannot simply use our content approach like we have done this in the other three parts in activities,
broadcast receivers and services within content provider.
We have to do it differently.
The easiest way might be simply using the ADB shell because beside the activity manager we are also
having a content provider in there.
So we could simply use content query and then we provide the URI of the entry we want to query.
Okay, but what if we are not having access to the ADB shell?
So let's say we want to write our own malicious application like we have done this in the broadcast
receiver section two took very uncertain entry to fetch these data.
Well, then we have to do it in the following way.
So here we are having now the contacts database or the contacts application.
And if we now want to query these contacts in our own application, we need to do this within content
resolver.
And this sounds now a little bit complex, but let's make this together so we will master this part
right now, okay?
In our own application, we need to define and content resolver and this content resolver is now asking
this content provider to provide the content to us.
This is why the name perfectly fits content provider.
So if we are having the permissions and if this part is being exported through, then we can access
this.
So these are our two use cases which we have in all components right now activities, broadcast receivers,
services.
And also here, if the user has given the permission to our application to access these contacts database,
then by asking it, the content provider is returning back and cursor to this database.
And what this cursor does is it simply just in pointer to in database entry or maybe a database selection,
for example, this one over here.
So here we are having now an pointer to the first row of our database.
Okay.
The content provider must include the following methods which can be now used by our application to
interact with this database so we can query, update, insert or delete.
We can also lock this down a little bit, but this is most of the time not the case.
Okay, so this is the whole concept.
In our own application we are defining in content resolver.
We are asking the content provider to provide an entry to the database and then we can use the methods
query update, insert delete to interact with this one.
Alrighty, perfect.
And one last note over here.
If we are dealing with custom content providers, then those databases are being stored in the data
data directory.
So we're having data data, then the package identifier slash DB there, we will have the whole database
being stored.
And if this one has not been encrypted, then we can simply download it and analyze it with SQL light
or a square light browser, whatever you like.
You can also choose other tools, but these are.
The most common ones.
Okay.
And if this database is being encrypted, then we have several options in case if it's being encrypted
via a user provided data, for example, and password and key pin, something like this, then it will
be hard.
But if you start in this application and the database is automatically being decrypted, then there
needs to be all the stuff available in this application.
So we need to have the algorithm on keys, certificates, whatever is required.
And within the reversing section, we will have to look into an encryption algorithm and very popular
ones, which is as so that we will learn how to deal with the things like this.
Okay.
So now I would suggest let's have a look into encoding example.
So how does the source code regarding to an content provider looks like that?
We know what we are dealing with.
All right.
So on the left, we've got our application and on the right we've got our checking application which
wants to get access to this content provider.
If we ask nicely, then the content providers returning this cursor and we can interact with this one.
Okay, here we are now having the very method of this content provider and we can see it's returning
our cursor.
Alright, but within the query we've got now a lots of parameters, we've got URI, we've got protection,
we've got selection, we've got selection ax and we've got sort order.
So one, two, three, four, five parameters in this query method.
Well so this sounds like an and complex method and indeed it might be, but this one comes down to a
single SQL syntax, which is super amazing.
So all these five parameters are being transformed into an SQL statement like this one over here.
So we are having select projection our second parameter.
So this is our selection argument from table name.
This is our URI where selection equals selection ax.
Both parameters are three and four are given over here ordered by sort order.
So all these parameters are being transformed into an SQL statement.
And if you're talking about scaled statements, there's one type of attack that that immediately catches
me, which is SQL injection.
And indeed, this is this might be possible in content providers, but to be honest, it's not that
dangerous.
Like we're having this in Web applications right now.
Nevertheless, let's talk about it.
So here we're having now this select statement.
Let's insert some values into our query method and see what happens.
Okay.
So here we have now our query.
We've got this URI, which is our, our content prefix authority name and then the table name, which
is news.
In this case, we can already tell.
We try to we try to query the table news.
Maybe we want to fetch some news of our application.
So simply just like, okay, what's up to date right now?
The next parameter, our operation is our payload and we skip this for now.
So we simply we simply just handle this as payload and the other ones will be filled with null.
So if you're taking the SQL statement from the last slide, then we are having the following.
We've got select prediction from URI, where selection equals selection ax order by sort order.
Let's insert all those null values because this will be irrelevant in our syntax.
All right.
We are getting the following select projection from URI and now we're having their null equals null
order by null.
So everything after from URI is irrelevant.
Okay, let's simplify the statement.
This means we would get the following and select projection from Uri.
So far so good.
In our case.
Right now we are fetching we are fetching news information, for example, some headlines, dates,
timestamps and things like this.
So now let's see how we can turn this one into a different query based on an SQL injection within an
SQL injection.
And then take us able to insert own SQL code into an existing query and transform this into a completely
new one.
Let's say instead of the news, we want to access the user table regarding to usernames and passwords.
How can we do this?
Well, all we need to do is inserting the following payload.
If we're inserting the following payload, our SQL syntax will transform into the following select asterisks
from user semicolon and those dashed dash the make and comment out of everything which is following.
So we are simply just saying everything behind this dash.
Dash is in common and we end our SQL syntax exactly over here, which means instead of covering the
news, we are now querying the user's table.
And yeah, in this case we would fetch all these information first name, last name, password and email.
All right.
So it's absolutely ridiculous, right?
Yes, and it is.
But there's a little bit of downside.
To be honest, I haven't encountered an SQL injection within a content provider which was really exploitable.
Why?
Because most of the time they develop as giving you access to the database anyway.
So if we get access to the news table, then we might have also access to the users table.
It's pretty unlikely and super rare that developers are locking tables like this down.
So therefore, if you would have critical data, they might be stored into two different, completely
separated databases.
And having an SQL injection in the In the Lane database doesn't provide us any any further information.
Nevertheless, it's definitely something we should check out.
Okay.
To sum this up, if you want to attack the content provider, we need to make sure that we're having
the permissions.
I mean, regarding to system permissions.
Okay.
We can ask the user to give this in case of custom permissions.
We can include us into our own application if it's not being protection level signature.
Okay.
All right.
Beside this, we also need to make sure that the content provider is being exported.
I mean, here we are not having content filters.
We are only having exported equals.
True, because content providers are not being invoked via intents.
If we want to interact with an content provider in our own application, we have to define and content
resolver and ask the content provider to give us the content.
If this is the case, then most of the time we get access to the whole database, which makes SQL injections
possible, but most of the time not that useful for us because we can vary those information anyway.
Developers are separating these critical databases and do not provide us access to this.
But nevertheless, these are all things we have to check if we are dealing with an content provider.
Okay.
Besides, in interacting with databases, content provider can be also used in combination with files
so we can read and write to and file.
And this gives us new attack vectors, which is pretty amazing for the attacker and a little bit unfortunate
for the developer.
So these vulnerabilities can be a huge threat to the application and they are still exist in common
applications nowadays.
So Google is, of course, aware of this and also of the threat of this vulnerability.
And Google will deny the upload to the play store for those type of applications.
So it might get less relevant in the future.
But let's imagine how many apps we've got out there right now.
And this might also take a while until Google is addressing this globally.
Beside the play store, I mean, there also exist a lot of other stores and they might not check those
applications for this type of vulnerability, which means it can be still in threat also in the future.
Let's imagine you've got some some mobile application on an vehicle or within your Iot system or whatever
else.
So these applications might not be downloaded from the official store.
They might have custom stores.
And therefore, this this type of vulnerability, I guess it won't be fixed within the next three,
five years right now.
So now we know there could be a huge vulnerability in the interaction with files and I would suggest
let's find it out.
Okay.
And here we have a music application which defines the following content provider.
We can see it is exported, which makes it possible to interact with it from a third party application.
In our case, we're having our own application on the right.
Okay, now let's assume we are having the following use case.
The music application takes a file from our own application and starts playing it.
Therefore, within the interaction of the content provider, we are providing a URI which is addressing
our file in the following scheme in content, colon slash slash authority slash filing.
The music application is resolving this URI and accessing the file.
And in this case, for example, playing it.
Okay, so far everything seems to be fine, right?
Well, not at all.
Let's see through the eyes of an attacker, if we can determine the file name by not choosing a file
from the internal directory of this application.
So the protected context directory of the zip.
We're talking about the data.
Data directory.
Do you still remember our alarm application with the pin xml file in our preferences?
Of course you do.
And you know what?
We can now make the application opening this file for us so we can simply provide this in the following
way.
So in content, colon, slash, slash our authority and then slash file and modify the simply just in
path traversal which goes back one directory entering the share preferences and opening the pin xml.
Depending on the code, the application is displaying this content or it's returning this content back
to our own application, which would be even more amazing for an attacker right now because this would
be exploitable remotely.
So we could use this content scheme to access every file in the protected data directory of this application.
Amazing, right?
Absolutely.
So how all of this works, we will find out in the next couple of videos.
So within the first one, we will perform our SQL injection and in the second one, we will have an
look into a path traversal vulnerability accessing those files and we will also have look into a real
world example.
So in 2020, Trend Micro did analyze and card your application and they identified exactly this type
of vulnerability in their I guess the data which was accessible was not that sensitive.
But of course this depends from application to application.
Alrighty.
Okay.
So I guess we have seen everything in the theory right now and let's exercise this a little bit.
Let's find out how to exploit this content provider.
So therefore, I'm looking forward to see you in the next video.