La ralentización que provocan Meltdown y Spectre

Recientemente han aparecido dos vulnerabilidades de seguridad, estas afectan al hardware, no al software, y son muy graves, pues incluso su solución dejará secuelas. Meltdown afecta a todas las CPU de Intel y a algunos modelos de ARM, mientras que Spectre afecta a todos, también a los chips de AMD. Por lo tanto, prácticamente cualquier dispositivo equipado con un microprocesador moderno resulta afectado, desde móviles hasta servidores.

Meltdown

Ya le han hecho logotipo.

Las CPU modernas – o no tanto, pues ya hace unos años de esto – usan técnicas que aprovechan el paralelismo para acelerar la velocidad de procesamiento, una de ellas es la ejecución especulativa. El siguiente pseudocódigo permitirá un sencillo ejemplo de su funcionamiento:

si func1() = func2() entonces
   imprime func3()
fin si

En una arquitectura clásica, primero se ejecutaría la función 1, luego la 2 (o viceversa, depende del lenguaje) para, finalmente, si ambas dan el mismo resultado (este es el “peor” de los casos), ejecutarse la tercera. Su tiempo total equivaldría al de las tres funciones; pero gracias a la ejecución especulativa, la función 3 se calcula mientras se calculan la 1 y la 2, que también pueden paralelizarse, con lo que el tiempo total se reduce al de la función más lenta. Nótese que, si por ejemplo existiera alguna variable global que la función 3 consulta y que puede ser modificada por la 1 o la 2, esta paralelización no podría hacerse, con esta dificultad podemos imaginarnos lo compleja que resulta esta tecnología.

Esta es posible gracias a la duplicidad de las puertas lógicas en las CPU modernas y a la zona de memoria caché que, siguiendo el ejemplo, permite almacenar el resultado de la función 3 en espera de las dos anteriores. En lo que se refiere a la gestión de la memoria RAM, por razones de seguridad, tanto a nivel del microprocesador como a nivel del sistema operativo, existen medidas para evitar que un proceso pueda leer posiciones de memoria pertenecientes a otro. Gracias a ellas, cada proceso puede acceder sólo a la memoria que le ha asignado el kernel; en caso de necesitar más, le concederá más páginas, mientras que por otro lado libera las que dejen de usar otros procesos.

Pues bien, la vulnerabilidad está en el control de acceso a la memoria caché: la información ahí alojada temporalmente por la ejecución especulativa de un proceso, sería accesible por otro, mediante un hipotético exploit. Es decir, procesos que se ejecutan en ring-3 podrían acceder a información sólo disponible en ring-0, algo que debe ser posible sólo para el kernel del sistema operativo.

Spectre

Spectre también. ¡Que cuco!

Hasta donde yo sé1, todavía no ha sido publicado ningún exploit que aproveche completamente las posibilidades que otorga este fallo, pero al ser estas enormes, se está trabajando (me imagino que a destajo) desde hace días en su solución. Como el error es a nivel físico, en el hardware, y ni Intel ni ningún otro fabricante de micropocesadores va a reponer los chips afectados2, se arreglará a nivel de software, parcheando los sistemas operativos, todos, se implementarán en el kernel controles de seguridad más estrictos, y estos van a ralentizar el funcionamiento de los programas.

Putin Melting down

¿Todavía no tenemos ningún exploit, verdad?

Esta es precisamente la secuela comentada al principio del artículo; según una estimación inicial, una vez instaladas las actualizaciones, los procesos serán entre un 5% y un 30% más lentos. Aparentemente, cuantas más llamadas haga el proceso al sistema operativo (cualquier acceso a disco, red, etc.) más se verá afectado. Mientras que, por ejemplo, un proceso que hace uso intensivo de la CPU para cálculos apenas se verá afectado, programas como los sistemas gestores de bases de datos (MySQL, Oracle, SQLServer, etc.) o los servidores web lo notarán bastante más. Sin embargo, cabe esperar que progresivamente se vaya optimizando la solución, pero está por ver hasta que punto.

Probablemente, a quien más afecta este fallo de seguridad es a los centros de datos, pues para un atacante es más jugoso poder acceder a la información de miles (o de millones) de usuarios, que colgar en una web un código Javascript malicioso que pueda acceder a los datos de los procesos en ejecución de nuestro ordenador personal o de nuestro móvil. Paradójicamante, también es a ellos a quienes más va a perjudicar la solución al ser los mayores consumidores de tiempo de CPU. A medida que vayan actualizándose las máquinas, es factible que notemos como se ralentizan las webs y diferentes servicios en la nube.

