La Comunidad DragonJAR » Router

Vulnerabilidad en Routers Thomson a Fondo

DragoN — Sun, 31 Oct 2010 21:43:48 +0000

Este documento pretende ser de forma explícita, la opción de poder obtener la clave WEP de los router Thomson, en sus versiones 6 y 7, de las cuales se ha realizado pruebas satisfactorias.

Estos routers son distribuidos en Mexico por una compañía que presta los servicios de internet, en España creo que por Orange, y en Guatemala por la empresa que ya conocemos, y que es la principal en los servicios de internet residencial.

Bueno, sin mas preámbulo vamos a las prueba, que pienso que es lo que mas apreciamos, si es cierto es lo que mas aprecio cuando alguien divulga algo interesante sobre las redes inalámbricas, aunque después me toque que leer la introducción. (claro esta que en emergencias la introducción se pasa por alto, si, eso, el conocimiento hace que saltemos ese paso)

Materiales:

1). Sistema Operativo: en este ejercicio utilizo Windows Xp.
2). Software: inSSIDer 2.0 http://www.metageek.net/products/inssider

Figura No1. Acerca de inSSIDer

Aunque también se puede utilizar NetStumbler, (utilizado por excelencia): http://www.netstumbler.com/downloads/ (para las antenas caseras me ha servido mucho para direccionar la señal)

3). Tarjeta de Red Wifi: en este ejercicio he utilizado una marca Sabrent (vale también una Alfa con chip Realtek 8187L):

Figura No 2. Propiedades Tarjeta Wifi con chip Realtek

4). Laptop: si, Porque? (después lo explico), con una batería al 100% de carga y que dure mas de una hora.

En que consiste?

La vulnerabilidad o defecto de fábrica consiste en que, si observamos físicamente estos routers en la parte inferior, traen consigo una etiqueta donde esta el nombre del SSID por defecto y su correspondientes claves WEP y WPA, que vienen siendo las mismas.

En la versión 6, el nombre del SSID que viene por defecto esta compuesto por la siguiente cadena: SpeedTouch123456 y en la versión 7, esta cadena a cambiado por esta otra: Thomson123456, denotando que los últimos seis caracteres son hexadecimales.

Resulta que conociendo estos caracteres hexadecimales, utilizando ingenieria reversa, se puede llegar a obtener la clave WEP por default. Existe un programa desarrollado en C, creado por él que hizo este estudio, el cual pueden encontrar en varios sitios:

http://www.gnucitizen.org/blog/default-key-algorithm-in-thomson-and-bt-home-hub-routers/

http://foro.elhacker.net/hacking_wireless/routers_thomson_caso_espanol_redes_wepwpa_%E2%80%9Cspeedtouchxxxxxx%E2%80%9D_al_descubierto-t208312.0.html

http://lampiweb.com/foro/index.php?topic=1763.0

En fin, si buscamos en la red, seguro que encontraremos mucha información al respecto.

Otra vulnerabilidad?

Para mi opinión creo que si, se trata del contenido de este ejerció, entonces manos a obra.

Resulta que por alguna extraña razón (y creo que no es así) cuando se inicia o reinicia un router de esta marca, nos da la grata sorpresa!!!

Ahora si, primer paso:

Abrir (ejecutar) el inSSIDer:

Figura No3. InSSIDer ejecutandose.

Entre las bondades de esta aplicación están las de capturar las SSID que nos rodean, o sea que nos muestra las redes que están a nuestro alcance, para realizarlo solo hay que presionar el botón “Start”, que se encuentra en la parte superior derecha, con esto se inicia el “scan”:

Figura No. 4. inSSIDer con redes detectadas

Como se podrá observar, hay 6 redes detectadas, y se nos muestra las características de cada una, como la dirección MAC, el nombre del fabricante, etc., pero la información que nos interesa es el SSID y que el fabricante sea “Thomson”.

Ahora solo resta iniciar o reiniciar el router, y allí es donde nos muestra su defecto ( o virtud), depende de que lado estemos para hacer la critica, procedo entonces a reiniciar el primero que sale en la lista, y observar luego la siguiente figura. Se nos regala esa cadena hexadecimal que necesitamos para luego aplicarla al programa stkeys.exe o cualquier otro que mas nos guste, ya que actualmente hay hasta versiones GUI para aquellos que no son adeptos al uso de la consola.

Entonces, para que una laptop con buena batería, pues esto lo experimente en un día lluvioso, cuando de repente se fue la luz (como se dice por aquí) y me quede a ciegas trabajando con el reflejo de la pantalla, es esa ocasión la batería estaba al 100%. Seguido, como a la media hora, se nos hizo la luz, entonces iniciaron a resaltar también los bombillos, la refrigeradora, los ventiladores, y entre ellos los ROUTERS marca Thomson, y así fue como buen observador vi de lo que la tarjeta WIFI se estaba alimentando.

Figura No 5. SSID inicial cuando se inicia el router Thomson

Figura No. 6. Usando WZCSVC para ver redes detectadas

Conclusión:

Llegando a este punto final, este ejercicio se aplica para aquellos routers en los cuales los IPS no cambian la clave WEP/WPA que trae por default, bueno aca la critica desde el otro lado, siendo yo un ISP tomaría en consideración lo siguiente:

Cambiar la clave WEP/WPA por default que traen los equipos de marca Thomson.
Siendo el punto 1 una vulnerabilidad, cambiaría los equipos que distribuyo con el servicio, en este caso los routers de esta marca, por una versión sin esta vulnerabilidad.
Sabiendo que esta vulnerabilidad se repitió en la versión 6 y 7, mejor cambio los routers por otra marca.
Esperando que este documento sea para uso didáctico y que sea de mucha utilidad no solo para lo cual fue presentado, sino para tomar en consideración para cuando necesitemos contratar los servicios de un ISP, de forma particular o como empresa.
Esta vulnerabilidad la descubrí hace aproximadamente 3 años, porque anteriormente esta empresa T*****, configuraba el nombre del SSID con el número de teléfono, por ejemplo: si el número telefónico era: 78895678, este mismo número colocaba como SSID, y la clave WEP/WPA era nada mas y nada menos que este número convertido en hexadecimal, con lo cual quedaría así:
SSID: 78895678
clave WEP: 4B3DA3E
pero la clave WEP debería ser de 64 bits, que corresponde a 10 caracteres hexadecimales y al convertir el número telefónico solo obtenemos 7 caracteres, entonces idearon esto: agregar un 1 al inicio y 10 en hexadecimal al final, entonces la clave quedaría así:
14B3DA3E0A (“1” + “4B3DA3E” + “0A”)

Hoy si, termino, divulgar estos conocimientos y aventuras, en ocasiones nos trae consecuencias, tales como que te llamen “hacker”, y sabiendo que la palabra “hacker” la asocian como “delincuente”, pero para alguien maduro y con otra perspectiva sabe que todos llevamos un “hacker” adentro. O acaso nunca te ha tocado arrancar tu vehículo al empujón!!

Escrito por José de Paz (Guatemala) para La Comunidad DragonJAR

Anexo:
Codigo Fuente

También puede interesarte...

SeguriSemanal II

Cortex — Mon, 08 Jun 2009 01:00:40 +0000

Y despedimos otra semana más acompañado de nuestro habitual boletín de seguridad y alguna otra tendencia. Bastante información compartida en la red esta semana y más de un lanzamiento (que para el que no sabía) le arreglará el día.

En el día de ayer como se había anunciado previamente, la Comunidad DragonJAR estuvo presente en el BarCamp Medellín, en resumen el evento estuvo excelente y felicitamos por la perfecta coordinación que realizaron Laura Camila, Emerson y Camilo (cabezas principales del evento) y a todas las demás personas que hicieron parte de la logística. En el día de mañana habrá información más detallada del evento.
La gran noticia de la semana es el lanzamiento de OpenSolaris 2009.06. Se incluyen múltiples mejoras en muchos aspectos del sistema, ZFS, Virtualización, Rendimiento, y mucho más.
A pesar de que aún se encuentra en fase de desarrollo, Windows 7 está superando con creces a su hermano mayor Windows Vista. Se incluyen muchas cosas nuevas que pueden confundir a más de uno, por este motivo la gente de Ethek ha decidido crear una serie de artículos en los que enseñar a usar muchas cosas que quizás no conoces. I II III IV V VI.
Ya se encuentra disponible la Edición 37 de SET, una E-Zine dedicada al Hacking. Encontramos muchos temas interesantes como Ingeniería Social y estafas, Programando Shellcodes IA32, HeapOverflows en Linux, y mucho más. Descárgala aquí.
octalh de Aztek Mindz ha desarrollado una herramienta para los routers 2wire 2701HG-T que permite entre sus varias utilidades permite obtener información sobre el dispositivo, obtener la lista de los equipos, borrarla, resetear contraseña, entre otros. Aquí encuentras el ejecutable.
En IronGeek nos muestran como podemos proteger la cache ARP para evitar ataques de envenenamiento de ARP haciendo usa de la herramienta ARPFreeze.
El próximo martes Microsoft hará publico el habitual boletín de seguridad mensual para el mes de Junio, ya se encuentra un adelanto de lo que habrá.
Little Snitch es una aplicación para Mac que te permite mantenerte informado sobre las conexiones exteriores que se intenten establecer. La versión 2.1.4 ya está aquí.

Una semana más que se culmina, con la expectativa de que la que nos recibirá será mucho mejor.

También puede interesarte...

Nuevo Gusano Infecta Routers, Modems, y Sistemas GNU Linux

DragoN — Thu, 26 Mar 2009 06:49:29 +0000

Un nuevo gusano llamado psyb0t descubierto por la empresa DroneBL, acecha la red, esto no es nada nuevo, todos los días salen gusanos tratando de conseguir la mayor cantidad de víctimas posibles para convertirlos en zombies y realizar las tareas que encargue su creador, pero este gusano tiene una particularidad que lo hace diferente, es capaz de infectar routers, modems y sistemas gnu linux.

Es la primera vez que se observa un ataque exitoso utilizando la infección en este tipo de dispositivos y se calcula que el número de afectados supera los 100.000 equipos y va en aumento, ya que su detección y desinfección son complicadas y “difíciles” de llevar a cabo para un usuario promedio.

