Mega, un servicio no tan seguro

Por Arturo Quirantes, el 28 enero, 2013. Categoría(s): Tecnología

Les imagino al tanto del último invento de Kim Dotcom. Después de que el FBI tirase abajo su invento Megaupload, ahora vuelve a aparecer con un esquema llamado Mega, diseñado para que puedas almacenar películas piratas, pero claro, ellos no saben nada y nosotros tampoco. La idea es que tengas un espacio “en la nube” para guardar tus archivos de forma protegida. Me recuerda a aquellos paquetes de uva prensada que se vendían en EEUU durante la prohibición con el aviso de “no meta usted este paquete en un barril, ni le añada agua y azúcar, ni lo deje fermentar en lugar seco y fresco durante quince días, porque entonces obtendría usted una bebida alcohólica, y eso es ilegal.”

Cualquiera que sea el uso que hagan los usuarios de Mega, nos proporciona una buena oportunidad de ver cómo se puede garantizar la seguridad de eso que llaman la Nube. En el caso que nos ocupa, la idea es que el cliente se encargue del proceso de creación de claves, algo que supuestamente beneficia a ambas partes: el usuario controla sus claves y Mega se lava las manos en caso de uso fraudulentos de su servicio.

Si no lo he entendido mal, todo se lleva a cabo desde el propio navegador del usuario gracias a un paquete en JavaScript que se descarga desde los servidores de Mega. Al registrarse en el servicio, el usuario introduce su nombre, dirección de email y contraseña. Después de recibir un email para confirmación haciendo clic en el enlace correspondiente, su navegador crea una pareja de claves asimétricas RSA. Es decir, utiliza el sistema de criptografía de clave pública, que usa dos claves distintas para cifrar y para descifrar. La clave de cifrado es pública (cualquiera puede conocerla y usarla para cifrar archivos), pero la clave de descifrado es secreta y conocida únicamente por el usuario.

La contraseña que ha creado el usuario sirve dos propósitos: autenticarnos frente al servicio (es decir, convencer a Mega de que yo soy yo y no otro yo), y cifrar los datos gracias a la clave maestra, que servirá para activar un algoritmo de cifra AES, considerado muy seguro. La seguridad del sistema se basa en una jerarquía de claves. Si lo que dicen los chicos de Linuxnoveles es correcto, el proceso de subida de archivos es semejante a esto:

1) Generamos una clave de 128 bits para ese archivo (llamémosle Ks)

2) Ciframos el archivo con esa clave

3) Generamos otra clave para enviar el archivo (sea Ke), imagino que con nuestra clave asimétrica RSA

4) Enviamos el archivo y su clave Ks, todo protegido con la clave Ke

5) Mega guardará tu archivo y tu clave Ks

Por supuesto, en el paso 5) no se puede almacenar Ks así por las buenas. Se supone que es secreta, así que la clave ha de ser asimismo cifrada. Qué cosas, cifrar una clave de cifrado ¿no? Pero así es más seguro, así que lo que se hace es cifrar Ks con la clave maestra del usuario. Es decir, esa clave maestra cifra la clave que descifra el archivo.

Puede que al lector le parezca raro tanta clave que cifra otra clave, que protege otra clave, que … No se preocupe, esta estrategia de “cifrado por capas” es muy habitual, ya que cada clave sirve a un propósito distinto. Usted lo hace en casa: la llave de entrada a su casa permite abrir la puerta y entrar para introducir el PIN que desconecta la alarma, y luego necesita la combinación para poder abrir la caja fuerte, que puede que contenga el PIN de su móvil, etcétera. Haciéndolo bien, el sistema puede hacerse muy seguro.

El problema con el esquema de Mega es que se han descubierto diversas vulnerabilidades, algunas de ellas triviales. Voy a intentar explicárselas de la forma más sencilla posible, y solamente me centraré en las que tengan componentes criptográficos. Sé que hay muchos otros fallos (en JavaScript, en SSL… ), pero no voy a entrar en ellos y se los dejo al lector como ejercicio.

La generación de claves asimétricas