Por supuesto, los fabricantes de microprocesadores también se verán afectados, especialmente Intel, cuyas CPU son vulnerables a ambos fallos. Si finalmente deben modificar el funcionamiento de la ejecución especulativa, todas las existencias almacenadas ya no sirven, las líneas de producción también deberán ser modificadas, etc. En definitiva, pérdidas millonarias en todo el sector. Está por ver en qué queda todo.


1 Si bien yo no me actualizo diariamente sobre seguridad informática, lo que sé acerca de este tema principalmente me interesa desde el punto de vista del desarrollo de software.
2 A diferencia de la industria automovilística, que sí responde.

Editado el 10/1/2018:

Anoche, en una actualización que aparentaba ser cotidiana del Ubuntu 16.04 que tengo en mi ordenador de sobremesa, se instaló el kernel 4.4.0-108; al reiniciar el sistema, el fallo fue estrepitoso y tuve que purgar esta versión para regresar a la 4.4.0-104. El objetivo de esta actualización del kernel era solucionar la vulnerabilidad Meltdown; cuyas consecuencias, por cierto, siguen sorprendiendo, pues rara vez fallan estas actualizaciones.


Editado el 12/1/2018:

  • Ya existe una prueba de concepto para Meltodown, se encuentra en este repositorio de Github.
  • En cuanto a la actualización del kernel de Ubuntu, parece ser que la versión 109 funciona correctamente y soluciona la vulnerabilidad.

Contraseñas seguras y fáciles de recordar

La identificación correcta y segura de usuarios sigue siendo uno de los dolores de cabeza de la seguridad informática: pasan las décadas (que en informática son eones) y sigue sin haberse generalizado una solución mejor que la identificación mediante usuario y contraseña. Para nosotros, los humanos, es difícil recordar contraseñas y aún más disponer de una contraseña diferente para cada sitio. Los ordenadores tampoco nos están ayudando: los avances en el hardware han convertido en inseguras contraseñas que previamente no lo eran, lo que nos obliga a tener que recordar unas claves cada vez más largas y con alternancia de letras, números y signos. Algunos expertos proponen soluciones que dejan atrás la identificación mediante usuario y contraseña; mientras estas no se generalicen, expongo una solución que ayude a mitigar el problema.

Cuando introducimos la contraseña, la aplicación le aplica una función de hash o de cifrado simétrico y compara el resultado con el dato almacenado para el usuario: sólo si ambas cadenas de texto coinciden el usuario será validado. La razón de este proceder es que, por razones de seguridad, las contraseñas nunca se almacenan en forma de texto plano en el servidor; pues si un intruso logra acceder a la base de datos, ya no tiene ningún impedimento para acceder a las contraseñas de todos los usuarios.

Consulta Usuario Contraseña

Consulta SQL de usuario y contraseña que muestra cómo se almacenan las contrseñas

En un mundo teórico e ideal, se usaría una función de cifrado, pues ésta garantiza que sin la clave no se puede invertir, es decir, no se puede obtener el original a partir del texto cifrado. La contrapartida es que estas funciones consumen bastante CPU comparadas con ciertas funciones de hash. Esto no se notaría en una pequeña aplicación, pero cuando hay cientos de miles de usuarios validándose cada día, el consumo de tiempo de CPU puede impedir un tiempo de respuesta óptimo de ésta. Como “solución”, lo habitual es emplear una función de hash, pues estas, generalmente, requieren menos cálculos. Ahora bien, éstas fueron creadas para usos diferentes al de la seguridad, por lo que la seguridad de las contraseñas se ve comprometida.

Aunque pueda parecer extraño, es la proliferación de las Unidades de Proceso Gráfico (GPU) lo que ha comprometido tanto la seguridad de las funciones de hash. Estos coprocesadores son el corazón de las tarjetas gráficas y están especializados en cálculos para gráficos 3D; es gracias a ellos que los videojuegos pueden calcular millones de triángulos por segundo, con sus texturas, etc. A día de hoy, tienen otras aplicaciones más oscuras, por ejemplo ataques de fuerza bruta1 contra hashes, y para hacer peor las cosas, con algoritmos especializados en aprovecharlas.

