El Talón de Aquiles del estandar 802.11i: Proceso de autenticación PSK (I)

4 de febrero de 2008 Por

[N.d.E. Comenzamos con esta entrada una serie de tres artículos, de cierto nivel técnico, en relación con WPA, concretamente con WPA-PSK. Los dos primeros posts están dedicados a la exposición teórica del problema, mientras que los dos últimos entrarán en detalles prácticos. Para aquellos menos introducidos en temas WiFi, les prometo un artículo en breve describiendo los conceptos relacionados con esta tecnología.]

El método empleado por WPA para autenticar a las estaciones WiFi supone uno de los puntos débiles de este protocolo de seguridad, como veremos a continuación. Por lo que respecta a la autenticación, en función del entorno de aplicación, es posible emplear dos modos de autenticación diferentes WPA-PSK (Pre Shared Key) o WPA-EAP (Extensible Autentication Protocol).

En entornos personales, como usuarios residenciales y pequeños comercios, se utiliza WPA con clave pre-compartida o también llamada WPA-PSK y autenticación IEEE802.1X. En estos entornos no es posible contar con un servidor de autenticación centralizado, tal y como hace la autenticación EAP. En este contexto, WPA se ejecuta en un modo especial conocido como “Home Mode” o PSK, que permite la utilización de claves configuradas manualmente y facilitar así el proceso de configuración del usuario domestico.

[Read more…]

Security thru obscurity en el sector de la automoción

1 de febrero de 2008 Por

Probablemente conozcan un principio utilizado principalmente en el mundo de la seguridad informática, denominado “Seguridad por oscuridad”, que es la traducción del homólogo inglés “Security thru obscurity“. Básicamente, consiste en ocultar los detalles de diseño e implementación —entre otros— de un programa o dispositivo, consiguiendo (o pretendiendo conseguir, al menos) que el producto actúe como una caja negra y por tanto sus potenciales puntos débiles no puedan ser, o sean descubiertos. Pueden obtener más información de la Wikipedia [versión completa del artículo en inglés].

Por lo general, esta suele en la gran mayoría de los casos, una mala política, porque con lo ancha y vasta que es Internet, siempre hay alguien que acaba descubriendo esos puntos débiles. Entonces es cuando decimos que una vulnerabilidad esta siendo explotada “in the wild” (y eso suele ser malo). Es decir, que gracias a las prácticas oscurantistas de la compañía X, el servidor del señor Juanito queda expuesto a los ataques del señor Luisito, que conoce los problemas de seguridad que la companía X ya sabe pero no quiere decir. Ya se imaginan el resto.

Y esto venía a cuento porque la semana pasada, viendo la televisión, aparecía en un programa un sujeto cuya cara aparecía convenientemente oculta, mostrando diversos métodos para robar coches, todos ellos (los métodos) aparentemente muy sencillos y de fácil aplicación (aunque les confieso que no me he puesto a ello ni tengo intención de hacerlo, la verdad; yo ya tengo coche y a mi lo ajeno me produce mucho respeto). Y lo que ví, aparte de mostrarme —como era de esperar— que lo que les he contado en el primer párrafo no sólo se aplica en el ámbito de la informática, sino que se encuentra en otros muchos ámbitos de la “vida real”, me dejó con la duda de si los dueños de Audis TT —por ejemplo— son convenientemente informados de las “vulnerabilidades” que tienen sus automóviles en cuestión de seguridad y finalmente, si, oponiéndome al principio que les comentaba, yo debería decirles aquí cómo robar un Audi TT.

Como era de esperar, he decidido que no. Primero, porque me da cosilla hacerlo. Y segundo, porque sin una prueba de concepto, a ver quién se lo cree.

Nada más. Como siempre, pasen un buen fin de semana.

Cursos y certificaciones para profesionales TIC

31 de enero de 2008 Por