El psyb0t se propaga a través de los servicios ssh, telnet y http, explotando vulnerabilidades en ellos o realizando ataques de fuerza bruta ante contraseñas débiles en los usuarios, tan pronto logra acceder al dispositivo descarga un archivo malicioso que permite a su creador administrar remotamente el dispositivo robando información sensible que pasa por el, realizando denegaciones de servicio o cualquier otra tarea que desee realizar su creador, aparte de esto modifica las reglas del firewall para impedir el acceso a el panel de administración del dispositivo.

Si notas un comportamiento extraño en tu red y ya descartaste infecciones de los equipos que la confirman, no olvides revisar la configuración de tu router o modem, si no puedes entrar al panel de control de ellos posiblemente estas infectado con el psyb0t.

Recomendaciones si estas Infectado con el psyb0t

Resetea La Configuración de tu Dispositivo
Actualiza tu firmware a la última versión
Sigue las Instrucciones indicadas por DroneBL

Recomendaciones para evitar ser infectado por el psyb0t

Mantén al día la versión de tu firmware
Utiliza contraseñas fuertes (nunca nos cansaremos de repetirtelo)
Deshabilita los servicios que no utilices en tus dispositivos
Revisa periódicamente el panel de control de tus aparatos

Para Más Información:
DroneBL
Psyb0t Attacks Linux Routers
Psyb0t, infección en ¡routers!, ¡módems! y ¡Linux!

También puede interesarte...

Hacking de Redes UPnP – Parte III

DragoN — Thu, 05 Feb 2009 00:23:53 +0000

=======================
Hacking de Redes UPnP – Parte I
Hacking de Redes UPnP – Parte II
Hacking de Redes UPnP – Parte III
=======================

Continúa desde “Hacking de Redes UPnP – Parte II“

Una Introducción a Miranda

Miranda es una herramienta de administración de UPnP escrita en Python. Lleva consigo una línea de comandos que soporta autocompletado e historial de comandos, y provee la habilidad de guardar tu trabajo en un archivo que puede ser recargado para su posterior análisis. También puedes alterar las configuraciones del programa sobre la marcha, y registrar todos tus comandos en un archivo log, de manera que puedas saber exactamente lo que ejecutaste y cuando lo ejecutaste.

Miranda puede descubrir hosts UPnP tanto activamente como pasivamente, y con un simple comando pueden ser enumerados todos los tipos de dispositivos, servicios, acciones y variables. Las variables de estado del servicio pueden ser automáticamente correlacionadas con sus acciones asociadas, e identificadas tanto sus variables de salida y/o entrada para cada acción. Miranda almacena la información de todos los hosts en una estructura única de datos y te permite desplegar directamente toda la información y ver su contenido.

Finalmente, puedes ejecutar cualquier acción soportada por el host UPnP; si la acción requiere algún valor de entrada, se te informará su nombre y su tipo (string, 4 byte entero, 2 byte entero, etc), así como los valores permitidos o rangos de valores que el host UPnP ha suplido, y se le pedirá que ingrese el valor.

Descubriendo hosts UPnP con Miranda

Cuando inicias Miranda por primer vez, te llevará a una shell interactiva con un prompt ‘upnp>’ a la espera de ejecución de comandos. La primera cosa que probablemente quieras hacer es descubrir si hay algún host UPnP en tu red; esto puede ser realizado con los comandos ‘pcap’ o ‘msearch’. Cuando es ejecutado el comando ‘pcap’, Miranda se pondrá en escucha (modo pasivo) buscando mensajes SSDP NOTIFY, mientras que el comando ‘msearch’ consultará los dispositivos UPnP usando un mensaje M-SEARCH. Por defecto, ‘msearch’ buscará todos los dispositivos UPnP, pero también se le puede especificar que busque un determinado tipo de dispositivo o servicio si así se desea. En este ejemplo, simplemente buscaremos algún dispositivo:

Código:

upnp> msearch

Entering discovery mode for 'upnp:rootdevice', Ctl+C to stop...

****************************************************************
SSDP reply message from 192.168.0.1:5678
XML file is located at http://192.168.0.1:5678/igd.xml
Device is running Embedded UPnP/1.0
***************************************************************

Discover mode halted...

Aquí podemos ver que hay un host UPnP en la red, el cual resulta ser un router DI-524. También podemos ver que es reportado el tipo de servidor UPnP (‘Embedded UPnP/1.0¿), y la ubicación del archivo XML raíz.

Ejecutando el comando ‘host list’ nos muestra la lista de todos los hosts UPnP descubiertos y el número índice de cada uno (el número índice es usado en comandos subsecuentes para hacer referencia a un host específico):

Código:

upnp> host list

       [0] 192.168.0.1:5678

Hemos descubierto un host UPnP, ahora necesitamos enumerar sus capacidades. Ejecutando el comando ‘host get 0′ obtendremos toda la información UPnP del host con el índice 0:

Código:

upnp> host get 0

Requesting device and service info for 192.168.0.1:5678 (this could take a few seconds)...

Host data enumeration complete!

