Al estudiar los cifrados en bloques, muchos llegarán a estudiar sobre AES y el modo de operación Electronic Codebook (ECB), concluyendo rápidamente que es inseguro por su predicibilidad y por "ver al pingüino". Esta expresión se origina por un ejemplo clásico de la inseguridad del modo ECB: La imagen del pingüino Tux encriptada con AES-ECB deja patrones, permitiendo ver la silueta del pingüino pese a que los datos se encuentren encriptados. Sin embargo, rara vez se llega más allá de esto y no se deja en claro cómo se puede explotar el modo AES-ECB.

En este artículo, se mostrarán un par de vulnerabilidades que demuestran cómo explotar AES-ECB para filtrar datos o incluso construir tokens válidos sin conocer la clave.

Recordando: ¿Qué es AES-ECB?

Electronic Codebook (ECB) es el modo de operación de AES más simple para encriptación en bloques. Sin entrar a detalle de cómo funciona AES, este modo toma bloques independientes del texto plano y los encripta bajo una llave de forma predecible. Es decir, bajo la misma llave, el mismo texto plano producirá el mismo texto cifrado. Para desencriptar texto cifrado, se realiza el proceso inverso sobre los bloques resultantes.

¿Por qué se le considera vulnerable?

Como se explicó, un ejemplo clásico de por qué nunca debería ser usado es el del pingüino. Pero, ¿cómo se traslada esto a texto, como contraseñas o mensajes encriptados? Básicamente, se puede aprovechar el hecho de que, en cifrados largos, es posible encontrar bloques de cifrados repetidos en este modo de operación, dando lugar a filtrados de información del texto plano. Es por este motivo que píxeles negros resultan en los mismos píxeles de color similar en la imagen encriptada de Tux, generando una silueta similar a la de su imagen original. Aunque en texto no se puedan "reconocer siluetas" fácilmente como en imágenes, el hecho de que se pueda reconocer el uso de ECB ya resulta como información esencial para el atacante.

¿Cómo se puede atacar AES-ECB?

ECB puede ser fácilmente explotado sin necesidad de encontrar su llave aprovechando el hecho de que el mismo texto plano producira el mismo texto cifrado bajo la misma llave.

Ataque "Byte-a-la-vez" (Byte-at-a-time)

Este ataque puede utilizarse cuando se tiene un oráculo que encripta en AES-ECB-128 y que añade un secreto después del texto plano el cual deseamos obtener.

1LLAVE = "YELLOW SUBMARINE" # Llave de 16 bytes
2
3funcion oraculo(plano):
4  SECRETO = "CRIMENYCASTIGO"
5  cifrado = ecb(plano || SECRETO, LLAVE)

Como atacantes, solo podemos ingresar textos planos y recibir textos cifrados. Para obtener el secreto, aprovechamos la propiedad esencial de ECB: mismo texto plano, mismo texto cifrado.

Para no entrar en detalles, asumamos que ya descubrimos que el oráculo trabaja en modo ECB y el tamaño de bloque con el que trabaja. Asumiendo que el tamaño de bloque es de 16 bytes, podemos mandar un texto de longitud de 15 bytes. ¿Cuál será el último byte del bloque? El primero del secreto (los últimos bytes son de padding para completar un bloque de 16 bytes).

1AAAAAAAAAAAAAAAC RIMENYCASTIGO\x03\x03\x03
28b13487e8f1047de93607d08d9fe978d b5780ece70c8dd174e969fb9cefe3051

Ahora, tenemos un texto cifrado para AAAAAAAAAAAAAAAC. Como atacantes, solo sabemos que los primeros 15 bytes son A, no conocemos el último. Desde nuestro punto de vista, es AAAAAAAAAAAAAAA?. Sin embargo, un ataque de fuerza bruta en este punto es sencillo, puesto que solo debemos iterar sobre el byte en la última posición. En otras palabras, iteramos sobre todas las posibilidades del último byte hasta encontrar el texto plano que nos resulte en el mismo texto cifrado.

1AAAAAAAAAAAAAAAA -> e44085fa2bda33d86aa340b4c16c05ad
2AAAAAAAAAAAAAAAB -> a7c937df474962e3ac3e2cf16e91a053
3AAAAAAAAAAAAAAAC -> 8b13487e8f1047de93607d08d9fe978d
4AAAAAAAAAAAAAAAD -> 87e8e3f36c3ffd12bfa42de08c9dea92

Encontramos que AAAAAAAAAAAAAAC resulta en el mismo texto cifrado que obtuvimos originalmente. Por lo tanto, descubrimos que el primer byte del secreto es C.

Para el segundo byte, repetimos el proceso con 15 bytes conocidos.

1AAAAAAAAAAAAAACR IMENYCASTIGO\x04\x04\x04\x04
24d2011f5243628d4ed1d2859887c6d5f 707b29f0feea4f85ef2bc56a4b07a465

Obtenemos un texto cifrado para AAAAAAAAAAAAAACR. Conocemos los primeros quince bytes, incluyendo el descubierto C. Solo necesitamos iterar todas las posibilidades hasta encontrar el texto cifrado que concuerde con el obtenido.

De esta forma, ¡vamos "un byte a la vez" hasta encontrar por completo el secreto!

Ataque "Cortar y pegar" (Cut and paste)

Este tipo de ataque aprovecha el hecho de que los bloques resultantes del modo ECB son independientes entre sí, por lo que se puede construir un mensaje cifrado válido juntando diversos bloques encriptados bajo la misma llave. Un ejemplo clásico de esto son parámetros web encriptados o cookies. Supongamos que tenemos una cookie que es codificada y luego encriptada de la siguiente forma con AES-ECB-128:

1{email: user@domain.com, uid: 10, role: user}
2email=user@domain.com&uid=10&role=user
376783c923486a619c4023e9232d70805e0810b2a085db3dcf1e30716db69d85780aa101b7b10a13cbebb4d292cbcd91d

Supongamos que tenemos una aplicación que permite generar cookies dando un correo electrónico solo con el rol de usuario y nuestro objetivo es generar una cookie con rol de administrador. Supongamos que en circunstancias normales no podemos generar una cookie de administrador y simplemente escribir [email protected]&role=admin será filtrado.

Para lograr esto, podemos combinar un bloque cifrado que termine precisamente en role= y otro que empiece precisamente en admin con el padding adecuado.

Primer bloque

Asumiendo un tamaño de bloque de 16 bytes, podemos ingresar un correo electrónico que hará que role= sean los últimos 5 bytes en el segundo bloque.

1{email: aaaaaaaaa@b.c, uid: 123, role: user}
2email=aaaaaaaaa@ b.c&uid=10&role= user\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c
37f8b7a8f498304ef8a3a61e517196d6b 2a08f00b4fe99175e500e6d41131af2e 834eca357dd8ebe6f976c63d96610a50

Segundo bloque

Luego, necesitmos un bloque en el que admin sea los primeros 5 bytes de un bloque junto a padding valido para que sea el último bloque de la cookie construída. Nuevamente, ingresamos un correo electrónico específico para esto.

1{email: aaaaaaa@b.admin\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b, uid: 123, role: user}
2email=aaaaaaa@b. admin\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b  &uid=10&role=use r\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f\x0f
3d33b8ca31dc3205b3cdffc44d5edb364 f88c0e393aa911dffab14d568a79733d 0b7ea87569727652d415c42e4dc153ed 774ddbdff07a3abe8c90ca2e2ec5a320

Con estos dos bloques, simplemente "cortamos" el último bloque del primer cifrado que obtuvimos, el que empieza con user y "pegamos" el bloque que empieza con admin del segundo cifrado generado. De esta forma, ¡obtenemos una cookie válida con el rol de administrador!

17f8b7a8f498304ef8a3a61e517196d6b 2a08f00b4fe99175e500e6d41131af2e f88c0e393aa911dffab14d568a79733d
2email=aaaaaaaaa@ b.c&uid=10&role= admin
3{email: aaaaaaaaa@b.c, uid: 123, role: admin}

Conclusión

Estos días, es conocimiento común que el modo ECB no debe ser usado bajo ningún contexto. Comose ha visto, motivo de esto es la facilidad con la que se pueden filtrar datos o construir mensajes cifrados válidos. Sin embargo, ocasionalmente se verán estos problemas en CTFs y (espero que no) en sistemas desplegados. Por lo tanto, vale la pena conocer cómo vulnerar Electronic Codebook en el caso excepcional que se encuentre en estado salvaje.