Para aquellos profesionales que estén buscando ampliar conocimientos (o gestores intentando exprimir el presupuesto departamental) y hayan pensado en realizar alguna certificación o curso, a continuación se proponen un listado de las principales certificaciones relacionadas, directa o tangencialmente, con el área de la seguridad informática. No están todas las que son, pero sí son todas las que están:

  • ITIL. Marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información (TI) de alta calidad. Ofrecido por la OGC británica (Office of Government Commerce UK).
  • CISSP (Certified Information Systems Security Professional) de ISC2, certificación de seguridad independiente. Trata de abarcar diversos dominios de seguridad TIC, desde controles de acceso a criptografía o continuidad de negocio.

    • [Read more…]

In God Google we trust

29 de enero de 2008 Por

[Hemos decidido, para incrementar la participación en el blog, abrir de manera indefinida los comentarios, de modo que ya no es necesario estar registrado para realizar un comentario sobre una entrada. Por supuesto, aquellos usuarios registrados pueden seguir comentando como usuarios registrados. Esperamos que esto les motive a dejarnos sus opiniones.]

Ayer por la mañana amanecí con la noticia de FACUA de que “Protección de Datos confirma que la lectura de los correos de los usuarios para mostrarles publicidad personalizada vulnera la legislación española y comunitaria“, en patente referencia a Gmail. Esta misma noticia también ha aparecido en ALT1040, EuropaSur, y seguramente a estas alturas habrá aparecido ya en muchos otros sitios. He demorado este comentario por tres razones: la primera, por falta de tiempo; la segunda, porque Fernando se me adelanto con la entrada a propósito del escándalo de Société Générale (entrada que quizá no he dejado reposar demasiado); y la tercera, para poder encontrar argumentaciones convincentes, aunque a muchos no se lo parecerá.

Y es por esta tercera razón por donde voy a empezar, porque está claro que GMail es actualmente y con toda probabilidad el mejor sistema de correo electrónico gratuito que existe. Es eficiente, es rápido, está bien pensado y tiene una capacidad con la que, como bien publicitan, probablemente no te haga falta borrar un correo nunca más. Por ello, no es extraño que cualquier comentario en contra de GMail suela despertar un aluvión de críticas; es en mi opinión algo razonable; y es que como ya hecho en anteriores ocasiones, insisto que a título personal, soy un usuario de Google y GMail.

Lo que voy a hacer a lo largo de esta entrada es destacar algunos puntos que me parecen de interés en relación con GMail (aunque asumo que puedo estar equivocado en más de uno), y que intentan mostrar que no porque un servicio sea bueno y gratuito hemos por ello de venderle nuestra alma; Google no es al fin y al cabo una ONG ni una “Fundación por un correo electrónico mejor”, sino una empresa que presta un servicio con el cual hace negocio, y eso al menos debería mantener alerta nuestro espíritu crítico; piensen qué pasaría si Telefónica adoptase algunas de las políticas de Google en cuestión de privacidad (y no, el nivel de satisfacción del usuario no es un factor a considerar en la gestión de los datos de carácter personal, o DCP en adelante). Antes de empezar, advierto que quizá esta entrada sea algo larga, pero creo (es más una esperanza que un creencia) que no se les hará pesada:

[Read more…]

Con eMas no habría pasado…

28 de enero de 2008 Por

[Actualización 29/01: Hemos decidido, para incrementar de alguna manera la participación en el blog, habitualmente escasa como pueden apreciar, abrir de manera indefinida los comentarios, de modo que ya no es necesario estar registrado para realizar un comentario sobre una entrada. Por supuesto, aquellos usuarios registrados pueden seguir comentando como usuarios registrados. Esperamos que esto les motive a dejarnos sus opiniones, que les aseguro estamos ansiosos por escuchar.]

No es mi intención trivializar el caso, todo lo contrario, y sobre todo si tenemos en cuenta su magnitud económica. Pero el caso de la Société Générale (y la que está cayendo) ha vuelto a poner encima de la mesa la necesidad cada vez mayor de implantar sistemas de monitorización de las actividades de negocio de las organizaciones, y sobre todo de aquellas que pueden poner en peligro su estabilidad financiera, como ha ocurrido en el caso que nos ocupa.