Otro debilitamiento viene dado por las vulnerabilidades descubiertas en los algoritmos de hash más utilizados. En primer lugar, la más grave afecta al veterano (1991) md5, aunque ya hace casi 13 años de su descubrimiento, a día de hoy se sigue usando para cifrar contraseñas pues algunos desarrolladores todavía desconocen que ha quedado descartada para la seguridad. En segundo lugar, a SHA-1 también le ha caído la suya, a pesar de que haber sido creado por la agencia nacional de seguridad estadounidense NSA. De todas formas, no olvidemos que estos algoritmos se crearon con objetivos diferentes al cifrado: la comprobación de la integridad de los datos y la firma de digital, por lo que no pidamos peras al olmo.

Algunos datos bastarán para que el lector se haga una idea de lo delicado de la situación: Un ordenador normal de sobremesa equipado con dos tarjetas gráficas ATI Raedon 7970, trabajando con contraseñas limitadas a los caracteres de un teclado inglés, números incluidos y con distinción de mayúsculas y minúsculas, puede generar en 45 minutos los hashes md5 de todas las contraseñas posibles de 6 caracteres, las de 7 en una hora y 47 minutos y en 465 días la de 8 caracteres. Limitando los caracteres sólo a las letras (con distinción de mayúsculas y minúsculas) y los números, como sucede con las contraseñas más habituales, para 6 caracteres sólo hacen falta 3 segundos,  4 minutos para 7 caracteres, 4 horas para 8 y 10 días para 9 caracteres. He aquí una tabla con resultados para otros algoritmos donde se puede observar que, si bien obtienen mejores resultados, no son lo suficiente, pues no olvidemos que se pueden poner muchas tarjetas a trabajar en paralelo y, además, la nube no solo proporciona soluciones de almacenamiento, sino también de cálculo para procesos intensivos.

gpu rig

Tarjetas gráficas trabajando en paralelo: Esto no sólo es el paraíso gamer.

Estos ataques se vuelven mucho más dañinos si, en vez de generar las claves con caracteres al azar, hasta probar todas las combinaciones posibles de n caracteres, para después pasar a las de n + 1, se emplea un diccionario formado por miles de contraseñas habituales. Las combinaciones fácilmente se pueden ampliar añadiendo caracteres a las palabras del diccionario: se pueden añadir, por ejemplo, las cadenas “1”, “12”, “123”, etc. a todas las palabras, de manera que si el diccionario contiene la palabra “boby”, es factible que el usuario dueño de un perro con este nombre lo pase mal. Estos ataques son menos brutos y resultan mucho más eficientes que ir probando todas las combinaciones posibles de caracteres. En definitiva, contraseñas como “1a2N567mJ” o “andres123” resultan tan solo un poco mejores que la célebre y más usada de todas: “123456“.

El programador que esté leyendo esto, podría pensar que estos cálculos son demasiado pesimistas y que no afectan a su software porque usa una salt (también conocida como semilla). Esta es una cadena de texto que se concatena a la contraseña del usuario antes de aplicar la función de hash, tanto cuando se va a almacenar en la base de datos como en el proceso de validación. La debilidad de este sistema consiste en que un atacante que ha logrado comprometer la seguridad de la base de datos, muy probablemente también habrá accedido al código fuente de la aplicación y, por lo tanto, conocerá la semilla, por lo que la privacidad de los usuarios volverá a depender exclusivamente de la fortaleza de su contraseña. Ahora bien, si se genera aleatoriamente una salt por cada contraseña, entonces sí que un ataque por fuerza bruta puede ser inviable.

<?php
hash("sha1", "Talvez este salt mejora la seguridad, o no..." . $password);

Para proteger a los usuarios de esta nueva realidad se les sugiere – y a veces se les obliga – que sus contraseñas estén formadas por minúsculas, mayúsculas, números y signos de puntuación y que además tengan una extensión mínima, ésta última en aumento a medida que avanza el hardware. El gran problema de estas contraseñas es que son difíciles de recordar; si además se le añade la recomendación de tener una diferente por cada sitio, para evitar que si un atacante logra obtener la de uno pueda acceder a todos los demás, la misión de recordarlas todas es un sobresfuerzo. En la misma línea de reforzar la seguridad, van las recomendaciones de no guardar las contraseñas en ningún sitio y renovarlas periódicamente. Ejemplos de contraseñas seguras son:

  • o{0Or.-49q]gMt-
  • Pr&)6gm1$_dvfZ9

Los usuarios necesitan de la informática que les facilite la vida y les abra nuevas posibilidades, no que les añada más problemas, pero hay una solución. Los humanos, a diferencia de los ordenadores, somos realmente malos memorizando estas cadenas de texto. Esto es debido a que carecen de significado, nosotros asociamos ideas, conceptos, mientras que para un ordenador la semántica es irrelevante: no sabe de información, “sólo” maneja datos (pero en una cantidad y una velocidad a años luz de nuestra capacidad). Entonces, trabajemos como nos resulta cómodo a nosotros y hagámoselo difícil a los malos. A continuación algunas contraseñas tan seguras como las anteriores, o más, y mucho más fáciles de recordar:

  • En un lugar de la Mancha,
  • ¡Cuatro días con sus noches!
  • A ver cuándo vuelven a robarles todos los datos de sus usuarios…

La idea es que la frase tenga cierta relación con el sitio web al que da acceso. Así, por ejemplo, la última es especialmente fácil de recordar como contraseña para Yahoo. En todo caso, si nuestra memoria no es muy buena, tener escrito en algún lugar “seguro”, un listado con los sitios web y por cada uno la idea asociada para recordar la frase, es más fiable que escribir directamente las contraseñas. Si además, en las frases se incluyen letras y signos propios de nuestro idioma, que no están en los 128 caracteres de la tabla ASCII (los americanos no pensaron en nuestro idioma), les estamos poniendo las cosas realmente difíciles a los malvados, pues los diccionarios están generalmente orientados a la esfera anglosajona.

Desafortunadamente, no se puede aplicar esta solución a todos los sitios web, pues algunos no aceptan el espacio como carácter válido en la contraseña u obligan a usar al menos un número. Si la norma obliga a usar algún signo no es problema pues una frase fácil de recordar sigue siéndolo aunque se le añada puntuación. En mi opinión, estas normas en las contraseñas de los usuarios son una mala idea, pero lamentablemente algunos sitios, una minoría, las tienen.

Los sistemas alternativos a las contraseñas consistentes en guardar bio datos presentan problemas de privacidad: en la identificación facial o de retina, por ejemplo, el almacenamiento de estos datos permitiría, a quien disponga de ellos, la identificación de ciudadanos en cualquier sitio donde se les haya grabado. Sin llegar a estos extremos, que a día de hoy todavía pueden parecer un poco de ciencia ficción (aunque cada vez menos), actualmente ya disponemos de la verificación en dos pasos para reforzar la validación de usuarios. Este sistema es, además, compatible con la solución aquí expuesta, pues generalmente el primer paso consiste en la introducción de la contraseña.

En conclusión, mientras no se halle una solución al problema que la informática lleva arrastrando desde que, en sus albores, uno de sus primeros sistemas necesitó que un usuario se validara, vamos a seguir usando contraseñas. Una clave que hace 10 años todavía era segura, ya no lo es. Para evitar el infierno de tener que recordar un número de contraseñas creciente, de una extensión, a la vez, también creciente, espero que la idea que aquí expongo, y que salió del blog de un empleado de Microsoft, se siga expandiendo, porque la seguridad y la privacidad no es tema baladí.


1 Estos ataques consisten en generar contraseñas, aplicando a cada una la función de hash para, finalmente, comprobar si algún registro de la tabla coincide con el resultado. Obviamente, el atacante debe haber podido acceder a la tabla de la base de datos donde se almacenan los usuarios.

Editado el 9/1/2018:

A modo de ejemplo de los riesgos que para la privacidad tiene el almacenamiento de bio datos, sirva esta noticia que informa acerca de las continuas filtraciones que sufre el sistema con más datos biométricos almacenados en el mundo. Por menos de 10 dólares se puede obtener información de una base de datos formada por más de mil millones de usuarios.

Cómo funciona la firma digital

Acaba de pasar la campaña de la declaración de la renta de este año y millones de españoles la hemos realizado telemáticamente, por lo tanto hemos firmado digitalmente nuestra declaración; pero no por habitual es conocido por todos para qué sirve y cómo funciona la firma digital.

