Archivo por meses: mayo 2012

Peligroso SNMP Parte I

Posted on por
Responder
Anuncios

Siempre había oído hablar de las debilidades del protocolo SNMP en su versión 1 y 2, pero hasta ahora no me había puesto a trastear con ellas, así que preparado un laboratorio virtual, me puse manos a la obra.

De forma muy resumida diremos que SNMP (Simple Network Management Protocol) es un protocolo que nos va a permitir monitorizar los dispositivos de red y su comportamiento, pudiendo detectar posibles fallos, irregularidades o corroborar que nuestra red funciona correctamente. Empleando UDP y los puerto 161 y 162, cada equipo de red configurado para ser administrado o monitorizado mediante este protocolo, tendrá un agente que irá recogiendo información y la guardará en una base de información interna denominada MIB (Management Information Base). Cada entrada de esa MIB constituirá un objeto, el cual será identificado mediante una sucesión única de números, denominado OID (Object Identifier). Por ejemplo si monitorizamos la memoria en uso de un switch Cisco, el objeto será «ciscoMemoryPoolUsed«; el OID, 1.3.6.1.4.1.9.9.48.1.1.1.5; y el valor será un número entero no negativo.

Por otro lado tendremos una estación (PC o servidor) denominada NMS (Network Management System) la cual tendrá instalada un software de monitorización. Este software preguntará o escribirá al, o en el equipo, por el valor de un OID concreto. El equipo, sea un switch, router, etc; responderá a la NMS con el citado valor. Luego dependiendo de éste y de la configuración del propio software, éste nos podrá mostrar en pantalla lo que sea, por ejemplo una casilla en verde si todo va bien, en amarillo si hay algo raro o en rojo si algo ha fallado y tenemos que salir a toda pastilla a arreglarlo.

Para que el equipo administrado y la estación de monitorización se entiendan se han de definir lo que se denomina «comunidades«. Un comunidad es una palabra clave utilizada como autenticación entre uno y otro. Las hay de lectura y de lectura-escritura. Con la primera  la NMS leerá valores de los objetos en la MIB del equipo, mientras que con la segunda podrá escribir en ella. Obviamente la NMS deberá tener definidas las MIB, sean estándar o propietarias, de los equipos a monitorizar o bien los plugins que los interpreten.

Para este post he montado un laboratorio con GNS3 y algunas máquinas virtuales VMWare comunicadas mediante los switches que previamente he configurado en el simulador. A continuación os pongo una captura con parte de la topología que nos interesa:

Como vemos el switch OF_01 es un switch de acceso al que están conectados 4 equipos, W7001, un Windows 7; XP001, un Windows XP; NST, distribución Network Security Toolkit y BT5R2, con un Backtrack 5, todos ubicados en la misma VLAN, en este caso la 10. W7001 lo utilizaremos para correr Cain; NST, un Nagios con unos plugin instalados para monitorizar la carga de CPU, memoria usada de los switches y un «ping» a la IP de gestión de los equipos para ver si siguen «vivos»; y BT5R2 para ejecutar algunas aplicaciones para SNMP, nmap y wireshark.

El switch «OF_01» tiene dos uplinks hacia dos switches de capa 3 que harán las funciones de distribución/core denominados «CORE_OF_01» y «CORE_OF_02». Tendrán HSRP configurado para la interfaz VLAN 10, OSPF como protocolo de enrutamiento y SNMP igualmente para la monitorización.

Para utilizar SNMP en los switches, los habremos configurado de la siguiente manera para las comunidades de lectura y lectura-escritura, respectivamente.

OF_01(config)# snmp-server community roedorta ro
OF_01(config)# snmp-server community rwedorta rw

Una de las medidas más comunes para “proteger” nuestros equipos es configurar sólo la comunidad de sólo lectura. De esta manera evitaremos que si alguien nos compromete nuestros equipos no podrá hacer cambios en ellos, sólo leer los objetos de la MIB. Lo malo es que en ciertos escenarios es necesario utilizar también la de lectura-escritura ya que es empleada por algunas aplicaciones de gestión, como CiscoWorks, para hacer cambios en nuestros equipos.

