Detectando direcciones IP marcianas (Mars Attack)

Fecha: 1 de junio del 2020

 

Escenario

 

Este tema sale de casualidad cuando realizaba el laboratorio #194 y entre las pruebas de conexiones me encuentro

con unos logs que nunca había visto:

                                                                                                               

*May  8 12:39:23.703: IP ARP: sent req src 10.0.0.0 0017.95c0.aca2, dst 10.0.0.1 0000.0000.0000 FastEthernet0/0

*May  8 12:40:17.103: IP ARP req filtered src 192.168.1.10 e86a.64dc.e2f5, dst 192.168.1.1 0000.0000.0000 wrong cable, interface FastEthernet0/0

*May  8 12:40:17.135: IP ARP req filtered src 0.0.0.0 e86a.64dc.e2f5, dst 192.168.1.10 0000.0000.0000 martian source

*May  8 12:40:31.703: IP ARP: sent req src 10.0.0.0 0017.95c0.aca2, dst 10.0.0.1 0000.0000.0000 FastEthernet0/0

 

                                            

 

 

Me llamó mucho la atención, pero por qué se generaron estos dos logs  ?

 

Se puede deber justo a un momento en que la placa cambiaba de IP o de link UP/DOWN y generó el ARP, lo que llevó

a transmitir con la IP de origen 0.0.0.0 y justo el router estaba en debug.

 

En ese momento traté de repetirlo una y otra vez sin resultados, lo cual me llevó a este lab algunos dias después.

 

Buscando sobre este tema llego a cisco.com donde encuentro la primera explicación racional del término “martian address”.

 

Defining Martian Addresses

 

The Martian Addresses Page enables entering those addresses that should not be seen on the network and may indicate an attack.

 

There are two kinds of Martian addresses:

 

1.       Addresses defined to be illegal in the Martian Addresses Page.

2.       Source addresses that are illegal from the viewpoint of the protocol, such as loopback addresses.

 

These addresses include any address within the following ranges:

 

0.0.0.0/8 (Except 0.0.0.0/32 as a Source Address) — Addresses in this block refer to source hosts on this network.

127.0.0.0/8 — Used as the Internet host loopback address.

192.0.2.0/24Used as the TEST-NET in documentation and example codes.

224.0.0.0/4 (As a Source IP Address) — Used in IPv4 Multicast address assignments, and This formerly known as Class D Address Space.

240.0.0.0/4 (Except 255.255.255.255/32 as a Destination Address) — Reserved address range, and is formerly known as Class E Address Space.

 

Every packet that enters the device is checked. If its source IP address is a Martian address, it is filtered.

 

Ejemplo de una firma de IOS IPS:

 

Caí en la cuenta que los IDS/IPS tienen firmas contra estos ataques y recordé mi lab #34 en Julio del 2010, 10 años antes enseñando CCNASec.

 

 

1.- Pruebas realizadas:

 

No pude reproducir el log tan facilmente con la máquina original (Windows 10), por mas que intenté manipulando el patch con tráfico o intentara

forzando el cambio de IP mientras transmitía no podía lograr resultados.

 

1.1.- Forzando la dirección de IP de la placa:

 

Al querer forzar la placa con dirección de origen 0.0.0.0 el sistema operativo nos devuelve un error.

 

 

El error nos indica que el valor debe estar entre 1 y 223, por lo que podríamos probar con 127.0.0.1

 

 

2.- Pruebas en Linux:

 

Linux es mucho mas amigable con estos chanchuyos, por lo tanto es la mejor opción para forzar “tráfico marciano”.

 

2.1.- Pruebas con origen 0.0.0.X:

 

Las pruebas en Linux me permitieron falsear las IP origen pero no pude lograr el log deseado.

 

root@kali:~# hping3 192.168.1.1 -a 0.0.0.1

HPING 192.168.1.1 (eth0 192.168.1.1): NO FLAGS are set, 40 headers + 0 data bytes

^C

--- 192.168.1.1 hping statistic ---

6 packets transmitted, 0 packets received, 100% packet loss

round-trip min/avg/max = 0.0/0.0/0.0 ms

root@kali:~#

 

2.2.- Resultado en el router:

 

No generó logs en el router, la PC con dirección 0.0.0.1 directamente no generó tráfico.

 

2.3.- Pruebas con origen broadcast:

 

root@kali:~# hping3 192.168.1.1 -a 255.255.255.255

HPING 192.168.1.1 (eth0 192.168.1.1): NO FLAGS are set, 40 headers + 0 data bytes

^C

