Español | English
rss facebook linkedin Twitter

Donde los scanners de vulnerabilidades no llegan – II

Servicios UDP

La mayoría de los scanners no son capaces de analizar y detectar correctamente vulnerabilidades en servicios UDP.

Esta es tal vez la deficiencia más flagrante de este tipo de programas, ya que es un problema técnicamente solucionable. Aunque la concepción clásica de estos scanners no se adapta bien a este tipo de servicios.

El proceso de trabajo clásico de un scanner de vulnerabilidades es:

  1. Explorar los puertos abiertos.
  2. Determinar el tipo de servicio y la versión del software utilizado (normalmente a través del banner).
  3. Determinar si el servicio o la versión del software esta afectado por alguna vulnerabilidad.
  4. Presentar un informe de lo encontrado.

El problema es lo que los puertos UDP no permiten determinar claramente su estado:

http://en.wikipedia.org/wiki/Portscanning#UDP_scanning

Básicamente cuando probamos un puerto UDP solo nos responderá con un paquete ICMP_PORT_UNREACHABLE si el puerto esta cerrado. Si no recibimos ese paquete, podemos estar ante 2 situaciones: el puerto esta abierto o el puerto esta filtrado. No podemos diferenciar a priori si el puerto esta filtrado o abierto.

La única forma de determinar de forma fiable si un puerto UDP esta abierto y existe un servicio accesible, es utilizar una petición especifica de cada protocolo concreto y esperar una respuesta en ese protocolo.

Algunos scanners incluyen pruebas simples para protocolos UDP habituales: DNS, SNMP, IKE.

Pero estas pruebas solo se realizan contra el puerto por defecto: DNS(53/udp), SNMP(161/udp), IKE(500/udp). Si el número de puerto ha sido cambiado, el scanner será incapaz de detectar correctamente el servicio y por lo tanto de determinar si presenta vulnerabilidades.

Algunos pensaran, "bueno, los servicios UDP son marginales", pero están lejos de la realidad. Aquí tenéis por ejemplo una lista de servicios UDP que son ampliamente utilizados:

  • DNS = 53/udp
  • TFTP = 69/udp
  • NNS (NetBIOS Name Service) = 137/udp
  • SNMP = 161/udp
  • IKE = 500/udp
  • NTP = 123/udp
  • BOOTPS/DHCP = 67/udp y 68/udp
  • SUNRPC = 111/udp
  • SYSLOG = 514/udp
  • RIP = 520/udp
  • RADIUS = 1812/udp
  • RTSP (Real Time Streaming Protocol) = 554/udp
  • Clientes P2P = Unos cuantos
  • L2TP = 1701/udp
  • HSRP (Hot Standby Router Protocol) = 1985/udp

A que más de uno os suena...

Ramón Pinuaga
Departamento de Auditoría

2 comentarios:

Daniel Vigueras dijo...

El problema está en que un escaneo de vulnerabilidades udp se volvería más costoso.
Si reconocemos N servicios y vamos a escanear P puertos deberíamos envíar P*N datagramas UDP, es decir, para cada puerto un datagrama por cada servicio asociado que pueda estar escuchando ahi.

elf_infector dijo...

Yo creo que el verdadero problema reside en el propio protocolo UDP puesto que "no hace bien su trabajo" ya que como bien dice Ramón "El problema es lo que los puertos UDP no permiten determinar claramente su estado" lo que reafirma lo que acabo de decir.
Esto de acuerdo en lo que dice Daniel, y aunque yo no soy capaz de dar una solución más efectiva pienso que la mayoría de los escanners de vulnerabilidades no resuelven muy bien este tipo de caso porque prefieren centrarse en servicios TCP que son los mas comunes hoy en día.

Un saludo


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login