Antes de dar respuesta a estas preguntas no está de más decir que muchas veces decimos “firma electrónica” para referirnos a la digital cuando ésta es un concepto jurídico. La firma electrónica son unos datos que acompaña la información e identifican al emisor firmante. Podría incluso ser una imagen que contiene nuestra firma de puño y letra escaneada, otro tema sería la nula seguridad y validez legal de dicho método. Los países en cuya jurisdicción existe la firma electrónica, sólo otorgan a una firma digital segura la equivalencia funcional de una firma manuscrita.

El objetivo de la firma digital es garantizar que en el envío del emisor al receptor el documento no ha sufrido ninguna alteración. Para lograrlo utiliza la criptografía asimétrica que, a diferencia de la simétrica que sólo usa una clave para el cifrado, utiliza dos claves llamadas pública y privada. La administración española sólo reconoce a las autoridades de certificación como emisores válidos de claves.

Veamos ahora el funcionamiento. Generalmente se habla de documentos, pero realmente lo enviado y firmado puede ser cualquier tipo de archivo: desde una imagen a un ejecutable. Sobre el fichero a firmar en primer lugar se aplica una función de hash, una de calidad, un algoritmo md5 no sirve. Sobre la cadena que devuelve la función de hash se aplica el algoritmo de criptografía asimétrica que mediante la clave privada cifrará la cadena. El resultado es la firma digital.

Firma Digital

Esquema del funcionamiento de la firma digital

Para que el receptor pueda confirmar que el documento no ha sido modificado desde que lo firmó el emisor, debe en primer lugar descifrar la firma digital para después aplicar la misma función de hash sobre el documento enviado, si ambos resultados coinciden el documento es el original, si por el contrario no coinciden el documento ha sido alterado. Para descifrar el receptor no usa la clave privada sino la pública del emisor, esta es la gracia de la criptografía simétrica.

Una versión menos segura de este sistema sería usando un sistema de cifrado simétrico, donde sólo existe una clave. La debilidad de este sistema es que emisor y destinatario deben ponerse de acuerdo en cuál será la clave e intercambiarla de modo seguro. Para solucionar esto nació la criptografía simétrica.

Hay que tener en cuenta que gracias a la firma digital:

  • Sabemos que el documento no ha sufrido modificación desde que fue enviado.
  • El emisor no puede negar lo enviado.

Pero por si misma no puede garantizar la privacidad de la comunicación, es decir, que alguien entre emisor y receptor haya tenido acceso al documento.

La CIA hackea Notepad++

Notepad ++

Esta cara le quedó cuando se enteró.

En la última actualización rutinaria del extendidísimo editor Notepad++ miro de reojo el log de bugs arreglados y mejoras y me encuentro el siguiente fix:

1.  Fix CIA Hacking Notepad++ issue (https://wikileaks.org/ciav7p1/cms/page_26968090.html).

Aparentemente, el inocente e inofensivo Notepad++, forma parte de las herramientas hackeadas por la CIA.

Juego para aprender acerca de los ataques XSS

Juego XSS

Página de presentación

XSS son las iniciales de Cross-Site Scripting. Se trata de una vulnerabilidad que puede tener una aplicación web y que explotada permite a un atacante inyectar código del lado cliente, generalmente Javascript, en la misma. Con ese código el atacante pretende conseguir varios objetivos ilícitos. El más peligroso de ellos sería hacerse con la sesión del usuario en el sitio.

Esto sólo es posible si la aplicación no transforma adecuadamente los datos que los usuarios pueden introducir o no los sanea antes de volverlos a mostrar. El programador debe decidirse por una de las dos opciones en función del tipo de datos que espera, pues según qué datos podrían verse alterados si se sanea la entrada.

Que una aplicación tenga en un punto, o en varios, esta vulnerabilidad pues ser debido a razones como:

  • El programador no sabe proteger su aplicación de estos ataques.
  • Fecha de entrega del producto demasiado ajustada o cambios de última hora.
  • Cambios sobre cambios que agotan la energía del programador.

Sobre aspectos como los factores humanos o funcionamiento de la empresa poco puede hacer el programador pero sobre el primer punto llega Google al rescate. Esta empresa ha sacado un juego, más orientado a desarrolladores que a crackers, para que aprendan acerca de las diferentes técnicas que los malos tienen a su disposición. El juego se presenta en forma de niveles y es bastante instructivo. Aquí tienes el enlace si quieres jugar.

Esto no es por amor al arte. Los de Mountain View pagarán hasta 7500$ a quien encuentre y reporte una vulnerabilidad de este tipo en cualquier aplicación de Google.