Con independencia de que la versión que se ha dado de lo ocurrido me resulta realmente difícil de creer (es decir, que una sola persona sea capaz, sin que nadie se entere, de cometer un fraude por una cantidad equivalente al 80% de los beneficios obtenidos por el BBVA el pasado ejercicio), este hecho nos pone delante de las narices la necesidad del control interno y la oportunidad de la implantación de normas equivalentes a la SOX (Sarbanes-Oxley Act) americana en el ámbito europeo; qué mejor momento que éste para exigirlo.

Es más, a mi modesto entender no debería tratarse de normativas sectoriales (como los acuerdos de Basilea en el sector financiero o Solvencia en el sector asegurador), sino que este tipo de regulación debería extenderse a cualquier sector de negocio, adaptándose a las características intrínsecas de cada caso. Los directivos de cualquier organización deben tener muy presente que la falta de control de factores de riesgo —ya sea un riesgo reputacional, el riesgo de una rotura de stock de un producto crítico, o el riesgo que puede estar asumiendo un comercial en una determinada operación de venta por alcanzar los objetivos de año— puede poner en peligro en un momento dado la continuidad en el mercado de su empresa, sin tener en cuenta posibles perjuicios para terceras partes (los clientes, por ejemplo) y responsabilidades de carácter penal para los implicados.

Tomen esto como una primera aproximación a temas que van cogidos de la mano: el análisis de riesgos, la monitorización de procesos y la continuidad de negocio. Aparte de eso, nada más; que les sea leve el lunes.

[N.d.E. Sin ánimo de hacer autobombo, algo a lo que como pueden ver en este blog no estamos acostumbrados (ni nos gusta, puedo añadir) “eMas” es un producto desarrollado por S2 Grupo y orientado a la monitorización de procesos y la gestión en tiempo real.]

[N.d.E. El próximo miércoles, nuestro compañero Antonio Villalón participará en el 1er Foro Latinoamericano STC a través de videoconferencia, con una ponencia en torno a la Convergencia de las Seguridades. Les seguiremos informando.]

Sistemas SCADA

25 de enero de 2008 Por

¿Se acuerdan de aquella entrada sobre los potenciales problemas de seguridad (y sus consecuencias) de los sistemas SCADA? Aquel texto fue reproducido en Kriptópolis y despertó varias suspicacias por su aparente nivel de alarma; algunas de las quejas apuntaban al típico “no seamos paranoicos”, al “estamos viendo fantasmas”. Por supuesto, crear alarma injustificadamente no era ese el propósito de aquella entrada ni de ninguna otra.

Al parecer, según informa Steve Bellovin en su blog, y de acuerdo a información de la CIA, grupos de hackers han sido los responsables de la pérdida de fluido eléctrico en varias ciudades extranjeras, como parte de una trama dedicada a la extorsión. Me atrevo a decir que Barcelona no es una de ellas; eso sería genial como excusa desde algún punto de vista político, aunque sin duda traería mucha más cola desde otros; una cosa es tener problemas de dimensionamiento, y otra saber que tu red eléctrica está completamente a merced de los delincuentes; a mí al menos esto último me asusta mucho más. Como apunta Bellovin, aunque es obvio que las redes de este tipo de servicios no deberían estar conectadas a Internet, esto no siempre es posible; a veces por requisitos funcionales, y a veces incluso por un exceso innecesario de innovación y/o publicidad. Esta es sólo otra noticia más en relación con sistemas SCADA y cómo los problemas de seguridad tienen consecuencias en la vida real (ver opinión de Bellovin al respecto).

Por otro lado, si quieren leer una opinión algo más escéptica sobre estos ataques energéticos y las declaraciones de la CIA, les remito a la entrada de Bruce Schneier, con cuyas opiniones estoy últimamente en desacuerdo (véase su artículo sobre Wifis abiertas y lo que escribimos aquí sobre ello).

Y eso es todo; estamos estos días envueltos en S2 Grupo en un proceso de certificación de la ISO 9001 y recertificación de nuestro SGSI (ISO 27001), por lo que pueden imaginar que el tiempo que podemos dedicarles es más bien escaso (y aún así, aquí seguimos).

Como siempre, gracias por seguir leyéndonos, pasen un buen fin de semana y si es posible, nos vemos de nuevo el lunes.

Google lo sabe todo. Y no olvida.

23 de enero de 2008 Por

Si siguen este blog, ya conocen nuestra pequeña y particular obsesión por Google (y si no, ya lo saben). Eso no quita, por supuesto, que un servidor (yo) utilice sus servicios tanto como lo necesite; el hecho de que Google conozca mis hábitos de navegación, tenga acceso a mi correo de Gmail, o sepa quién y cuando accede alguien a mi blog personal les confieso que no me quita el sueño; quizá porque asumo que no hay nada en todo ello que le pueda ser interesante a Google, más que desde un punto de vista publicitario (siempre por supuesto en un ámbito personal, ya conocen aquello de “en casa del herrero…”). También es cierto que en algún momento de mi vida tuve una relativa preocupación por la indexación y almacenamiento que este buscador realizaba de los grupos de discusión (Usenet News), debido a mi por aquel entonces habitual costumbre de enzarzarme en discusiones estériles y nada sensatas con otros usuarios de estos grupos. Eso y otras cosas hicieron que decidiese añadir una etiqueta CONTENT=”NOARCHIVE” a toda aquella información que vuelco en mi página personal; esto no evita que Google (y otros motores de búsqueda) indexe los contenidos, pero sí que los guarde en caché, dándome la libertad de poder eliminar o cambiar cualquier texto en cualquier momento. Claro que siempre quedan aquellos robots menos educados, o los servicios de lectura feeds, pero dejemos eso para otro momento.

En resumen, cuando uno dispone de un acceso total a los medios de publicación, tomar algunas precauciones es sencillo (y recomendable). Pero esto cambia radicalmente cuando es un tercero quien publica estos datos. Entonces, esta información está accesible a cualquiera que tenga acceso a Internet gracias a Google, hasta que la fuente original decida eliminarla, algo que no siempre es tan fácil como cambiarle el nombre a un fichero. Y no se trata de cuando alguien decide publicar información que uno mismo hizo públicamente accesible en por ejemplo un blog personal, como comentamos aquella vez, sino de cuando es un tercero que sin autorización y en ocasiones con todo el respaldo legal, publica algo que a nosotros nos gustaría ocultar.

Este es precisamente el problema que refleja el reportaje que inspira esta entrada: que si sales retratado en el BOE por alguna sanción de cualquier tipo (como por ejemplo orinar en la calle), seas inocente o culpable, prepárate a que tus amigos, familiares, compañeros de trabajo, futuros jefes, o alumnos (como en este caso), sepan qué y cuando lo hiciste. La parte buena de todo este asunto es que la AEPD ha resuelto a favor del “demandante”, y exige a Google que elimine los datos de su buscador. La parte mala del asunto es que Google no entiende de exigencias, y aunque no ha dicho que no lo vaya a hacer, ya ha añadido que aunque los borren, volverán a aparecer; es decir, la típica política del buscador basada en la respuesta “me da igual lo que me digas, seas quien seas, aunque podemos hablar de ello, si te sientes mejor” a cualquier petición de cualquier tipo, sea legítima o no.

Pero no me gustaría enzarzarme con Google, que sin duda podría admitirse que comparte parte de la culpa, sino que prefiero apelar a la incapacidad de muchos organismos gubernamentales para entender cómo funciona Internet y en particular los motores de búsqueda. Seamos claros: Google no lo indexa todo, sino que como la mayor parte de los grandes buscadores, proporciona herramientas que evitan que ciertas partes de una web se indexen y se almacenen; para empezar, el fichero robots.txt y las etiquetas meta NOINDEX y NOARCHIVE. Aún así, aunque no entendiese de restricciones, y esto aplica a aquellos motores de búsqueda menos educados, existen innumerables medidas para que ficheros que deben ser electrónica y públicamente accesibles lo sean, sin que los buscadores los vean: a bote pronto, páginas protegidas por contraseña, captchas para acceder a repositorios documentales, o servir los documentos previa petición interactiva y distribución de éstos mediante URLs temporales. Entiendo que es complicado admitir que un gobierno soberano tenga que plegarse a las técnicas y funcionamiento de las grandes corporaciones, pero por una parte, lo hacen a diario con las eléctricas, financieras, fabricantes de automóviles, etc., y por otra, mientras no se alcance una solución, el deber de ese gobierno es velar por la protección de los datos de sus ciudadanos. Porque una cosa es que cualquiera pueda saber que tú orinaste en la calle buscando y leyéndose el BOE correspondiente, y otra que Google se lo diga en su primer resultado de búsqueda.

Para acabar, la moraleja de esta entrada está muy clara: no orinen en la calle, por lo que pueda pasar.

Actualización 13h: Me comenta Fernando Seco que no está completamente de acuerdo en que Google tenga que eliminar dichos datos de sus búsquedas, puesto que los BOE y otros documentos gubernamentales son accesibles públicamente. Además, añado yo que probablemente Google no almacena los datos del BOE, sino que sólo los indexa y organiza, por lo que de algún modo, podríamos decir que la responsabilidad de que éstos sean indexados por Google recae toda o casi toda en el organismo que los publica, y no en el gigante norteamericano. ¿Ustedes qué opinan?

(Por cierto, el pasado 19 de enero se publicó el nuevo Reglamento de la LOPD (PDF). Permítannos un tiempo para analizarlo y ya les comentaremos.)

Bichos et al. (y IV): Recomendaciones

21 de enero de 2008 Por

Como ya comentamos en nuestro anterior artículo, vamos a finalizar esta serie de artículos aportando una serie de recomendaciones que pueden ayudarnos a reducir el riesgo de infección por un troyano/virus no documentado y, por lo tanto, no detectable por los sistemas antivirus (en su momento, ya introdujimos otras recomendaciones de carácter más general).

1) No ejecutar nada que “nos pasen”. La manera más fácil de conseguir infectar un equipo es pasarle un “.exe” a un usuario y pedir que lo ejecute. Se puede hacer con más o menos florituras pero el efecto final es el mismo. Pongámoselo difícil a los intrusos, concienciemos a los usuarios (y a muchos técnicos) para que no ejecuten absolutamente nada que no se les proporcione por medios confiables. Si “obligamos” al desarrollador de este tipo de troyanos a integrarlo con la explotación de algún tipo de vulnerabilidad para su propagación, aumentamos enormemente la posibilidad de que nuestros sistemas de detección reconozcan la explotación de dicha vulnerabilidad. Pero para ello es necesario que no puedan conseguir que lo ejecute nadie.

2) Mantener actualizado el sistema, el antivirus y las aplicaciones de acceso a Internet. Si mantenemos actualizados nuestros sistemas es más difícil que se disponga de alguna “puerta de entrada” a él. Es cierto que existen los 0-day exploits (ya hablamos brevemente de ellos), pero ya estamos poniendo un impedimento más; estamos obligando a que exploten una vulnerabilidad no documentada y a que lo hagan sin alertar a nuestros sistemas de detección de intrusos o antivirus.

3) Realizar auditorías de seguridad periódicas. Tampoco servirá de nada tener todo perfectamente actualizado y a usuarios y técnicos perfectamente concienciados si resulta que tenemos el disco duro completamente compartido y que cualquiera puede irse tranquilamente al directorio correspondiente y dejar el troyano para que se arranque en el siguiente inicio de sesión. Existen herramientas como el Microsoft Baseline Analyzer, capaces de realizar auditorías de seguridad de todos los sistemas conectados a un Dominio Microsoft. En el caso de sistemas No-Microsoft existen otro tipo de herramientas.

4) Correos en texto plano. Intentar evitar los correos en formato HTML, ya que en la inmensa mayoría de los casos no es necesario e introduce grandes riesgos de infección. Evitar también mandar y recibir anexos, porque aunque la fuente sea fiable, no sabemos quien puede haber sido el generador original del anexo.

5) Utilizar la firma digital. La suplantación de la personalidad en el envio de correos electrónicos es una práctica completamente trivial, por lo que resulta muy fácil emplear técnicas de Ingeniería Social para engañar a un usuario y hacerle creer que el correo se lo manda el departamento de informática (por ejemplo) solicitándole que instale la aplicación anexa (el departamento de informática es una fuente confiable, ¿o no?).

6) Configurar el navegador. Es preferible que el navegador, por defecto, limite todas las características peligrosas que pueda tener una web (javascript y similares) y que, por contra, si encuentra que por culpa de ello se visualiza incorrectamente alguna web, se configure dicha web en un nivel más confiable que permita visualizarla de forma correcta. Esto disminuirá la probablidad de vernos infectados al llegar casualmente (o siendo engañados) a alguna web que utilice alguna de estas características peligrosas para infectarnos.

Probablemente podrían aplicarse muchas más normas, pero simplemente siguiendo las aquí mostradas incrementamos en gran medida la dificultad de que este tipo de riesgos pueda verse materializado en nuestros sistemas.

Recordemos que la seguridad no es producto, sino un proceso. Lo que es seguro hoy no tiene porque serlo mañana. No podemos incrementar sustancialmente nuestro nivel de seguridad mediante el uso de una única herramienta, por muy sofisticada que ésta parezca. La seguridad sólo consigue incrementarse mediante una simbiosis equilibrada de las herramientas, infraestructuras, procedimientos y, sobre todo, del factor humano, probablemente el más importante de todos.

Bichos et al. (III): PoC de Malware Indetectable

18 de enero de 2008 Por

Hace ya algunos meses del primer y segundo artículo de “Bichos et al” en los que comentábamos la posibilidad de desarrollar sin demasiadas complicaciones software malicioso indetectable por los sistemas antivirus. Durante este tiempo, he intentado dedicar tiempo a realizar una pequeña prueba de concepto y a realizar diversas pruebas con diferentes sistemas antivirus para demostrar que es posible burlarlos siguiendo las pautas que se mencionaron en el apartado anterior.

Sin embargo, no llegué a terminar dicha prueba de concepto, puesto que en el proceso de documentación descubrí el troyano RaDa, desarrollado por Raúl Siles, David Pérez y Jorge Ortiz, que demuestra exactamente lo mismo que se pretendía en este artículo, y siguiendo una filosofía muy cercana a la aquí planteada.

Dicho troyano camufla su tráfico encapsulando a través del protocolo HTTP o HTTPS, haciéndolo por tanto indistinguible para cualquiera (incluyendo un sistema de detección de intrusiones) de un acceso web legítimo. Dicho trabajo fue publicado como reto como parte del Honeynet Project y, tal y como mencionaron sus autores en el documento de solución de dicho reto [PDF], hasta el momento de ser publicado en la web ningún sistema antivirus había sido capaz de detectarlo, con lo que vemos un claro ejemplo de la limitación de la detección basada en firmas: software malicioso nuevo, del que no existen firmas.

Imaginemos que en lugar de publicar el código para ser analizado, los autores lo hubieran utilizado para infectar determinados equipos que resultaran de su interés. El resultado hubiera sido que los sistemas infectados, a pesar de tener un sistema antivirus perfectamente configurado y actualizado, no hubieran sido capaces de detectar la infección, quedando todos los datos a disposición del atacante.

