Ejemplo de fugas de información en tráfico ICMP (ping)

 

Escenario para aplicar en detección de intrusiones, CCNA Security, Febrero 2013

 

Escenario

 

 

Detalle

 

Utilizamos la herramienta FrameIP para generar tráfico ICMP "a medida", desactivamos el tamaño por defecto del

paquete (16 bytes) y escribimos información a transmitir.

 

1. Debemos seleccionar: Type 8 (echo request), este tipo no lleva código (code) ID 200 (puede ser otro, aquí reproducimos

el generado por un ping anterior) Sequence 1 (en casos normales la secuencia irá aumentando)

Podemos obtener parámetros de ICMP en: http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml

 

2. Enviar mediante Send Frame (lo hará de uno en uno, también podemos seleccionar la cantidad de paquetes a enviar)

 

 

 

2. Detalle del tráfico recibido y capturado mediante Wireshark

 

2.1. Ping normal de prueba (enviado)

 

C:\>ping 10.0.0.109 (enviado)

 

Haciendo ping a 10.0.0.109 con 32 bytes de datos:

 

Respuesta desde 10.0.0.109: bytes=32 tiempo=2ms TTL=128

Respuesta desde 10.0.0.109: bytes=32 tiempo=2ms TTL=128

Respuesta desde 10.0.0.109: bytes=32 tiempo=6ms TTL=128

Respuesta desde 10.0.0.109: bytes=32 tiempo=3ms TTL=128

 

Estadísticas de ping para 10.0.0.109:

    Paquetes: enviados = 4, recibidos = 4, perdidos = 0

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 2ms, Máximo = 6ms, Media = 3ms

 

C:\>

 

2.2. Ping normal de prueba (recibido)

 

 

 

2.3.  Ping adulterado

 

 

3. Contramedida para mitigar el ICMP tunneling

 

3.1 Activamos la firma Large ICMP en el IPS del firewall

 

 

3.2. Modificamos la firma 2151-0 para paquetes de mas de 100 bytes (como ejemplo)

 

 

3.3. Aplicamos los cambios

 

 

3.4. Verificamos

 

C:\>ping 10.0.0.254

 

Haciendo ping a 10.0.0.254 con 32 bytes de datos:

 

Respuesta desde 10.0.0.254: bytes=32 tiempo=1ms TTL=255

Respuesta desde 10.0.0.254: bytes=32 tiempo<1m TTL=255

Respuesta desde 10.0.0.254: bytes=32 tiempo<1m TTL=255

Respuesta desde 10.0.0.254: bytes=32 tiempo<1m TTL=255

 

Estadísticas de ping para 10.0.0.254:

    Paquetes: enviados = 4, recibidos = 4, perdidos = 0

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 0ms, Máximo = 1ms, Media = 0ms

 

C:\>ping 10.0.0.254 -l 100

 

Haciendo ping a 10.0.0.254 con 100 bytes de datos:

 

Respuesta desde 10.0.0.254: bytes=100 tiempo=1ms TTL=255

Respuesta desde 10.0.0.254: bytes=100 tiempo=1ms TTL=255

Respuesta desde 10.0.0.254: bytes=100 tiempo=1ms TTL=255

Respuesta desde 10.0.0.254: bytes=100 tiempo=1ms TTL=255

 

Estadísticas de ping para 10.0.0.254:

    Paquetes: enviados = 4, recibidos = 4, perdidos = 0

    (0% perdidos),

Tiempos aproximados de ida y vuelta en milisegundos:

    Mínimo = 1ms, Máximo = 1ms, Media = 1ms

 

C:\>

 

Firewall#sh logg (verificamos alarmas del IPS)

Syslog logging: enabled (1 messages dropped, 237 messages rate-limited,

                0 flushes, 0 overruns, xml disabled, filtering disabled)

    Console logging: level debugging, 331 messages logged, xml disabled,

                     filtering disabled

    Monitor logging: level debugging, 0 messages logged, xml disabled,

                     filtering disabled

    Buffer logging: level debugging, 5 messages logged, xml disabled,

                    filtering disabled

    Logging Exception size (4096 bytes)

    Count and timestamp logging messages: disabled

 

No active filter modules.

 

    Trap logging: level informational, 597 message lines logged

 

Log Buffer (4096 bytes):

 

*Feb 26 19:40:38.266: %SYS-5-CONFIG_I: Configured from console by vty0 (10.0.0.234)

*Feb 26 19:40:45.446: %IPS-4-SIGNATURE: Sig:2151 Subsig:0 Sev:2 Large ICMP [10.0.0.234:0 -> 10.0.0.254:0]

*Feb 26 19:40:46.450: %IPS-4-SIGNATURE: Sig:2151 Subsig:0 Sev:2 Large ICMP [10.0.0.234:0 -> 10.0.0.254:0]