Ahora buscamos en todos los datos que hemos recogido de este host usando el comando ‘host info’. Este comando nos permite desplegar los datos del host interno de Miranda y ver la información que este almacena. Observa también que todos estos comandos se autocompletaran automáticamente, de manera que no tendrás que escribirlos por completo:

Código:

upnp> host info 0

xmlFile : http://192.168.0.1:5678/igd.xml
name : 192.168.0.1:5678
proto : http://
serverType : Embedded HTTP Server 3.23
upnpServer : Embedded UPnP/1.0
dataComplete : True
deviceList : {}

Código:

upnp> host info 0 deviceList

InternetGatewayDevice : {}
WANDevice : {}
WANConnectionDevice : {}

Código:

upnp> host info 0 deviceList WANConnectionDevice services WANIPConnection actions

AddPortMapping : {}
GetNATRSIPStatus : {}
GetGenericPortMappingEntry : {}
GetSpecificPortMappingEntry : {}
ForceTermination : {}
GetExternalIPAddress : {}
GetConnectionTypeInfo : {}
GetStatusInfo : {}
SetConnectionType : {}
DeletePortMapping : {}
RequestConnection : {}

Dependiendo del host, puede haber muchos datos en esta estructura, así que si quieres ver el resumen de los datos para un host particular, ejecuta el comando ‘host summary’:

Código:

upnp> host summary 0

Host: 192.168.0.1:5678
XML File: http://192.168.0.1:5678/igd.xml
InternetGatewayDevice
     manufacturerURL: http://www.dlink.com
     modelName: D-Link Router
     UPC: 123456789001
     modelNumber: None
     presentationURL: http://192.168.0.1:80
     friendlyName: D-Link Router
     fullName: urn:schemas-upnp-org:device:InternetGatewayDevice:1
     modelDescription: Internet Access Router
     UDN: uuid:upnp-InternetGatewayDevice-1_0-12345678900001
     modelURL: None
     manufacturer: D-Link
WANDevice
     manufacturerURL: http://www.dlink.com
     modelName: D-Link Router
     UPC: 123456789001
     modelNumber: 1
     presentationURL: None
     friendlyName: WANDevice
     fullName: urn:schemas-upnp-org:device:WANDevice:1
     modelDescription: Internet Access Router
     UDN: uuid:upnp-WANDevice-1_0-12345678900001
     modelURL: http://support.dlink.com
     manufacturer: D-Link
WANConnectionDevice
     manufacturerURL: http://www.dlink.com
     modelName: D-Link Router
     UPC: 123456789001
     modelNumber: 1
     presentationURL: None
     friendlyName: WAN Connection Device
     fullName: urn:schemas-upnp-org:device:WANConnectionDevice:1
     modelDescription: Internet Access Router
     UDN: uuid:upnp-WANConnectionDevice-1_0-12345678900001
     modelURL: http://support.dlink.com
     manufacturer: D-Link

El comando de resumen nos muestra todos los tipos de dispositivos que este host reporta, así como algún dato adicional relacionado con cada tipo de dispositivo. Si quieres ver toda la información que miranda almacena sobre un host en particular, lo puedes hacer con el comando ‘host details 0′. Sin embargo, la información arrojada por este comando es por lo general bastante larga, probablemente quieras guardarla en un archivo y verla en un editor de texto; esto puede ser hecho con el comando ‘save info 0′:

Código:

upnp> save info 0 dl524

Host info for '192.168.0.1:5678' saved to 'info_dl524.mir'

El argumento ‘dl524′ es opcional; si ninguna cadena es pasada como argumento, se usará entonces el número índice en su lugar. Mientras que estemos en la sesión, también podemos guardar los datos que Miranda ha almacenado sobre todos los hosts que han sido descubiertos, de modo que después podamos cargarlos de nuevo e iniciar una nueva sesión:

Código:

upnp> save data session1

Host data saved to 'struct_session1.mir'

Enviado comandos UPnP con Miranda

Ahora vamos a explorar algunas de las acciones que podemos ejecutar en este dispositivo. Anteriormente cuando ejecutamos el comando ‘host info’, listamos todas las acciones disponibles para el servicio WANIPConnection que está asociado con el dispositivo WANConnectionDevice; veámoslas de nuevo:

Código:

upnp> host info 0 deviceList WANConnectionDevice services WANIPConnection actions

AddPortMapping : {}
GetNATRSIPStatus : {}
GetGenericPortMappingEntry : {}
GetSpecificPortMappingEntry : {}
ForceTermination : {}
GetExternalIPAddress : {}
GetConnectionTypeInfo : {}
GetStatusInfo : {}
SetConnectionType : {}
DeletePortMapping : {}
RequestConnection : {}

Como puedes ver, este servicio es el que soporta las acciones AddPortMapping y DeletePortMapping, así como algunas otras que parecen interesantes. Primero intentaremos ejecutar la acción GetExternalIPAddress; esto se puede hacer con el comando ‘host send’. Para ejecutar un comando, debes indicar el número índice del host, el nombre del tipo de dispositivo que soporta el servicio, el nombre del servicio que soporta la acción, y el nombre de la acción que quieras ejecutar (de nuevo, todos estos campos se autocompletan, no es mas que escribir mientras se va mirando)

