So in that case take a look at issues that are related to input validation.
So when we ever get like input from a user we should be validating that input in whatever way that we
can.
So we should be like sanitizing make sure that they don't input anything that's vulnerable or that could
potentially lead to an exploit essentially.
So there are a few different types of input validation errors that can occur inside of interest up.
So we're going to take a look at a few common ones right now.
So for the first set of input validations they have to do with database validation.
So when we're inputting things into this we can see that for instance if I put a user here and press
search we'll see user not found.
So you can see it will echo back would it ever r r value that input it is.
And it will tell us that it's not found or it will echo back at the details that the user presumably
if we had put one that is found if we're looking for the code that's related to this we can go to sequel
injection activity and this will show us exactly what's going on.
So as you can see here it's doing a raw query against the database.
And this is the query that's actually happening and you can actually see that when it encounters an
exception it's going to actually show the exception in the error log.
So this means that if we go in to our log cut which I've got opened here an Android Studio when I input
in something invalid.
So for instance some a very good example of this for testing purposes would be like a single quote a
single code is a piece of sequel syntax visit turpitude like code it should cause an error.
See when I search this we've got this error here that's an unrecognized token.
This tells us that we're interpreting that token as code rather than interpreting it as an input.
So this means immediately to me that this is vulnerable to sequel injection.
So let's take a look at how we can craft sequel injection with this.
We have access to the query here and again this isn't an uncommon thing if we can d compile the code
we can gain access to the queries and as you can see our input is going in right here so comes in right
in the middle here running between two single quotes.
What that tells me is that if I can end the single quote and then input something that's always true
and then maybe put a comment at the end that will allow me to execute where a user equals blank or C
one equals one which is always true which will return to me the whole database back.
So let's take a look at exactly what that looks like if I put the closing quote here.
This will close the user's input and then we'll say or s it or 1 equals 1 and then we can put a comment
so those two dashes at the end is a comment or 1 equals 1 is something that's always true.
And the closing single quote would close off this starting quote here.
So B user equals blank or 1 equals 1.
And if he comments that this and breached here are this end single quote.
Here is an interpret it as code and in doing this it will give us a valid query and valid query is going
to return to us all of the contents inside of the database c c when I click search here it exposes the
whole database credentials.
Right.
So you can see that this is an example of being able to leak information from a database using an invalid
input.
So sequence directions are a very common type of input validation error that happens in a lot of different
instances so this would be one example and this is one thing that you're always able to sort of test.
I'm not always where you get the error is actually printing into the log it's actually quite rare that
someone would give you that.
However again if you just sort of like search for raw query or query in general you should be able to
find instances where this sort of thing happens.
So this is one type of input validation that's relatively common.
I'm going to show you another type of input validation that is rather interesting and a bit different.
So with this one here you see that we can type in a U or L to view.
So if I put it like Google dot S.A. for instance if I press a view you see it brings up the web page
for Google.
So this is just like a simple web browser.
And if we go into the code of it we can get a bit of a better idea of what's actually happening.
C.C. here we have the input validation scheme.
You see that it just does a load you around.
Now on the surface this probably looks quite innocent because load your l would imply to us that we're
just loading any sort of you know web page you roll.
However the interesting point here is that in Android we actually treat files as you heard Alice as
well.
So you can actually access files on the system using the you are all path of them.
So for instance you could do something like this you could say file you go colon and then you put three
back slashes and then you put in the D path to the file.
So we'll see data data for instance.
I'm going to pick a file that I know exists.
So this is inside of the data files that we're looking at.
We were taking a look at insecure storage and we know that there is one here called a card up seemed
to underscore preferences that eczema.
You could see it just put in the whole path of the end of the file itself and now it just crashed there
so let's try that one more time.
Not sure why it crashed there.
We'll give this another try.
There are some instances where this app may crash on you.
It's not overly common but it could be from some other testing that I was doing related to this app
for input validation.
But let's go ahead and try this.
Diva preferences exit no.
You'll see when I click on view here it actually displays the file below here.
So if you remember this is the file that we created in the end.
Improper storage.
So this shows us how we can actually access that storage without necessarily even having root permissions.
If we happen to know this path which they wouldn't be unreasonable for us to know it if we have a really
device we can find it very easily or we can find it through the code we can actually access it if there's
ever like a browser that happens to take in these file parts for instance.
So this is a very critical vulnerability because it allows for information leaks and we can get to really
any sort of file on the system utilizing this and we might even be able to access this from other applications
if it has like a provider that allows us to launch this activity maybe.
Right.
So this is a very common and critical vulnerability.
So this is the type of input validation that you can look out for something as passed like a web page
utilizing this whole this load you are.
It's very possible that we'll be able to load internal user rails which are actually past the files.
So this is another type of common input validation.
Again.
So we have databases and we have your URL loading the third type of input validation is a little bit
different.
And the way that it essentially works is by calling external libraries.
So we'll see here is this uses the D J and I func are not function but class rather and you'll see that
it uses a very specific piece initiate launch sequence.
So what's interesting about this is that if we go to this sum to this input validation three we're able
to use we're able to put in some inputs and attempt to get it to launch and you'll see it gets this
access denied it in these cases.
What we're actually able to do with this is since it's loading a shared object library it means that
it's probably written in C or C++ C and C++ or relatively infamous for buffer overflows if you can input
something way too big into this input.
We may be able to get it to overflow.
So for instance if I just type in like a whole bunch of these and I pushed the red button you'll see
the application crashes when an application crashes like that it tells us that there could potentially
be a problem and it might be related to a buffer overflow if we want to get a bit more detail we can
actually go back into the log catalogs and I'm assuming it's probably going to give us some information
inside of here when we try to crash this.
So let's try this again yeah you'll see there we got the whole lake sort of dump.
So this right here is what we would call a stock trace essentially.
So you can see it gives us a lot of information here.
The main things that you want to get here is that you see the parts of the stock that we've actually
accessed so we can see that we're actually overflowing the stock here and you can see that it's giving
us some errors related to that.
Now what happens here is if we get actually specially crafter input we may be able to get the device
to execute code which may be able to get us access to execute code under the permissions of the application
itself.
And this would be an extremely critical vulnerability.
This is like a CBS as ten point show but even just getting them the stack overflow to happen creates
a very critical vulnerability as well.
So oftentimes like with Java it's not very common to see a stack overflow.
But if you're using C C++ libraries or languages similar to that where you have to do memory management
this is definitely something that's in the possibilities.
So if you're able to find something like this it's an extremely critical vulnerability.
And again the things that you want to look out for for this is any sort of class that is loading a shared
object.
So this deejay and I class we talked about this earlier in this series but you see that it has like
this load library right.
Any time you see that load library you might be loading ISO files which are typically C C++.
Now one other thing that I will note about this is that we rent.
When we rent strings against this library one of the strings that came up was SDR TR C.P. y or string
copy string copy is one of those C functions that is infamous for buffer overflows if things are allocated
properly.
So those are the sort of instances where we can actually utilize strings to see what kind of functions
might be getting called it reveals to us you know the function that's getting called which is s t RCP
wire string copyright.
So and we can see that when that is use it seems like it's causing the buffer overflow.
So it seems like that string copy is what's causing that sort of problem to actually get remote code
execution is a fairly more complex topic.
It won't be one that we'll talk about in this but I wanted to demonstrate how you might be able to identify
those sort of problems in an Android application to be able to report them because again even just finding
a buffer overflow like that is a critical vulnerability.
So this gives you an idea of a few different types of input validations that might commonly be found
in Android applications.
So any of these issues in general are very critical because they mostly allow you to access things you
shouldn't be able to or potentially do remote code execution.
So they're all very critical vulnerabilities in all ones that you should be able to relatively easily
find if they do exist in an application.
So this gives you certain some of the fundamentals to be able to locate those.