So in this video we're gonna take a look at insecure data storage so there's a lot of different ways
to try to store data in Android applications and a lot of them may appear secure on the surface.
However with the proper permissions and 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 sort of a two sided vulnerability intensive like getting user data.
It's a bit of a weaker vulnerability because it requires access to be able to access most of these files.
There may be ways however to get access to these files without permissions and that would be an indication
of a vulnerability.
However if there's specific like developer secret data inside of these files and we're able to access
them then this would be a vulnerability whether or not we have access because we shouldn't be able to
get access to those sort of secret data pieces such as api keys and passwords and that sort of good
stuff.
So in this video we'll take a look at a few different types of vulnerabilities like this.
So the first one is the encrypted your data storage part one.
With this we can enter in say a user name and a password and we can save it onto our device.
So we enter the username and password and then we hit safe and it will say third party credentials saved
successfully.
We take a look at the code for this.
We can see that when we see the credentials it's using what's called a shared preference.
Now with shirt preferences they're essentially specific type to 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 data we can access it from a known location.
That is a sort of local to the application and not accessible unless you have permissions.
This works very well for trying to store data that isn't sensitive so I don't I would just like data
that's generally used by the application maybe like locations of images or like a set of questions like
a survey or something like that.
These sort of things wouldn't be sensitive because they're accessible by the user through the application.
However if we can access something that isn't accessible to the user through the application this would
be an instance of information disclosure.
So how do we gain access to these shared preferences folder.
What I'm going to do is I'm going to go ahead and shell into my device and when I challenge my device
I'm going to go ahead and make myself a super user using the s you command.
And then what we're gonna do is we're gonna see into the Data folder and then inside of here there's
another data folder.
So we're a data slash data and inside of here you'll see data for all of the applications that are on
your device.
So 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 C.D. into that folder you'll see inside of here we have a few different options you have the
cash.
We have the code cache we have databases we have the libraries and then we have our shared preferences
the shared preferences is where we save all the data that's ready.
Using this shared preferences object.
Right.
So anytime that we do this we're gonna be saving it that shared preferences folder.
So now if I C.D. into shared preferences you'll see that we have this single excel 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 stores the user name and password
that we typed in.
So whatever we type in inside of there will be what's stored here.
So for instance I might change this to password one for instance and save it.
Then we should see that this will change to password one which 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 routed device.
The fact that I have a good device is sort of irrelevant to my like ability to access this data.
I shouldn't be able to get usernames and passwords whether I read it or not.
So this would be an example of insecure data storage.
Right.
And then you can go into like the other pieces like you know the password really should be hashed or
something like that.
In this sense it really doesn't matter of a task or not because you can all find brute force that password
and potentially gain access to it and you'd know how it's hash based on the the code.
Since we have access to the code we have access to the password hash.
Therefore on hashing the password or finding the house that corresponds to that password wouldn't necessarily
be hard and thus the password is extremely long.
But there are certain instances where it could be like a weak password you might be able to compromise
it and gain access.
So this is something to know about these shared access points is that they are 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 speaking of databases 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 insecure data storage.
So in this one again I can put in my username and password and again when I do this I can save it and
it will save it successfully.
So if we take a look at the code here you can see that we're inserting the data into a mine into a secret
light database.
Right.
So in general most databases that you work with through Android are going to be sequel lite but you
can also tell that because of the import up here that's a sequel like database that exposes what kind
of database is being used.
So you can see that this information is being saved to some sort of database and we can ask well where
can we find that database.
Right.
And the answer is if we see the upward directory we'll see this folder called databases.
If we go into the databases folder we can see that there's a bunch of different databases that exists
inside of here.
Now we want to determine 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 I.D. too.
This tells us that the I.D. to database is the one that we're likely looking for.
So what I can do is I can see sequel like three I.D. two.
And as you can see this opens up the I.D. to database inside of sequel light.
And then from here you can type in a command like dot tables and that'll show you the tables that exist
in the database and then we can do just like a simple select star from my user and you can see it exposes
any users that were input it into this input field right.
So I did the test one 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 data 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 route whether you can access it without it you're still able to access sensitive
data which you shouldn't be able to do.
So this is something that we need to consider as well is that these databases if they aren't properly
secured could be compromised.
The proper thing to do here is to use a library.
There are a few like a sequel cipher for instance I think is one that's available for Android and what
they'll do is they'll password protect these databases for you through like an encrypted process.
So any time that we need to access it it needs to sort of like decrypted and then run our queries and
then encrypted again.
So if this is done then we tried to access it to the sequel like three command.
We won't be able to we have to actually crack the encryption on the database.
And if that encryption is sufficiently strong then it would be a much more secure data storage than
just storing stuff in plain text out in the open.
Right.
So this is another thing to consider and this is even before we consider the fact that it looks like
this could easily be like a victimize of sequel injection.
Right.
You could probably do sequence action because you just can count naming stuff into it but that will
be something for another lesson anyhow.
Yeah.
So this would be another example of some insecure data storage is if we store things in these databases
that are available to us a really user can still gain access to them and potentially get to those credentials.
Now the third type of insecure data storage is sort of like a more generic type of insecure storage.
Again it's the same sort of structure where we have user name and we have password.
And again we can save it and get the credential safe successfully.
But if we take a look at this really all this does is it creates a temp file.
You see it has you info in front of it and it sets it to readable and write a book and then it writes
in 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.
So it's got application info data after data.
There is this data directory that we're currently inside of.
So when we do this you'll be able to see that I can let's quit out of sequel light and if I see up one
directory you'll see this you info temp folder that's now been created.
And again I can simply just cut that folder and you'll get user name and password rate so you can see
that it again just the data in plain text even though it's in a directory that can only be accessible
by route the data is still up there and accessible.
So you can still get access to it.
So this gives you a good idea of the different types of insecure data storage that exists so in general
if you're looking at any sensitive data that is stored inside of databases instead of shared preferences
or just inside of temp folders anywhere a user can gain access to them.
So those folders should be treated with the same level of security that someone is able to access them
if they so choose to.
So you have to keep that in mind and work with things like encrypted files or encrypted databases in
order to ensure that people can't actually access this data because leaving it out in the open means
that if you have a routed user who's using your application they can gain access to that data which
could potentially be catastrophic depending on what kind of data is accessible there.
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
usernames or passwords or generic information about like the application application usernames and passwords
and usernames and passwords any of that sort of stuff then we don't want that to be stored here because
then you can gain access to it.
This gives you an idea of what to look for for these sort of things.
Again we decompose the application you can look at things like share preferences and file rates and
database inserts to find these sorts of vulnerabilities or in general you can just sort of use the up
a little bit and then go to its data directory and see what kind of stuff is available inside of there.
So these are some common vulnerabilities that will typically exist inside of Android applications that
you are now able to find and report if you find them.