Security Art Work

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.

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.

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.

Comentaba Enrique Dans hoy un artículo de Bruce Schneier en Wired, titulado “Steal This Wi-Fi“. Básicamente, éste (Schneier) viene a defender los argumentos por los que tiene su Wi-Fi abierta a todo aquel que quiera utilizarla, y aunque algunos de los argumentos me parecen correctos, con otros discrepo profundamente, así que no me he podido resistir a escribir algo. Aprovecho además para recomendar a nuestros lectores, habituales y esporádicos, que si han decidido no dejar abierta su Wi-Fi, cambien de WEP a WPA, sí o sí. Las molestias del cambio es mínimo, y el incremento en seguridad, muy sustancial (vean este artículo del propio Schneier si no se lo creen, como apunta un comentarista por allá).

Pasando al artículo, el primer y creo que principal argumento de Schneier para dejar la Wi-Fi abierta es la cortesía con los invitados; si alguien recibe calefacción, agua y una taza de café, ¿porqué no Internet? Admito que el argumento es correcto, pero en mi caso, nunca he tenido un invitado que haya tenido la necesidad de acceder a Internet con su propio dispositivo, por lo que esa cuestión nunca se me ha planteado. Por supuesto, si de manera frecuente tuviese amigos que necesitasen acceso a Internet, me plantearía alternativas. También afirma, en referencia a la seguridad de los datos propios, que, puesto que se conecta a menudo con Wi-Fis de aeropuertos y hoteles, la seguridad debe residir en el PC, y no en la red. Estoy de acuerdo, pero no es mi caso; apenas utilizo el ordenador cuando no estoy en casa, y no acostumbro a usarlo en hoteles o aeropuertos, por lo que la exposición de los datos que conservo en éste a terceros está limitada por elementos que controlo: la red y el propio PC. Si tuviese que viajar a menudo, me abstendría de utilizar servicios como la banca electrónica u otros en los que el dispositivo es un mero transmisor; llámenme paranoico si quieren. Por último, hablando del robo de ancho de banda, estoy de acuerdo en que resulta más una molestia que otra cosa, excepto en aquellos casos en los que la otra persona decide abusar de tu generosidad; que alguien te quite ancho de banda no supone demasiado, la verdad.

Hasta aquí, los argumentos en los que puedo estar más o menos de acuerdo o no se aplican a mi caso. Sin embargo, hay otros con los que estoy mucho menos que de acuerdo, y hay uno en particular que es para mí, la principal razón para evitar tener tu Wi-Fi abierta. Éste se basa en la posibilidad de que alguien efectúe actos delictivos mediante tu equipo: pornografía infantil, estafa, intrusión en empresas, etc. Alguien puede pensar que el hecho de tener tu Wi-Fi abierta puede servir como defensa frente al juez, algo así como un “yo no he sido”. Este es un argumento más defendido por Dans que por Schneier. El caso es que a no ser que a las tres de la mañana entren en tu casa los GEOs y confisquen de repente todo tu equipamiento informático, si un buen día recibes una citación judicial, iba a ser complicado un mes después convencer al juez de que tu Wi-Fi se encontraba abierta. Es algo como decir que te habían robado el coche cuando te llega una multa dos meses después de la infracción. No conozco demasiado el sistema de registro de los Access Points, pero me juego un brazo a que no guardan en una memoria no volátil las modificaciones en la configuración (para demostrar, por ejemplo, que el proveedor te lo instaló abierto en origen), y me juego el otro a que nadie o casi nadie tiene configurado el sistema de syslog del Access Point, que por otra parte esté probablemente muy limitado en el tipo de eventos que genera. Y aún en el caso de que el juez admitiese que el Access Point estaba abierto, te tocaría demostrar que efectivamente, no has sido tú el autor de las acciones delictivas (lo más normal es que tus potenciales vecinos se desmarcasen del uso de tu Wi-Fi, si ven el panorama feo). En definitiva, que lo más posible es que acabes delante de un juez, lo que te robará tiempo, dinero, te meterá en un lio que puede ser considerable, y si el juez en cuestión decide que puesto que la conexión está a tu nombre por contrato, te toca apechugar con la culpa, te costará más dinero o cosas peores.

Por último, se hace mención a los problemas (actuales o futuros) que puede tener WPA, y en esto también incide Dans más que Schneier, que es muy consciente de las fortalezas y debilidades de WPA. Por supuesto que WPA tiene sus limitaciones de seguridad; básicamente igual que muchas tecnologías y protocolos seguros, pero eso no es suficiente para afirmar, como dice Enrique Dans, que no sirve para evitar el crimen por sus problemas de seguridad, que es lo mismo WPA que nada. No. Quizá WEP sea casi lo mismo que no tener nada (y ni aún así), pero WPA es lo suficientemente seguro para que no sea nada nada fácil romperlo si se hace uso de una clave robusta. De hecho, hay que tener mucho interés, bastante tiempo y unos no despreciables conocimientos técnicos para intentarlo; y eso no asegura que se consiga. Y si pasamos a WPA2, les puedo asegurar que pueden dormir tranquilos. Por supuesto que tiene sus limitaciones y saldrán problemas técnicos en el futuro, al igual que los tienen el ssh o el https, pero eso no evita que sigamos utilizando la banca electrónica, ¿verdad?

En mi opinión, aunque tener tu Wi-Fi abierta es un signo de generosidad hacia otras personas, y algo que algunos agradeceríamos cuando nuestro proveedor decide cortarnos la conexión un sábado por la mañana, puesto que después de todo desconocemos que hace “el otro” a través de tu AP, creo que los riesgos exceden las ventajas, aunque después de todo es una decisión personal. No es cuestión de pensar que todo el mundo es malo, pero tampoco que todo el mundo es “güeno”. Simplemente porque meterse en un proceso judicial, aunque salgas indemne, debe ser ya de por sí algo bastante traumático (y costoso). Y tampoco se fíen, en el lado contrario, y como les decía José Selvi hace unos días, de todo aquel que tiene su red abierta, porque no todo es lo que parece.

El lunes, más. Como siempre, pasen todos un buen fin de semana.

Si recuerdan, y no se nos han perdido por el camino, en la entrada de ayer nos quedamos con el cálculo de SA+3[A+3] (es decir, elemento A+3 del array S en la iteración A+3) mediante el algoritmo PRGA. No obstante, como les decíamos, no parece muy factible asumir que los valores de S[0], S[1] y S[A+3] permanecerán quietos tras el barajado de KSA. Y aquí es donde entra en juego la estadística; FMS calcularon mediante la fórmula

En este punto recordemos una de las dos premisas que presentamos al comienzo del análisis: conocemos el texto plano del primer byte del paquete, ya que corresponde con el valor 0xAA. Realizando un XOR de ese byte con el primer byte encriptado podemos conocer un 5% de las veces el valor de SA+3[A+3]. Retrocediendo aun mas con este valor podemos calcular el jA+3 y con ello determinar el valor de Clave[A+3]. Una vez determinado el byte A, podremos ir incrementando el valor del índice (A+1) para buscar el siguiente byte de la clave [A+3+1, 255, X], y vuelta a empezar. Poco a poco incrementaremos el valor de A averiguando por completo el total del vector Clave[].

Existen posteriores mejoras del algoritmo FMS que identifican un mayor numero de IVs débiles y que producen como resultado una determinación de la clave con un menor número de paquetes. Personas como KoReK introdujeron nuevas capacidades al algoritmo permitiendo la recuperación de una clave de 128 bits con 800000 IVs y de una de 65 bits con 200000 IVs.

Se ha seguido trabajando en la mejora de este algoritmo, y la universidad de Darmstadt (véase este enlace) ha conseguido rebajar el número de paquetes considerablemente mediante la creación de la herramienta PTW. Haciendo uso de su aplicación es posible conseguir la clave de cifrado (128 bits) con tan solo 50000 IVs. Y con este, queda finalizada la serie de tres “capítulos” sobre porqué no es nada recomendable utilizar WEP (teniendo en cuenta además que WPA suele estar disponible en la mayoría de dispositivos) y porqué su mala fama sí es justificada; pueden obtener más información de este completo artículo de Linux Magazine [PDF] y de innumerables sitios en Internet.

Tras la introducción de ayer y la descripción de la relación que existe entre la clave de cifrado maestra y los IVs de la cadena que conforma la entrada al algoritmo KSA, hoy continuaremos con el análisis del algoritmo KSA. El código de éste se puede observar a continuación.

     KSA

     for i = 0 to 255
          S[i] := i
     j := 0
     for i = 0 to 255
          j := (j + S[i] + Clave[i mod “tamañodelaclave"]) mod 256
          Intercambia(S[i], S[j])

Vemos que principalmente esta compuesto por dos bucles; un primer bucle que inicializa un vector de enteros S, muy importate como posteriormente veremos, y una segunda iteración que tiene como objetivo desordenar el vector anterior en función de la clave maestra. En este caso el valor de la variable “tamañodelaclave“ será 5 para 64 bits y 16 para 128 bits. Realicemos una pequeña traza de las tres primeras iteraciones que nos ayudaran a comprender su funcionamiento. En el estado inicial, tras la inicialización del vector S, el valor de las variables es el siguiente:

     Clave[] = (A+3, 255, X, Clave[3], …, Clave[A+3], …)
     S[] = (0, 1, 2, …, A+3, …, 255)

Partiendo de este estado vamos a aplicar las tres primeras iteraciones para observar el comportamiento del algoritmo.

     Iteración 0
     
     i = 0
     j = 0 + 0 + Clave[0] = A+3
     S[] = (A+3, 1, 2, ..., 0, ...) 

     Iteración 1

     i = 1
     j = (A+3) + 1 + 255 = A+3                  [Ya que se aplica “j mod 256"]
     S[] = (A+3, 0, 2, ..., 1, ...)

     Iteración 2

     i = 2
     j = (A+3) + 2 + X
     S[] = (A+3, 0, S[j], ..., 1, ...)

[Read more…]