Como parte del reto del Honeynet Proyect se instaba a los participantes a desarrollar una firma para la detección de este troyano por medio del tráfico que genera. Evidentemente, por tratarse este desarrollo de una prueba de concepto, los desarrolladores tampoco pusieron especial enfasis en ocultar la comunicación más allá que utilizando el protocolo HTTP (y sin ponerle ese énfasis que sin duda un atacante malicioso habría puesto, consiguieron su objetivo, demostrando la ineficacia de los sistemas antivirus), y los comandos intercambiados se transmitían en texto plano. En caso de que un administrador detectara alguna anomalía y visitara la web, vería claramente que no se trata de una web corriente. Pero, si en lugar de emplear este sistema —más que suficiente para lograr el objetivo que se perseguía— la comunicación hubiera sido cifrada, ocultada dentro de algún nombre de imagen o de algún parámetro “ALT” dentro del tag HTML “img”, o se hubiera empleado algún método alternativo para esconder el propósito malicioso de la web, el resultado hubiera sido completamente diferente. Finalmente, los autores también hacen referencia a la posibilidad de utilizar otro tipo de protocolos para la ocultación de este tipo de tráfico como puedan ser el tráfico ICMP, el correo, DNS, etc.; les recomiendo fervientemente la lectura del citado artículo.

Para acabar, ¿quiere decir esto que no podemos hacer nada para evitar ser infectados? Pues ni sí, ni no. S�? podemos, pero NO confiando únicamente en los antivirus. Éstos no son sino otra herramienta más que nos ayuda a mejorar nuestro nivel de seguridad, que puede resultar eficaz para la detección y eliminación de virus de difusión amplia —que representan a fin de cuentas la inmensa mayoría de los que nos vamos a encontrar—, pero en la que no podemos delegar toda nuestra seguridad.

El lunes, en la próxima y última entrega de esta serie veremos varios consejos que pueden ayudarnos a reducir los riesgos de esta naturaleza. Como siempre, pasen un buen fin de semana.

Nivel de seguridad inalambrica en la ciudad de Valencia

16 de enero de 2008 Por

El pasado fin de semana estuve dando un paseo portátil en mano por la ciudad de valencia obteniendo resultados aterradores. Las capturas de datos en el escenario de pruebas ofrecieron la posibilidad de establecer una categorización del uso de los métodos de cifrado inalambrico por parte de la población consultada, permitiendo medir el nivel de seguridad de las redes Wireless en la capital del Turia.

Se obtuvieron como resultado cuatro grandes grupos: redes abiertas “OPN”, Access Points (AP) con seguridad WEP, redes que hacen uso de WPA, y puntos de acceso con WPA2. Los datos recabados reflejan el grado de seguridad de las conexiones inalámbricas que utilizan el estándar IEEE802.11, estimando de esta forma la exposición de riesgo de la población que hace uso de este tipo de tecnología. El gráfico de la izquierda establece el porcentaje de uso de cada protocolo obtenido de una muestra de 2658 puntos de acceso tomada en el escenario de pruebas, con la siguiente distribución:

» 538 puntos de acceso sin cifrado de datos.
» 1514 con seguridad WEP.
» 513 redes con el protocolo de seguridad WPA activado.
» 93 AP’s que usan WPA2.

Como se puede observar, el 20% de los puntos de acceso no contempla ningún tipo de cifrado de datos o control de acceso. El 57% utiliza seguridad WEP, mientras que el 19% hace uso de WPA en su punto de acceso inalámbrico. En último lugar aparece WPA2 con un escaso 3% de uso.

Teniendo en cuenta estos datos, podemos casi asumir con certeza que el 99% de los puntos de acceso con WEP son explotables de forma exitosa. Me aventuraré aún más y diré que el 15% de los puntos de acceso con WPA pueden ser atacados con resultados positivos. De la misma forma, el 15% de los AP’s con WPA2 lo son también, debido a que los métodos de ataque son los mismos: diccionario y Rainbow tables (precomputación del SHA-1 (guardado en forma de listado hash) de WPA y WPA2 para acelerar el proceso de crackeo; véase este enlace). Si a ello le sumamos el porcentaje de las redes abiertas obtenemos el siguiente resultado:

Podemos decir por tanto que sí, el 80% de las redes inalámbricas en la ciudad de Valencia son potencialmente vulnerables.