--- 192.168.1.1 hping statistic ---

8 packets transmitted, 0 packets received, 100% packet loss

round-trip min/avg/max = 0.0/0.0/0.0 ms

root@kali:~#

 

2.4.- Resultado en el router:

 

*Mar  1 01:20:36.059: IP: s=255.255.255.255 (FastEthernet0/0), d=192.168.1.1 (FastEthernet0/0), len 40, rcvd 3

*Mar  1 01:20:37.075: IP: tableid=0, s=255.255.255.255 (FastEthernet0/0), d=192.168.1.1 (FastEthernet0/0), routed via RIB

 

2.5.- Pruebas con origen clase E:

 

root@kali:~# hping3 192.168.1.1 -a 240.0.0.1

HPING 192.168.1.1 (eth0 192.168.1.1): NO FLAGS are set, 40 headers + 0 data bytes

^C

--- 192.168.1.1 hping statistic ---

8 packets transmitted, 0 packets received, 100% packet loss

round-trip min/avg/max = 0.0/0.0/0.0 ms

root@kali:~#

 

2.6.- Resultado en el router:

 

*May 31 23:16:48.499: IP: tableid=0, s=240.0.0.1 (FastEthernet0/0), d=192.168.1.1 (FastEthernet0/0), routed via RIB

*May 31 23:16:48.499: IP: s=240.0.0.1 (FastEthernet0/0), d=192.168.1.1 (FastEthernet0/0), len 40, rcvd 3 (no hay logs de martian source)

*May 31 23:16:48.499: IP: s=192.168.1.1 (local), d=240.0.0.1, len 40, unroutable (obviamente porque es clase E)

 

2.7.- Probamos agregando la ruta a 240.0.0.0:

 

Esta prueba ya es para ver si el equipo lo permite o no, no aporta al resultado esperado (el log con martian source).

 

Cisco1841#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

Cisco1841(config)#ip route 240.0.0.0 255.255.255.0 192.168.1.200

%Invalid destination prefix

Cisco1841(config)#

 

3.- Pruebas falseando ARP:

 

3.1.- Utilizamos la herramienta arp-scan para falsear tráfico ARP (cuando fracasaba en las pruebas, caí en la cuenta que

el log original era un log ARP, y yo estaba tratando de generar tráfico asumiendo que el ARP se producía de facto).

 

 

3.2.- Resultado de TCPdump:

 

 

3.3.- Resultados en el router:

 

*Jun  1 21:21:21.707: IP ARP req filtered src 0.0.0.0 001b.38fe.8ac7, dst 192.168.1.0 0000.0000.0000 martian source ( gotcha ! )

*Jun  1 21:21:21.719: IP ARP req filtered src 0.0.0.0 001b.38fe.8ac7, dst 1192.168.1.1 0000.0000.0000 martian source

*Jun  1 21:21:21.719:  IP ARP req filtered src 0.0.0.0 001b.38fe.8ac7, dst 192.168.1.2 20000.0000.0000 martian source

*Jun  1 21:21:21.747: IP ARP req filtered src 0.0.0.0 001b.38fe.8ac7, dst 192.168.1.3 0000.0000.0000 martian source

*Jun  1 21:21:21.747: IP ARP req filtered src 0.0.0.0 001b.38fe.8ac7, dst 192.168.1.4 0000.0000.0000 martian source

 

3.4.- Probamos con origen 127.0.0.1:

 

*Jun  1 21:28:38.083: IP ARP req filtered src 127.0.0.1 001b.38fe.8ac7, dst 192.168.1.0 0000.0000.0000 martian source

*Jun  1 21:28:38.095: IP ARP req filtered src 127.0.0.1 001b.38fe.18ac7, dst 192.168.1.1 0000.0000.0000 martian source

*Jun  1 21:628:38.095: IP ARP req filtered src 127.0.0.1 001b.38fe.8ac7, dst8 192.168.1.2 0000.0000.0000 martian source

 

3.5.- Probamos con origen 192.0.2.0:

 

Esta prueba dió resultados diferentes a las otras, aquí dimos con el primer mensaje de los logs originales (wrong cable).

 

*Jun  2 12:07:11.375: IP ARP req filtered src 192.0.2.10 001b.38fe.8ac7, dst 192.168.1.0 0000.0000.0000 wrong cable,

 interface FastEthernet0/0

*Jun  2 12:07:11.375: IP ARP req filtered src 192.0.2.10 001b.38fe.8ac7, dst 192.168.1.1 0000.0000.0000 wrong cable,

 interface FastEthernet0/0