Para saber si un equipo está ejecutando SNMP podremos hacer un escaneo de nuestra red mediante nmap:

nmap -sU -sV -p 161 192.168.10.0/24

Con los resultados arrojados, si además lo acompañamos de una captura con Wireshark nos podemos encontrar con otra información extra analizando protocolos como CDP, en el caso de estar activado, o HSRP. En nuestro caso nos centraremos en la IP 192.168.10.10 ya que el escaneo con nmap nos indica que la versión de SNMP es «Cisco SNMP service».

Nmap scan report for 192.168.10.10
Host is up (0.021s latency).
PORT    STATE SERVICE VERSION
161/udp open  snmp    Cisco SNMP service
MAC Address: C2:05:18:1C:00:00 (Unknown)

Por otra parte la captura de Wireshark nos dice que la IP 192.168.10.2 y 192.168.10.3 son el nodo «Active» y «Standby» en HSRP. A priori podemos pensar que sería mejor ir a por ellos, pero para empezar iremos a los más cercanos y cuando obtengamos más información ya iremos escalando…

Aquí partiremos que tenemos en nuestro poder el nombre de las comunidades. Podremos tener varios métodos para obtenerlas por ejemplo un MITM, ya que la el nombre de comunidad va en texto plano y por tanto fácilmente interpretable. Sin embargo esto no siempre surtirá efecto ya que la NMS debería estar situada en una granja de servidores detrás de algún cortafuegos. Otras métodos podrán ir desde una archivo de configuración antiguo (habrá quien cambia las contraseñas y los usuarios de los equipos pero no el nombre de comunidad), ingeniería social o simple picaresca.

Otra alternativa será realizar un ataque por fuerza bruta empleando la herramienta onesixtyone incluida dentro de la distribución BackTrack, y que como ejemplo de ejecución tenemos:

root@bt:/pentest/enumeration/snmp/onesixtyone#./onesixtyone -w <espera en milisegundos entre paquete y paquete> -c <diccionario con nombres de comunidad> -i <lista con host objetivo>

Bien sea por un método u otro, el caso es que como digo tendremos los nombres de comunidad, en nuestro ejemplo roedorta como lectura y rwedorta para lectura-escritura.

A partir de aquí podremos con aplicaciones como snmpenum.pl y snmpcheck.pl, incluidas también en Backtrack, recolectar información de nuestro obejtivo y conocer algo más de él.

Para ello:

root@bt:/pentest/enumeration/snmp/snmpenum# ./snmpenum.pl 192.168.10.10 roedorta cisco.txt > /root/Desktop/switch.txt

root@bt:/pentest/enumeration/snmp/snmpcheck# ./snmpcheck-1.8.pl -t 192.168.10.10 -v 2 -c roedorta > /root/Desktop/switch01.txt

Como podemos ver SNMP puede ser muy útil si los administradores no han tomado algunas precauciones en cuanto a la configuración de este protocolo se refiere. Pero llegados a este punto y visto las distintas aplicaciones incluidas en BackTrack nos vamos a ir ahora a Caín, instalada en el equipo W7001. Caín es una aplicación que nos va a permitir llevar a cabo una gran cantidad de tareas, desde generar certificados falsos, ataques MITM, crackeo de contraseñas, arpspoofing, sniffer, etc.

Pero … ¿para qué la utilizaremos?

Esto lo dejamos para la siguiente entrega que será dentro de poco, que por ahora hay con qué practicar un poco.

Un saludo y…. seguiremos informando….

Autonegociación

Posted on por
6
Anuncios

Andaba repasando algunos de mis apuntes cuando encontré un tema que aunque parezca básico y elemental puede, en algunos casos, darnos algún quebradero de cabeza, la auto-negociación.

