¿Romper WPA/WPA2 con GPUs? ¡Chorradas!

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)8 = 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.

Echando cálculos, y si no me equivoco, se tardarían 7.927 años en barrer todas las posibles cadenas, y eso suponiendo que has acertado con el ESSID (ya que la cadena de cifrado depende de él) y que la PSK es ¡sólo de 8 caracteres!, cuando la longitud de la cadena en WPA puede ser mayor de 60 caracteres. Teniendo en cuenta además que cada incremento de la longitud en 1 caracter multiplica por un factor de 100 el tiempo necesario, pueden hacerse una idea de la magnitud temporal si tomamos 12 caracteres en lugar de 8.

Así que este producto esta bien, sí, pero esta muy muy lejos de lo que anuncian, y es más un reclamo comercial que otra cosa. He visto varios anuncios de este tipo con gente que vende colecciones de DVD’s con tablas precomputadas, que aseguran que rompen todos las claves WPA. Chorradas; el verdadero problema de seguridad de WPA son los usuarios y solo será vulnerable cuando se rompa el cifrado (RC4/AES).

Para acabar, si les gusta el tema de aparatillos hardware que permiten incrementar la potencia de cálculo, Picocomputing contruye mediante ASICs y FPGAs dipositivos que pueden llegar a barrer 1000 palabras por segundo. Aunque vistos los cálculos previos, no se hagan ilusiones…

Actualización 20/10, 13:15h (N.d.E.): El autor, Roberto Amado, ha publicado una segunda entrada rebatiendo algunos comentarios.

Actualización 20/10, 11:45h (N.d.E.): Mientras espero la contestación de Roberto Amado a los comentarios realizados, tanto aquí como en menéame.net, hay varios aspectos que es necesario comentar.

El primero es que aunque quizá el término “phising comercial” esté algo cogido por los pelos, decir que “WPA/WPA2 protected networks are not immune against distributed attacks performed with GPU-accelerated algorithms“, como Elcomsoft hace en su nota de prensa, es cuanto menos amarillista; sólo hay que echar un vistazo a Google para ver hasta qué punto ha calado el mensaje. La seguridad de WPA2 sigue siendo igual de robusta hoy que antes del anuncio de Elcomsoft, siempre y cuando, como es habitual, la contraseña tenga una longitud mínima y sus correspondientes reglas de complejidad.

En segundo lugar, aunque no se menciona el uso de una única GPU, utilizar 5, 10, 100 o 1000 no resulta un factor decisivo comparado con el incremento temporal que tienen dos o tres caracteres adicionales; descontando por supuesto que no todo el mundo dispone de tal cantidad de dispositivos.

En tercer lugar, comparar la seguridad de WEP con WPA/WPA2 carece totalmente de sentido, y no hay mucho más que decir al respecto.

En cuarto lugar, para la velocidad de crackeo por fuerza bruta es necesario el uso de tablas precomputadas, que pueden incrementar la velocidad hasta cerca de 40,000 passwords por segundo; no obstante, dichas tablas, aparte de tener que calcularlas, dependen del SSID de la red, por lo que en muchas ocasiones resultan de escasa utilidad. Al respecto, alguno parece haber asumido que el crackeo se hace haciendo pruebas con la Wifi, cuando en el artículo jamás se menciona ese punto. Otra persona dice que los ataques de fuerza bruta no se usan desde hace 20 años, pero me abstendré de contestar a dicha afirmación.

Para acabar, resulta más bien decepcionante (aunque previsible, por otro lado) que en lugar de aportar argumentos convincentes, algunas personas (no todas, afortunadamente) se limiten a insultar o a rebatir el artículo con afirmaciones vacías. En breve espero tener una respuesta de Roberto con todos los detalles. Hasta entonces, espero que apliquemos, antes de soltar los dedos, esa cautela que tanto se pide.

La dificultad de la detección de intrusiones

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.

Si llamamos A al suceso “el detector de intrusiones ha emitido una alerta” e I al suceso “se ha producido una intrusión”, tenemos que la probabilidad condicional P(A|I) es la medida de la “precisión” de nuestro detector (la probabilidad de que cuando se produzca una intrusión se emita una alarma), por lo que nos interesa que sea cuanto más alta mejor. Por otro lado, P(A|no I) es la probabilidad de falso positivo: la emisión de una alerta más a atender por parte del personal técnico de seguridad que nos aporta más bien poca información. Obviamente, nos interesa que esa probabilidad sea lo más baja posible.

En el fondo, lo que nos interesa es que el detector de intrusiones sea “efectivo”: que detecte el mayor número de intrusiones pero manteniendo la tasa de falsas alarmas en un nivel aceptable. Nos interesa también que, cuando vemos una alarma, la probabilidad de que corresponda a un ataque, P(I|A), sea lo más alta posible. Relacionando todo lo anterior con ayuda del Teorema de Bayes, tenemos que:

P(I|A) = P(I) x P(A|I) / [ P(I) x P(A|I) + P(no I) x P(A|no I) ]

Como estimación, el detector de intrusiones ubicado en la zona desmilitarizada de un cliente relativamente pequeño ha procesado unos 500 millones de datagramas IP en los últimos 4 meses, a partir de los cuáles ha generado 339 alertas. De esas alertas, 128 se corresponden con ataques reales. Suponiendo una precisión del 100% (que ya es suponer), P(A|I) = 1, tenemos que las intrusiones detectadas son todas las que se han producido, y que la probabilidad de intrusión, tomando 10 datagramas por cada una de ellas, es P(I) = (128*10) / (500*10+6) = 2,56*10-6. Como P(no I) = 1 – P(I) se aproxima mucho a 1, sustituyendo en la anterior ecuación nos queda, aproximadamente:

P(I|A) = 2,56·10-6 x 1 / [ 2,56·10-6 x 1 + 0,99 x P(A|no I) ]

con lo que se observa claramente que el factor dominante es ese 0,99 de P(no I), y que la probabilidad de falso positivo tendría que ser muy baja para contar con una efectividad adecuada. Cualquiera que haya trabajado atendiendo las alertas generadas por un detector de intrusiones actual convendrá en que no es ni mucho menos el caso: la mayor parte del tiempo es dedicado a descartar falsos positivos. La cuestión es: ¿es realmente posible obtener una tasa de falsos positivos tan baja? El tiempo lo dirá, pero a día de hoy la solución quizá pase por facilitarle la vida al técnico de seguridad en forma de herramientas que le faciliten la gestión de las alertas generadas y la consulta de la información necesaria para procesarlas cómodamente.

P.S. La falacia de la probabilidad condicional también es aplicable a otros ámbitos de la seguridad. Por ejemplo, dado el bajo número de población terrorista con respecto a la población total de un país, aun suponiendo que los gobiernos cuentan con herramientas de vigilancia masiva altamente precisas, es difícil que la tasa de falsos positivos (no terroristas identificados como terroristas) sea tan baja como para asegurar una detección eficaz según los parámetros anteriores. Además, ¿cuál sería el coste de ser clasificado como un terrorista cuando no lo eres? ¿Y el de la pérdida de derechos civiles asociada a ese tipo de vigilancia?

ClickJacking

Clickjacking es una técnica reciente que ha sido descrita por varios especialistas de seguridad que han podido tener acceso a los detalles de la vulnerabilidad como TERROR?FICA. Según los datos que se han facilitado, la vulnerabilidad permitiría a un atacante preparar un sitio web malicioso mediante el cual podría realizar un “secuestro de clicks”, es decir, cada click que hagamos en el navegador podriamos estar clickando en otro sitio que no es el que pensamos, con el consiguiente riesgo de ejecución de malware y amenazas similares.

Los detalles de la vulnerabilidad, que afecta a practicamente todos los navegadores, iba a ser presentada en la OWASP AppSec de Nueva York pero parece ser que ha sido cancelada debido al riesgo de dar los detalles antes de que los fabricantes hayan podido desarrollar sus parches, hecho complicado puesto que según han confirmado ellos mismos no es una vulnerabilidad de fácil solución.

Por los datos que se han podido obtener, exploradores “lynx-like” no son vulnerables a este tipo de ataques. Otro de los datos que se ha publicado es que no tiene nada que ver con Javascript, por lo que usar complementos tipo NoScript no será 100% efectivo (aunque por lo que se ha podido averiguar sí que protegerá de algunos vectores de ataque).

A partir de estos datos que se han ido filtrando, varios especialistas en seguridad han “teorizado” sobre la posible vulnerabilidad, localizandola en un problema sobreponiendo un iframe transparente sobre otro que contenga otra web, de tal manera que al clickar en la web que consideramos inofensiva estamos clickando al mismo tiempo en enlaces de la web maliciosa. Hay sitios en los que incluso han creado una pequeña prueba de concepto.

