All right, guys, welcome back.
And so far we haven't talked about permissions and permissions.
I mean, this is a pretty important topic regarding to app hacking.
So therefore, let's do this over here.
Let's find out how the Android system is handling those applications or even better, sandboxing them.
So every application on the Android system is generally being sandboxed, which means application.
One cannot simply access the data of application two and application three.
And I mean, this is good.
Imagine having an Android system where every application can access the data of each other.
This means and third party application could simply access our banking data.
I mean, this would be horrible.
Well, for example, our photos, activating the microphone, taking pictures, stuff like this.
So this is something we do not want to have.
So how is the Android system handling all this stuff?
Well, it might be easier than you think.
I mean, we are having a Linux system and the Android system is simply just assigning and single user
for every application.
This is the whole magic behind this.
So every application gets its own user ID and this simply means if user one wants to access the data
of user tool and this will be simply denied and these permissions are being defined in a file in this
one in platform XML which is stored under ETSI permission.
So here we are having a file containing most of our users.
We will learn that not all can fit into this one, but more on this later.
Okay, so this file defines our user IDs and this is being individual for every application.
All right.
But now we are having the case that the application needs to exchange data between each other.
I mean, this could be, for example, accessing the photos or accessing the microphone, geolocation
or, for example, exchanging data between other applications based on content provider, broadcast
receiver.
We will learn more about this later.
So how is this being done right now?
Well, we could simply add user tool to our app one, for example, based on groups.
So this user tool will be now added to our application one, which means we are now having also access
to the data of application tool, for example, photos, microphone, camera, stuff like this.
All of this is being defined in the packages dot XML file.
So after adding a user to our application, this permission will be inserted over here and it's also
being tracked if the user has been granted this permission or not.
All right.
Okay.
So far so good.
We are having individual users and we can also add users to other applications.
Both of them are defined in those files.
But now we are having some some system users and those users needs to be active before the system is
running.
And these user IDs, for example, the ADB shell, this will be hardcoded into an kernel file in this
one over here.
So that will be defined that some users have some predefined IDs and they are not stored in those two
files above.
And also where those user applications start, for example, at ID 10,000.
But I mean, this is not that important right now.
And the important thing speak here right now is the package start XML file because this file gives us
access or even denies us the access to those permissions.
All right.
Okay.
So far so good.
But now it's the question, how can we ask for permission?
I mean, this is the most important part.
How can we access photos, camera, microphone and stuff like this of our Android system?
And the answer for this one is being defined in the Android manifest XML.
We have already seen this in the Android manifest before, but let's recap this very quick.
So this is an configuration file and in there we define all our permissions we want to access in our
application.
If we have not defined permission in there and we want to access the data, then the application will
crash, which means we cannot simply circumvent this until we are having, for example, root privileges
or an exploit like dirty pipe.
Dirty pipe is in race condition where an yeah and socket can write into an process which should be only
able to read.
And this could be this could be abused to override certain configuration file, for example, the package
does not exempt, but unless we are not having an exploit or root privileges, we cannot circumvent
this.
So we need to define our permissions over here.
All right.
If we define those permissions, these will be added into the packages, XML.
And for example, over here we have read context Internet and read external storage.
So these single user IDs will be defined over there.
They will be simply added.
And also there is some kind of tracking if the user has granted those permissions or not.
So this is how the Android system is handling this stuff.
Pretty nice, right?
Absolutely.
And so far, everything seems to be fine.
And regarding to the core system permissions, it is fine.
But what developers sometimes underestimate is custom permissions.
And this one, this can be absolutely ridiculous.
And we will also have examples regarding to this one.
So for now, if you fell asleep, no problem.
But.
Now you need to wake up because now it's interesting part.
Okay.
So you woke up perfect because now we talk about custom permission and this can be your pony under the
Christmas tree.
So what isn't custom permission?
I mean, applications can exchange data between each other.
For example, app one can share data with application tool.
But let's say these data are a little bit critical.
For example, it could be an one time password or in turn message from your banking application.
So therefore you want to make sure that those data are being protected and only application two is able
to access them.
How is this being done?
Well, with the custom permission.
And so far, we haven't talked about those four key components activities content provider, broadcast
receiver or services.
But I mean, it's also not that relevant right now.
We will do this later on extensively.
For now, we only need to consider that those are possibilities to exchange data between each other
and this is being defined in the Android manifest XML.
Okay, so far over here we are having our application one, this has now an custom permission and now
we need to be very precise on this one.
The custom permission, if it's being defined over here, does not start with user's permission because
it doesn't use this permission.
It's defining this one.
So if you find this tag permission, then we are having an Yeah most likely and custom permission which
is being defined in this app, which means this permission is protecting something in this application
over here we can see we've got this permission, then we've got this Android label.
This is, by the way, from the CE application, which we, I guess have seen so far.
Otherwise we will also have to look into this one.
But back to this one.
So this permission over here is being defined and now we are having a label allows reading of the key
and see Android name.
This is the name of this permission.
And then we've gotten protection.
LEMON In this case, dangerous.
And this is also a little bit misleading, but more on this later.
Okay, so here we have our first custom permission and this one is it's telling us allows reading of
the key and see.
So the key it's a table.
Yes it's in table.
And this table contains our passwords.
And if an application has this permission, it can access our passwords in our safe application over
here.
All right.
And this permission is being defined over here.
So this is something like, for example, like the context permission where we are using this user's
permission, contacts over here, we are now defining and complete own permission.
Right now, underneath we have another custom permission.
Here we have permission and broad label allows editing of the key and C and this means we can write
to this table right now.
This is the name here we have now right keys over here.
It was red keys.
Now we're having right keys.
And here once again, we have this protection level, okay?
And this means the application.
One can provide data to all applications, but only the ones having this permission.
This one over here are allowed to interact with this data.
All right.
If not, I guess this is absolutely no problem, because when we talk about content provider and we
do this pretty extensively, then this will be a little bit more clear right now.
So now the question, how can we as a third party application or as an attacking application can get
those permissions?
Well, we only have to define them in our application.
So over here we can see we can simply tell users permission.
And then instead of context, photos, microphone, we simply define those custom permissions of application
one.
And now if we have defined them in our application tool, we can simply ask nicely, Can I read your
keys?
Which means your passwords, credentials, stuff like this, and this application is now responding
back.
Yes, you ask that nicely.
You are allowed to do this.
So in custom permission is not being an and real protection for this one.
So you cannot protect your data based on a custom permission unless you choose the correct protection
level.
But now the question what is the correct protection level?
So far I can tell you dangerous.
It's not.
So what are those options we have as a developer?
Well, we've got the following.
We've got dangerous, normal signature and signature system.
But signature system is something we cannot use in our own apps.
So therefore we only focus on dangerous, normal and signature.
All right.
Protection level dangerous simply means the user needs to be informed about this, but this is all.
And then the user can make the decision if our application is allowed or denied to access the contracts.
I mean, yes, if the user denies everything, then we are not able to read out this stuff.
These contain.
Or maybe the keys in the custom permissions, but I mean, relying on a user decision if some critical
data can be accessed, I guess that's not the best idea.
But I mean, it's even better than normal because normal simply means we are not being informed about
this.
So that's another protection level.
For example, if you are using the Internet permission and this permission is not being displayed anywhere,
it's simply automatically being granted.
But I mean, yes, of course, we cannot simply use the protection level normal for some high sensitive
permission, like camera or microphone, for example.
But this is something we do not have to bother about because this is being done by the Android system
unless we define our own custom permission, because then we are in charge of this.
And if we would choose normal for some high risk permission, for example, accessing the databases,
keys, passwords and stuff like this.
And then this would be definitely a finding.
I mean, every application could access our data without the user being informed about this.
This would be bad.
So normal is definitely not the right option for sensitive permissions.
But I would also say dangerous.
It's it's really not the best case.
I mean, we are outsourcing such and such critical task to the user.
And this is something we should handle as a developer.
All right.
So what is better?
The best option would be signature, but there's a little bit of a downside regarding to this one.
Signature means every application that has been signed with the same key can access the data.
So this means if you write our own third party application and try to access, for example, those this
key database and this has been protected with the protection level signature and then we would need
the private key of the application owner of SIF to access this data.
And of course this is something we do not have.
And this is also the downside regarding to this one right now because protection level signature, I
mean, this is the best approach.
But I mean, we cannot share our private key.
This would be more ridiculous right now and therefore this might not be practical in the daily business.
And therefore, most of the time we have to deal with protection level dangerous, which means the user
is being informed about this, which is good, but if the user clicks over here, then all these data
are being gone, which could be absolutely bad for the user right now.
All right.
So this is everything we need to know about permissions in a nutshell right now.
It was a lot of theory.
And therefore, I would suggest let's recap this on practical view on our Ubuntu VM.
So let's dive into those permissions file.
Let's see what's inside there and let's recap this a little bit.
All righty.
Okay.
So I see you on the your point of view.
All right, here we are back at Ubuntu VM and now let's have some practical view on the whole topic.
So we start with the pre configured user IDs in our Android system and these are being defined in the
Android file system conflict.
H.
So within our kernel, we cannot simply access this and then file over here.
We have to take a look into the Android source code.
So let's do this.
So we are simply searching for Android file system conflict h in the browser of our choice in the search
engine of our choice.
And here we get the Android Google source code.
So let's open this one and here we have it.
So this is an predefined list in our kernel and this is defining some user IDs.
For example, the ID system has the user ID 1000 radio is 1001 and so on.
I mean, this can change depending on the manufacturer and the Android system we are using.
So here we can see this one is for version Android 4.2.
I guess regarding to our Google Pixel, this is still the same.
So the Bluetooth I guess still has 1002 and so on.
But nevertheless, I mean, if you want to be more precise regarding to our device, then we have to
look for the exact version and also the exact model and manufacturer.
So for now, we stick to this one.
All right, here we can see the camera has this user ID and so on.
Let's go down a little bit.
Yes, ADB, Shell, this one over here.
This is the ADB debug shell and this is the user ID 2000.
Let's verify this.
If you open a new terminal and making an ADB connection typing in ID, there we have it.
User ID 2000.
Perfect.
We can also see for example, net BT might be bluetooth admin 3001.
Yes, exactly.
Exactly what we can see over here in this one.
All right.
And then we've got a bunch of other stuff.
And this one is also pretty, pretty nice here.
We can see this is our first user app.
So our user application started the user ID 10,000 and it simply goes upwards.
This is just a definition.
Okay, user IDs start at 10,000 and every time we install a new application, this value will be increased.
And let's see.
Therefore, yeah, let's keep it open.
Okay.
Therefore we switch into the data data directory and if you perform an LZ dash l then we have no permission.
So we switch into the root context and do this once again.
And here we have this.
So let's see, do we find some, some user applications?
This one, for example, this one is the com MWI example C application and this one has now this strange
user ID.
So that's the user ID and the group.
So here we are having you zero underscore a 129 this is not some kind of alias.
So our user ID for this application is 10,129.
So we can substitute the eight with the 10,000.
We could also verify this within the package manager.
So the package manager so the package manager I guess has an option for this one.
Let's see.
Yes, over here.
So here we can see with the new option.
We can also show the package uid if we go up once again, we have talked about the C application which
has the user ID 10,129.
This A can be substituted.
So let's do this.
So let's, let's see if this is correct.
We are using p m list packages at this time with the dash uppercase u option.
This one list packages uppercase U well the package manager of course in front of this here we have
it and now we've got all these user IDs behind this.
And if you do not want to search for C, then we can also grep this and then we go, oh, there we go.
We, we have an and hacking application already there.
And you can also see we are doing something with logging bypass.
But this one, this is our C application.
So maybe let's do it this way, the exact package.
Okay, let's clear this and there we go.
So, so you already have a little bit of spoiler, but we're going to do further this course.
But for now, we can see, yes, we are having the user ID 10,129 and if we scroll up a little bit,
we can see that every application has its individual user ID.
All right.
And this is how the sandbox is being implemented.
Every application gets its own user ID.
So far, so good.
So now the question, where are those user IDs thought?
I mean, here we can see them, but there can be or where those being defined and this file we have
seen in the theory part but let's have a practical view on this one.
This was the ETSI permission platform XML.
Yes.
I mean, it's a little bit hard to read, but I guess it's still fine.
Let's scroll up a little bit.
There we go.
So here we can see, for example, the Android permission internet has this user ID, shell or OC.
Interesting.
Then we can see modify audio settings, has this user ID audio server and this one, this is being it's
being packed together.
So audio server, I mean, it's some kind of alias for this user id like this a 129 I guess regarding
to our c f application.
So therefore this UID over here is some kind of alias for this and we can see the audio server is being
packed together with all these permissions, which means if we grant this user ID to our application,
we have access to all these permissions over here.
Pretty cool, right?
And let's scroll up a little bit.
But I mean, yes, there's a lot of stuff in here.
For example, Red Locks.
This has the group ID lock over here, net admin, internet.
There we have it.
That's the group ID.
And over here.
Yes, here we have the user ID.
All right.
So, yes, I guess that's the that's the interesting part over here.
All right.
So this file contains our user IDs and group IDs.
All right.
But still, we do not have this matching.
So here those core permissions are being defined.
But now if we ask for one, how is this being added into our application?
Well, this is being defined in the package as XML, and this one is within the data system.
Packages exempt.
Yes.
So this file contains all necessary information for our application.
For example, the signing key permissions and stuff like this.
But I mean, let's simply have look into this one.
That's why we are here.
Okay.
Yes.
So that's a lot of stuff.
So therefore, let's copy a little bit out into a more readable format.
All right, here's the beginning and then let's open this studio code because there we have some XML
highlighting.
Yes.
So here we have this package as example, and we can see the Google Authenticator is using lot of stuff.
So therefore, let's not focus on core Android applications because they have lots of permission.
Let's stick to our C application.
So come and W are example.
See here for example, we can also see this was the custom permission we have seen in our Android manifest
example, at least on the theory part within these slides.
So this one is of course also being an and permission defined over here.
So as our contexts permission we can now ask for this, for this one over here and we can see protection
is being set to one, which was the protection level dangerous.
All right.
Okay.
But for now, let's stick to our or let's say let's go back to our see that we're here and we can see
maybe let's enable some word wrapping that we don't have to scroll.
Okay.
Now we have everything here.
Okay?
And this is our package name, our individual identifier for this app.
Then we've got the code path.
So this is base64 encoded.
But I mean, there's no real value behind this.
We can simply we can simply access this directory.
Maybe let's do this by inserting all these strange characters.
We shall first.
Yes.
So you can see this is a real directory path right now.
So then we've got our library.
So this, by the way, our APK file, then we've got some libraries, some other stuff, which is not
that important.
Here we have the user ID 10,129 exactly what we have seen in our in our listing.
And then this one over here, this is the certificate.
And I mean, this one needs to be included over here regarding to the protection level signature.
Protection level signature means we can give access to other applications that have the same signing
key and therefore this one needs to be stored over here.
If we now provide this protection level, this file, this package XML file has track off this one and
can make the decision of application three if this one is allowed to access the data or not already.
Okay.
And then we've got these permissions which this application is using here.
We can see permission, Internet, and this one is flex zero.
So this is the protection level normal, which means no certain user pop up or other stuff is being
required, it's automatically being granted.
And in case if you would have granted more permissions, then they will be also listed over here.
Let's go to another application.
Let's see, I guess our space pane application should be also here in the space ping.
Oh, unfortunately not then.
Insecure bank?
Yes.
So here we can see this is another app.
It's another capture the flag application.
And this one, I mean, the structure is the same.
We can see all the stuff over here, the Android app path, which is this one.
The package name native libraries signing key and this time we can see this app is using user credentials,
re profile, internet and network state and we can also see if those permissions has been granted or
not.
If we have root privileges, I mean, we can add all those permissions and we can then can set this
to true or false however we like.
But if we have permissions, I mean that then it's not required to access certain permissions in an
application.
Then we already have access to everything.
All right.
So if you want to add and let's say add all of them over here.
Yes.
With root privileges.
This would work all, for example, with the dirty pipe exploit.
This would also work, which might be a little bit more interesting right now.
But I guess if you can override or modify those system files, then you can achieve everything else
without modifying or accessing or entering some new permissions over here.
Okay.
So this is all right.
Now, regarding two permissions.
I mean, we have seen if we go back to this one within our data data directory, every application will
be assigned to an own user ID.
This user ID can be fetched via the package manager or within the packages XML.
Or if you're talking about core Android users, then within the what was it?
Yes.
The platform.
So this is how our our permission sandboxing concept works, which means this safe application over
here has this user ID and therefore it's not allowed to enter the data of this app until we give this
permission, for example, for a database.
This could be done by an content provider to access the data in a database.
If you provide this in custom permission and this application is using the custom permission, then
we are allowed to access those data.
So this is what we have seen over here, Red Keys and we have it.
There we have it.
So this isn't custom permission defined in the CV application.
Remember on the the android manifest example.
I will blend it in and if we assign this permission to our app, then we have to check the protection
level.
If it's dangerous and pop up might occur on older versions of this app.
This might not be the case, but on newer version and pop up will definitely appear.
But if the user grants this access, then we can we can interact with this app.
Alrighty.
Okay.
If not, don't worry.
If you talk about content provider, it will make SNAP and this part will be crystal clear.
I'm pretty sure about this one.
All right.
So now this is really all for this video in case if you have any questions, drop me a message under
the comments and otherwise.
I'm looking forward to see you in the next one.