Para que dos dispositivos de red, bien un equipo final (PC o servidor) y un switch o un switch con otro, se comuniquen entre sí ambos deben tener los mismos parámetros del enlace configurados en ambos extremos. Estos parámetros son, la velocidad y el dúplex. La velocidad normalmente viene expresada en mega-bits o giga-bits por segundo , siendo los valores más comunes 100 Mbps y 1000 Mbps (1Gbps) aunque también los hay de 10 Gbps o incluso se habla ya de 100 Gbps. Por otro lado, el dúplex se refiere a cómo fluyen los datos en la interfaz de red. Esto es, se puede enviar o recibir (half dúplex), método similar a aquellos “walkie-talkies” que más de uno hemos tenido de pequeños, en los que hablabas o escuchabas, pero las dos cosas a la vez no podían ser. O por otro lado tenemos el otro caso en el que puedes enviar y recibir a la vez (full dúplex). Por poner otro ejemplo, es lo que vendría a ser un teléfono. Allí puedes hablar y escuchar al mismo tiempo; otra cosa es que te entiendas con el otro, pero por poder, se puede.

Estos parámetros de velocidad y dúplex pueden ser configurados tanto de forma automática, como manual. La forma automática es lo que se denomina auto-negociación, es decir los equipos ya sean PC’s, servidores, switches, routers, etc. “hablan” entre si y acuerdan emplear una velocidad y un dúplex (half o full) concreto. Comenzarán por las velocidades más altas y modos full-dúplex hasta llegar a las más bajas y en modo half-dúplex. La auto-negociación es un mecanismo/protocolo y como tal debe ejecutarse en ambos extremos. Por el contrario otra de las opciones configurarlos manualmente, indicar que el enlace funcione a una velocidad y dúplex concreto.

Uno de los problemas más comunes que pueden darse, es que los extremos no estén configurados de manera igual por algún fallo en el proceso de negociado. Por ejemplo un extremo a 100 Mbps full-duplex y otro a 100 Mbps half-duplex.

Si esto sucede las consecuencias podrán ser desde una pérdida de rendimiento hasta que no haya comunicación en el enlace. En este caso el modo en half-dúplex escuchará el medio y enviará datos si no detecta ninguna señal en la línea Rx (recepción). En cambio si detecta alguna señal mientras envía se producirá una colisión con lo que el envío cesará, esperando un tiempo aleatorio hasta que se pueda reenviar la trama y proseguir con la comunicación. Sin embargo, en el modo full-duplex esto no ocurre ya que una interfaz operando en este modo puede emitir y recibir a la vez con lo que no se producirían colisiones. Por tanto, puesto que el extremo con full dúplex enviará siempre que tenga tráfico, pero en el extremo con half-dúplex la cosa se complicará puesto que al llegarle señales, con más o menos frecuencia, en su línea Rx no podrá enviar hasta que estas no cesen. Cuantas más tramas genere el extremo full-duplex menos posibilidad de envío tendrá el extremo half-dúplex.

Para evitar problemas lo mejor es comprobar que ambos extremos estén configurados de igual manera, o los dos extremos en auto-negociación o en manual. Sin embargo diré que he visto cómo un switch Cisco 3750G-12S y un Firewall Juniper sólo se comunicaban en modo automático y no había manera de que lo hiciesen configurándolos de forma manual; y otro en que algunos servidores con sistema operativo concreto parece que no negocian bien con el switch y hay que configurarlos manualmente.

En los switches Cisco se pueden elegir los dos modos de configuración. Para equipos con IOS, dentro del modo de configuración de cada interfaz con los comandos speed y duplex  indicaremos los valores concretos:

switch(config-if)#speed ?
10    Force 10 Mbps operation
100   Force 100 Mbps operation
auto  Enable AUTO speed configuration

switch(config-if)#duplex ?
auto  Enable AUTO duplex configuration
full  Force full duplex operation
half  Force half-duplex operation

Y si lo que tenemos es CatOS:

Switch> (enable)set port dúplex <modulo/puerto> full|half|auto

Switch> (enable)set port speed <modulo/puerto> 10|100|auto