Efectivamente, la solución teorizada parece tener sentido a partir de la información que ha sido facilitada de forma pública, pero no existe ninguna seguridad de que este sea el único vector de ataque.

Por ello, realizamos las siguientes recomendaciones a seguir hasta que se conozcan más detalles sobre la vulnerabilidad:

  • No clickar en enlaces que provengan de correo, MSN, etc, podrían llevarnos a una web maliciosa que parezca una web legítima.
  • Utilizar RUNAS (en Windows ó “su” en Linux) para lanzar un navegador con un usuario con mínimos privilegios en la máquina cuando queramos navegar libremente por páginas no conocidas, y NUNCA confiar en una web legítima que aparezca en este navegador.
  • Accede a las webs relevantes para tí desde los marcadores de tu navegador.
  • Esperar ansiosamente que en fabricante publique el parche que solucione la vulnerabilidad.

Consideraciones de seguridad en entornos virtualizados

Hace ya unos cuantos meses introdujimos brevemente el concepto de entornos virtualizados, si recuerdan la entrada de nuestro compañero José Selvi. La cuestión es que cualquiera que haya tenido la oportunidad de “tocar” un entorno virtualizado ya sabe las ventajas que ofrece esta tecnología. Yo personalmente, aún recuerdo aquella época donde la llamada del operador 24 horas a las 2 de la mañana daba el inicio a una noche de nervios, crisis, backups y reinstalaciones hasta que el servidor volvía a la vida (si lo hacía).

Hoy en día, se pueden tener tranquilamente varios servidores “host” en un clúster albergando decenas de servidores virtuales. Estos servidores virtuales pueden migrarse de un host a otro en caliente, según se necesiten más o menos recursos; si hubiese un error crítico en uno de los hosts, automáticamente se balancearían todos los servidores virtuales de uno a otro. En resumen, llegas por la mañana, sacas un café y mientras lo saboreas te das cuenta que esa misma noche un “host” se ha apagado inesperadamente, pero que todos los servidores virtuales asociados siguen en marcha, esto es vida…

[Read more…]

Demo de ataque DNS y troyanización

En relación con la vulnerabilidad del DNS que les comentábamos el otro día, les traemos un video de demostración de cómo aprovechar la vulnerabilidad del DNS descubierta recientemente para provocar una intrusión en un sistema, aprovechando los servicios de actualización automática:

http://www.infobyte.com.ar/demo/evilgrade.htm

Para los que se pierdan un poco, lo que Francisco Amato (Infobyte) hace primero es realizar un ataque Kaminsky para envenenar la cache del DNS utilizado por la víctima para que java.sun.com resuelva a la dirección de su equipo.

Una vez hecho esto, lanza el servicio evilgrade, que emula el servicio de actualización de la máquina virtual de Java, por lo que cuando desde el equipo víctima se pretende realizar la actualización, la solicita al servidor malicioso en lugar de hacerlo al original de Sun, con lo que evilgrade contesta con un paquete de actualización que es ejecutado por la máquina víctima, ejecutando un “Remote Shell” mediante el cual se consigue acceso al equipo.

Como prueba de la intrusión, Amato deja en el escritorio un fichero de texto con la palabra “Owned” para constatar que el equipo ha sufrido una intrusión.

Como curiosidad, y para remarcar la seriedad del problema, el propio creador de la Metasploit Framework ha sufrido un envenanamiento de la web www.google.com debido a que el DNS de su proveedor (AT&T) no estaba parcheado correctamente (como, podría añadir, seguramente todos los de los principales proveedores de Internet, nacionales e internacionales).

Nada más. Sigan temblando :P

Vulnerabilidad en DNS “disclosed”

Si nos siguen regularmente, sabrán que solemos dejar un par de días, como poco, entre entrada y entrada. Lunes, miércoles y viernes suele ser la periodicidad que personalmente más me gusta. Pero hay ocasiones, como esta, en las que las circunstancias imponen un cambio de planes. Ni que decir tiene que para aquellos que no la leyeron ayer, les recomiendo que le echen primero un vistazo a la entrada anterior, sumamente interesante y un fiel reflejo de la seguridad de las organizaciones y los riegos de carácter práctico que implica la movilidad y la portabilidad, tanto a nivel de datos de carácter personal como de cualquier otro tipo.

Pasemos ahora a eso que ha alterado el orden natural de publicación y hará que este viernes no vaya a haber ninguna entrada. Ya tienen bastante con lo que tienen, hasta la semana que viene.

Empecemos con una pequeña introducción. Hace unas semanas, tal y como avisamos aquí mismo, Dan Kaminsky informaba de un peligroso problema de seguridad en el servicio de DNS; no creo que nadie necesite que le explique para qué sirve el DNS, ni de cuál es su criticidad en el marco de Internet. El problema era de una importancia tal que dió de plazo aproximadamente un mes para desvelar los detalles técnicos del problema, hasta el 6 de agosto, en la conferencia que daría en Black Hat, tiempo que los proveedores deberían aprovechar para parchear sus sistemas. Cosa que la mayoría de grandes proveedores no han hecho, todo sea dicho.

Hace un par de días, Halvar Flake se puso a especular sobre el problema. Y parece que se acercó bastante. Ese mismo día, la gente de Matasano publicó en su blog una interesante entrada en su blog, dando muchos detalles sobre la vulnerabilidad, y violando —al parecer— el acuerdo que habían alcanzado con Dan Kaminsky. Aunque eliminaron la entrada y pidieron disculpas, Internet no olvida, y su entrada se encuentra tanto en Google, como en otros blogs, en Slashdot, PC World ya ha hablado de ello y vayan ustedes a saber dónde o quién más. En otras palabras, el problema es casi oficialmente de carácter público y es probable (aunque no seguro) que Dan Kaminsky aclare finalmente los detalles.

La explicación que les voy a dar no pretende ser técnicamente profunda, pero espero que les sea suficiente; por supuesto, si detectan algún error, hagánmelo saber. Seguiré básicamente, pero no al pie de la letra, los pasos que Matasano describía en su entrada. Como conceptos básicos, deben conocer qué es un servidor DNS, y la estructura recursiva que el protocolo tiene. Si el servidor A no conoce la dirección IP para www.victim.com, preguntará a uno de mayor nivel, y así sucesivamente. Veamos ahora dos tipos de ataques clásicos sobre el DNS.

a) DNS Forgery. Este ataque se basa en hacer creer al servidor DNS que www.victim.com no tiene la IP 1.2.3.4, que es la legítima, sino que es 4.3.2.1, que en realidad apunta a www.evil.com. De este modo, cuando alguien le pregunte al servidor DNS por la IP de www.victim.com, éste devolverá la IP de www.evil.com. Imaginen ahora que www.victim.com es la web de un banco y www.evil.com reproduce fielmente su interfaz. Seguro que ven el problema.

La idea es la siguiente. Cuando Pepe pide la dirección de www.victim.com, si su servidor DNS Pepe_DNS no tiene su dirección IP, preguntará a Alguien_DNS por dicha IP, y así recursivamente. Esa solicitud lleva asociado un query id (QID), que sirve para autenticar la respuesta. La intención del ataque es devolverle a Pepe_DNS la IP de www.evil.com como si fuese la de www.victim.com, antes de que el servidor DNS legítimo lo haga, con la gracia de que además, Pepe_DNS guardará esa dirección IP en caché durante un tiempo, por lo que muchas de las siguientes consultas devolverán la IP de www.evil.com.

Claro que para hacer eso, necesito saber el QID de la petición, o la respuesta será descartada. Antes, cuando los QIDs eran consecutivos, algo así podía resultar sencillo. Ahora los QIDs se generan aleatoriamente (¡vaya!). Imaginen ahora que puedo hacer que Pepe_DNS pida no una, sino 1000 veces la IP de www.victim.com; hay 1000 veces más QIDs, y sólo tengo que adivinar uno de ellos. Imaginemos además que empiezo a preguntarle a Pepe_DNS como resolver direcciones que controlo; podré acceder a los QIDs y eventualmente, con suerte y algo de tiempo, quizá consiga predecir la semilla de generación de los QIDs.

La solución básica para eso es lo que hace DJBDNS, que es combinar el QID con el puerto de petición del cliente DNS, con lo que aumentamos la seguridad de 16 bits a 32 bits, haciendo la cuestión de adivinar sensiblemente más complicada.

b) DNS RRset poisoning. Este ataque está basado en la estructura de los paquetes de respuesta del DNS. La idea es que en la respuesta que recibo del servidor, además de la información solicitada, existe una parte del paquete que puede contener información adicional “de interés”. Por ejemplo, si yo pregunto por www.evil.com, Pepe_DNS puede contestarme con la IP de www.evil.com y en el campo de “información de interés” darme la IP de www.victim.com, que por supuesto no es la IP legítima.

Claro que alguien se preguntará porqué podría alguien pedir la IP de www.evil.com. Imaginen que acceden a un blog, que tiene una imagen alojada en www.evil.com. Con sólo eso, ya estamos intentando resolver www.evil.com, y el resto ya lo saben. La solución a esto es muy sencilla, al menos en el nivel teórico: no hagas caso del campo “informacion de interés”, excepto si contiene información sobre el dominio sobre el que he preguntado; es decir, que si pregunto por www.evil.com, puede interesarme mail.evil.com, pero no mail.victim.com.

c) Pasemos finalmente al ataque de Dan Kaminsky, que está basado en una combinación de los dos anteriores ataques. Imaginemos que preguntamos por aaaaa.victim.com. Seguramente el servidor legítimo, que es más rápido, le conteste diciéndo que no existe tal dominio (NXDOMAIN). Sigamos intentándolo con aaaab.victim.com, con aaaac.victim.com, de manera recursiva, hasta que llegado un determinado punto, seremos más rápidos y conseguiremos que Pepe_DNS crea que xgsdty.victim.com tiene la dirección 4.3.2.1.

Claro que xgsdty.victim.com es una dirección inexistente, y aunque en la práctica tenemos un DNS “poisoned” (envenenado), no parece servir de mucho ya que nadie va a preguntar por la IP de xgsdty.victim.com. Pero ahora, mediante la técnia del segundo ataque descrito, podemos decirle a Pepe_DNS cuál es la IP de www.victim.com, incluyendo su dirección en la “información de interés”, que sí que nos aceptará por pertenecer al dominio victim.com.

Dicho de otra forma, se trata de conseguir que Pepe_DNS acepte como respuesta legítima una respuesta ilegítima de nivel 3 (xgsdty.victim.com), que aunque no sirva de nada, incluya información sobre la IP de otros dominios de nivel 3 (www.victim.com) del mismo dominio de nivel 2 (victim.com). Tomando un ejemplo más real, si consiguimos que el servidor acepte como válido un paquete que le dice que tazxvb.google.com tiene como IP 1.2.3.4, éste aceptará como válida cualquier información adicional sobre google.com: www.google.com, mail.google.com, etc.

Les dejo a ustedes sacar las conclusiones sobre qué pasaría si el DNS que habitualmente utilizan piensa que www.google.com tiene la IP de www.evil.com. Bien. Pues les adelanto que la mayoría de DNS son (aún) tristemente vulnerables (pueden comprobarlo en el blog de Dan Kaminsky). Ah. Y no saben lo peor, o lo más divertido, depende de su gusto por la ironía; que su DNS no sea vulnerable no significa que estén a salvo, gracias a la estructura jerárquica del servicio de DNS de Internet.

¿No les parece fascinante, y a la vez, un problema “de cagarse”? Nada más. Buen fin de semana a todos.

Vista Hacked en 2 minutos

Un ejemplo de la cantidad de ataques físicos que pueden hacerse contra los sistemas operativos cuando se tiene acceso físico al sistema:

Vista Hack

En este caso, los chicos de Offensive-Security han grabado en video (y con música poco discreta) una pequeña demostración mediante la cual reinician un Windows Vista con una Live-CD y copiando el cmd.exe con otro nombres son capaces de lanzarlo sin realizar autenticación de usuario y hacerse con privilegios de SYSTEM (usuario de máximos privilegios del sistema).

Además, como podeis ver en el video de demostración, la prueba fue realizada en aproximadamente 2 minutos; si a eso le sumamos el tiempo de descargar e instalar algún software tipo backdoor, ponle 3 minutos. Con hacer una rápida visita al baño podriamos encontrarnos con nuestro portátil comprometido.

La solución a este problema pasa por el cifrado completo del equipo, bien sea mediante herramientas de pago, bien mediante algunas herramientas OpenSource que realizan esta función (TrueCrypt).

En un próximo post, alguna información sobre cifrado completo del sistema.

¿Cifrado = Privado?

Hace poco estuve realizando un curso de Administración y Mantenimiento de Windows Server 2003 para mejorar mis conocimientos sobre este sistema operativo, ya que cuanto más conoces un sistema, más sencillo resulta auditar la seguridad del mismo, que es a lo que me dedico en mi actividad profesional.

