Esta semana vamos a hablar del comportamiento por defecto de las librerías Zip. Si eres un desarrollador de aplicaciones, es muy probable que hayas utilizado esto antes. La mayoría de los recursos que se descargan por internet están en formato zip, esto tiene sentido; los datos comprimidos son más pequeños, por lo que se descargan más rápido y consumen menos ancho de banda.

Si quieres algunos ejemplos más concretos: texturas para juegos, paquetes de idiomas para autocompletar en los teclados, ... Muchos recursos no se incluyen automáticamente en la aplicación, sino que se descargan posteriormente.

Pero tenga cuidado al usar esta funcionalidad, los nombres de los archivos en zip pueden contener información de recorrido. Cuando se extrae, esto hará que se creen archivos fuera del directorio previsto. Esto se hace a menudo con la intención de sobrescribir los archivos existentes.

Digamos que tenemos un archivo zip que contiene los siguientes dos archivos:

archivo1
../archivo2

Cuando se extrae este archivo, el archivo1 se extrae donde esperamos que esté, en el directorio de descompresión. Sin embargo, el archivo2 fue escrito un directorio más arriba de donde le pedimos a la biblioteca zip que extrajera el archivo.

Así que tenga cuidado, si su librería zip no tiene cuidado de manejar adecuadamente este caso, permitirá a un atacante escribir un archivo arbitrario en el sistema. Compruebe siempre si su librería es segura, esta regla general es válida para cualquier librería, pero en particular sabe comprobar el comportamiento por defecto de su librería zip para este tipo de archivos.

Vamos a demostrar las consecuencias cuando este caso no se maneja correctamente en Android. En Android se utiliza la librería Java Zip (java.util.zip), que permite recorrer la ruta como se ha explicado anteriormente por defecto.

El formato Dalvik Executable (.dex) de Android tiene limitaciones en cuanto a la cantidad de clases que puede tener un solo archivo. Las aplicaciones que necesitan más clases pueden hacer uso de la librería MultiDex Support que se ha añadido desde el nivel 21 de la API (Android 5.0 Lollipop). Esta librería guarda archivos .dex secundarios en el directorio de datos de la aplicación, este directorio es escribible por el usuario de la app y este código será cargado y ejecutado cuando el archivo .dex sea necesario.

Esto significa que un atacante puede modificar el archivo .dex sobrescribiéndolo mediante un archivo zip malicioso y, lo que es peor, este archivo se cargará y se ejecutará, dando lugar a una vulnerabilidad de ejecución remota de código. Esto no es sólo un ejemplo teórico, sino que se ha demostrado en la aplicación My Talking Tom, que tiene más de 100 millones de descargas en la tienda de aplicaciones. Aquí hay un vídeo del exploit que se presentó en Black Hat.

Compruebe siempre el comportamiento de su biblioteca zip para conocer sus inseguridades. Si no puedes desactivar el path traversal en tu librería zip, asegúrate de validar el nombre de cada entrada antes de extraerla. El nombre debería estar canonizado y la ruta resultante debería estar en el directorio en el que quieres extraer el archivo. Ya que estamos, también deberías comprobar el tamaño total del archivo extraído para evitar las bombas zip, pero esto será un post para otra semana.

Si quieres jugar a algunos retos sobre el cruce de caminos o quieres poner a prueba tus habilidades de codificación segura, echa un vistazo a nuestra plataforma.

Nos vemos la próxima vez, y recuerda, ¡con código seguro o sin código!

- Podemos inyectar un archivo en un zip cuyo nombre esté prefijado con un número arbitrario de " ../ "
- Si la librería zip no tiene cuidado de manejar adecuadamente este caso, nos permitiría escribir fuera del directorio de extracción previsto
- Si el archivo zip no es de confianza, esto da al atacante una vulnerabilidad de escritura arbitraria

https://www.blackhat.com/docs/ldn-15/materials/london-15-Welton-Abusing-Android-Apps-And-Gaining-Remote-Code-Execution.pdf