Español | English
rss facebook linkedin Twitter

Seguridad en protocolos de enrutamiento dinámico (I)

En la vorágine de la seguridad de Internet muchas veces olvidamos que no todo es XSS, SQL Injection, Directory Traversal, NMAP, Nessus o cualquier otra herramienta de seguridad o vulnerabilidad a nivel de host que se nos pueda ocurrir. No debemos olvidar que también hay que garantizar la disponibilidad, confidencialidad e integridad en las comunicaciones para lo cual los protocolos de enrutamiento dinámico juegan un papel fundamental en el mundo IP. Sin embargo, mucha gente desconoce si estos protocolos implementan algún mecanismo de seguridad, o de hacerlo, cuál es exactamente.

Uno de los posible ataques contra este tipo de protocolos es evitar que se envíen los mensajes legítimos de actualización de rutas con el objetivo de generar una denegación de servicio de la red (parte de la red dejaría de estar disponible). Sin embargo, los ataques más dañinos son aquellos que buscan modificar la tabla de rutas con un objetivo determinado, a través del envío de mensajes de actualización generados artificialmente. La corrupción de esta tabla permite a un atacante lograr una denegación del uso de la red, bien a través de generación de congestión, limitando la visibilidad entre partes de ésta, o generando bucles de enrutamiento. Además incluso, el atacante en cuestión podría lograr una denegación de servicio contra un host en particular, al poder desviar todo el tráfico en circulación contra él, o también acceder a información confidencial si logramos encaminar un determinado flujo de tráfico hacia un sniffer instalado en la red.

¿Realmente esto resulta tan sencillo como parece? ¿No existen mecanismos de seguridad en estos protocolos que permitan evitarlo?

En realidad sí que existen, aunque no en todas las versiones de los distintos protocolos. Además, algunos de estos mecanismos ofrecen una falsa sensación de seguridad, mientras que los más avanzados no son del todo seguros o no se implementan por aspectos de rendimiento.

Comenzando con éste, dedicaré los próximos post en este blog a analizar algunos de los mecanismos de seguridad comunes a varios protocolos de enrutamiento dinámico. También trataré algunos aspectos más particulares a cada protocolo e intentaré transmitiros en qué consisten algunas de las técnicas más novedosas que se están tratando de aplicar para mejorar la seguridad de estos protocolos. Así pues, comencemos …

Una manera sencilla de evitar que un router ajeno a una red e introducido en ésta de manera clandestina altere los mensajes de enrutamiento, es la autenticación de los mensajes de actualización de rutas. RIP y OSPF ofrecen dos mecanismos de autenticación.

El primero de ellos, conocido como autenticación de texto plano (“plaintext authentication”), se basa en que los routers de un mismo segmento de red comparten una clave “secreta” que se incluye en la cabecera de los mensajes del protocolo. El router que recibe el mensaje de actualización compara esta clave incluida en la cabecera con la que tiene en memoria, y si coinciden acepta el paquete. En caso contrario lo rechaza. Este mecanismo de seguridad es sencillamente inútil ya que basta con instalar un sniffer en la red para obtener la clave “secreta” compartida por todos los routers.

El segundo mecanismo también se basa en una clave secreta compartida previamente por los routers de la red pero en este caso se firma el mensaje aplicando una función de resumen o hash de tipo MD5 al mensaje de actualización. En el caso particular de OSPF, a cada paquete se introduce el identificador de la clave secreta, la clave secreta en sí misma y también un número de secuencia de 32 bits que garantiza la protección contra ataques por repetición. Posteriormente se calcula su MD5 y se inserta en el campo en el que previamente se había añadido la clave compartida. En la siguiente figura se muestra este proceso:

Este mecanismo, aún mejorando mucho la seguridad en la autenticación de los mensajes de actualización, resulta inútil cuando uno de los routers legítimos resulta comprometido ya que sólo garantizan la integridad salto a salto. Así, el router comprometido podría falsear la información de los mensajes de actualización de rutas procedentes de los routers vecinos al generar los vectores de distancias o los estados de los enlaces, consiguiendo el atacante su objetivo de modificar la tabla de rutas de los demás routers a su gusto.


¡Hasta el próximo post!


Elyoenai Egozcue

S21sec labs

1 comentario:

fglez@bankinter.es dijo...

Yo estuve probando ayer el Pen Test Framewrk 0.4 y alcontrario de lo que tu dices , siguen saliendo muchas mas vulnerabilidades de blind sql inyection que de cualquier otra.

Claro que a lo mejor es por usar el proxy CHORIZO (es que desde el trabajo solo tengo salida por el puerto 80)



--------------------------------------

Delivered-To: rarezmail@gmail.com
Received: by 10.100.249.7 with SMTP id w7cs235553anh;
Mon, 21 Apr 2008 02:10:10 -0700 (PDT)
Received: by 10.86.4.2 with SMTP id 2mr12704709fgd.49.1208769009331;
Mon, 21 Apr 2008 02:10:09 -0700 (PDT)
Return-Path: fglez@bankinter.es>
Received: from smtp.bankinter.es (dns.bankinter.es [195.235.30.34])
by mx.google.com with ESMTP id g28si5132287fkg.2.2008.04.21.02.10.08;
Mon, 21 Apr 2008 02:10:09 -0700 (PDT)
Received-SPF: pass (google.com: domain of fglez@bankinter.es designates 195.235.30.34 as permitted sender) client-ip=195.235.30.34;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of fglez@bankinter.es designates 195.235.30.34 as permitted sender) smtp.mail=fglez@bankinter.es
Received: from bankinter.es ([10.0.197.228])
by smtp.bankinter.es with ESMTP id m3L9A83l006277
for rarezmail@gmail.com>; Mon, 21 Apr 2008 11:10:08 +0200 (MEST)
To: rarezmail@gmail.com
Subject: Rm: [EBONIA] Nueva version PenTest Framework (0.4)
MIME-Version: 1.0
Message-ID: OFA69EBD26.DBB171BD-ONC1257432.0032706F-C1257432.003273CE@bankinter.es>
From: Francisco Gonzalez Lopez fglez@bankinter.es>
Date: Mon, 21 Apr 2008 11:11:00 +0200
Content-Type: multipart/alternative; boundary="=_alternative 003273CDC1257432_="

Este es un mensaje de varios componentes en formato MIME.
--=_alternative 003273CDC1257432_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

----- Remitido por Francisco Gonzalez Lopez/Bankinter con fecha 21/04/2008 =


"Javier Megias Terol" jmegias@gmv.com>=20
=20
Enviado por: Seguridad-en-Ebonia@googlegroups.com
12/02/2008 15:09
Por favor, responda a
Seguridad-en-Ebonia@googlegroups.com


Para
Seguridad-en-Ebonia@googlegroups.com>
cc

Asunto
[EBONIA] Nueva version PenTest Framework (0.4)


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login