Esa clave RSA de 2048 bits sirve varios propósitos, como el de enviar las claves de los archivos. Ahora bien, en el proceso de creación de las claves es necesario un conjunto de datos aleatorios, pero los ordenadores son muy malos generando aleatoriedad. El servicio Mega utiliza un generador de números llamado Math.random(), pero no es un generador aleatorio sino pseudoaleatorio; es decir, parece que genera azar pero es sólo aparente.

Una forma adicional de generar azar (o, como dicen los entendidos, “entropía”) es que el usuario mueva el ratón o pulse teclas. Esa puede ser una buena fuente de azar, no perfecta pero buena. Sin embargo, cuando se genera la clave RSA el servicio Mega muestra un aviso que dice “para reforzar la clave, hemos recogido entropía de los movimientos del ratón y tecleos.” Hemos, en pasado. Normalmente, servicios similares dicen algo como “vamos a generar azar, por favor mueva usted el ratón un rato.” Pero Mega usa los movimientos anteriores. ¿Y si nos hemos pasado diez minutos en el baño antes de pulsar “generar clave” y el ratón ha estado quieto? ¿Y si tengo estropeado el ratón y estoy usando el teclado? ¿Y si nuestros dedos han pulsado teclas de forma ordenada? Mega debería pedir al autor que generase azar en ese momento, no decirlo a toro pasado.

La deduplicación

Este es uno de los apartados que ha generado mayor polémica. Mega se reserva el derecho de borrar un archivo si comprueba que es un duplicado exacto de otro archivo que ya esté en algún lugar de Mega, sea en la cuenta propia o en la de cualquier otro, aunque por supuesto permitirá al usuario acceder a ese archivo dondequiera que esté.  La idea es que, si hay doscientos usuarios que tienen una copia de la última peli de Star Trek, Mega no tenga que guardar 200 veces el mismo archivo. Lo que hace es borrar 199 de esas copias y darle acceso a los 200 usuarios a la copia que queda.

El problema es que supuestamente ni siquiera Mega sabe qué es lo que estamos guardando. Los 200 clientes tienen cada uno de ellos una copia cifrada de la peli, y cada uno de ellos ha usado una clave diferente, así que ¿cómo sabe Mega que son todas la misma película? Incluso si Mega tiene una forma de conocer que hay 200 películas idénticas sin descifrarlas, el hecho es que sabe algo muy importante: que hay 200 películas idénticas. Y si a uno de los usuarios le cae un puro de la SGAE o la RIAA, ¿cuánto tardarán los otros 199 usuarios en poner sus barbas a remojar?  En suma, cualquier procedimiento de detectar archivos duplicados es una vulnerabilidad porque revela información acerca de dichos archivos.

En su web, Mega intenta aclarar este y otros conceptos. Afirman que la deduplicación se hace sobre los archivos cifrados, lo que implica que no pueden descifrarlos. Vale. Pero luego se queda a gusto afirmando:

Si el mismo archivo se sube dos veces, cifrado con la misma clave aleatoria de 128 bits, solamente se guarda una copia en el servidor

De acuerdo con eso. Pero díganme, genios de Mega: ¿cuál es la probabilidad de que dos usuarios distintos utilicen la misma clave aleatoria de 128 bits? Pues una entre 2^128. Y resulta que 2^128 es una cifra con 39 dígitos decimales. Es más probable acertar el gordo de la lotería primitiva seis veces seguidas (sin ser concejal de urbanismo). Menos mal que enseguida matizan:

O bien (¡y esto es mucho más probable!), [si] un archivo se copia a otra carpeta o a otra cuenta de usuario mediante el administrador de archivos o la API, todas las copias apuntarán al mismo archivo físico

Esto ya tiene más sentido. No en el primer caso, porque eso de almacenar varios archivos iguales es algo tonto; pero resulta que un usuario puede compartir un archivo con otros usuarios, y lo que hace la deduplicación es sencillamente darles acceso al mismo archivo en lugar de crear más copias.

Según parece, una medida adoptada con el sano propósito de ahorrar espacio de almacenamiento ha sido tan mal explicada que prácticamente se han disparado en el pie. Personalmente, no me gusta la forma de actuar en lo que respecta a archivos duplicados. Si mi colega me ha pasado una copia de una peli, prefiero que él tenga su copia y yo la mía. Entiendo que Mega no quiera malgastar espacio, pero yo tengo un espacio asignado, y la forma en que lo lleno es cosa mía.

El modo de encadenamiento

Los archivos cifrados se guardan según un esquema llamado ECB (Electronic Codebook Mode). No quiero enrollarme demasiado, y emplazo al lector interesado a que eche un vistazo a mi libro sobre criptografía, pero el cogollo del asunto es que un archivo grande M se cifra en bloques: M = (M1, M2, M3 … Mn). Existen diversas formas de efectuar el proceso de cifrado. La más sencilla, la ECB, consiste en cifrar cada uno de los bloques de forma independiente y luego unir todos los bloques cifrados obtenidos. Es decir, si Ek es nuestro algoritmo de cifrado, hemos hecho esto:

C = [C1, C2, … Cn] = [Ek(K1), Ek(M2) … Ek (Mn)]

 El modo ECB es sencillo y rápido, ya que el bloque cifrado Ci depende solamente del bloque en texto llano Mi. El problema es que permite a un atacante hábil hacer jugarretas. Por poner un ejemplo sencillo, supongamos que hablamos de películas. Yo cojo varias y las cifro con la misma clave. Si las películas son todas de la misma productora, tendrán los mismos fotogramas iniciales (los focos del logo de la 20th Century Fox, por ejemplo), y por lo tanto los primeros bloques cifrados serán iguales entre sí. De ese modo, un atacante podría obtener información sobre el tipo de película o su procedencia, lo que le vendría muy bien a los abogados de la Fox.

Hay otros tipos de encadenado de bloques que permiten evitar estos ataques, pero adolecen de sus propios problemas, como la propagación de errores. Mucho me temo que el único motivo por el que Mega escogió el modo ECB es por su rapidez. Muchos usuarios entenderán eso de “cifrado mediante AES de 128 bits,” pero pocos sabrán los entresijos de seguridad relativos a los diferentes modos de encadenado. De todos modos, los de Mega parecen reconocer implícitamente la vulnerabilidad del modo ECB, porque anunciaron “¡no usaremos ECB!”, con exclamación incluida.

Si pierde usted la contraseña, la pierde para siempre

Hay dos constantes en el uso de una contraseña por parte del usuario medio. Una: escogerá contraseñas débiles en gran número de casos. Dos: tarde o temprano, se le olvidará. Este segundo problema es algo muy común. Sea por olvido o por cualquier otro motivo, llega el momento de cambiar la contraseña. Y no es una tontería, porque la contraseña desbloquea nuestras claves de cifrado. Sin ella, todo el contenido de nuestra cuenta de Mega es solamente un montón de bits. La propia Mega incide en la importancia de ese hecho: “la única clave que Mega exige que se almacene en el lado del usuario es la contraseña de login, en el cerebro del usuario

Los servicios de Internet suelen dar dos alternativas: o bien recuperar la contraseña mediante alguna verificación de identidad (las típicas preguntas del tipo “¿cuál era el nombre de su mascota?”), o bien crear una contraseña nueva. Incluso en caso de que toda vaya bien, cambiar de contraseña cada cierto tiempo es una buena política de seguridad.  Bien, pues ¿saben ustedes cuál es el procedimiento que usa Mega para cambiar o recuperar contraseñas? En una palabra: ninguno. Si a usted se le olvida su contraseña, AJO Y AGUA, jamás podrá recuperar sus archivos.

Lo triste es que no hay motivo técnico para que esto sea así. Mega ha reconocido el problema, y promete mejoras para el futuro, pero lanzar un servicio de almacenamiento sin la menor posibilidad de cambiar claves es como si Ford lanzase un nuevo modelo de vehículo al mercado y luego se olvidase de enviar repuestos a los concesionarios.

Mi clave es más grande que la tuya

