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/24 — Used 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