So this video, we're going to take a look at it and secure data
storage. So there's a lot of different ways to try to
store data in Android applications. And a lot of the
may appear secure on the surface. However, with the proper
permissions in setups, you will be able to gain access to them,
as someone who is not supposed to gain access to them
which in turn can mean that you can compromise sensitive data
either from the user or from the
developers themselves. So this is horrific a two-sided. Vondra
bility. Incense of like, getting use
your data. It's a bit of a week or vulnerability because it
requires root access to be able to access mostly
files. There may be ways however, to get access
these files without Root permissions and that would be an indication
of a vulnerability. However, if there's specific like
developer secret data inside of these files and
were able to access them. Then this would be a vulnerability whether
or not we have root access because we shouldn't be able to get access
to those sort of secret data pieces, such as API keys,
in password, it sent that certificates.
So in this video will take a look at a few different types of up
on her abilities like this.
So the first one is at the investiture data storage part
1 with this, we can enter in say a
username and a password, and we
can save it onto our device. So we enter the username and password and
then we hit save that. It was a third-party credentials. Safe. Successfully.
We take a look at the code for this.
We can see that we received the credentials. It's using would call
the shirt preference that was shirt preferences. They're
sexually specific types of the files that exists
in a like in a standard directory and
these files will be able to store different pieces of information in
them. And the idea is that when we're trying to access, I
think that we can access it from an unknown location. That is
a certificate to the application and not accessible. Unless
you have root permissions. This works very well for
trying to store data, that isn't sensitive. So I don't
generally used by the application may be like location to
images or like a set of questions like a survey or
something like that. These are the things wouldn't be sensitive because
they're accessible by the user through the application.
If we can go to the user to
the application, this would be an instance of information
disclosure. So how do we gain access to
the shared preferences folder? What I'm going to do
is I'm going to go ahead and she'll into my
device.
Am I showing for my device? I'm going to go ahead and make myself a
Superuser using the Su command. And then
what we're going to do is we're going to CD into the data folder and then
it's tied up here. There's another beautiful there. So we're
Jada slashed data and it said, if you're go see data for
all of the applications that are on your device, to
all of these applications have data associated with them.
This one right here is the folder associated with
Diva. The name will always match the name of the application itself. So
we can CD into that folder.
You see, inside of here. We have a few different
options. Are the cast will be cold cash. We have databases to be
at the library, is ending ever shared preferences. The should
preferences is where we see Wild the data.
That's written using this shirt preferences objects, right?
So any time that we were going to be sleeping and sweatshirt
preferences folder. So now I buy CD into
shared preferences, you'll see that we have this single XML
file.
And if I use the cat command, I can see what's
inside of that file. I mean, alternatively, you could also
pull it off the device and read it, but on the cat command allows
you to see it quickly. And as you can see, it's toward the
username and password that we types it. So, whatever
we type in inside of there, will be with storage here. So for
instance, if I change this to password one for instance and
save it, then we should see that this will change
the password one, but you can see right
here.
So you can see that this would be considered insecure data storage because
I can gain access to it, just by having a rooted device
device that I have a rooted device is sort of irrelevant to
my likability to access this date. I should have be able to get
your Sims ID passwords, whether braided or not. So, this would
be an example of insecurity in a storage.
Right? And then you can go and take the other pieces like, you
know, the password really should be hashed or something like that. It in
the sense. It really doesn't matter with half your not cuz you can
offline force that password and potentially gaining access to it.
You know, how attached based on the, on the code since
we have access to the code, we have access to the password hash
therefore unhatching the password or
finding a house that corresponds to that password wouldn't necessarily be
hard unless the password to unlock but there
are certain instances where if we could do a quick password might
be able to compromise any gain access. So this is something to
know about these shared access points is that they're accessible by
users. So we really should be favoring things like online
servers. If we can or sort of
hardening these down like password protecting the files or password
protecting a database for instance, and I'm speaking
of the pieces we could take a look at database storage as well. So
let's go ahead and I'll go back here.
And we have a second and secure data storage so
I can put in my username and
password.
And again, I do this, I can save it and it will save it successfully. So,
we take a look at the code here. You can
see that were inserting the data into a
mi into a sequel, light database, right? So in
general, most databases that you work with through
Android or going to be sequel light, but you can also tell that because of the
import up here that says seek with light database that exposes what
kind of database is being used. So you can
give you this information is being saved you some sort of database then we can
ask. Well, where can we find that database, right?
And the answer is if we CD up when directory will see this
folder called databases. We going to the databases folder,
we can see that there's a bunch of different databases that
exists inside of here. Now, which of these databases
is the correct one. And we
really just have to sort of look at the different things
that are available here. You'll see open or create database IDs, to
the tells us that the IDS to database is
the one that were likely looking for. So I can do
is, I can see a sequel, light 3 IDs to.
And as you can see, this opens up the IDS to
database inside of SQL light. And from
here, you can take me to come in like. Tea bowls and
that will show you the table that exist in the database. And then we can
do just like a simple Flex car from my user. And
you can see it exposes any users that were
in, put it into this input field. Right? So I did the test went
earlier username and password was the one that I just did. So you
can see that this very easily exposes the user.
So again, since I can access this.
It isn't considered to be a secure data storage method because
even though I have access doesn't really mean much
if I can access the data still, you know, whether you
can access it with Ruth, but you can access it without root access to
sensitive data, which you shouldn't be able to do. So, this is
something that we need to consider as well as that these databases have
been properly, secured could be compromised. The
proper thing to do here is to use a library on
the roof. You like a sequel safer? For
instance, I think is one that's available for Android. And what
they'll do with the password? Protect these databases for you through
like an encrypted process to anytime to
access it needs to sort of like decrypted and then run
or queries and then encrypted again, so if this
is done, then if we tracked it to his people like 3 and won't
be able to, we have to actually cracked the encryption on the database and
encryption is sufficiently strong. Then
it would be a much more secure data storage benches
stirring stuff in plain text out in the open, right? This
is another thing to consider and this is
Before we consider the fact that it looks like, this could easily be like
I'm victimized of SQL injection rate. You could probably do
SQL injection, cuz we just can't at knitting stuff into it,
but that will be something for another like, yeah. So
this would be another example of semantic. Your data
storage is, if we store things in the databases that are
available to us. I really do user. Can still gain access to them and potentially
get to those credentials.
That was their type of insecure. Data storage is sort
of like a more generic type of insecure storage
again. It's the same sort of structure. We
have username and password.
Eddie, can save it and get the credentials, see if
successfully. But if we take a look at this really all this
does is it creates a temp file? You see, as you info
in front of its and it says it's readable writable and
then it right to the username and password and saves it. So, when
this sort of thing happens, we're essentially saving
it. Local to that data folder. And you can tell
that because I'm so it's get up with Kitchen in photo editor. Is
this data directory that we're currently inside of semen,
we do this. You'll be able to see that I can quit out
of SQL light. And if I CD
up One Directory, you'll see this, you info folder. That's
now been created. And again, I can simply just
cat that folder and you'll
get username and password great. So you can see that it
again to seize the data in plain text, even
though it's in a directory that can only be accessible by
Route. The data is still there and accessible so
you can so we can access to it. So this gives you a good idea of the
different types of insecurity to storage that exist.
General. If you're looking at any sensitive data,
that is stored inside of databases. And so, does shift preferences or
just inside of folders, anywhere, a root user
can gain access to them. So it was folder should be treated with
the same level of security that someone is able to access them if
they so choose to. So you can keep in that in mind
and work with things like encrypted files are encrypted
data bases. In order to ensure that people can't actually access the
day because I'm leaving it out in the open means that
if you have a rear diffuser, who's using your application, they can
gain access to that data, which could potentially be catastrophic if
any website that has access to both are right. If it's just
their username and password. It's not really that big of a deal, but if it's
other people's names are passwords or generic information
about like the application application
using two passwords and usernames and passwords any of
that stuff that we don't want that to be stored here
because then you can get access to it.
52 idea. What to look for for these sort of things up. I
give me to decompile the application. You can look at things likes, your
preferences and file rates and a database inserts, to
find these sorts of vulnerabilities. Or in
general. We can just refused the up a little bit and then go to. It said, they
did director and see what kind of stuff is available inside of there. So, these
are some common fund abilities that will typically exist inside of
Android applications that you are now able to find and
report if you find them.