La Comunidad DragonJAR » DNS

Video Tutoriales de Wireshark

DragoN — Sat, 05 Jun 2010 23:42:20 +0000

Wireshark es una herramienta gráfica utilizada por los profesionales de la seguridad y las redes para identificar y analizar el tipo tráfico en un momento determinado. En el mundo de la IT se denominan analizadores de protocolos de red, analizadores de paquetes, packet sniffer o sniffer. Wireshark permite analizar los paquetes de datos en una red activa como también desde un archivo de lectura previamente generado.

En la comunidad somos conscientes de la importancia de esta herramienta, por eso hemos publicado el Wireshark Portable, la Guía Básica de Wireshark y ahora les traigo una serie de vídeo tutoriales, creados por CACE Technologies, la casa del Wireshark, donde nos explican el funcionamiento de esta excelente herramientas y nos muestran algunos casos en los que Wireshark ha salvado el día.

Serie de Introducción a Wireshark

Introducción a Wireshark

Aprende como empezar con Wireshark.
Duración: 5m 51s

Atajos de teclado personalizados en Wireshark

Empieza capturando rápidamente con un atajo de teclado personalizado.
Duración: 2m 26s

Serie los Misterios de las Redes

Resolviendo los Misterios de las Redes

Betty DuBois presenta la Resolución de la serie Misterios de las Redes.
Duración: 1m 50s

El caso de la Descarga Perdida

Betty nos muestra como Wireshark y CACE Pilot le salva el día a uno de nuestros clientes.
Duración: 5m 6s

The Case of the Slow Network

Betty shows how Wireshark and CACE Pilot saved the day for one of her
clients.
Duración: 5m 44s

El caso del balanceo de cargas en servidor DNS

Betty resuelve el misterio del balanceo de cargas de un servidor DNS en un ISP.
Duración: 9m 17s

El caso del iSCSI SAN lento

Betty sigue la pista del culpable de la lentitud en el iSCSI SAN.
Duración: 8m 6s

En la Campus Party Colombia 2010 nuestro amigo Carlos Andrés Rodallega Obando mas conocido como Roguer, dará una charla y taller sobre Wireshark, espero que estos vídeos les sirva de iniciativa para lo que veremos en este gran evento.

También puede interesarte...

Evita el Pharming desde Firefox

DragoN — Tue, 13 Apr 2010 07:38:21 +0000

El pharming es uno de los fraudes mas extendidos por Internet, consiste en modificar los registros de un servidor DNS o los archivos “hosts” del sistema operativo, para que cuando se haga una petición a una url especifica, en vez de dirigirse a la IP que corresponde a ese dominio, nos envía a una dirección diferente escogida por el atacante.

cabar3t, un usuario de nuestra comunidad, que ha estudiado este tipo de fraudes en internet y ha creado una solución para identificar adecuadamente si estamos siendo victimas de pharming o realmente estamos visitando la pagina a la que deseamos entrar.

La solución propuesta por cabar3t, es una extensión para Mozilla Firefox que permite detectar sitios web falsos que han sido manipulados previamente por un ataque de pharming. Cuando un usuario accede a un sitio web determinado, se realiza una consulta DNS del nombre de dominio asociado al sitio web accedido. Luego de recibir la dirección IP asociada al sitio web, se procede a realizar consultas adicionales del nombre de dominio a otros servidores DNS que están por fuera de la red local, para comparar las respuestas obtenidas con la dirección IP inicialmente devuelta por el servidor DNS local.

Si alguna de las respuestas obtenidas por parte de los otros servidores es igual a la dirección IP devuelta por el servidor DNS local, entonces el sitio web es válido. Por el contrario, si no existe ninguna correspondencia entre las respuestas de los servidores DNS, es posible que el sitio web al cual accede el usuario sea falso.

Puedes ver un vídeo de su funcionamiento a continuación:

Si quieres instalar este plugin en tu navegador, solo tienes que visitar la pagina de complementos para Mozilla Firefox, buscar el Test Pharming y seguir los pasos vistos en el vídeo.

Mas Información:
Anuncio en nuestra Comunidad
Pagina oficial del Plugin Test Pharming

También puede interesarte...

Servidor de DNS Publico por parte de Google

DragoN — Fri, 04 Dec 2009 20:36:59 +0000

Google, esa empresa que pretender apoderarse de toda la informacion de internet (y lo esta logrando), ha publicado hoy un nuevo servicio de DNS Publico que pretende “mejorar” nuestra experiencia en internet, aumentando la seguridad y velocidad con la que navegamos.

Antes de pasar a explicar detalladamente este servicio, definamos que es un servidor DNS:

DNS corresponde a las siglas en inglés de “Domain Name System”, es decir, “Sistema de nombres de dominio”. La función de este sistema es organizar e identificar dominios. Básicamente, lo que hace es proporcionar un nombre a una o varias direcciones IP de un dominio. Por ejemplo, el nombre de dominio dragonjar.org puede traducirse por 62.212.66.77 El nombre hace que resulte mucho más fácil recordar la URL y las direcciones de correo electrónico.

Ahora que conocemos lo que es un servidor DNS, hay que saber que la mayoría de IPS cuentan con su propio servidor DNS para que sea utilizado por sus usuarios, pero muchos de los administradores de estos servidores, descuidan este servidor, no lo actualizan constantemente y esto puede causar problemas a los usuarios.

Ejemplos:

Si decidiera cambiar de servidor la comunidad dragonjar, esta continuaría con la misma url (dragonjar.org), pero su dirección IP cambiaría, los servidores DNS que no actualizan su base de datos constantemente seguirían enviando a los visitantes de nuestra comunidad a la vieja dirección ip, a los que le saldría un mensaje de error, por que la comunidad ya no se encuentra en esta ip, con los OpenDNS o los DNS de Google, no pasaría esto, ya que son servidores que se actualizan constantemente y mantienen su base de datos al día.
En cuanto a seguridad, seguramente recordaran el fallo en el protocolo DNS del que todos hablaban en julio del año pasado, esta vulnerabilidad permitía, entre otras cosas, la suplantación de identidad en los nombres de dominio, si un servidor DNS es vulnerable, un atacante podría redirigir a todos los usuarios que de ese servidor, que cuando escriban mibanco.com los envié en realidad a phishingdemibanco.com o a un sitio en el que pueda infectarlos con algún malware. Afortunadamente ya existe una solución para este fallo, pero muchos servidores siguen sin aplicarla, si tu DNS es uno de ellos la única forma de estar a salvo mientras le aplican el parche o actualizan el software, es utilizando servidores alternos como Open DNS o este nuevo servicio de Google.

Por estos motivos nacen servicios de DNS públicos que solucionan estos problemas, manteniendo al día sus servidores DNS y actualizando constantemente su base de datos para saber en todo momento que IP pertenece a un nombre de dominio especifico, el actual líder de este mercado es Open DNS que no solo nos ofrece un servidor DNS seguro y rápido, sino que tiene como valor añadido la posibilidad de Filtrar sitios Webs y muchas otras opciones que puedes ver en su pagina oficial.

¿Que Nos Ofrece el Servidor DNS Publico de Google?

Rapidez: según google su nuevo servicio de DNS publico es mucho mas rápido que cualquier otro, resolviendo el nombre de dominio de una pagina en pocos mili segundos, para comprobar esto la gente de manu-j.com ha creado un script en bash que permite medir el tiempo que tarda en resolver un dominio el OpenDNS, Tu ISP y Google, el ganador de estas pruebas es el nuevo servicio de google, se los dejo para que hagan sus propias pruebas

#!/bin/sh isp=$(dig +noall +stats 2>&1 | awk '$2~/^SERVER:$/{split($3,dnsip,"#");print dnsip[1]}'); m="-------------------------------------------------------------------------------"; s=" "; h="+${m:0:25}+${m:0:12}+${m:0:12}+${m:0:12}+${m:0:12}+${m:0:12}+"; header=("Domain${s:0:23}" "Your ISP${s:0:10}" "Google${s:0:10}" "4.2.2.2${s:0:10}" "OpenDNS${s:0:10}" "DNS Adv.${s:0:10}"); echo "${h}"; echo "| ${header[0]:0:23} | ${header[1]:0:10} | ${header[2]:0:10} | ${header[3]:0:10} | ${header[4]:0:10} | ${header[5]:0:10} |"; echo "${h}"; for i in "lifehacker.com" "facebook.com" "dragonjar.org" "reddit.com" "tb4.fr" "bbc.co.uk"; do ii="${i}${s:23}"; echo -ne "| ${ii:0:23} |"; for j in "${isp}" "8.8.8.8" "4.2.2.2" "208.67.222.222" "156.154.70.1"; do r="${s:10}$(dig +noall +stats +time=9 @${j} ${i} 2>&1 | awk '$2~/^Query$/{print $4" "$5}')"; echo -ne " ${r:${#r}-10} |"; done echo -ne "\n${h}\n"; done

Seguridad: en el DNS de Google se incorporan varios niveles de seguridad durante las peticiones, y se informa a los usuarios si estan siendo victimas de ‘DNS Poisoning’, tambien intentan bloquear los ataques de Denegacion de Servicio.

¿Qué Información almacenara google sobre mi?

Esta es la parte delicada del servicio, google es el proveedor de publicidad mas grande del mundo, y le interesa bastante tener un perfil detallado de cada usuario para poder ofrecerle publicidad acorde con este perfil, aunque en las políticas de privacidad actuales del sistema dice que solo registrara la ip temporalmente (48 horas) y nunca guardara tus datos personales ni tu correo electrónico, los datos de tu ubicación geográfica si se almacenaran permanentemente, de igual forma las paginas que visitas y otros datos técnicos.

¿para que usara google estos datos?

Para el “mantenimiento de los servidores” y con fines estadísticos y de optimización.

En lo personal no me convence del todo para que se van a utilizar nuestros datos de navegación, aunque google dice que para nada “malo”, pero no hay que olvidar que su negocio es la informacion y si tiene mas, mejor para ellos, seguiré utilizando los OpenDNS, aunque son un poco mas lentos, tienen bastante valor añadido y como dice su propio autor, no se pueden comparar estos 2 servicios.

Si deseas el servicio de Google solo tienes que poner los DNS 8.8.8.8 y 8.8.4.4 en tu conexión de red.

inicio
panel de control
Conexiones de red
click derecho en Conexión de área local luego en propiedades
doble click en Protocolo Internet (TCP/IP)
seleccionar “Usar las siguientes direcciones de servidor DNS”
ingresar estos 2 DNS => 8.8.8.8 y 8.8.4.4

¿como se instalan los DNS de Google en GNU/Linux?

Solo tienes que poner los DNS 8.8.8.8 y 8.8.4.4 en tu conexión de red.

Edita el archivo /etc/resolv.conf y coloca los siguientes datos

$ vi /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

Si te dio curiosidad y deseas utilizar los OpenDNS puedes seguir el mismo tutorial, pero cambiando las IP’s 8.8.8.8 – 8.8.4.4 por 208.67.222.222 y 208.67.220.220

Mas Información:
Pagina Oficial de Google Public DNS
Post del foro que Inspiro este Artículo

También puede interesarte...

Curso de Redes en GNU Linux

DragoN — Sat, 18 Jul 2009 05:47:33 +0000

Gaston Diaz parte del staff de la Revista Tux Info, me ha enviado un correo donde comparte con toda La Comunidad DragonJAR, una serie de cursos principalmente enfocados en software libre, el segundo de esta serie de cursos que comparten con nosotros es el Curso de Redes en GNU Linux.

En el curso de Redes en GNU Linux, aprenderemos a administrar correctamente una red creada con GNU Linux, a montar diferentes servicios de red y otras labores propias de un administrador de red.

Las tematicas tratadas en el curso de redes con GNU/Linux son:

Introducción
Usuarios del sistema Unix
Servidor DCHP
Servidor DNS
Entidad Certificadora
Servidor web Apache
NFS
Samba
Otros servicios
Copias de seguridad (Backup)
Servidores de Impresión
Servidor de terminales
VNC
OpenLDAP
Enrutamiento
Varios

Descargar Gratis el Curso de Redes con GNU Linux

Mirror I

Los otros cursos de esta serie:

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...

H D Moore, victima de su propio invento.

DragoN — Wed, 30 Jul 2008 02:30:35 +0000

El creador de Metasploit, el popular framework de explotacion que fue el primero en incluir un modulo funcional de la ultima vulnerabilidad de DNS, ha sido victima de su propio invento.

Martes por la mañana, en la compañia de Moore (BreakingPoint), tuvo redirecciones de parte de su trafico a una pagina falsa de Google que habia puesto un scammer. Segun Moore, el hacker fue capaz de hacer esto ejecutando la vulnerabilidad de envenenamiento de cache en un servidor DNS en las redes de AT&T que estaba en ejecucion en Austin, Texas.

Cuando Moore intento visitar google.com, fue redirigido a una pagina falsa que servia como el index de la pagina de Google en un frame HTML junto con otras tres paginas diseñadas para hacer click automaticamente en publicidad. Aunque ninguna maquina de BreakingPoint fue comprometida, la situacion es bastante incomoda y peligrosa.

Lo interesante del asunto fue como se dieron cuenta los empleados de BreakingPoint, que luego de que algunos empleados mediante amigos y familiares que tambien estaban usando los servidores de DNS de AT&T notaran que la pagina de Google no estaba bien, ya que los atacantes omitieron la imagen de la NASA que tenia Google en su pagina por la conmemoracion de sus 50 años

También puede interesarte...

Apple sigue sin parchar la vulnerabilidad de DNS

DragoN — Tue, 29 Jul 2008 01:13:42 +0000

Ya van semanas desde que Kaminsky alerto y anuncio a las grandes compañías acerca de la vulnerabilidad de DNS y Apple, una de dichas compañias, todavía no ha parcheado la vulnerabilidad. Apple usa el servidor BIND de la ISC en sus productos, y este demonio fue una de las primeras herramientas en ser parcheadas, sin embargo Apple sigue sin incluir las versiones corregidas en sus productos, incluyendo Mac OS X Server.

Todos los usuarios de Mac OS X Server que lo utilizan para DNS recursivo deben cambiarse de plataforma o vivir en riesgo de ser comprometidos y que su trafico sea redirigido. Afortunadamente, la comunidad de Mac se ha manifestado creando paquetes compilados de las versiones de BIND que corrigen el problema.

Yo no he visto servidores DNS que corran bajo Mac OS X Server, sin embargo, ¿algunos de los presentes se han topado con algunos?

También puede interesarte...

Protegete de la vulnerabilidad en el protocolo DNS

DragoN — Thu, 24 Jul 2008 02:27:31 +0000

Hace algún tiempo comentaba nuestro amigo arpunk sobre la grave vulnerabilidad en el protocolo DNS que permitiría a alguna persona malintencionada falsificar las respuestas del servidor de nombre de dominio facilitando la suplantación de cualquier sitio en Internet.

Esta vulnerabilidad fue descubierta por Dan Kaminsky y prometió que daría los detalles sobre la misma en la conferencia Black Hat de agosto un mes después de ser anunciada , para dar tiempo de corregirla a todos los proveedores de Internet.

Pero en este mundo de la seguridad informática nadie tiene la ultima palabra y Thomas Dullien, CEO de la compañía Zynamics publico en su blog su opinión sobre lo que podía ser el problema descubierto por Kaminsky, una cosa llevo a la otra y en poco tiempo la información detallada sobre el fallo estaba disponible en Internet (los pormenores de esto los podes ver en esta noticia de hispasec).

Dicho esto y al ver que la mayoría de ISP’s en colombia (me imagino que igual para muchos países de latinoamerica) no se han dignado de corregir este error (para ver eres vulnerable visita este enlace y dale en [Check My DNS] o usar este test mucho mas completo y grafico), les pondré una pequeña guía sobre como evitar ser victima de DNS Cache Poisoning utilizando openDNS un servidor de nombre de dominio que ademas de protegernos de phishing, corregir nuestras direcciones mal digitadas y otras bondades comentadas en esta entrada que hice sobre la herramienta en el 2006, estos DNS se encuentran debidamente parcheados para evitar el error del que estamos hablando.

¿como se instalan los openDNS en Microsoft Windows?

Solo tienes que poner los DNS 208.67.222.222 y 208.67.220.220 en tu conexión de red.

1). inicio
2). panel de control
3). Conexiones de red
4). click derecho en Conexión de área local luego en propiedades
5). doble click en Protocolo Internet (TCP/IP)
6). seleccionar “Usar las siguientes direcciones de servidor DNS”
7). ingresar estos 2 DNS => 208.67.222.222 – 208.67.220.220
(aquí un manual mas grafico)

¿como se instalan los GNU/Linux?

Solo tienes que poner los DNS 208.67.222.222 y 208.67.220.220 en tu conexión de red.

Edita el archivo /etc/resolv.conf y coloca los siguientes datos

$ vi /etc/resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220

Después de realizar este cambio, revisa de nuevo tus DNS en el siguiente enlace (como mencionaba arriba) te debe aparecer un mensaje como el siguiente:

Your name server, at 208.69.32.15, appears to be safe, but make sure the ports listed below aren’t following an obvious pattern.Requests seen for c07cdebf2f49.toorrr.com:
208.69.32.15:57932 TXID=3338
208.69.32.15:37244 TXID=35929
208.69.32.15:30620 TXID=48781
208.69.32.15:50722 TXID=45827
208.69.32.15:45687 TXID=19781

Esto indica que ya estas usando unos DNS debidamente parcheado por lo tanto no eres vulnerable, pero recuerda que esta es una solución TEMPORAL y solo funciona en el equipo donde configures los openDNS, lo ideal es que avises a tu ISP para que corrijan el fallo y eviten que otras personas sigan vulnerables ante este peligroso problema.

ACTUALIZADO:
Ya existen varios exploits para esta vulnerabilidad, ahora la actualización para nuestros ISP’s y la utilización de openDNS mientras resuelven el problema es mas que recomendada,

Aquí pueden ver un resumen del tema DNS al día de hoy (26 de julio 2008)