En cualquier caso son características que deberemos tener en cuenta a la hora de la configuración de equipos o detectar posibles puntos de fallos, especialmente de rendimiento. En fin otra cosa más a tener en cuenta sobre todo si alguien nos compromete un switch al que tenemos servidores conectados y nos cambia los valores…

Bueno, nos vemos en la próxima…

Seguiremos informando…

Conectándonos a casa…Parte II

Posted on por
Responder
Anuncios

Siguiendo con el tema anterior, en este post vamos a explicar los pasos a seguir para poder conectarnos al servidor y establecer así el túnel cifrado.

Para este ejemplo lo haremos con un equipo con Windows 7 in. Para ello nos descargaremos e instalaremos la aplicación OpenVPN para este sistema operativo, desde aquí.

Luego nos dirigiremos a C:\Program Files\OpenVPN\config y allí pegaremos los certificados y claves privadas ca.cert, cliente01.cert, cliente01.key y ta.key que utilizará la aplicación como credenciales para poder autenticarnos contra el servidor. Luego crearemos un archivo de texto con extensión .ovpn que será nuestro archivo de configuración, el cual editaremos de la siguiente manera:

#Modo de funcionamiento
client
#Tipo de interfaz
dev tun
#Protocolo de transporte
proto udp
#IP o FQDN y puerto a la escuha de éste
remote <IP o FQDN> <Puerto>
#Certificado de nuestra AC
ca ca.crt
#Certificado de nuestro equipo cliente
cert cliente01.crt
#Clave privada de nuestro equipo cliente
key software01.key
#Clave para modod TLS
tls-auth ta.key 1
#Papel en el modo TLS, en este caso cliente
tls-client
keepalive 10 40
persist-key
persist-tun
verb 3
comp-lzo yes
cipher AES-256-CBC
tls-cipher DHE-RSA-AES256-SHA
auth SHA512

De los parámetros anteriores veremos cómo hay algunos que especifican claramente el papel que juega nuestro equipo, es decir es un cliente y no un servidor. Esto queda claro en la primera línea, client.  Por tanto al cliente hay que decirle contra quién se tiene que conectar. Esto lo conseguimos con la línea remote <IP o FQDN> > <puerto a la escucha del servidor>. Alguno dirá ¿qué pasa si mi ISP me da una dirección IP dinámica? Para esto podremos crear una cuenta en DynDNS y configurar nuestro router o nuestro servidor para actualizar periódicamente nuestra IP. Finalmente las líneas tls-auth ta.key 1 y tls-client especifican los parámetros del modo TLS. En la primera vemos que finaliza en 1  (a diferencia del servidor que termina en 0) y en la segunda cómo se especifica que se trata de un cliente.

Con esto aún nos quedaría indicar que la aplicación debe ejecutarse con permisos de administrador para que podamos agregar a nuestra tabla de rutas que todo el tráfico dirigido a la red de nuestra casa salga por la interfaz de nuestra VPN (tun0) en lugar de la interfaz física conectada a la red en la que nos encontremos, un hotel, aeropuerto, casa de un colega, etc.

Y ya está, con pinchar con el botón derecho del ratón sobre el archivo de configuración y seleccionar “Start OpenVPN on this config file” se abrirá una ventana de consola donde figurará todo el procedimiento de conexión y al cabo de unos segundos tendremos nuestra VPN establecida.

A partir de ahí podremos trabajar con las unidades de red tal y como estuviéramos en casa. OJO!! Acordarse que el tipo de interfaz que tenemos funcionando (tun0) es de capa 3 con lo que el tráfico broadcast utilizado por ciertos protocolos de red NO se pasará de una interfaz a otra, con lo que si queremos mapear unidades de red en nuestro equipo deberemos indicar la IP y no su nombre. ¿Si?

Pues nada, con este artículo ya damos por finalizado la creación nestra VPN casera. Ahora me voy a preparar un laboratorio para las siguientes entradas.

Seguiremos informado….