Código:

upnp> host send 0 WANConnectionDevice WANIPConnection GetExternalIPAddress

NewExternalIPAddress : 68.12.34.56

‘NewExternalIPAddres’ es el nombre de la variable asociada con esta acción, y ’68.12.34.56′ es el valor devuelto para esa variable por el IGD. Algunas acciónes tienen varias variables asociadas con ellas; estas variables pueden ser tanto de entrada (valores que le pasamos al IGS) o de salida (valores devueltos por el IGD). En el caso de la acción GetExternalIPAddress, solo hay una variable de salida. Sin embargo, si hay alguna variable de entrada disponible para una acción, Mirando nos pedirá que introduzcamos estos valores antes de enviar la acción. Toda la información de la variable puede ser enumerada/vista usando los comandos ‘host info’ o ‘host details. No tenemos que tener ningún conocimiento sobre estas variables antes de ejecutar las acciones UPnP.

Intentemos mapeando el puerto 8080 en la WAN para abrir la interfaz administrativa que está en el puerto 80 del IGD (192.168.0.1):

Código:

upnp> host send 0 WANConnectionDevice WANIPConnection AddPortMapping

Required argument:
     Argument Name:  NewPortMappingDescription
     Data Type:      string
     Allowed Values: []
     Set NewPortMappingDescription value to: All your ports are belong to us

Required argument:
     Argument Name:  NewLeaseDuration
     Data Type:      ui4
     Allowed Values: []
     Set NewLeaseDuration value to: 0

Required argument:
     Argument Name:  NewInternalClient
     Data Type:      string
     Allowed Values: []
     Set NewInternalClient value to: 192.168.0.1

Required argument:
     Argument Name:  NewEnabled
     Data Type:      boolean
     Allowed Values: []
     Set NewEnabled value to: 1

Required argument:
     Argument Name:  NewExternalPort
     Data Type:      ui2
     Allowed Values: []
     Set NewExternalPort value to: 8080

Required argument:
     Argument Name:  NewRemoteHost
     Data Type:      string
     Allowed Values: []
     Set NewRemoteHost value to:

Required argument:
     Argument Name:  NewProtocol
     Data Type:      string
     Allowed Values: ['TCP', 'UDP']
     Set NewProtocol value to: TCP

Required argument:
     Argument Name:  NewInternalPort
     Data Type:      ui2
     Allowed Values: []
     Set NewInternalPort value to: 80

La acción AddPortMapping recibe varios valores, pero hay unos puntos importantes que deben ser mencionados:

1. Los valores Booleanos son ’1′ (verdadero) o ’0′ (falso)
2. El argumento NewProtocol solo permite dos valores, ‘TCP’ o ‘UDP’
3. No especificamos ningún valor para la variable NewRemoteHost, la cual permite que todos los hosts remotos coincidan con esta asignación de puertos.

No recibimos ningún dato porque la acción AddPortMapping no tiene ninguna variable de salida definida (de nuevo, toda esta información es almacenada en la estructura de datos, si tienes curiosidad). Sin embargo, podemos verificar que la acción fue ejecutada exitosamente lanzando la acción GetSpecificPortMappingEntry:

Código:

upnp> host send 0 WANConnectionDevice WANIPConnection GetSpecificPortMappingEntry

Required argument:
     Argument Name:  NewExternalPort
     Data Type:      ui2
     Allowed Values: []
      Set NewExternalPort value to: 8080

Required argument:
     Argument Name:  NewRemoteHost
     Data Type:      string
     Allowed Values: []
     Set NewRemoteHost value to:

Required argument:
     Argument Name:  NewProtocol
     Data Type:      string
     Allowed Values: ['TCP', 'UDP']
     Set NewProtocol value to: TCP

NewPortMappingDescription : All your ports are belong to us
NewLeaseDuration : 0
NewInternalClient : 192.168.0.1
NewEnabled : 1
NewInternalPort : 80

AHora podemos borrar el puerto mapeado con la acción DeletePortMapping. Igual que AddPortMapping, la acción DeletePortMapping no devuelve ningún dato a menos que haya ocurrido un error:

Código:

upnp> host send 0 WANConnectionDevice WANIPConnection DeletePortMapping

Required argument:
     Argument Name:  NewProtocol
     Data Type:      string
     Allowed Values: ['TCP', 'UDP']
     Set NewProtocol value to: TCP

Required argument:
     Argument Name:  NewExternalPort
     Data Type:      ui2
     Allowed Values: []
     Set NewExternalPort value to: 8080

Required argument:
     Argument Name:  NewRemoteHost
     Data Type:      string
     Allowed Values: []
     Set NewRemoteHost value to:

Hay una gran multitud de otras acciones interesantes, como por ejemplo ForceTermination, la cual provoca la caída de la conexión WAN del router. Vale la pena explorar los varios servicios y acciones para cada dispositivo que estés auditando.

Conclusión

Si bien, UPnP es un protocolo que pocos entienden, está activo en una vasta mayoría de redes caseras, e incluso también en algunas redes corporativas. Muchos dispositivos soportan UPnP en orden de facilitar el uso para los consumidores, sin embargo, a menudo soportan acciones que ningún servicio debería de estar posibilitado de ejecutar automáticamente, y especialmente sin ninguna autorización. Peor aún, la implementación del protocolo en sí rara vez es construido con una mentalidad prioritaria en la seguridad, dejándolo abierto a futuros ataques.

