p2a
1.0.0
Este proyecto tiene como objetivo crear una herramienta fácil de usar que analizará un archivo pcap para devolver cualquier ambigüedad encontrada en los paquetes TCP. Actualmente también estamos trabajando en la implementación de análisis UDP y ARP.
Describir:
Contribuyendo: cualquier comentario/idea/aporte es bienvenido.
make
./p2a -v ./pcap_files/some_pcap_file.pcap -s results.json $ ./p2a -h
Usage: ./p2a [OPTIONS] FILE
-h,--help: display this help message
-v,--verbose: verbose option
-d,--debug: debug option
-x,--exclude OPTIONS: exclude some possible ambiguities from analysis
--exclude ret,mac,ttl
ret: exclude retransmission analysis
mac: exclude MAC addresses analysis
ttl: exclude TTL analysis
-s,--save FILENAME: saves results to file FILENAME
JSON format - FILENAME should contain the JSON extension
Examples:
./p2a -v ./pcap_files/some_pcap_file.pcapng
./p2a --exclude mac,ttl --verbose my-pcap-file.pcap -s results.json
Acabo de agregar la opción de guardar todos los resultados en un archivo JSON. Para hacerlo, se puede usar la opción --save file.json . Guarda todas las sesiones en este archivo, ya sea que se encuentren ambigüedades en ellas o no. Actualmente estoy trabajando en una manera de representar bien el archivo JSON en un archivo HTML (usando algo de JavaScript).
SHA(IP, Port)
Hicimos que el script sha esté disponible para fines de depuración. Toma como argumento una dirección IP y un número de puerto y devuelve el hash SHA1 de (IP|Puerto). Este valor se utiliza como identificador de sesión en el script p2a .
make sha
./sha -h
Usage:
./sha IP PORT
./sha 127.0.0.1 12345
IP: 127.0.0.1
Port: 12345
SHA1: 21bf549a8095063f49cff573e689b6b10365f4c8 Direcciones IP y whois
Si una sesión resulta sospechosa, puede resultar útil saber a qué se refiere. Para hacerlo, se puede usar Wireshark y aplicar un filtro de visualización para mostrar solo la sesión determinada.
Un enfoque más sencillo puede ser utilizar whois para saber quién es el propietario de la dirección IP.
Para usar whois con todas las direcciones IP del archivo de captura:
for ip in $( tshark -r file.pcapng -T fields -e ip.dst -e ip.src | egrep -o " [0-9]+.[0-9]+.[0-9]+.[0-9]+ " | sort | uniq ) ; do whois $ip | egrep " ^[Oo]rgani[sz]ation " ; doneSi
tsharkno funciona, aquí hay un script en C que hará lo mismo.
El campo Tiempo de vida (TTL) de un paquete IP corresponde a cuánto tiempo se "permite" que ese paquete viaje por la red antes de ser descartado por los enrutadores. Es un valor de 8 bits que normalmente se reduce en uno en cada salto.
Según la página de Cisco sobre el ataque de caducidad TTL:
"Cuando un dispositivo IOS recibe un paquete con un valor TTL menor o igual a uno, un dispositivo IOS envía un mensaje ICMPv4 tipo 11, código 0 , lo que genera el impacto correspondiente en la CPU . Este impacto se produce porque hay más CPU. Se requiere procesamiento para responder (usando paquetes con TTL excedido) a paquetes con valores TTL menores que uno que simplemente reenviar un paquete con un valor TTL mayor que uno".
"El comportamiento de caducidad de TTL crea un vector de ataque de denegación de servicio (DoS) contra equipos de red. Los dispositivos de red están diseñados específicamente para reenviar paquetes ordinarios lo más rápido posible. Cuando se encuentran paquetes de excepción, como aquellos con valores de TTL que caducan, se pueden producir cantidades variables. Un enrutador dedica muchos esfuerzos para responder adecuadamente".
Análisis/Código:
En utils.c , definimos un TTL_THRESHOLD (=10 por ahora). Si el TTL de un paquete es inferior a este valor, se activa una bandera para indicar que el TTL es bajo. Si se activan demasiadas banderas de este tipo, podría tratarse de un ataque de caducidad TTL.
El archivo pcap de muestra (que contiene un paquete con un TTL bajo) se capturó utilizando los scripts ubicados en el directorio ./attack_scripts/low_ttl .
El envenenamiento ARP consiste en engañar a un host haciéndole creer que somos la puerta de enlace predeterminada . La víctima pregunta periódicamente a la puerta de enlace predeterminada su dirección MAC (protocolo ARP). Pero un atacante puede enviar paquetes a la víctima diciendo que la puerta de enlace predeterminada está en otra dirección MAC (la dirección MAC del ataque, por ejemplo). El atacante sólo necesita enviar esos paquetes "con suficiente regularidad" para que la víctima "descarte" los mensajes reales de la puerta de enlace predeterminada .
Esto puede permitir al atacante proceder y atacar a la víctima de muchas maneras: hombre en el medio, DoS, agujero negro,...
Ejemplo:
La dirección IP de la víctima es 192.168.10.2 y la puerta de enlace predeterminada es 192.168.1.1 :
sudo arpspoofing -i wlan0 -t 192.168.10.2 192.169.1.1 El atacante seguirá enviando paquetes ARP a la víctima indicándole que 192.168.1.1 está en la dirección MAC del atacante. De esta forma la víctima enviará sus paquetes (destinados a Internet) al atacante, quien no los redirigirá (opción -r para redirigirlos).
Análisis/Código:
Para el análisis, dado que solo estamos analizando paquetes IP (por ahora), p2a guarda en una lista vinculada todos los pares (MAC address, IP address) que encuentra. Al verificar un nuevo par determinado, revisa la lista vinculada y devuelve un error si la dirección IP ya está asociada a otra dirección MAC.
Para el ejemplo anterior, nuestro script detectaría que 192.168.1.1 ( puerta de enlace predeterminada ) está asociada a dos direcciones MAC diferentes: la real, hasta que el atacante entra y le dice a la víctima que es la puerta de enlace predeterminada y que su dirección MAC se obtiene. asociado a la puerta de enlace predeterminada (desde el punto de vista de la víctima).
Cada byte de datos enviado en una conexión TCP tiene un número de secuencia asociado. Esto se indica en el campo del número de secuencia del encabezado TCP .
Cuando el socket receptor detecta un segmento de datos entrante, utiliza el número de acuse de recibo en el encabezado TCP para indicar la recepción. Después de enviar un paquete de datos, el remitente iniciará un temporizador de retransmisión de longitud variable. Si no recibe un acuse de recibo antes de que expire el temporizador, el remitente asumirá que el segmento se ha perdido y lo retransmitirá.
Podemos ver la retransmisión de TCP cuando otro paquete posee el mismo acuse de recibo y números de secuencia que el paquete actual.
Las retransmisiones TCP son bastante comunes y pueden ser totalmente normales (si un paquete se retransmite porque se perdió legítimamente), pero también pueden ser una señal de un problema en la red o en una comunicación.
El exploit de superposición de fragmentos de IP ocurre cuando dos fragmentos contenidos dentro del mismo paquete IP tienen desplazamientos que indican que se superponen entre sí en su posicionamiento dentro del paquete. Esto podría significar que el fragmento A está siendo sobrescrito completamente por el fragmento B, o que el fragmento A está siendo sobrescrito parcialmente por el fragmento B. Algunos sistemas operativos no manejan adecuadamente los fragmentos que se superponen de esta manera y pueden generar excepciones o comportarse de otras maneras no deseadas. al recibir fragmentos superpuestos. Esta es la base del ataque de lágrimas . ( de Wikipedia )
También se pueden utilizar fragmentos superpuestos en un intento de eludir los sistemas de detección de intrusiones . En este exploit, parte de un ataque se envía en fragmentos junto con datos aleatorios adicionales; fragmentos futuros pueden sobrescribir los datos aleatorios con el resto del ataque. Si el paquete completo no se vuelve a ensamblar correctamente en el IDS, el ataque pasará desapercibido.
Ataque de lágrima: implica enviar fragmentos de IP destrozados con cargas útiles superpuestas y de gran tamaño a la máquina de destino.
AÚN NO IMPLEMENTADO
Si observamos múltiples valores TTL para una determinada sesión, podría significar que la ruta ha cambiado, es decir, que los paquetes no siguen al final de la conexión el mismo camino que al principio. Esto podría deberse a cambios externos genuinos, pero también podría significar que un atacante cambia la ruta que toman los paquetes (para realizar un ataque MiTM, por ejemplo).
Sin embargo, la mayoría de las veces, una sesión tiene dos o tres valores TTL diferentes a lo largo de toda la conexión: la mayoría de las veces, el cliente y el servidor no utilizan los mismos valores TTL iniciales.
El script devuelve un error si hay más de dos valores TTL diferentes para una sesión determinada.
| Directorio | Descripción/contenido |
|---|---|
./attack_scripts | Scripts simples para probar y registrar algunas ambigüedades de TCP (suplantación de identidad, TTL bajo) |
./pcap_files | Archivos PCAP para probar p2a |
./tests_libpcap | Dos scripts para probar y empezar a usar libpcap |
libpcappcappcap al final de la página web.tcpdumplibpcaplibpcap en Cpcap.h
