No sé si es debido al par de entradas que Roberto publicó hace unos meses poniendo los puntos sobre las íes en relación con la noticia lanzada por Elcomsoft (en la que afirmaba que era posible romper WPA/WPA2 100 veces más rápido utilizando el poder de procesamiento de GPUs y su producto de recuperación de contraseñas), pero durante los cuatro últimos meses más de 1200 usuarios han llegado a este blog buscando cómo crackear/hackear/romper las claves/contraseñas/hash de wpa/wpa2.

Y no me extraña en absoluto, a la vista de lo que se publica en las revistas de divulgación informática. En concreto, el otro día fui a parar a un artículo de Noé Soriano (director de Comunicación y Marketing de ConsultorPC) en PC Actual, titulado ¿Ya no son seguras las redes WiFi?, que contiene unas afirmaciones que me gustaría comentar. En concreto, todo se resume en la siguiente frase:

En esta entrada me gustaría comentar un software de la compañía Lumension (antes SecureWave) denominado Lumension Device Control^TM (antes Sanctuary), que forma parte de una amplia gama de productos orientados a la seguridad activa, y que resulta muy útil a la hora de administrar el uso de dispositivos móviles en cualquier empresa y controlar el tráfico de información confidencial.

Esta aplicación nos permite discriminar qué usuarios y/o equipos pueden ejecutar contenidos en dispositivos de almacenamiento como memorias USB, Pda’s, Blackberry, etc. Tiene también una peculiaridad bastante interesante que es la de llevar un registro de todo lo que se copia, mueve o se borra de cualquier dispositivo externo, aspecto importantísimo a la hora de controlar qué datos confidenciales o de uso interno se están utilizando y evitar así que dicha información se transmita sin control alguno.

Recientemente ha sido publicado un nuevo vector de ataque de phishing de mayor complejidad que el clásico envío masivo de correos electrónicos, y que podría permitir el robo de credenciales en aplicaciones bancarias, juegos-online, etc. El denominado In-session Phishing se vale de una vulnerabilidad en la mayoría de los navegadores web: Internet Explorer, Firefox, Safari, o Chrome, al hacer uso de ciertas funciones javascript.

Para explotar con éxito este fallo de seguridad es necesario que se den las dos situaciones siguientes:

1. El usuario este autenticado en la aplicación objetivo del robo de credenciales.
2. Un segundo site que alberga cierto código malicioso es visitado por el usuario, mientras en la web objetivo se esta todavía autenticado.

Al parecer el navegador procede a albergar una huella cuando una página web que utiliza ciertas funciones javascript es visitada, funciones muy habituales según sus descubridores, Trusteer. De esta manera es posible desde una segunda página interrogar al cliente con preguntas binarias sobre si se está o no autenticado en un cierto dominio. Si la respuesta es afirmativa, el código malicioso presenta un sencillo pop-up que informa al usuario sobre una falsa caducidad de la sesión y la necesidad de reautenticarse en la aplicación. En ese momento el usuario no percibe ningún comportamiento extraño puesto que hasta el momento confía en que estaba registrado en un site totalmente lícito.

Pueden comprobar, si miran el código fuente de la prueba de concepto (adjunta debajo), que el enlace del “a href” efectivamente apunta a Google, y que por tanto, al pasar sobre el enlace, la barra de estado muestra la dirección de Google. Tengan cuidado con estas cosas.

El año 2008 fue el año de la “vulnerabilidad crítica que pone en compromiso toda la seguridad de Internet”. Hemos visto varios casos de estos, primero la vulnerabilidad del DNS, luego algunas otras vulnerabilidades en los protocolos de enrutamiento, y alguna otra cosa de menor importancia.

En todos ellos, al final, la solución siempre ha sido la misma: apoyarnos en el uso de certificados digitales (clave pública y privada) para garantizar que estamos conectando donde realmente queremos conectar, y que toda la comunicación entre ambos extremos va a permanecer cifrada, no legible e inalterable por agentes externos a nuestra comunicación.

—Buenos días, Maestro, hoy vengo a traerte una ofrenda.
—Vaya, una tira cómica de xkcd… son un tanto curiosas.

(…)

