Applications are everywhere. Now, the first question I need to ask you is, what is an application? And well, 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 when I'm talking about our web apps. So today with things like Google Maps, or Dropbox, or even slither.io are all applications in the 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 say 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, well, Mike, how do we attack an application? Well, it's easy. It depends on the application. If it's a web app, I can easily just type something in the URL box.
It'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 Kali Linux. And there's lots and lots of injection tools built into that tool set 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. Now, there's lots of examples of this. But right here is one of my favorites. This is a fella named Seth bling, who took a super ns system. This was in 2016.
So he takes a Super NES system and taking advantage of vulnerabilities in the Super NES. 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 SQL. Now, SQL is a wildly complicated, incredibly powerful query language. for SQL compliant databases, so I'm not going to ask you to memorize a ton of SQL 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 SQL query. In fact, here's an example of an incredibly complicated SQL query right here. Now, to do a SQL 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.
And I'm just going to say select asterisk 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 LDAP injections now LDAP stands for Lightweight Directory access protocol and LDAP is a way to create 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, they're not going to store this by themselves.
What they're going to do is they're going to use LDAP queries to talk to something to go ahead and do some authentication or whatever it might be. Now LDAP spin around for a long, long time. It's based on the x dot 500, which you need to know for the exam. And it works fantastically well uses TLS encryption, all kinds of stuff like that. But the challenge we can run into is that poorly formed applications can be taken advantage of by putting LDAP information in where we shouldn't be doing it and creating LDAP injections. Now, before we get into this, I don't want to turn you into an LDAP expert, but I do 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 cn stands for the common name. So if I'm querying a particular user or a particular printer or computer, there's going to be just the name itself.
Now, we'll also then have organizational units. That's what all these Oh user 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 from right to left I can see some interesting things. So my top level domain is calm. So it's total sim.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 here we'll put in our form, and we'll type in the username 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 LDAP injection. Basically, what I'm saying is, 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 applicant. What I want to do is go through a couple 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. 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 You're going to have a age variable, and that age variable is going to go from one to 110. And if somebody is 111, well, they're not going to use your application, whatever the case might be, the actual value is fixed in size. So it might be, for example, a two byte integer value. So in this case, it's only going to be able to store 16 bits. And heaven forbid, you put an 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 gonna use my calculator here on my phone itself. So I'm going to type in a big value here, really big value. And I'm going to do something to the x 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 to talk about. I've got a variable of X number of bytes, and you've got these number of bits and doesn't fit. And that's going to be a good clue that you're running into these types of problems. Okay, 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 harden our applications to prevent stuff exactly like this from happening to your apps.