La mejor defensa contra los ataques UPnP tanto locales como remotos es simplemente deshabilitarlo en algunos/todos los dispositivos de la red. Sin embargo, considerando que este protocolo y otros protocolos “auto-magicos” son diseñados para ayudar a Joe, quien probablemente esté inadvertido de los peligros de tales protocolos, la única verdadera solución es que los vendedores sean mas atentos en sus diseños, y sus implementaciones, mas seguras.

=======================
Hacking de Redes UPnP – Parte I
Hacking de Redes UPnP – Parte II
Hacking de Redes UPnP – Parte III
=======================

Tercera y Ultima parte del articulo Plug-N-Play Network Hacking traducido por Cortex en nuestra seccion Traducción de Artículos de La Comunidad.

También puede interesarte...

Hacking de Redes UPnP – Parte II

DragoN — Tue, 27 Jan 2009 19:40:41 +0000

=======================
Hacking de Redes UPnP – Parte I
Hacking de Redes UPnP – Parte II
Hacking de Redes UPnP – Parte III
=======================

Continúa desde “Hacking de Redes UPnP – Parte I“

Una vista general sobre el protocolo UPnP

EL protocolo UPnP usa la dirección mulicast (multidifusión) 239.255.255.250 y el puerto TCP 1900. Los dispositivos que ofrecen servicios UPnP periódicamente enviarán mensajes SSDP NOTIFIY a 239:255:255:250:1900, anunciándose a cualquier cliente UPnP que en este en escucha. Si observas el tráfico en tu LAN que use un router con los servicios UPnP activos, notarás que éste envía una ráfaga de mensajes SSDP NOTIFY cada pocos segundos; esto ocurre porque la mayoría de los routers en realidad se anuncian como multiples dispositivos UPnP, y envían una notificación por cada tipo de dispositivo.

Asimismo, los clientes UPnP pueden enviar peticiones SSDP M-SEARCH a 239:255:255:250:1900 para ver si algún dispositivo UPnP responde. Los clientes pueden enviar una petición M-SEARCH buscando algún dispositivo UPnP, o pueden especificar que están buscando algún dispositivo en particular, o pueden consultar solo por algún dispositivo que soporte un servicio UPnP específico. Los hosts UPnP que concuerden con los dispositivos/servicios pedidos responderán con un mensaje SSDP RESPONSE, el cual contiene la misma información que la enviada en un mensaje SSDP NOTIFIY.

Un mensaje SSDP NOTIFY enviado por un host UPnP contiene una cabecera ‘Location’ la cual especifica la ubicación de un archivo XML. Este archivo XML contiene datos indicando, entre otras cosas, el tipo de dispositivo y los servicios soportados por el host, así como las rutas a otros documentos XML adicionales que describen los servicios detalladamente. Para descubrir las capacidades UPnP completas de un IGD, se debe analizar todos los archivos XML para extraer los tipos de dispositivos, servicios, y acciones ofrecidas por el IGD.

Los servicios UPnP soportan varios servicios que a su vez anuncian las acciones que soportan. Un cliente UPnP puede enviarle alguna petición al dispositivo UPnP en cualquier momento, esta podría ser una petición para abrir un puerto, cambiar el servidor DNS por defecto, o cualquier otra que el dispositivo soporte. Los datos enviados/devueltos en cualquier petición o respuesta son enviados usando SOAP, el cual usa XML para estructurar la información enviada entre las dos partes. Las peticiones SOAP son esencialmente peticiones HTTP POST con alguna cabecera SOAP adicional incluida en las cabeceras HTTP.

Auditando dispositivos UPnP manualmente

Para descubrir si algún router soporta UPnP, puedes ir a la interfaz administrativa de este y verificar si hay alguna opción para habilitar/deshabilitar UPnP, mientras que la mayoría de los routers tienen UPnP habilitado por defecto, algunos no.

Para realmente auditar la configuración de algún dispositivo UPnP, puedes encender Wireshark y buscar paquetes SSDP NOTIFIY siendo enviados a la dirección multicast 239.255.255.250 al puerto 1900; estas notificaciones serán dispositivos UPnP anunciándose a la red. Una vez los mensajes SSDP NOTIFIY son capturados, puedes examinar las cabeceras SSDP de los datos arrojados para obtener la ubicación del archivo XML raíz. Una vez tengas ese archivo (simplemente haciendo una petición HTTP GET), puedes examinarlo para ver que dispositivos y servicios soporta el host UPnP. Luego, puedes solicitar los archivos XML adicionales al host (uno por cada servicio) y analizar esos archivos XML para determinar que acciones soporta cada servicio, y luego correlacionar las posibles variables de estado (variables de entrada/salida) usada para cada acción, así como identificar cuales variables son usadas como “entrada”, y cuales como “salida” (una acción puede usar una variables como parametro de entrada, mientras que otras usan la misma variable como parametro de salida).