—Perdona por la interrupción. Como te decía, desde el punto de vista de Alicia, hay poco que pueda hacer. Puede desactivar la ejecución de script en su navegador, lo que la dejará sin poder visitar muchas de las páginas que le interesan. Puede activarlo sólo para los sitios de confianza, asumiendo que éstos no son vulnerables a este tipo de ataques (lo que es mucho asumir) y, por supuesto, ser sanamente desconfiada para evitar la parte de ingeniería social del ataque. Y poco más. La responsabilidad está en quienes han desarrollado el sitio web vulnerable, que deben corregir la aplicación Web para que no lo sea.
—¿Se puede conseguir eso?
—Claro. El éxito del ataque se basa en que el sitio Web devuelve el código script que se le inyecta y que se ejecuta en el navegador de Alicia. Basta con no hacerlo.
—¿No devolver el script que luego se ejecuta?
—Ese es el enfoque que siguen muchos desarrolladores. Aplicar “html encoding“. ¿Sabes lo que significa?
—Sí, claro, se trata de “escapar” un carácter especial de un código html para que se muestre como tal, en lugar de ser interpretado por el navegador. Se utiliza siempre que se muestran ejemplos de html en un sitio Web.
—Exacto. Si quiero que en una página salga “<br />” en lugar de un salto de línea en el navegador, debo escribir “&lt;br /&gt;”, ya que esa secuencia tiene un significado especial. He de indicarle al navegador que no debe interpretarla, sino mostrarla, utilizando &lt; para “<” y lo mismo con el resto de caracteres.
—Entonces, basta con “escapar” todos los caracteres especiales.
—En principio. Claro que eso tiene el inconveniente de no permitir al usuario que introduzca negritas, cursivas o enlaces dentro de su texto. Quizás un inconveniente aceptable.
—Bueno, se pueden permitir algunos de los caracteres especiales o, mejor dicho, determinadas combinaciones, como “<a href=”, pero no otras, como “<script>”.
—Sí, claro. Es la táctica de detectar las entradas no deseables y eliminarlas o neutralizarlas. El problema es que hay más formas de introducir un script en un texto de manera que no se detecte con facilidad. Por ejemplo, se puede introducir “%3D%3C%73%63%72%69%70%74%3E”, que es lo mismo que “<script>”, como parte de una URL. Pero lo peor es que puedes estar protegiendo la aplicación frente a determinadas formas de introducir un script, pero luego aparecer en el futuro otras que no tenías previstas y no ser capaz de detectarlas.
—Pero seguro que sabes una solución y me la vas a contar…
—Pues la solución es obvia, si aplicamos una de las buenas prácticas de programación que cualquier buen desarrollador conoce: validar cualquier entrada del usuario contra una especificación de las entradas correctas. O sea, admitir lo que es correcto según las especificaciones del programa y rechazar cualquier otra cosa.
—Usando expresiones regulares.
—Es uno de los métodos más útiles, sí.
—En resumen, que el XSS se evita controlando bien todas las entradas a la aplicación, validándolas según la especificación de lo que se considere una entrada correcta.
—Ni más, ni menos.

Dentro de las herramientas ciertamente peligrosas (aunque muy útiles en algunas ocasiones), durante estos últimos años se están popularizando las de acceso remoto a los PCs de escritorio, a pesar de que en realidad son muy antiguas y desde siempre han traido importantes problemas de seguridad, como por ejemplo, el Back Orifice (cuyo nombre estarán de acuerdo conmigo que es bastante descriptivo).

Las últimas versiones de estas herramientas que les comento están diseñadas para saltarse todas las políticas de seguridad perimetral implantadas en las organizaciones; por supuesto, el uso de dichas herramientas puede ser perfectamente lícito, pero puede también no serlo (y en ese caso, convertirse en un riesgo de seguridad) si no son controladas y validadas por la normativa de la organización.

Se ha publicado recientemente que la empresa Elcomsoft ha desarrollado una nueva tecnología que permite utilizar la GPU de la tarjeta gráfica Nvidia para romper el cifrado de WPA/WPA2 hasta 100 veces más rápido que utilizando un PC normal [engadget, ItWire, securityandthe.net]. Aunque no dudo en absoluto que dicho anuncio sea cierto, permitidme una sarcástica carcajada para lo que es un phising comercial en toda regla, y veamos por qué.

Dado que la longitud mínima de una PSK de WPA o WPA2 es de 8 caracteres y el alfabeto manejado es de [A-Za-z0-9Sym32], tenemos (29+29+10+32)⁸ = 10.000.000.000.000.000 posibles palabras del lenguaje, que son… bastantes. Teniendo en cuenta que, siendo benévolo, los procesadores actuales mas potentes (utilizando el algoritmo de Aircrack) pueden a lo sumo barrer 400 palabras por segundo, y multiplicando por el incremento de la capacidad de procesamiento de la tarjeta Nvidia tenemos un total de 40.000 palabras del lenguaje por segundo.

Supongamos que sospecha padecer una enfermedad que afecta a 1 de cada 1000 habitantes. Para salir de dudas, decide someterse a un test cuya precisión, según su médico, es del 99%, habiendo clasificado como enfermos a 1 de cada 100 pacientes sanos en promedio a lo largo de los años. Para su desgracia, el test resulta positivo. ¿Hasta que punto debería preocuparse? Sorprendentemente, la probabilidad de que realmente usted esté enfermo es tan sólo de aproximadamente el 9%; contrariamente a lo que tenderíamos a pensar, unas 91 personas de cada 100 en su situación estarán sanas pese a haber dado positivo en el test.

Este sesgo en nuestra intuición probabilística, conocido como la falacia de la tasa base, la paradoja del falso positivo, la confusión de la inversa o la falacia de la probabilidad condicional, suele presentarse cuando el índice de incidencia de un suceso (esto es, su probabilidad a priori) es bajo. Y éste es precisamente el caso en el problema de la detección de intrusiones en seguridad informática, como observó el investigador sueco Stefan Axelsson en un artículo de 1999. Veámoslo con un poco más de detalle.