FORMAT STRING ATTACKS - Disclosure of information and DoS

0 - INTRODUCTION

- Format String vulnerabilities result from data entry in a program under the guise of "format strings". The format strings are characters used in the input and output functions to specify the conversion between a data set and a string of characters.

- Thus, vulnerability is a result of the interpretation by the program of data inputs as instructions or commands of language itself. The consequences of the attack would be for example the execution of arbitrary code, reading or dumping the stack as a protected information disclosure, and denial of service, all affecting the security and stability of the system.

- Although C and C ++ languages are prone to suffer from Format String attacks, other programming languages are also vulnerable to these attacks, such as Perl, PHP, Java, Ruby, etc ... 

- The below links offer information about Format String attacks in several different languages than C / C ++:

http://www.drdobbs.com/security/programming-language-format-string-vulne/197002914

http://www.drdobbs.com/security/programming-language-format-string-vulne/197002914?pgno=2

http://www.drdobbs.com/security/programming-language-format-string-vulne/197002914?pgno=3

http://www.drdobbs.com/security/programming-language-format-string-vulne/197002914?pgno=4

- During the resolution of this exercise the C language has been used  because it is traditionally which has suffered most attacks of Format String type.

- To explain the attack should be noted the following:

a) Function Format: ANSI C standard converts a variable primitive programming language as a format function representation in the form of readable string for a human being. For example: printf, fprintf, sprintf, etc ... are examples of language functions in format C. Such functions are called variadics, and characterized by accepting a variable number of arguments. As we will be seen below, the arguments can be of two types: on the one hand the argument that characterizes the format output, on the other hand the values to be formatted.

b) Format String: this is the set of arguments used in the function format and are composed of text and parameters ASCIIZ (ASCII Code 0, strings ending in 0) type. Its utility is to specify and control the representation of variables. They are quoted, for example: printf ( "Today is November day %d. \ n", 22);

c) Conversion Character: this is the parameter that defines the type of conversion to be performed by the format function. For example %d (integer, reads an integer from memory), %f (Floating point, reading a real number format from memory), %c (char, a single character), %s (string, reading from the memory of a string of characters), %x (reading from the stack an hexadecimal number), etc ...

- As mentioned above, the attack would be implemented by inserting entries maliciously crafted, what would not be adequately validated by the program, so that the behavior function format would be different than expected.

- Regarding comparison with Stack Overflow attacks, both attacks seem interested in making a malicious usage of the stack. However, while the attack Stack Overflow is specially designed to rewrite the contents of the stack, forcing the program to execute arbitrary instructions, the Format String attack focuses on using converters from C language, for example %s, %x, etc ..., so that the stack interpreters the converters as part of the entered parameter in the function as an argument.

- The consequences of an Stack Overflow attack usually result in altering the flow control program, which executes its instructions leading to different outputs from initial purpose. However, Format String attacks are oriented either to the disclosure of information stored in certain memory locations or the denial of service (DoS). Both cases can be checked in detail in the following example.


1 - FORMAT STRING ATTACK - EXAMPLE - Disclosure of information and DoS

- To ilustrate the Format String attack a simple program (fs.c) written in C will be used.

- The original purpose of the program is simply to return to the screen the argument entered by the user at the command line.

- However, the program contains proprietary information ("INFORMACION 1" and "INFORMACION 2") that might be disclosed using a Format String attack.

- Editing and compiling the program in a Linux enviroment:




- Let's examine the code of the program. Two pointers (*s1 and *s2) are defined to memory locations that store certain reserved information:



- Also, an instruction has been introduced which aims simply to print out the argument argv [1] inserted by the user via the command line: 

printf (argv [1]);


- Thus, the purpose of the program in not at all intended to "reveal" the information stored in s1 and s2, but simply return to the screen the argument entered by the user. 

- However, let's see how through manipulation of the command line input the result can be very different than expected.

- First, let's enter a string in the command line argument, which is printed below the screen, according to the proper purpose of the program:



- However, let's see what happens when the arguments are entered by the user conversion characters.

- Introducing %s:



- Introducing %s%s:



- Introducing HOLA%s%s:




- It is observed that by introducing in the command line the converter %s a "revelation of information" (information disclosure, information leakage) occurs, so that the program behavior differs from the original purpose of it.

- As defined in the program, pointers *s1 and *s2 are stored on the stack in consecutive positions, prior to argument argv [1] expected to be received by the line command.

- Thus, upon receiving as input the conversion character %s, the printf function reads from the stack the nearest string, printing it. Upon receiving %s%s it performs the same operation with the two strings stored in the stack.

- To check the above concepts and analyze the contents of the stack the gdb GNU debugger  will be used on the program.