Obviamente, auditar hosts UPnP manualmente puede consumir extremadamente mucho tiempo y nos forza a generar manualmente peticiones a los dispositivos UPnP para lanzar ataques contra ellos. Usar una herramienta para automatizar el proceso haría nuestra vida mucho más fácil… Esto será lo que trataremos en la parte III del artículo.

=======================
Hacking de Redes UPnP – Parte I
Hacking de Redes UPnP – Parte II
Hacking de Redes UPnP – Parte III
=======================

Segunda parte del articulo Plug-N-Play Network Hacking traducido por Cortex en nuestra seccion Traducción de Artículos de La Comunidad.

También puede interesarte...

Hacking de Redes UPnP – Parte I

DragoN — Thu, 22 Jan 2009 18:15:25 +0000

=======================
Hacking de Redes UPnP – Parte I
Hacking de Redes UPnP – Parte II
Hacking de Redes UPnP – Parte III
=======================

UPnP (Universal Plug-N-Play) es un protocolo que permite que varios dispositivos de red se autoconfiguren por si mismos. Uno de los usos mas comunes de este protocolo es permitir que dispositivos o programas abran puertos en tu router casero con el objetivo de comunicarse apropiadamente con el mundo exterior (El Xbox, por ejemplo, lo hace). El protocolo UPnP está basado en protocolos y especificaciones pre-existentes, más precisamente en UDP, SSDP, SOAP y XML.

Este artículo tratará sobre algunos problemas de seguridad relacionados con UPnP, brevemente describe el funcionamiento interior del protocolo, y muestra como identificar y analizar los dispositivos UPnP en una red usando herramientas open source. En el artículo nos enfocaremos en IGDs (Internet Gateway Devices ó Dispositivos de pasarela a Internet, por ejemplo, routers), pero es importante recordar que hay muchos otros dispositivos y sistemas que soportan UPnP también, y pueden ser vulnerables a ataques similares.

El problema con UPnP

Permitir que programas legítimos alteren la configuración del router a medida que lo vayan necesito hace la vida de los usuarios de Joe mucho más fácil – desafortunadamente, también hace la vida de los hackers de Joe más fácil. Con el fin de que UPnP sea verdaderamente “plug-n-play”, no hay ninguna autenticación en este protocolo; es decir, cualquier programa puede usar UPnP para alterar la configuración del router (o de cualquier otro dispositivo UPnP).

A principios de este año, PDP (de GNUCITIZEN) publicó una investigación que había realizado sobre la seguridad de UPnP. Si bien los problemas de seguridad de UPnP no son nuevos, es un protocolo que normalmente solo funciona dentro de una red local, forzando al atacante a infiltrarse en la red antes de explotar cualquier vulnerabilidad de UPnP. Sin embargo, PDP mostró que era posible usar Flash para enviar peticiones UPnP desde dentro del navegador de un cliente a un router con UPnP habilitado y cambiar la configuración del firewall de este. Dado que el archivo Flash puede ser embebido dentro de una página maliciosa, o inyectada dentro de una página confiable via XSS o SQL Injection, un atacante podría usar esto para remotamente alterar la configuración del router. Lo que es peor es que en la mayoría de los casos, estos cambios en la configuración no son reflejados en la interfaz administrativa del router, dejando la víctima completamente sin conocimiento de lo que ha ocurrido.

Por supuesto, para las redes inalámbricas UPnP es peligroso incluso sin el ataque Flash, tanto que un atacante puede mantener distancia física de la red mientras gana acceso a la red interna. Una vez dentro, puede empezar a alterar la configuración del router vía UPnP.

¿Qué tan serio es esto?

La seriedad de este ataque depende en la implementación de UPnP usada por el router, como también de la configuración del router. Por ejemplo, el ataque de la alteración de la configuración vía Flash descrita anteriormente debe de adivinar cual es la dirección IP del router; esta es usualmente fácil de predecir, pero algunos router también se asignan sus propios hostnames lo cual hace que cualquier intento de adivinación de la dirección IP no funcione. Sin embargo, incluso si un router no se resuelve a un hostname, la seguridad a través de la oscuridad no es una buena práctica, y simplemente cambiar la dirección IP no debe considerarse como suficiente defensa contra un ataque de este tipo.

Además, algunas implementaciones UPnP son mas riesgosas que otras; varios IGDs con UPnP activado permiten que la configuración DNS sea directamente alterada vía UPnP, lo cual sería solo el comienzo de un ataque MiTM/Phishing. Otros, particularmente esos dispositivos que usan algún tipo de Linux embebido, de hecho, usan los valores que reciben a través de las peticiones UPnP sin filtrarlos, como parte de comandos shell ejecutados, dejándolos abiertos a ataques de inyección de comandos. Una lista de algunos router vulnerables puede ser encontrada aquí.