*Feb 26 19:40:47.450: %IPS-4-SIGNATURE: Sig:2151 Subsig:0 Sev:2 Large ICMP [10.0.0.234:0 -> 10.0.0.254:0]

*Feb 26 19:40:48.450: %IPS-4-SIGNATURE: Sig:2151 Subsig:0 Sev:2 Large ICMP [10.0.0.234:0 -> 10.0.0.254:0]

 

Firewall#

 

4. Otros ejemplos de tráfico ICMP ilegal

 

Puede crearse un ICMP tunel, en donde se inserta tráfico TCP o UDP (con su carga), como carga en un paquete del tipo PING,

esto permite acceder a aplicaciones o servicios remotos que tal vez sean bloqueados por una ACL de salida de nuestra red, pero

que tal vez tenga permitido el tráfico ICMP, con buenas intenciones, para diagnóstico.

 

Para mitigar esto se debe ser mas específico con la sentencia de la ACL y restringir el permit a los host considerados confiebles:

 

Firewall(config-ext-nacl)#permit icmp any any

 

por:

 

Firewall(config-ext-nacl)#no permit icmp any any

 

y agregamos una regla para un host confiable o con tareas de diagnóstico:

 

Firewall(config-ext-nacl)#permit icmp host 192.168.1.123 any

 

Firewall#

 

Fuente: http://icmptunnel.blogspot.com.ar/2012/09/blog-post.html

 

Ping traffic is ubiquitous to almost every TCP/IP based network and  subnetwork.  
It has a standard packet format recognized by every IP-speaking router and is used universally for network management, testing,

and measurement. 
As such, many firewalls and networks consider ping traffic to be benign and will allow it to pass through, unmolested. 

This project explores why that practice can be insecure. 
Ignoring the obvious threat of the done-to-death denial of service attack, use of ping traffic can open up  covert channels through

the networks in which it is allowed. 

 

 

Traffic ICMP Engine

The Traffic ICMP engine analyzes nonstandard protocols, such as TFN2K, LOKI, and DDoS. There are only two signatures (based

on the LOKI protocol) with user-configurable parameters.

TFN2K is the newer version of the TFN. It is a DDoS agent that is used to control coordinated attacks by infected computers (zombies)

 to target a single computer (or domain) with bogus traffic floods from hundreds or thousands of unknown attacking hosts. TFN2K sends

randomized packet header information, but it has two discriminators that can be used to define signatures. One is whether the L3

checksum is incorrect and the other is whether the character 64 `A' is found at the end of the payload. TFN2K can run on any port

and can communicate with ICMP, TCP, UDP, or a combination of these protocols.

LOKI is a type of back door Trojan. When the computer is infected, the malicious code creates an ICMP Tunnel that can be used to send

small payload in ICMP replies (which may go straight through a firewall if it is not configured to block ICMP.) The LOKI signatures

look for an imbalance of ICMP echo requests to replies and simple ICMP code and payload discriminators.

The DDoS category (excluding TFN2K) targets ICMP-based DDoS agents. The main tools used here are TFN and Stacheldraht.

They are similar in operation to TFN2K, but rely on ICMP only and have fixed commands: integers and strings.

Table B-40 lists the parameters specific to the Traffic ICMP engine.

Table B-40 Traffic ICMP Engine Parameters 

Parameter

Description

Value

parameter-tunable-sig

Whether this signature has configurable parameters.

yes | no

inspection-typee

Type of inspection to perform:

•Inspects for original LOKI traffic.

•Inspects for modified LOKI traffic.

is-loki
is-mod-loki

reply-ratio

Inbalance of replies to requests. The alert fires when there are this many more replies than requests.

0 to 65535

want-request

Requires an ECHO REQUEST be seen before firing the alert.

true | false

Fuente:

http://www.cisco.com/en/US/docs/security/ips/7.0/configuration/guide/cli/cli_signature_engines.html

 

IPS Signatures

 

General Loki ICMP Tunneling

               

Signature ID:      6302-0

Original Release:  S2

Release: S399 (download)

Original Release Date:        February 02, 2001

Latest Release Date:           May 08, 2009

Default Enabled:  False

Default Retired:    True

Alarm Severity:    High      

Fidelity: 85           

 

Description

 

This signature fires when an imbalance of ICMP echo replies to echo requests is detected. This may indicate a covert ICMP control channel, like Loki.

 

Recommended Filter

 

Exclude network management stations as sources and destinations.

 

Benign Triggers

 

This signature can false positive in environments with devices that respond with multiple ICMP echo replies to a single echo request, mimicking a

possible covert ICMP control channel. This behavior has been seen with certain kinds of load balancers. Network management systems are also a

common source of false positives for this alarm.

 

Fuente:

 http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=6302&signatureSubId=0&softwareVersion=6.0&releaseVersion=S399

 

 

 

 

 

 

 

(2013) Networking from nirvana

Rosario, Argentina

 

 

 

.