- The disassembly of the main function shows that the call to printf function occurs in the memory address 0x08048433:




- Setting a breakpoint just before the call to printf, at the above address 0x08048433:




-The program is run with the input argument HOLA:



- The content of the stack is analyzed:




- Arguments received by the printf routine are stored in the lower memory addresses of the stack:




- The stack would have the following content, from low to high memory, placing the esp pointing to the direction 0xbffff598, which contains the string HOLA introduced by command line:




- This explains that while printf reads arguments stored on the stack they are consecutively printed on the screen. In this case only HOLA because it has been executed the gdb command (gdb) run HOLA:




- Now, what would happen in case of introducing into the program many string parameters, beyond the values stored on the stack? The program would begin to read meaningless memory addresses, printing strange characters:





- Finally, in case of entering more converters % s the result would be the failure of the program (segmentation fault), because it would be trying to access invalid addresses. For example:




- See the same result in gdb:




- The program finishes running with a SIGSEGV signal indicating an invalid memory access, or segmentation fault.




- In this late case the attack would result into a denial-of-service attack (DoS), since the program fails without performing the purpose for it was written.

- Another interesting converter for conducting String Format attacks is converter % x, which reads the stack in hexadecimal values.

 - Let's see what happens with gdb running on four %x converters :










- At that point of the execution, the contents of the stack are:




- The program runs to the end, and the output matches the contents of the stack, except the first memory location (whose content will be seen soon):



- The first contents of the stack (lowest memory addresses) are the converters themselves %x% x%x%x, introduced as parameters:




- It can be observed the same result running the program directly from the command line, with fout %x converters arranged in the form of 0x%08x. The result would be the dump of the stack content. 

- It means that the memory addresses stored on the stack in hexadecimal format would be obtained:




- Since the program output matches the contents of the stack it is concluded that the information disclosure attack has been successful.

HEAP OVERFLOW - Overwriting the Heap with the vulnerable function strcpy

0 - INTRODUCTION

- The Heap is a memory area whose function is to store variables assigned dynamically at runtime. In the C language the instruction malloc() is used to allocate memory to the heap, so that the access to that memory area is via a pointer returned by malloc().

- For example: char * c = malloc (40); where 40 bytes are allocated to the pointer *c during program execution.

- The Heap is organized by the compiler itself, so overflow attacks are more difficult to exploit and replicate than the remaining overflow attacks. In addition, there is a large dependency on the compiler used, as well as libraries installed.  

- The following example uses the environment CodeBlocks 13.2 of C programming with GNU GCC compiler under Windows operating system. Any test of the program in other environment or compiler would probably give a different result, since as been said dynamic memory allocation at runtime depends heavily on the environment, compiler and used libraries.

1 - EXAMPLE

- In this exercise a successful Heap Overflow attack is performed, taking advantage of the inherent vulnerability of strcpy function of language C.

- C language function strcpy copies the string pointed at the source in the array pointed to the destination, including the final null character, returning it once the destination array makes the copy.

- Its structure is as follows:

- strcpy is vulnerable to overflow because it is not able to control the size of the copy. It can occur that the copy destination array remains overwritten, overlapping memory locations. To avoid this problem, the size of source array should be at least equal to the target array.

- The goal of the program is to show how by introducing a crafted argument it can be achieved to modify the expected output of the program, taking advantage of the vulnerability of the strcpy function, working specifically on the area dynamic allocation memory (heap).

- The program is as follows:

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

int main(int argc, char *argv[])

{

char *segundo = malloc(5); // segundo is declared before primero

char *primero = malloc(5);

strcpy(primero,"HOLA");

printf("Saludo (%p): %s\n",primero, primero);

strcpy(segundo,argv[1]); 

printf("Saludo (%p): %s\n", primero, primero);
}

- At first glance, the normal operation of the program would be printing twice the string HOLA, which has been copied by the strcpy function pointer named primero, since it is repeated twice the same statement: printf("Saludo (%p): %s\n",primero, primero);

- However, the intermediate instruction strcpy (segundo, argv [1]), depending on the length of argv [1], allows to alter the normal operation of the program, since argv [1]  could overwrite the contents of the first pointer.

- To analyze the behavior of the previous program, both in normal operation (printing HOLA HOLA) as well as malfunctioning (HOLA ADIOS), it is used Immunity Debugger for a Windows environment.

- First, the program is run with the input argument ADIOS, aiming to show that this argument itself has no significance on the output of the program:

- The instruction strcpy(segundo, argv [1]) loads into the dynamic memory pointer segundo the string ADIOS, entered as the parameter argv [1], in the direction 00580FB8:

- The string HOLA is allocated in 0058FD8.  In the following memory dump it is observed the distance between ADIOS (segundo) and HOLA (primero).

- As explained later, to make possible the future rewriting is imperative that segundo is declared before primero, so that segundo occupies a lower memory area than primero. 

- As discussed above, if input argv[1] is ADIOS, program execution would be normal, without occurring overwriting, :

- Now, let's see what happens when argv [1] argument is manipulated both in length and content.

- Running the program again, now with a parameter input consisting of 32 numbers plus the string ADIOS (later, we will see what is the reason of introducing exactly 32 numbers):

12345678901234567890123456789012ADIOS

- The instruction strcpy(primero, "HOLA") loads the string HOLA in the memory position 003C1058:

- The memory dump shows that 48 4F 4C 41 (HOLA in hexadecimal) occupies the  003C1058 memory location:

- Initially the input parameter argv [1] is located into 003C0EE9:

- However, the instruction strcpy (segundo, argv [1]) loads into the dynamic memory pointer segundo the string "12345678901234567890123456789012ADIOS", introduced previously as the argv [1] parameter:

- Thus, the input parameter argv[1] is finally housed in the memory 003C1038:



- What is the distance between 003C1038 and HELLO(003C1058)? it is exactly 32 bytes, because in hexadecimal 0x003C1058 - 0x003C1038 = 0x20 = 32d. 

- This is the reason because the amount of numbers to be entered in the input parameter to rewrite HOLA is 32, plus finally the string ADIOS.

- In this way, the memory location 003C1058 where HOLA was stored is now overwritten with the string ADIOS:

 

- The implementation of the program and its output confirms the previous memory dump:

- Let's notice that the first printf ("Saludo (%p):%s\n", primero, primero) is placed in the code before the overwriting, with the output:

Saludo (003C1058): HOLA

- However, the second printf("Saludo(%p): %s\n", primero, primero) is run after the overwriting, so the output is different:

Saludos (003C1058): ADIOS

- A remarkable aspect of this overflow is that it was achieved by calculating the exact location and size of the overwriting, which avoids a final exit program error.

INTEGER OVERFLOW - Altering the result of an arithmetic operation

0 - INTRODUCTION

- Integer Overflow happens when an arithmetic operation attempts to create a numeric value that is too large to be represented in its allocated storage space. 

- In programming, a variable is a memory space reserved to store a value corresponding to a data type supported by the language. Programming languages ​​have several types of variables, and measurement memory space reserved for the variable depends on the type of variable that is defined.

- For example, ANSI C assigns these values to the Integer type:




- If higher than permitted values ​​are assigned to char, short or int type variables, the program execution will not give any error, but truncate values.

- ISO C99 considers that the result of an integer overflow is of "undefined behavior", which means that standard compilers can do whatever they want, from completely ignoring the overflow to abort the program. What do most compilers is to ignore the integer overflow.

- The integer overflows can not be detected until they have occurred. This can be dangerous if the calculation has to do with the size of a buffer or the index of an array. 

- Most integer overflow are not exploitable because memory is not being directly overwritten, but sometimes they can lead to other kinds of bugs. Integer overflow attacks will not allow to overwrite memory areas, variables or code, but they can change the application logic and even outflank memory structures created through unsafe variables. In other words, the result can be unexpected given the resulting value will not be provided according to the logic defined in the program.

- To prevent an integer overflow, checking numerical values must be comprehensive so that there are no unexpected errors, including a check to detect whether the entered values ​​are between a range of certain values, ​​and of course, check measurement data type before using it.

1 - INTEGER OVERFLOW EXAMPLE - Altering the result of an arithmetic operation

- Let's consider this program written in language C:

- The program accepts 3 arguments (int, int, char), sums the 3 of them and finally outputs the result. 

-In case of proper input, arguments must be inside the range of accepted int and char type values. Let's see a normal operation for this program with values 1, 2, and 3:

- However, if the program is provided with arguments ​​which sum is outside the valid range, the sum exceeds the capacity of the outcome variable obtaining a negative number. For instance, let's see what happens with this input:

- How is it possible that the sum of those numbers is 0, instead of 2147483647 + 2147483647 + 2 = 4294967296? 

- Let's examine why the compiler considers that this sum is 0, instead of the expected result 4294967296.

- First of all it is important to notice that the number 4294967294 is out of the scope of the int type value range (-2147483648 to +2147483647).

- To understand the compiler's mind, we need to take the numbers written in a Two's Complement format, what is the usual way that negative numbers (starting by 1) are represented by compilers:

https://en.wikipedia.org/wiki/Two%27s_complement

