Welcome to a module an application attacks this module will deal with typical threats that are representative
of the perils that jeopardize modern applications.
First we'll take a look at three of the most widespread attacks.
The first exploits a buffer overflow vulnerability this type of attack aims to take control over or
control the execution of a program run by a user and exploits a flaw of an application causing it to
react in ways that were not provided for by the developers when entering some types of input.
The second class of the most prevailing application attacks is as a query manipulation or as fuel injection
most modern applications are in fact databased the majority of them store configuration data or working
data that is subsequently processed on servers.
We're not talking here strictly about databases.
The servers don't even have to be separate services in process servers servers that are launched by
an application itself have gained popularity.
There are still however classed as database servers and still communications are performed as well.
The third type is cross-site scripting.
This attack has been ranked as the most popular threat for years now.
Cross-site scripting relies on inserting a code on a Web site or in a modified link to a Web site in
hopes that visitors will run the code this hope is not without grounds.
Since web browsers follow a protocol according to the protocol browsers should interpret all the data
that a web server sense to them and execute or render them in the correct way.
The data can also include code that is not directly stored on a page.
We'll start with the buffer overflow.
The general idea for this attack is that it should enable attackers to take control over a program a
perfect scenario would include the program executing an attackers code the attacker doesn't need to
have access to the program source code.
This would be the best solution.
Not only to modify the program but also force it to execute arbitrary operations prepared by attackers
some questions seem to come up at this point.
First how can you change the operation of a program that is compiled.
We're referring here to languages like C and C plus plus the languages where the code is first compiled
to a binary version and only then is a distributed.
You can't change the code of such programs directly but you can control its execution.
This is possible because for an operating system for a PC or a processor program code is not different
from data.
It's simply strings of zeros and ones loaded into memory somewhere.
It's interpretation of the zeros and ones that matters.
A buffer overflow attack might take the following form.
We have a compiled program for example.
Any X-C file and want to run it the program has to be loaded into memory an operating system allocates
a place on the stack for the program since it has to control the program in some way.
The stack will contain the program's function headers and control register values.
The registers will include AS-P were the address of a currently executed function will be located and
V.I.P which indicates the data buffer of a currently executed function
as we'll see in a moment.
Apart from the program data a stack includes also data pertaining to program execution.
It also contains the values of local variables and function call arguments.
This is crucial.
Note that program structures and use a data structures meet in one buffer area user data is the input
stored into a program.
Let's take a look at a graphical representation of this.
We have a sample function that anticipates a string and will operate on the pointer of that string.
The length of the string is specified which could cause problems and assumption is that this link will
be 128 bytes.
What will happen though if the data exceeds the size we've prepared 128 bytes of space in the stack.
What's going to happen if the user will submit a longer string than assumed.
The data will overflow the buffer and consequently overwrite the other stack areas.
A stack is a FIFO structure.
What's important in the image above is that a given area has been allocated and the data located there
is too much.
The data needs to be placed somewhere it overrides adjacent areas that are behind them in the stack.
The areas were reserved for other data for example for functions that control execution.
If a program's execution reaches the point pictured above which means that the function completes him
will try to return control to the original program.
You will have to know the address of the function that called it and assumption is that this address
is in the location pictured.
This is not true as it turns out the area is now overwritten with other data.
The type of data depends on the length of the input string and the data that was contained in the input
as a consequence.
Once the function ceases to operate execution controlling for a given program does not return to the
call function but is instead located in some other place.
The question is what place in the easiest case the code parameter is not a simple string but a fragment
of code that an attacker wanted to run the location of the code was specially selected to overwrite
control registers.
At this point the program we run executes a malicious code supplied by an attacker.
Consider this potential attack scenario.
Step one to exploit a buffer overflow flaw is to locate insertion points a program's interface has to
be able to receive data from US and return information on handling the data.
For example prompt error messages
once we've located such insertion points restart checking if they're vulnerable to buffer overflow attack.
We don't do this on a victim's computer however since we don't have control over the program and consequently
can't monitor live events and reactions to various types of input.
This would be both time consuming and easy to detect although it would not prove much of a real problem.
If the software is typical for example it's an FPP server.
We only need to install on our local PC the same version of the server connection will be established
through a debugger that will give us access to all required data overriding control registers that managed
program execution.
For example IP register is the key stage of this attack
a function's return address is the value that will be overwritten the so-called opcode standard operation
codes will be a valuable aid in this making use of them.
We won't need to check for our location to override an address manually by trial and error instead will
find a table that specifies that a given DML holds IP register addresses at a specific system address
opcode documentation's are publicly available.
At any rate we need to find the end of a stack.
How much has been allocated for a program in the stack.
The selected program should at all times be held in the same location in main memory.
Ideally the software should always be running on a victim's computer.
This is how system services operate as well as operating system fragments and so on.
You can improve your odds by padding a buffer with no operation instructions.
In this way even if you failed to find the exact desired address space the address that has the beginning
of your malicious code ACP will go through the instructions one after another until it slides to your
executable code.
This technique is known as a slide up slide is a fairly common method used to increase the chance of
successfully running buffer overflow attacks.
The last step is to insert malicious code up to this point.
We have successfully controlled or monitored program execution we know which memory address holds return
addresses and we know the locations of other addresses that we want to overwrite.
Once you enter an address in this location the new address we submitted should hold a fragment of code.
We need to add a payload to the.