A look at exploiting vulnerabilities

As I was looking forward to continuing to discuss this topic, let me tell you a bit of history, theory and practice on vulnerabilities. We have all heard by now that security flaws can cost a lot, we all know that we must keep our software up to date, we all know that many updates are caused by security errors. But today I will tell you a little about how these errors are found and exploited 🙂 But before this we are going to clarify a few details in order to have a better overview.

Before starting

First I want to tell you that we are going to focus on the first vulnerability that I learned to exploit, the known Buffer Overflows, in this vulnerability we take advantage of a lack of memory verification to do fun things 🙂 But let's clarify a little more about it.

This is not going to be a real world scenario

I can't afford to teach them to break any program they see - first because it's dangerous for their computers, second because that would take more than my usual quota of words.

We go on a trip to the 80s

What I am going to show you I can do on my laptop, but it does not mean that it can be done today in a simple way 🙂 many of these concepts have already been exploited so many times that new protection methods and new methods to evade them have emerged 😛 but that returns us to the same place, there is no space to be able to tell all that 🙂

It may not work on your processor

Although I am going to use a very simple example, I want it to be quite clear from the beginning that the details of this are so many and so varied that just as it can come out the same as me, if you want to try it, the desired effect may also not be achieved 🙂 But you can imagine that I cannot explain that in this space, especially because with this introduction I have already taken more than 300 words, so we get straight to our point.

What is a Buffer Overflow

To answer this we first have to understand the first half of this combination.

Buffers

As everything is about memory in a computer, it is logical that there must be some type of information container. When we talk about inputs o outputs, we come directly to the concept of buffers. To keep it short, a buffer It is a memory space of defined size in which we are going to store a quantity of information, simple 🙂

Overflows occur, as the name implies, when a buffer fills with more information than it can handle. But why is this important?

Stack

Also known as stacks, they are an abstract data type in which we can stack information, their main characteristic is that they have an ordering LIFO (Last In First Out). Let's think for a second about a stack of plates, we put them on top one by one, and then we take them out one by one from the top, this makes the last plate that we have put (the one that is at the top) is the first plate that we are going to take out, obviously if we can only take out one plate at a time and we decide to do it in that order: P.

Now that you know these two concepts, we have to put them in order. Stacks are important because each program we run has its own execution stack. But this stack has a particular characteristic, grows down. The only thing you need to know about this is that while a program is running, when a function is called, the stack goes from a number X in memory to a number (Xn). But in order to continue we must understand one more concept.

Pointers

This is a concept that drives many programmers crazy when they start in the world of C, in fact the great power of C programming is due in part to the use of pointers. To keep it simple, a pointer points to a memory address. This sounds complex, but it is not so complex, we all have RAM in our machines right? Well this can be defined as a consecutive arrangement of blocks, these locations are normally expressed in hexadecimal numbers (from 0 to 9 and then from A to F, such as 0x0, 0x1, 0x6, 0xA, 0xF, 0x10). Here as a curious note, 0x10 DO NOT is equal to 10 😛 if we convert it to decimal order it would be the same as saying 15. This is something that also confuses more than one at first, but let's get down to it.

Records!

Processors work with a number of records, which work to transmit locations from physical memory to the processor, for architectures that use 64-bits, the number of registers is large and difficult to describe here, but to get the idea, the registers are like pointers, they indicate among others things, a memory space (location).

Now practice

I know that it has been a lot of information to process until now, but in reality they are somewhat complex issues that I try to explain in a very simple way, we are going to see a small program that uses buffers and we are going to break it to understand this about overflows, obviously this one is not It is a real program, and we are going to "evade" many of the countermeasures that are used today, just to show how things were done before 🙂 and because some of these principles are necessary to be able to learn more complex things 😉

GDB

A great program that is undoubtedly one of the most used by C programmers. Among its many virtues we have the fact that it allows us to see all this that we have been talking about so far, registers, the stack, buffers, etc. 🙂 Let's see the program that we are going to use for our example.

retinput.c

This is a fairly simple program, we are going to use the library stdio.h to be able to obtain information and display it in a terminal. We can see a function called return_input which generates a buffer called array, which has a length of 30 bytes (the char data type is 1 byte long).

The function gets(array); request information by console and function printf() returns the content of array and displays it on screen.

Every program written in C begins with the function main(), this will only be in charge of calling return_input, now we are going to compile the program.

Let's take a bit of what I just did. The option -ggdb tells gcc that it has to compile the program with information for gdb to be able to properly debug. -fno-stack-protector It is an option that obviously we should not be using, but that we are going to use because otherwise it would be possible to generate the buffer overflow in the stack. In the end I have tested the result. ./a.out it just runs what I just compiled, it asks me for information and returns it. Running 🙂

Warnings

Another note here. Can you see the warnings? clearly it is something to take into account when we work with code or compile, this is a bit obvious and there are few programs that today have the function gets() In the code. One advantage of Gentoo is that by compiling each program, I can see what might be wrong, an "ideal" program shouldn't have them, but you would be surprised how many large programs have these warnings because they are just VERY big and it's hard to keep track of them. dangerous functions when there are many warnings at the same time. Now if we continue

Debugging the program

Now this part can be a bit confusing, but since I have already written enough, I cannot afford to explain everything, so sorry if you see that I am going too fast 🙂

Disarming the code

Let's start by looking at our compiled machine language program.

This is the code of our main function in Assembly, this is what our processor understands, the line on the left is the physical address in memory, the <+ n> it is known as offset, basically the distance from the beginning of the function (main) to that statement (known as opcode). Then we see the type of instruction (push / mov / callq…) and one or more registers. Summarized we can say that it is the indication followed by the source / origin and the destination. <return_input> refers to our second function, let's take a look.

return_input

This is a little more complex, but I just want you to check a couple of things, there is a tag called <gets@plt> and one last opcode called retq indicating the end of the function. We are going to put a couple of breakpoints, one in the function gets and another in the retq.

Run

Now we are going to run the program to see how the action begins.

We can see that a small arrow appears indicating the opcode where we are, I want them to take into account the direction 0x000055555555469b, this is the address after the call to return_input in the function main , this is important as this is where the program should return when you finish receiving the input, let's get into the function. Now we are going to check the memory before entering the function gets.

I have put the main function back up for you, and have highlighted the code I was referring to, as you can see, due to the endianness has been separated into two segments, I want them to take into account the direction 0x7fffffffdbf0 (the first one from the left after the commando x/20x $rsp) since this is the location we have to use to check the results of gets, let's continue:

Breaking the program

I have highlighted those 0x44444444because they are the representation of our Ds 🙂 now we have started adding input to the program, and as you can see, we are only two lines from our desired address, we are going to fill it until we are just before the addresses that we highlighted in the previous step.

Changing the return path

Now that we have managed to enter this section of the code where it indicates the return of the function, let's see what happens if we change the address 🙂 instead of going to the location of the opcode that follows the one we had a moment ago, what do you think if we go back to return_input? But for this, it is necessary to write the address we want in binary, we are going to do it with the function printf from bash 🙂

Now we have received the information twice 😀 surely the program was not made for that, but we have managed to break the code and make it repeat something that it was not supposed to do.

reflections

This simple change can be considered a exploit very basic 🙂 he has managed to break the program and do something we want him to do.

This is just the first step in an almost infinite list of things to see and add, there are ways to add more things than simply repeating an order, but this time I have written a lot and everything related to shell coding it is a subject to write more than articles, complete books I would say. Sorry if I have not been able to delve a little more into topics that I would have liked, but surely there will be a chance 🙂 Greetings and thanks for getting here.