OK, digamos que ningún hostname es asignado a la IP del router, y su implementación UPnP no es vulnerable a DNS-Hijacking o inyección de comandos. Desafornatudamente, todavía no estamos fuera de peligros; recuerda que el uso mas común de UPnP es abrir puertos en un router. Debido a esto, casi todos los router que soportan UPnP también soportan la acción AddPortMapping; esta esencialmente permite a algun dispositivo o software decirle al router “redirige todo el tráfico proveniente del puerto X al host interno Y de la WAN el cual está en escucha en el puerto Z”. Bueno, ¿Y qué si redirigimos todo el tráfico proveniente de la WAN por el puerto 8080 a yahoo.com por el puerto 80? Ya sé, ya sé, yahoo.com no es un host interno! Pero algunas configuraciones UPnP no verifican lo que estan redirigiendo a los hosts internos, y en consecuencia se permite al atacante rebotar su tráfico por medio del router. Además, si el atacante conoce la dirección IP interna del router o su hostname, puede ser capaz de redirigir algun puerto del lado WAN del router al puerto 80 del lado LAN del router, abriendo efectivamente la interfaz administrativa del router al mundo.

=======================
Hacking de Redes UPnP – Parte I
Hacking de Redes UPnP – Parte II
Hacking de Redes UPnP – Parte III
=======================

Primera parte del articulo Plug-N-Play Network Hacking traducido por Cortex en nuestra sección Traducción de Artículos de La Comunidad.

También puede interesarte...

Análisis forense a un router Cisco

DragoN — Wed, 23 Jul 2008 05:03:49 +0000

En este post se van a tratar las prácticas forenses que se deben aplicar a un router Cisco o basados en Cisco.
En primer lugar hay que tener muy claro porque motivos se ataca un router.

Los principales motivos son los siguientes:

Porque atacar un router:

Realizar un ataque de denegación de servicios (DoS) al router y a la red a la que pertenece.
Comprometer otros routers a través de el.
Desviar firewalls de red, IDS o otros servicios.
Monitorizar y grabar el tráfico entrante o saliente de la red.
Redirigir el tráfico de la red a otro punto.

También hay que tener claro la filosofía de trabajo de un router Cisco. Esta compuesto principalmente por dos memorias donde almacena los datos:

Las memorias son:

Memoria RAM:
Es una memoria no persistente, quiere decir que lo que esta almacenado en ella se borra al apagar el equipo.

En ella se almacena:

Configuración activa.
Tablas dinámicas: ARP, Routing, NAT, Violaciones ACL, estadísticas protocolos…

Memoria Flash:
Es persistente, aun apagando el equipo, esta memoria no se borra.

En esta memoria se almacena:

Configuración de arranque.
Archivos del sistema IOS.

Para empezar el análisis tenemos que tener en cuenta, basándonos en los datos relativos a la filosofía de trabajo del router, una metodología concreta, que consiste en:

No apagar ni reiniciar el router, evidentemente perderemos todos los datos almacenados en la RAM. Que son todos los datos que importan para el análisis, sin estés datos, el análisis no tiene sentido.
Aislar el router de la red, sobre todo si el ataque ya se ha realizado. Siempre con el cuidado de no desconectar la alimentación. En algunas casos se puede realizar sin aislar pero después de recoger información, para monitorizar si la actividad continua.
Conectarse para realizar el análisis forense a través del puerto consola del router y no a través de la red, porque se corrompería la escena.
Grabar la sesión completa de análisis de la consola en un archivo de log.
Ejecutar comandos que muestran configuraciones, pero nunca ejecutar comandos de configuración del router.
Una vez extraída la información volátil, podemos analizar las vulnerabilidades del router y escanear sus servicios a través de la red.

Después de tener en cuenta estas recomendaciones, pasamos a los comandos que tenemos que utilizar en la consola para extraer la configuración activa y las tablas dinámicas. La sesión de consola en la que se ejecuten estés comandos, debe ser grabada.

Los comandos son:

show clock detail
show version
show running-config
show startup-config
show reload
show ip route
show ip arp
show users
show logging
show ip interface
show interfaces
show tcp brief all
show ip sockets
show ip nat translations verbose
show ip cache flow
show ip cef
show snmp user
show snmp group
show clock detail

También podemos utilizar una herramienta automatizada para recabar esta información, se trata de CREED (Cisco Router Evidence Extraction Disk). Un disco auto arrancable que ejecuta un script para obtener esta información, ejecutando estos comandos:

# terminal length 0
# dir /all
# show clock detail
# show ntp
# show version
# show running-config
# show startup-config
# show reload
# show ip route
# show ip arp
# show users
# show logging
# show interfaces
# show ip interfaces
# show access-lists
# show tcp brief all
# show ip sockets
# show ip nat translations verbose
# show ip cache flow
# show ip cef
# show snmp users
# show snmp groups
# show clock detail
# exit

Después de obtener está información pasaremos a encontrar las vulnerabilidades o servicios por los que se ha podido comprometer la seguridad del router.

Para analizar vulnerabilidades utilizamos herramientas como: Router Audit Tool (RAT) y Nipper.
Para analizar servicios utilizamos: nmap, Cisco Torch, Cisco Snmp Tool…

Más información y descarga de CREED (Cisco Router Evidence Extraction Disk)

Más información y descarga de Cisco Torch, Cisco Snmp Tool y Router Audit Tool (RAT) en el post “Herramientas para asegurar dispositivos Cisco”

Más información y descarga de Nipper en el post “Auditar seguridad en dispositivos Cisco”

Fuente del recurso: Guru de la informática