*Jun  2 12:07:11.379: IP ARP req filtered src 192.0.2.10 001b.38fe.8ac7, dst 192.168.1.4 0000.0000.0000 wrong cable,

interface FastEthernet0/0

*Jun  2 12:07:11.407: IP ARP req filtered src 192.0.2.10 001b.38fe.8ac7, dst 192.168.1.5 0000.0000.0000 wrong cable,

interface FastEthernet0/0

 

3.6.- Verificamos que no existen errores en los paquetes ARP:

 

 

3.7.- Probamos con origen clase E:

 

*Jun  1 21:26:50.947: IP ARP req filtered src 240.0.0.0 001b.38fe.8ac7, dst 192.168.1.0 0000.0000.0000 martian source

*Jun  1 21:26:50.959: IP ARP req filtere0d src 240.0.0.0 001b.38fe.8ac7, dst 192.168.1.2 0000.0000.0000 martian source

*Jun  1 21:26:50.963: IP ARP req filtered src 2400.0.0.0 001b.38fe.8ac7, dst 192.168.1.3 0000.0000.0000 martian so0urce

 

3.8.-Probamos con origen broadcast:

 

Nunca vimos en CCNA una dirección broadcast de origen, siempre de destino !

 

*Jun  1 21:32:37.119: IP ARP req filtered src 255.255.255.255 001b.38fe.8ac7, dst 192.168.1.0 0000.0000.0000 martian source

*Jun  1 21:32:37.131: IP ARP req filtered src 255.255.255.255 001b.308fe.8ac7, dst 192.168.1.6 0000.0000.0000 martian source

*Jun  10 21:32:37.135: IP ARP req filtered src 255.255.255.255 001b.38fe0.8ac7, dst 192.168.1.7 0000.0000.0000 martian source

 

4.- Pruebas desde un firewall PIX:

 

Si bien es un firewall viejo, es lo único que tengo para pegarle en testing, pero al menos veamos que responde.

En teoría un firewall expuesto a internet no debería tener que frenar ataques ARP ya que estos son dentro de una red local.

 

PIX-501# debug arp

PIX-501#

 

4.1.- Con IP origen 0.0.0.0:

 

1: arp-in: Dropping request at outside from unsolicited non-adjacent 0.0.0.0 001b.38fe.8ac7 for 192.168.1.0 0000.0000.0000

 

4.2.- Con IP origen 127.0.0.1:

 

1536: arp-in: Dropping request at outside from unsolicited non-adjacent 127.0.0.1 001b.38fe.8ac7 for 192.168.1.0 0000.0000.0000

 

4.3.- Con IP origen 192.0.2.10:

 

513: arp-in: request at outside from 192.0.2.10 001b.38fe.8ac7 for 192.168.1.0 0000.0000.0000 (lo toma como “normal”)

514: arp-set: added arp outside 192.0.2.10 001b.38fe.8ac7

 

4.4.- Con IP origen 240.0.0.0 (clase E):

 

2560: arp-in: request at outside from 240.0.0.0 001b.38fe.8ac7 for 192.168.1.0 0000.0000.0000 (sin respuesta)

 

4.4.- Con IP origen 255.255.255.255:

 

2048: arp-in: Dropping request at outside from unsolicited non-adjacent 255.255.255.255 001b.38fe.8ac7 for 192.168.1.0 0000.0000.0000

 

5.- Para terminar, un detalle importante del origen 0.0.0.0:                                                                                                                  

 

Una excepción a la IP de origen 0.0.0.0 es el DHCP discover, que tiene este origen, pero es aceptado porque es parte del

protocolo mismo, realizamos una captura de verificación de un ipconfig /release e ipconfig/renew.

 

*Mar  1 01:36:45.819: IP: s=0.0.0.0 (FastEthernet0/0), d=255.255.255.255, len 328, rcvd 2

*Mar  1 01:36:48.943: IP: s=0.0.0.0 (FastEthernet0/0), d=255.255.255.255, len 328, rcvd 2

*Mar  1 01:36:52.067: IP: s=0.0.0.0 (FastEthernet0/0), d=255.255.255.255, len 328, rcvd 2

*Mar  1 01:36:59.311: IP: s=0.0.0.0 (FastEthernet0/0), d=255.255.255.255, len 328, rcvd 2

*Mar  1 01:37:14.803: IP: s=0.0.0.0 (FastEthernet0/0), d=255.255.255.255, len 328, rcvd 2

 

 

(2020) Giorgio was right

Rosario, Argentina