- For instance, in Two's Complement format the number 1101 would not be 13 d, but -3 d:

(-1)*2^3 + 1*2^2 + 0*2^1 + 1*2^1 = -3 d

- So, the int arguments (2147483647) of this example must be converted from decimal to Two's Complement binary system format:

http://www.exploringbinary.com/twos-complement-converter/

- Then,  summing both up in a binary way:

  0111 1111 1111 1111 1111 1111 1111 1111 = 2147483647 d

 +

  0111 1111 1111 1111 1111 1111 1111 1111 = 2147483647 d

------------------------------------------------------------------------------

  1111 1111 1111 1111 1111 1111 1111 1110 = ?

- In the reverse way than previously, calculating the result of the binary sum 1111 1111 1111 1111 1111 1111 1111 11110 from Two's Complement format to decimal:

- So, the compiler takes the result of the partial sum as the negative -2. Then, the total sum would be 0:

(-2) +2 = 0 

- Another possible integer overflow case ​​for the same program would be as follows:

- In this late case:

- Summing:

0111 1111 1111 1111 1111 1111 1111 1111 = 2147483647 d

+

0111 1111 1111 1111 1111 1111 1000 0010 = 2147483522 d

------------------------------------------------------------------------------

1111  1111 1111 1111 1111 1111 1000 0001= ?

                   

- Converting the result from Two's Complement to decimal:

                                   

- The final total sum:

(-127) + 127 = 0

WI-FI PT / 4 - ATTACKS MAN-IN-THE-MIDDLE / 4.6 - Automating wireless MITM attacks with Easy-Creds

4.6 - Automating MITM attacks with Easy-Creds

- Easy-Creds is a powerful bash script whose main interest is to gather different hacking tools in just one suite of tools. Using Easy-Creds a lot of exploitation attacks can be launched in an automated way.

- From "kali", the attacker machine, easy-creds is started up:

- The first screen allows the user to choose between different options. For instance, option 3 creates a fake AP:

- Option 1 allows a simple fake AP static attack:

- The attack is not related with a web session hicjacking:

- "kali" is connected wiredly to the Internet with eth0 interface:

- "kali" is connected wiressly to the victim "roch" with wlan0 interface:

- The fake AP is called mitm:

- The channel in use is 6:

- The monitor interface is mon0:

- The MAC address won't be changed:

- The tunnel interface is at0:

- Because "kali" is not acting as the DHCP server, dhcpd.conf is not altered:

- The local network used by "kali" and "roch" is 192.168.0.0/24

- From the DNS servers offered by the ISP, the first one is picked up:

- Finally, the attack is launched:

- It is quite interesting to see how Easy-Creds allows to use at the same time all well-known tools and applications (Airbase-NG, DMESG, SSLstrip, Ettercap, URL Snarf, Dsniff). Once the attack configuration is finished, the different tools screens are displayed one on top of the next:

- At this point of the attack, "kali" using Easy-Creds waits until a user from the victim "roch" connects to mitm:

- Airbase-NG detects the association of "roch" (Client 28:C6:8E:63:15:6B) to the created fake AP called mitm:

- Ettercap detects how the DHCP server (the legitimate AP located at "kali"s wired eth0 interface) is offering to "roch" the IP=192.168.0.100, the default gateway GW=192.168.0.1, and DNS=24.159.193.40

- It can be verified that "roch", once connected to mitm, accepts those 3 parameters: IP, GW and DNS.

- If the victims connects to the Internet, either to www.google.com, www.ual.es or any other website, URL Snarf eavesdrops the connections immediately:

- Now, the client tries to check his email account pruebapfm@hotmail.com.As usual, because "kali" is acting as the Man-In-The-Middle, no padlock, HTTPS or green URL bar is shown:

- Ettercap captures the account name (pruebapfm@hotmail.com) and the password (passwordPFM):

- Finally, for the purpose of expanding the demostration of this practice, a Facebook test account is created:

       i) Email: pruebapfm@hotmail.com

       ii) Password: passwordPFM

- If the clients tried to connect the Facebook server normally (before the attack is launched), he would see the padlock and the HTTPS green bar at the URL, ensuring that the connection is being secured:

- However, once the MITM attack has been launched, the URL changes its look. No more padlock or green HTPPS at the URL bar:

- Again, Ettercap captures credentials pruebapfm@hotmail.com and passwordPFM for the Facebook account:

- If the attack is not launched in a smart way, it might appear to the client a screen warning that the connection is not being safe, because of the untruthful certificate used:

- Of course, under any circumstances the user should click "Proceed anaway". However, according to some Google's statistics, many users actually ignore the warning, clicking "Proceed anaway" instead of "Back to safety".