Applications are everywhere now.
The first question to ask you is what is an application and how do we attack it.
Now if you're an old guy like me an application was something that came on a CD and you installed it
on your machine or you downloaded it from the Internet and then you went through some installation process
and that's certainly an application and lots of organizations still do stuff like that.
Lots of in-house applications for database work or whatever they might have.
But I want to stress that there is an entire other class of applications where I'm talking about our
web apps.
So today with things like Google Maps or Dropbox or even slither dot IO are all applications in a very
real sense of the word.
But we access them through the web itself.
Now in this episode I want to talk about attacking apps in a generic way.
So we're just going to talk about some conceptual ideas of how apps are attacked but I'm going to save
the whole discussion of web apps in a completely separate episode so let's keep it kind of generic at
this point as we talk about attacking apps.
Now the first thing a lot of people ask me is what Mike how do we attack an application when it's easy.
It depends on the application.
If it's a web app I can usually just type something that you are Ehle box that's weird that the server
isn't anticipating or I might have a form that pops up and I can type something weird into a form that
causes havoc or if I really want to be evil I can grab my colleague Linux and there's lots and lots
of injection tools built into that toolset that allow me to create all kinds of naughty things that
I might want to do.
So there's lots and lots of different ways to actually attack an application.
So what I want to concentrate on though right now is how do we actually do these attacks.
And I'd like to start with probably one of the most common and most popular injection attacks
an injection attack simply means that you add some extra stuff into your input into an application that
does potentially naughty things.
Now there's a lot of different ways to do injection attacks.
And the first one I want to talk about is what I'm going to call a code injection a code injection simply
means that somehow you add extra code to the application to make it do stuff that it isn't designed
to do.
There's lots of examples of this but right here is one of my favorites.
This is a fellow named Seth bling who took a super any system.
This was in 2016.
So he takes a super NEA system and taken advantage of vulnerabilities in the super And yes he literally
clicks around using the controllers and adds code and changes.
This Super Mario Brothers game into flappy birds.
Now a command injection uses the application to get to the underlying operating system.
Now this is going to be very specific to the operating system.
You might be using So to help you out.
I've developed a very simplistic and very flawed form that we enter data into.
And if we take a look at this if I type my name and then I'm going to type in this double ampersand
and a linux command and if I hit enter it actually goes to a terminal.
This is not a good thing.
Most applications I should be careful when I say most but a huge percentage of applications are really
nothing more than front end for databases.
If we want to do a lot of stuff of keeping track of things or whatever we're doing.
Databases are very very important and probably the most common type of way to talk to a database is
through structured query language better known as S..
Q Well now as well is a wildly complicated incredibly powerful queering language for Eski Well compliant
databases.
So I'm not going to ask you to memorize a ton of sequel commands but I do want you to look for stuff
like this.
Commands like inner join select from insert into all of these types of words are clues that you're looking
at some form of sequel query.
In fact here's an example of an incredibly complicated sequel query right here.
Now to do a sequel injection Let's bring that form back up.
And in this case I can do something fairly trivial.
For example I'm going to type something into one of these fields that I'm just going to say.
Select asterisked from last name.
So basically I'm saying show me all of the last names and what happens really depends on the application
itself and how well it's protected.
Now the last type of injection I want to talk about is El Deppe injections.
Now L DEP stands for lightweight directory access protocol and eldership is a way to query directories.
Most large networks especially if you're running Windows is going to have some type of directory basis
for storing usernames and passwords and computers and locations and printers and groups and whatever
you might have.
So a lot of applications that want to get a username and password then it can store this by themselves
where they're going to do is they're going to use Elda app queries to talk to something to go ahead
and do some authentication or whatever it might be.
Now elde apps been around for a long long time.
It's based on the X-Com 500 which you need to know for the exam and it works fantastically well uses
tailless encryption all kinds of stuff like that.
But the challenge we can run into is that poor and we formed applications can be taken advantage of.
By putting all that information in where we shouldn't be doing it and creating eldership injections.
Now before we get into this I don't want to turn you to an el DEP expert but I do want to make sure
you understand what the structure of different objects in a directory look like so let's take a look
at this.
So what I've got written out here is a complete listing for one person in my directory.
So this entire thing is known as the distinguished name.
Now you read these actually from right to left but I'm just going to go from left to right because well
I'm a human being so N stands for the common name.
So if I'm querying a particular user or a particular printer or a computer it is going to be just the
name itself.
Now will also then have organizational units that's what all these o use are for.
So all use if you're in a Windows world.
They can be easily thought of as groups but they help to define where John Smith is within my organization
and then at the very end you're going to see what we call domain components and that's because pretty
much everybody is a part of some domain.
So I can read this and read it from right to left I can see some interesting things.
So might top level domain as dot com.
So it's total Semb dot com.
This person is a people.
This person is in Dallas.
This person works for accounting and this person's name is John Smith.
So an application might take this type of information so we'll put in our form and we'll type in the
user name and stuff like that and hit enter and they'll go ahead and query a domain controller to authenticate
this person.
But the actual authentication the actual query itself might look something like this.
Now that's great.
But imagine if I took that same form and I took this one particular field and I typed in this L damp
injection Basically I'm saying as my name is admin and my password is everything.
What that will do really depends on the actual system itself.
Now those are the injection attacks that you're going to see generically on the exam but that's not
the only way to attack an application.
What I want to do is go through a couple of other examples and let's do I don't know how about buffer
overflow.
Every time you enter data into an application it goes into a buffer a buffer is just a part of memory
that's set aside to store the data before it actually gets put into the application itself.
So a buffer overflow simply means to enter so much data into the buffer that the buffer blows up.
So what we can do here is like if we take a look at this little application here so in a particular
field I'm just going to start typing one letter zillions of times earn it and with any kind of luck
I can lock the system up.
The last one I want to talk about is integer overflow.
Any variable that's stored within an application usually is declared at the beginning of the application
itself.
So if you're going to have a age variable and that age variable is going to go from 1 to 110 and if
somebody is 100 and 11 Well they're not getting your application whatever the case might be the actual
value is fixed in size.
So it might be for example a to byte integer values.
So in this case it's only going to be able to store 16 bits and heaven forbid you put in 18 bits.
You never know what's going to happen.
So it's really really important to be comfortable with your bits and bytes.
Now probably the best way to show you exactly how this works is I'm going to use my calculator here
on my phone itself.
So I'm going to type in a big value here.
Really big you and I'm going to do some of the power on that and make it even bigger equals and you
can see I've generated an error.
So this is a great example of an integer overflow it just can't handle these types of values so we need
to be careful about these things on the exam.
Watch for questions or talk about I've got a variable of X number of bytes and you've got these number
of bits and it doesn't fit and that's going to be a good clue that you're running into these types of
problems.
OK so we've gone through a number of different ways to attack applications.
Now in later episodes I'm going to be showing you.
Well first of all we're going to be talking about web apps in particular and some of the things we can
do there but in later episodes we're also going to be talking about how do we hardener applications
to prevent stuff exactly like this from happening to your apps.