martes, 8 de abril de 2014

SNMP: Impacto de una mala configuración sobre un protocolo simple

En estos días me surgió la necesidad de comenzar a profundizar sobre el protocolo SNMP (Simple Network Management Protocol). Este es un protocolo antiguo pero ampliamente utilizado para realizar tareas de monitoreo y administración sobre diferentes tipos de dispositivos. Cómo todo protocolo que ofrece este tipo de funcionalidades, siempre existe el riesgo de poder facilitarle la vida a un atacante si el mismo no se encuentra debidamente configurado.

No es mi intención profundizar sobre la naturaleza del protocolo ya que existe muchísima documentación que describe de forma muy detallada al mismo. Sin ir más lejos, recomiendo la lectura del RFC 1157, donde se declaran todas las bases del protocolo SNMP.

Básicamente, el riesgo reside en como se configura tanto la comunidad "public" como aquella denominada "private". La primera de ellas suele utilizarse para realizar la lectura de la configuración actual del dispositivo. La segunda para realizar escrituras, y por transición, una modificación de la misma. De esta forma, estas validaciones se realizan a través de strings o cadenas. 

Existen diversos scripts en la red que pueden utilizarse sobre estos dispositivos con este tipo de configuración. En este caso, utilizaremos algunas herramientas ya incluidas en Kali Linux; particularmente en esta ocasión, serán ciertos módulos auxiliares que provee Metasploit

Mediante el módulo de snmp_login se puede realizar fuerza bruta, tanto sobre los strings de lectura como sobre los de escritura. Para ello utiliza un pequeño diccionario con aquellas strings más comunes, incluidas también en Kali Linux.


En este caso, se obtuvieron los strings correspondientes de sólo lectura ("public") y lectura-escritura (¨pr1v4t3"). Ahora es posible enviar una petición del tipo GET y GET NEXT para obtener todo el árbol de configuración del dispositivo. Para esta tarea, se ejecutó otro módulo de auxiliar de Metasploit llamado snmp_enum obteniendo una gran cantidad de información del sistema.

El servicio SNMP escucha sobre el puerto 161 por defecto y responde a través de paquetes UDP. De esta forma, luego de la ejecución del módulo auxiliar de Metasploit, se puede obtener información detallada del dispositivo.


Tal como puede observarse en la captura anterior, se determinó el hostname, e incluso la ubicación. Si se continúa analizando la información, pueden obtenerse detalles específicos del hardware del sistema.


Profundizando aún más, un atacante podría obtener información sobre las interfaces de red y las tablas de routing, lo que podría facilitarle el acceso a los sistemas dentro de la organización.



Como si esto fuera poco, en el peor de los casos puede acceder a información de los procesos y servicios que están ejecutándose sobre el dispositivo.


Si bien este es un caso extremo, con esta información un atacante podría conocer todos los procesos que se encuentran corriendo dentro del sistema objetivo. Esto podría habilitarle nuevos vectores de ataques a partir de los procesos y servicios vulnerables. En este caso puntual, el atacante podría inducir que el sistema posee una base de datos postgres y otra mysql. 

Escritura sobre la configuración

Aunque parezca poco probable, el escenario planteado anteriormente suele hallarse dentro de entornos corporativos. Esto no es un problema propio del protocolo, sino que muchas veces se debe a que estos servicios se encuentran operando sin que los administradores estén conscientes de ello.

Sin embargo, existe un escenario aún peor, y es donde el atacante puede realizar modificaciones en la configuración del dispositivo mediante la string que provee funcionalidad de READ-WRITE. En este ejemplo, la string es "pr1v4t3".

A modo de demostración, modificaremos el hostname mediante otro módulo auxiliar de Metasploit, que se conoce como smnp_set. Luego de haber establecido todos los parámetros, se indica el campo que se desea modificar en formato árbol con el nuevo valor.


Si ahora se comprueba nuevamente cuál es el valor de hostname, se verifica que el mismo ha sido modificado. Esto puede extenderse a otros parámetros configurables, donde el impacto podría ser de un orden mayor, como por ejemplo la modificación de la contraseña del dispositivo o incluso la denegación de servicio del mismo mediante baja de la interfaz correspondiente.

Conclusión

SNMP es un protocolo simple (tal como lo indica su nombre), el cual es muy útil para monitorear dispositivos y realizar modificaciones sobre las configuraciones de los mismos. El problema se origina cuando los administradores no están al tanto de la presencia de esta servicio, o en su defecto, cuando se dejan las configuraciones de las comunidades por defecto. Es importante recordar que si se permite el acceso a este protocolo de forma remota, un potencial atacante podría leer o modificar la configuración de los dispositivos a través de las respectivas community strings.

¡Así que ya saben!. Si realizan una test de penetración y obtienen como resultado la presencia del dispositivos con el servicio SNMP, y este posee community strings por defecto, el impacto podría ser el descripto en este post. Es por ello que siempre es recomendable modificar las strings.

Fernando Catoira

2 comentarios:

  1. La versión analizada es la 1 y en la misma se puede configurar desde y a que host se debe responder.

    La versión 3 utiliza un esquema más robusto de autenticación.

    Saludos.

    ResponderBorrar
  2. Saludos HH. Exactamente, es posible configurar a través del archivo snmpd.conf que red tendrá acceso a este protocolo. De esta manera, siempre aclaré que no es un problema del protocolo, sino de una mala configuración; esa es justamente la idea de la publicación.

    En este caso, la versión que utilicé como prueba es la 2c, y es verdad que la versión 3 ya es mucho más robusta. Será cuestión de tiempo hasta que sea la versión estándar sobre todos los dispositivos.

    Gracias por tu comentario.

    Saludos!

    ResponderBorrar