En la actualidad, los expertos en seguridad recomiendan claves RSA con una longitud mínima de 2048 bits. Las claves de 1024 siguen siendo seguras en la actualidad, pero visto lo visto en el pasado, mejor ir a lo seguro. El servidor seguro SSL de Mega https://mega.co.nz utiliza cifrado de 2048 bits, pero también utiliza https://*.static.co.nz, con clave de 1024 bits. Mega afirma que lo hace para ahorrar tiempo de CPU. No es realmente un problema, pero la verdad es que 2048 bits hubieran dejado buen sabor de boca.

¿Fiarme yo?

Mega ha descargado gran parte de la seguridad en el usuario. Esto es, en parte una buena idea, pero también es malo. El motivo: el ordenador medio es más vulnerable que una caja de zapatos. El usuario medio (ese que, según House, es idiota) usa un ordenador cuyo sistema operativo es vulnerable frente a virus, troyanos y todo tipo de bichos malos. Incluso sistemas bien protegidos pueden ser presa fácil de fallos de programación recién descubiertos o no parcheados.

La idea de Mega es que el usuario se sienta protegido incluso frente a ellos mismos. Da igual si el personal de Mega está infiltrado hasta el tuétano por el FBI, porque nuestros archivos se almacenan cifrados, algo así como esos guadamuebles que salen en los programas de subastas de Energy.

Sin embargo, sí que tenemos que fiarnos de Mega. El programa en JavaScript para crear las claves en nuestro navegador lo han creado y enviado ellos. ¿Cómo podemos estar seguros de que alguien no lo ha sustituido por una copia con fallos? ¿Y si Mega intenta engañarnos con un JavaScript vulnerable? La propia Mega reconoce que el usuario puede no fiarse de ellos, y le aconseja que en ese caso acceda a su cuenta mediante otras aplicaciones que no sean su web segura. Pero acto seguido afirma que “cualquier fabricante de software que ofrezca actualizaciones online de aplicaciones puede plantar código troyano en ordenadores específicos, con graves consecuencias.” Es decir, nos están diciendo que ojito con lo que instalemos en nuestro ordenador.  Esto es algo conocido y no es un fallo específico de Mega; lo indico como recordatorio de que invocar cosas del tipo “AES y RSA-2048” no convierte un sistema en seguro por arte de magia. Esto es criptografía, no Harry Potter

Crackeando el sistema

Se ha informado de que existe un programa llamado Megacracker que permite recuperar la contraseña de algunos usuarios de Mega. Aunque esto se ha señalado como una constatación de la vulnerabilidad de Mega, no es totalmente cierto. Voy a intentar explicárselo de la forma más breve posible.

Cuando se intercambian contraseñas o se guardan en bases de datos, basta hacer una copia para tirar abajo la seguridad del sistema. En los últimos años se han robado bases de datos con millones de contraseñas de todo tipo de usuarios, desde Sony hasta la NASA. Para paliar el problema, no se utilizan las claves tal cual, sino que se las pasa por una función llamada hash. Ese valor de hash representa a la clave, pero no permite averiguar nada sobre ella.

Recuerda levemente a la letra del DNI. Si no quiero revelar mi número de DNI pero tengo que identificarme, basta con que el verificador me pregunte “¿cuál es su letra del DNI’? Yo le digo cuál es, él comprueba si es la correcta y listo. El problema es que hay solamente 26 letras disponibles, así que la función que calcula la letra a partir del número del DNI no sirve como función hash, pero esa es la idea.

Eso significa que tomo mi contraseña, digamos que es 1234, la paso por la función hash y obtengo la ristra ue8gd18g2. Envío ue8gd18g2 y el servicio online verifica si hay un usuario con mi nombre cuya contraseña tiene un hash igual. Si es así, ya estoy verificado; en caso contrario, puerta. La ventaja de este procedimiento es que el servicio online ni siquiera necesita saber mi contraseña, le basta con el hash.

El problema es que, en ciertas circunstancias, ni siquiera el hash es completamente seguro. En teoría, no hay forma de obtener la contraseña a partir de su valor hash, pero en la práctica, y aquí está el detalle, los usuarios suelen escoger contraseñas débiles. Un atacante no tiene más que probar muchas contraseñas, calcular el hash de cada una de ellas y ver si coincide con el hash de la mía. Mi amigo el atacante toma 1234 y lo pasa por la función hash, obtiene ue8gd18g2, y luego ve que yo tengo un hash igual a ue8gd18g2. La conclusión es evidente: ese usuario está usando 1234 como contraseña. El proceso es automático. Hay programas que permiten efectuar miles de estas comprobaciones por segundo; y si usamos tablas ya precomputadas, esos miles se pueden convertir en millones.

La máxima de Schiller de “contra la estupidez, los propios dioses luchan en vano” es el eslogan no oficial de todos los BOFHs del mundo. Cada vez que un usuario escoge una contraseña fácil (y el término “fácil” es muy amplio, se lo aseguro), no hay más que coger el hash correspondiente y listo. Pero la idea de la función hash no es mala; es excelente, y si se utiliza bien resulta un arma extraordinaria contra los atacantes.

Como en otros casos similares, el diablo está en los detalles. Implementar una defensa basada en funciones hash es buena idea, pero sólo a condición de que se cumplan ciertas precauciones. Veamos si Mega aprueba o falla.

Precaución uno: use sal.

El término “sal” alude a un pequeño paquete de datos que se añade a la contraseña antes de calcular su valor de hash. El resultado es mayor seguridad, ya que los valores hash H(1234) y H(1234+sal) son totalmente distintos. Los ataques tipo “tabla arcoíris,” en los que se usan montones de valores hash precalculados, se vuelven ineficaces. Incluso conociendo el valor de la sal, el atacante necesitaría calcular montones de valores hash para dar con la contraseña adecuada; y puesto que la “sal” es aleatoria y cada usuario tiene un valor distinto, los métodos actuales de comprobación en grandes cantidades se vuelven inútiles.  Bien, la pregunta es ¿usa Mega algún tipo de sal? No encuentro información al respecto, pero el programa Megacracker no dice que use sal en absoluto, y de hecho dudo que pudiese funcionar si hubiese sal en el sistema hash que usa Mega. A falta de confirmación, mi conjetura es que Mega no usa sal. FAIL

Precaución dos: use una función hash lenta.

Sí, han leído bien. Habitualmente se suelen buscar funciones criptográficas rápidas y eficientes, pero recientemente se prefiere justo lo contrario en el campo de las funciones hash. La razón es sencilla: puesto que hay programas capaces de calcular gran número de funciones hash, cuanto más lento de calcular sea el hash, tanto más difícil lo tendrá un atacante. Es como un cajero automático donde se puedan introducir todos los PIN posibles, sean correctos o no. Un ladrón de dedos ágiles podrá probar las 10.000 combinaciones en principio, pero si el cajero tarda cinco segundos en procesar cada intento, el ladrón necesitará demasiado tiempo. Hay funciones hash lo bastante lentas para dificultad el trabajo del atacante. Mega no utiliza ninguna de ellas, sino que se basa en el algoritmo rápido de cifrado AES. Mala elección. FAIL.

Peor aún, lo que implementa Mega ni siquiera es una función hash, sino un bicho llamado CBC-MAC. Resulta que un MAC es un Código de Autenticación de Mensajes, diseñado básicamente para comprobar si un mensaje ha sido alterado (sea por ataque deliberado o por errores en la transmisión). Un CBC-MAC tiene ciertas aplicaciones en criptografía, pero no es una función hash adecuada porque el mensaje original puede alterarse sin que el MAC lo detecte. DOBLE FAIL.

Condición tres: no le enseñes el hash a desconocidos.

Si has metido la pata con tu función hash, lo menos que se te puede pedir es que mantengas el valor hash de tu contraseña lo más oculto posible. Darle al enemigo el valor hash, sobre todo si se trata de una función inadecuada, rápida y no usas sal, es buscarte problemas. Sin embargo, ¡eso es precisamente lo que hace Mega! Cuando envía el email de confirmación, incluye el típico enlace en el que hay que pulsar. La dirección del enlace incluye, entre otros datos, el hash de la contraseña del usuario. Es decir, si seguimos con el ejemplo anterior, donde teníamos H(1234)= ue8gd18g2, lo que estamos haciendo es darle ue8gd18g2 al enemigo; bueno, al enemigo y a cualquiera que esté mirando. Sabiendo el valor de hash, el tipo de función hash usada, y encima sabiendo que no hay sal por medio, más te vale no haber escogido una contraseña débil. Y eso es precisamente lo que aprovecha Megacrack. FAIL.

Estrictamente hablando, este fallo es también atribuible a todos aquellos usuarios que piensan que 1234 o el nombre del perro son buenas contraseñas. Sobre Megacrack, el comentario de Mega es sucinto y hasta cierto punto sarcástico: “un excelente recordatorio de que no hay que usar contraseñas de diccionario o fáciles de adivinar, sobre todo si la contraseña también sirve como clave de cifrado maestra para todos los archivos almacenados en Mega”  El problema es que cualquier servicio online ya debe contar con que el usuario medio es cortito, y habilitar todas las defensas posibles. Implementar métodos de hash tan inseguros como los de Mega es lo mismo que decir en voz alta “sí, el cliente es idiota, y nosotros también.”

Consideraciones prácticas

Yo, debo reconocerlo, no soy amigo de la Nube. He perdido demasiados artículos en la Red, confiando en que la web duraría eternamente, para aprender que, si no quieres perder archivos, lo mejor es guardarlos en casa; y si quieres mantenerlos protegidos, más aún. Por supuesto, no se molesten en contarme los mil y un casos en que sería útil tener archivos a disposición en cualquier lugar en que me conecte, porque eso ya lo sé. Acepto que la Nube tiene sus ventajas. Lo que no entiendo muy bien es la ventaja de usar Nube cifrada para las aplicaciones a que están destinado Mega.

No nos engañemos, ese servicio está diseñado para subir, compartir y bajar películas y demás archivos grandes de procedencia digamos dudosa. Con independencia de las consideraciones éticas, morales y legales de este proceder, piense usted un poco. Mega, al igual que Megaupload, reside en Nueva Zelanda, y por los mismos motivos. No es por los preciosos paisajes que todos conocemos desde que vimos la trilogía del Señor de los Anillos en el cine, ni siquiera porque allí vive la reina geek de Naukas, sino porque allí el FBI no puede encarcelar al amigo Kim Dotcom. Es decir, motivos legales que les interesan a ellos, no a nosotros.

Cada vez que quiera usted bajarse una película de su cuenta, los datos tendrán que recorrer decenas de miles de kilómetros y llegar hasta su ordenador, en el otro punto del globo, a la velocidad que le deje su proveedor de ADSL. Incluso con una velocidad de 20 megabits por segundo (que ya es mucho), mi copia de Star Trek tardaría más de diez minutos en bajar, y yo solamente he tenido conexión a esa velocidad en el mismo lugar donde me doy el lote con Scarlett Johansson, es decir, en sueños. Luego hay que descifrar la película. Y si quiero subirla, todos sabemos que la velocidad de subida es mucho menor (la A de ADSL significa Asimétrico). Tendré suerte si consigo colgarla en mi cuenta en menos de una hora. Eso para cada película que quiera mover. La verdad, no le veo ventaja frente un bittorrent. Es cierto que bajar algo mediante eMule o utorrent tarda más, pero cuando tienes el archivo en tu ordenador, ya no dependes de una conexión ADSL o de un servicio que hoy es gratis, mañana será de pago y el próximo día puede no existir. Como un tal Megaupload, por ejemplo.

Personalmente, coincido con otros autores en que el sistema de seguridad de Mega no está diseñado para proteger al cliente sino para proteger a Mega. Han intentado crear una especie de guardamuebles anónimo, donde el conserje mira para otro lado sin querer saber lo que los clientes guardan en el interior, y donde nadie más que el usuario tiene llaves de la puerta. De esa forma, cuando lleguen los hombres G, podrán encogerse de hombros y pretender que ellos no sabían nada. El problema es que sus candados son débiles y las puertas tienen fallos, así que si usted quiere proteger sus datos, le recomiendo que no los suba a Mega. Allí solamente una cosa es segura: que el amigo Dotcom va a seguir forrándose vendiendo humo. En este caso, el humo de la seguridad aparente.



Por Arturo Quirantes, publicado el 28 enero, 2013
Categoría(s): Tecnología