Durante la realización de este curso hubo algo que me impactó un poco en relación con el soporte que ofrece Microsoft en sus sistemas para cifrar archivos y carpetas en sistemas de ficheros NTFS. No cabe duda de que en un primer momento puede suponer muy funcional por el hecho de que se cifra la información sin tener que recordar una contraseña adicional, que todo se realiza transparentemente al usuario.

captura.jpgEl problema con las cosas “excesivamente funcionales y transparentes” es que en la mayor parte de los casos implican un decremento en su seguridad. Por poner un ejemplo, algunas de las preguntas que me surgieron al explicarme este método de cifrado:

¿Que pasa si el usuario olvida la clave y es necesario resetearsela? Se pierde la información cifrada sin posibilidad de recuperación. Al haber sido cifrada utilizando la contraseña de usuario.

En realidad no se perdería, lo cual aunque en principio puede parecer algo bueno, comprobareis que el mecanismo empleado vulnera en cierta medida la privacidad de los usuarios de este sistemas de cifrado integrado.

Cuando configuras un fichero o carpeta como cifrado con EFS, además del usuario que lo crea que evidentemente tiene acceso, puedes definir un listado de usuarios que también tendrán acceso a dicho fichero. Dichos usuarios son perfectamente gestionables por el usuario propietario del fichero. El problema radica en lo que podemos apreciar en esa misma ventana un poco más abajo. Existe un “rol” denominado “Agente de recuperación de datos” (que por defecto es el usuario Administrador y que el usuario no puede cambiar) que es capaz de acceder a cualquier información cifrada del sistema.

Como podeis imaginar, el hecho de que un usuario Administrador del sistema pueda acceder a toda esta información cifrada vulnera completamente la privacidad que se pretende alcanzar con el uso de herramientas criptográficas.

Todo esto me ha llevado a la conclusión que el sistema de cifrado EFS proporcionado por Microsoft en sus sistemas operativos no satisface los requisitos mínimos de seguridad, por lo que yo personalmente recomiendo utilizar software de terceros aunque ello implique tener que recordar una contraseña más o llevar con nosotros un token o certificado digital, nuestra privacidad vale esa molestia y mucho más.

Saludos.

Confusiones

Hace un par de días, leía en el blog de Enrique Dans que al parecer, Microsoft ha proporcionado a más de 2,000 policias en 15 paises un pequeño dispositivo USB llamado COFEE (Computer Online Forensic Evidence Extractor) que contiene unas 150 herramientas, y que conectado a un equipo Windows en funcionamiento permite obtener fácil y rápidamente datos para un análisis forense: datos de actividad en Internet, registros, y contraseñas y datos cifrados con BitLocker, el programa de cifrado de Windows Vista (entiendo que obtendrá datos y contraseñas residentes en memoria volátil sin cifrar, aunque Internautas afirme sin más que “permite a los investigadores acceder a todos los documentos, incluso aunque hayan sido cifrados”).

Esto ha levantado al parecer un pequeño revuelo en Internet, y aunque no es mi estilo, he de afirmar que la ignorancia es muy atrevida. Personalmente, no soy ni amigo íntimo ni enemigo acérrimo de Microsoft; tiene sus cosas buenas, y sus cosas malas, básicamente como cualquier gran empresa; aquello de Don´t be evil pasó a la historia. Pero esta me parece, al contrario de lo que muchos opinan, una buena noticia, por mucho que algunos se hayan llevado las manos a la cabeza y hayan puesto el grito en el cielo invocado las libertades civiles.

No me extenderé demasiado porque este es un tema que me parece obvio. El dispositivo proporcionado es una herramienta de análisis forense para un sistema (Windows) que resulta opaco en muchos sentidos, y más para personal policial no siempre especializado en delitos tecnológicos. No es, por supuesto, una puerta trasera que pueda ser utilizada indiscriminadamente sin conocimiento del usuario. Tampoco permite hacer cosas que no se puedan hacer en otros sistemas, simplemente las aglutina y las facilita. Es simplemente algo que, utilizado bajo una orden judicial y presencialmente, permite obtener información del sistema rápida y sistemáticamente; como utilizar una cámara de fotos en el lugar de un asesinato, antes de que limpien la sangre.

Nada más y nada menos. ¿Ustedes qué opinan?

[Fuentes originales en NYT y Seattle Times]

Sistemas SCADA

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