Qué es ECB, y por qué Adobe hizo muy mal usándolo para cifrar contraseñas de usuarios

Adobe y ECB

Recientemente la empresa Adobe sufrió uno de los mayores robos de contraseñas de la historia. Los números que se citan cifran el número de contraseñas robadas en 130-150 millones. La buena noticia es que las contraseñas estaban protegidas; la mala, que la protección es una birria.

No debería ser así. En principio, las grandes empresas no guardan las contraseñas de sus clientes en texto llano. En su lugar, las someten a lo que se llama una función hash. De esa forma, lo que el ladrón obtiene no es una contraseña C sino una función de esa contraseña F(C). Esa función no filtra información sobre el contenido, así que el ladrón no ha ganado nada. Para evitar la posibilidad de efectuar un ataque a gran escala (los llamados ataques con tablas Rainbow), la contraseña se une a un paquete de datos aleatorios llamado “sal.” El resultado es una protección casi total.

Problema: Adobe no usa funciones hash. Al contrario de lo que mencionó en un principio, las contraseñas estaban cifradas, no hasheadas. El algoritmo usado se llama TripleDES, que cuenta con una clave de 168 bits, y eso tampoco está nada mal. Una clave tan larga hace imposible probar todas las posibilidades, así que en teoría los usuarios deberían dormir tranquilos.

La pifia consistió en que Adobe usó TripleDES en una variante denominada “modo ECB.” Para explicar lo que eso significa, permítanme que cite algunos párrafos de mi libro Cuando la Criptografía Falla:

Matemáticamente, podemos representar el proceso de cifra como una función E que depende tanto del mensaje M como de la clave k: C=Ek(M). Como el algoritmo es simétrico, la función de descifrado es igual que la de cifrado, de forma que M=Ek(C). Sencillo hasta aquí. Pero ¿qué hacemos si el mensaje es mayor que un bloque? Lo lógico sería trocear el mensaje en bloques de, digamos, N Bits:

M = (M1,M2,M2 … Mh)

A continuación, ciframos cada bloque independientemente:

C1=Ek(M1)

C2=Ek(M2)

Ch=Ek(Mh)

El mensaje cifrado resultante es

C=(C1, C2, C3 … Ch)

Este modo de cifrar bloques de bits es el denominado Modo de Libro de Código Electrónico o ECB (Electronic Codebook Mode). Como han visto, en el ECB cada bloque se cifra de modo independiente, como si los demás bloques no existiesen. Es el modo que, a priori, nos parece más natural. Resulta especialmente útil a la hora de cifrar grandes bases de datos, ya que no necesitamos cifrar todo de nuevo cuando añadimos, alteramos o borramos información. Es la forma más rápida de cifrar, y la verdad, uno al principio puede plantearse por qué pensar siquiera que hay otras formas de cifrar. Por eso, ECB es el modo habitual en que muchos creadores de software incorporan sistemas de cifrado.

El problema con el modo de encadenado EBC es que resulta vulnerable a ciertos tipos de ataques. En este punto, el término “ataque” debe entenderse no en sentido estrecho (descifrar un mensaje) sino en el de dar a un intruso cualquier tipo de ventaja. Puede que un atacante no pueda leer un mensaje, pero si es capaz de insertar o sustituir parte del mensaje cifrado, eso también vale.

Para ilustrar la vulnerabilidad del modo ECB, vamos a imaginar una base de datos con la lista de clientes de un banco: nombre, número de cuenta, saldo. Supongamos que el criptoanalista tiene acceso a toda la base de datos cifrada (cosa que, a tenor de las noticias sobre robos de bases de datos, fallos de vulnerabilidad y pérdidas accidentales, resulta cada vez menos raro). Como toda la base de datos está cifrada con la misma clave, las redundancias que aparezcan pueden dar información sobre el contenido.

Por ejemplo, digamos que el atacante examina la base de datos, cifrada, y comprueba que hay diversas cadenas alfanuméricas que se repiten. ¿Puede tratarse de saldos en números redondos? Quizá 928hng4l significa diez mil, o kkwg972c es un nombre de pila común. Puede que el enemigo haya averiguado que yo fui el único cliente del banco online que realizó una retirada de fondos entre las 9:56 y las 9:57 de la mañana, y de ese modo averiguar cuál fue la única línea de la base de datos que ha sido alterada; eso le dice que 9n1ff2ka es el resultado de cifrar mi nombre.

He aquí el esquema de un ataque alternativo. Imaginemos que el Banco A envía un mensaje electrónico al Banco B, en el que se detalla una transferencia a un cliente suyo. Todo el paquete de datos está cifrado con la misma clave. Los datos de la transferencia están divididos en bloques: un bloque para el nombre del banco emisor, uno para el del banco receptor, tres para el nombre del destinatario, uno para la cantidad transferida y dos para el número de cuenta de destino: ERDDDMCC.

En esta ocasión, yo soy el atacante (qué quieren, me han vuelto a recortar el sueldo y hay que llegar a fin de mes como sea). En primer lugar, ordeno una transferencia legítima desde mi cuenta en el banco A a mi otra cuenta en el banco B, y grabo la transmisión ERDDDMCC. A continuación, intercepto otra transferencia, digamos erdddmcc, le quito los bloques correspondientes al banco de destino, nombre de destinatario y número de cuenta, los sustituyo por los míos, y envío el resultado eRDDDmCC. De ese modo, un desconocido a quien no tengo el gusto de conocer ha transferido sobre el papel (bueno, sobre el cable) una cantidad de dinero m a mi cuenta CC.

Fíjense que no conozco la clave, no sé quién es mi anónimo benefactor, y ni siquiera sé la cuantía de la transferencia. Tarde o temprano el banco receptor se dará cuenta de que el banco emisor no paga, se dirigirán al cliente y éste dirá que no es cosa suya, pero para entonces yo ya he vaciado mi cuenta y me he largado a las Seychelles, desde donde les estoy escribiendo bajo el nombre supuesto de Arturo Quirantes.

Por supuesto, los ataques que les estoy describiendo aquí son elementales, y el sistema bancario tiene mecanismos para detectar y perseguir este tipo de fraudes, así que recuerde: no lo intente usted en casa. Aun así, estos ejemplos ilustran el hecho de que el cifrado no es una herramienta mágica que nos protege de todos los problemas. Puede ocultar información hasta cierto punto, pero no evita ataques de repetición o alteraciones de datos. Es necesario algo más.

Adobe utilizaba el modo ECB para cifrar sus contraseñas; en cuanto al algoritmo TripleDES, cifra los datos en bloques de 8 bytes (64 bits). Eso significa que una contraseña como “estúpidos” se cifrará en dos bloques: “estúpido” y “s.” Digamos que “estúpido” se cifra como “zzkqhw18″ y “s” se cifra como “9tqk3hb2″ Eso significa que “estúpidos” se convierte en “zzkqhw18 9tqk3hb2″

Ahora bien, ¿cómo se cifraría la palabra “pajaritos”? Se haría de forma similar: “pajarito” se convierte en “fqmr89ha” y “s” se convierte en “9tqk3hb2″ Fíjense entonces cuál es el resultado de cifrar dos palabras diferentes:

Texto llano    Cifrado
estúpidos      zzkqhw18 9tqk3hb2
pajaritos      fqmr89ha 9tqk3hb2

¿Se dan cuenta? Ambos textos tienen el mismo bloque cifrado “9tqk3hb2″ Eso significa que, en la lista de contraseñas cifradas, ese “9tqk3hb2″ aparecerá muchas más veces que otros términos cifrados; concretamente, cada vez que un usuario utilice una contraseña de nueve caracteres que termine en “s.”

En este buen artículo de Naked Security se analiza el problema. En teoría, la cadena cifrada “110edf2294fb8bf4″ (16 caracteres hexadecimales, esto es, 64 bits) solamente debería aparecer con probabilidad de 1 entre 2^56, es decir, aparecería una vez cada 720 billones. En lugar de eso, aparece una vez cada 62. Su frecuencia es demasiado alta, indicando que es el resultado de cifrar un texto muy sencillo y frecuente.

Es ahora cuando aparece el elemento más divertido: la pista. La lista de datos robada a Adobe incluía dirección de email, nombres de usuario… y una pista. Ya sabe el lector que, cuando se le olvida la contraseña, puede recuperarla a base de contestar una pregunta tipo “nombre del perro” o “nombre de soltera de la madre.” En el caso de Adobe, lo que se guarda es una pista para recuperar la contraseña.

Pues bien, junto al texto cifrado “110edf2294fb8bf4″ aparecían pistas como “numbers 123456″, “==123456″ o “c’ est 123456″ Efectivamente, 110edf2294fb8bf4 es el resultado de cifrar la contraseña 123456. No es casualidad que sea una de las contraseñas más frecuentes en todo tipo de servicios web.

¿Qué hay del texto cifrado “2fca9b003de39778 e2a311ba09ab4707″? Con pistas como “rhymes with assword” o “the password is password”, no hay que romperse mucho la cabeza para concluir que es el resultado de cifrar “password”, otra contraseña muy frecuente. Lo extraño es que password tiene ocho caracteres, de forma que en teoría debería cifrarse mediante 2fca9b003de39778 solamente. Es posible que las contraseñas se guarden añadiendo un byte cero (con objeto de indicar el fino de la cadena en C), y luego guardando más bytes cero hasta completar el siguiente bloque de ocho bytes. Si eso es cierto, ” e2a311ba09ab4707″ será el resultado de cifrar ocho caracteres nulos, y aparecerá cuando la contraseña tenga una longitud de ocho caracteres.

Algunos usuarios se pasaron a pistas más sutiles, y así podemos ver la cadena “ecba98cca55eabc2″ junto a pistas como “sixxone” (seissuno), “1+6″ o “sixones” (seis unos). Eso nos da la contraseña 111111. El dibujante xkcd se hizo eco del fallo de Adobe, y con buen humor criptográfico declaró el robo de información como “el mayor puzzle de la historia del mundo

La metedura de pata de Adobe nos hace pensar por qué usaron esa forma tan rara de almacenar contraseñas. En lugar de una función hash con sal, echan mano de un algoritmo de cifra desfasado. La explicación que dio Adobe es increíble. En declaraciones a Ars Technica, la portavoz de Adobe explicó que la empresa sí que protege las contraseñas de sus clientes con un algoritmo hash (el llamado SHA-256), incluyendo sal. Eso es bueno, muy bueno. La gran cagada está aquí:

El sistema de autenticación atacado fue un sistema de respaldo, y estaba en proceso de desmantelamiento

Es decir, usan algunos de los mejores métodos para proteger información ¡y luego van y guardan una copia de seguridad con protección inadecuada! Esto es para pegarles con un calcetín sudado. Es como poner una puerta blindada en la entrada principal y mantener la misma puerta de madera vieja de la cocina.

No puedo estar más de acuerdo con los expertos: esto ha sido una pifia épica. No lo superan ni los de Spaceballs con su contraseña 12345. Increíble.


Deja un comentario

Tu email nunca será mostrado o compartido. No olvides rellenar los campos obligatorios.

Obligatorio
Obligatorio
Obligatorio

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>