AdSense

Wednesday, November 2, 2016

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:


- 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:




- 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






Monday, October 17, 2016

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".








WI-FI PT / 4 - ATTACKS MAN-IN-THE-MIDDLE / 4.5 - Stealing username/passwords with Ettercap MITM attack


4.5 - Stealing username / passwords with Ettercap MITM attack

- This attack is similar to the previous one, in that ARP spoofing is also used. However, now the tool Ettercap will be used in its command shell version. Options used are:

      - T = text only interface
      - q = quiet mode, nor printing packet content
      - M = MITM attack
      - ARP /192.168.0.25/ = ARP replies sent to "roch" 192.168.0.25


      
- Once the attack is launched, "kali" waits for a client to connect to Outlook. Again, there are neither padlock, nor HTTPS and green URL bar, because "kali "Ettercap is intercepting messages between "roch" and the Outook email server:



- Shortly, both test account name (pruebapfm@hotmail.com) and password (passwordPFM) are captured by Ettercap:



- At the victim "roch", it can be checked that not only the legitimate AP 192.168.01 has got the fake MAC address attached, but also all the devices connected to the network segment, either wired or wirelessly: