Del 12 al 14 de noviembre se celebra en la Sala Colón de IFEMA en Madrid VoIP2DAY.

VoIP2DAY, según los organizadores, nace como punto de encuentro del mundo de la Voz y el Video sobre IP en España y Portugal.

El evento está concebido con la aspiración a consolidarse como un referente anual dinamizador del creciente mercado local y puntero a nivel tecnológico mundial.

Si queréis ver el programa de actos en pdf pulsad aquí.

Me gusta la infografía del móvil HTC G1 de Google que he visto en la página de Consumer Eroski en su sección de Hardware de Nuevas Tecnologías. En un principio muestra sus características físicas comparadas con el famoso iPhone de Apple.

Tras verla en unos minutos te puedes hacer una idea clara de qué es lo que ofrece este móvil y compararlo con otros conocidos. Si queréis más información del famoso teléfono sólo tenéis que googlear un poco.

Según Wikipedia entendemos como Spoofing al uso de técnicas de suplantación de identidad generalmente con usos maliciosos o de investigación.

Hace ya unos días que se viene hablando de una grave vulnerabilidad en el protocolo DNS que consiste en permitir falsificar las respuestas del servidor de nombre de dominio facilitando con esto la suplantación de cualquier sitio en Internet, es decir, lo que actualmente se ha venido a denominar DNS Cache Poisoning y que puede devenir facilmente en un ataque DNS Spoofing.

Según leo en los maravillosos blogs de Kriptópolis y de Sergio Hernando esta vulnerabilidad fue descubierta por Dan Kaminsky que prometió que daría detalles sobre la misma en la conferencia Black Hat de agosto para, en principio, dar tiempo de corregirla a todos los proveedores de Internet aunque al parecer y como era de esperar ya se le han adelantado.

Problema
Grosso modo, la vulnerabilidad está implícita en la implementación del mismísimo protocolo DNS que como sabemos usa UDP.

Un DNS funciona enviando peticiones en paquetes individuales UDP, cada respuesta que recibe el servidor DNS usa una única random query ID, es decir, un identificador aleatorio único, y se tienen que cumplir dos reglas básicas: que todas las respuestas y peticiones emparejadas compartan ese ID, y que las respuestas se emitan desde el mismo puerto empleado en la petición. Si se cumplen las condiciones, la primera respuesta válida es la que prevalece.

Pero si un atacante tuviera la capacidad de conocer el puerto empleado en la petición y el valor de esa query ID, podría fabricar respuestas falsas que serían aceptadas, ya que cumplen con las condiciones y podría redireccionar nuestras peticiones de páginas, por ejemplo, bancarias a cualquier otra página y hacerse con las claves bancarias.

El query ID tiene 16 bits de longitud, lo que permite obtener 2^16 = 65.536 combinaciones posibles aunque en implementaciones defectuosas, puede ser menor, reduciendo el espacio considerablemente. Otras veces, la implementación defectuosa simplemente generará IDs predecibles.

Respecto a puertos estamos hablando de 64.511 posibilidades ya que hay que restar a 65.535 (valor límite) los 1.024 primeros puertos reservados. Sería fácil pensar que falsificar una respuesta es complicado estadísticamente hablando pero, en la realidad, es más fácil ya que, a parte de que no todos los rangos de puertos están disponibles, casi todos los DNS operan con los mismos puertos, lo que reduce drásticamente la combinatoria.

Protección
Bien, ahora que ya sabemos cuál es la vulnerabilidad, cómo funciona el protocolo DNS y cuál es el problema debemos preocuparnos por protegernos.

Lo primero que debemos saber es si nuestros DNS’s son vulnerables. Para saberlo hay dos páginas que nos indican si nuestros servidores DNS tienen esta vulnerabilidad y una tercera vía a través del command.com de Windows (Ejecutar → cmd).

1.- Visitando la página DoxPara Research y tras pinchar en Check My DNS nos mostrará si nuestros DNSs son o no vulnerables.

2.-. Visitando la página DNS-OARC y realizando el Web-based DNS Randomness Test. Se trata de un test más detallado que el anterior y que muestra sus resultados de forma más gráfica. Este test informa por separado de la aleatoriedad de los dos factores implicados en la vulnerabilidad:
a.- Aleatoriedad del puerto de origen.
b.- Aleatoriedad del identificador de la transacción.

3.- Desde la pantalla (Ejecutar → cmd) teclear:
nslookup -type=txt -timeout=30 porttest.dns-oarc.net

Solución

Bien, ahora ya que podemos saber si nuestros DNS tienen esa grave vulnerabilidad, ha llegado el momento de, dado el caso, solucionar el problema.

Solo tienes que poner los DNS que no tengan la vulnerabilidad, como por ejemplo 208.67.222.222 y 208.67.220.220 (DNS de OpenDNS) en tu conexión de red. Para ello, sigue estos sencillos pasos:

Windows
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 cualquier estos 208.67.222.222 – 208.67.220.220

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

nameserver 208.67.222.222
nameserver 208.67.220.220


Problemas detectados
El parche creado por Microsoft (MS08-037) comenzó dando problemas a los usuarios de Zone Alarm, un popular cortafuegos personal aunque, según parece, también existen problemas con servicios como Exchange Server, Active Sync, IPSec (Internet Protocol Security), IAS (Internet Authentication Services).

Por fin la gente de google se ha dado cuenta de que a una misma cuenta de gmail se accede desde varias máquinas y, en muchas de ellas, se mantenía la sesión abierta.
Según leo en Apuntes de seguridad de la información cuando entras en tu cuenta de gmail, debajo del todo, justo tras la información del espacio utilizado por tus correos, aparece una línea en la que te informa sobre la última actividad de la cuenta expresada en tiempo.

Pero si la visión del tiempo de sesión resulta clarificador, cuando pinchas sobre el enlace que viene justo a la derecha: Información detallada la ventana que se despliega es interesantísima ya que te muestra todas las sesiones abiertas asociadas a tu nombre de usuario de gmail, el tipo de acceso (desde navegador, móvil, POP3, etc.), la dirección ip de acceso y la hora de acceso junto con el tiempo de conexión. Además te indica la dirección ip pública de tu máquina para que compares y sepas si la sesión abierta es desde esa máquina.

Pero toda esta valiosa información estaría un poco coja si no pudieramos cerrar las sesiones abiertas en otras máquinas de forma remota. Efectivamente, es posible hacerlo, desde la misma ventana que se abre al pulsar sobre Información detallada por lo que Google, bajo mi entender, ha vuelto a dar en el clavo y ha mejorado un poquito más el concepto de sesión segura en una cuenta de Gmail. Así puedes estar al tanto y cerrar sesiones olvidadas abiertas en máquinas, por poner un ejemplo, del trabajo o, incluso, darte cuenta si alguien sabe tu usuario y contraseña y está accediendo a la información de tu cuenta de Gmail.
Por cierto, si a alguien no le aparece es útil función, según Apuntes de seguridad de la información indica que se habilitará de manera progresiva aunque yo, que dispongo de la última versión del Mozilla Firefox, la tengo disponible.
Captura pantalla de logo gmail: Vía flickr.com by autodafe