Técnica de codificación segura: el comportamiento predeterminado de las bibliotecas Zip puede provocar la ejecución remota de código
Esta semana vamos a hablar sobre el comportamiento predeterminado de las bibliotecas Zip. Si es un desarrollador de aplicaciones, es muy probable que lo haya usado antes. La mayoría de los recursos que se descargan a través de 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 ejemplos más concretos: texturas para juegos, paquetes de idiomas para completar automáticamente en teclados,... Muchos recursos no se incluyen automáticamente en la aplicación, sino que se descargan más adelante.
Sin embargo, tenga cuidado al utilizar esta funcionalidad, ya que los nombres de archivo de los archivos zip pueden contener información sobre el recorrido de las rutas. Cuando se extraigan, esto provocará que los archivos se creen fuera del directorio deseado. Esto se hace a menudo con la intención de sobrescribir los archivos existentes.
Supongamos que tenemos un archivo zip que contiene los dos archivos siguientes:
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 se escribió en un directorio superior al que pedimos a la biblioteca zip que extrajera el archivo.
Así que ten cuidado, si tu biblioteca zip no se ocupa de gestionar adecuadamente este caso, permitirá a un atacante escribir un archivo arbitrario en el sistema. Compruebe siempre si su biblioteca es segura. Esta regla general es válida para cualquier biblioteca, pero en particular debe comprobar el comportamiento predeterminado de su biblioteca zip para este tipo de archivos.
Vamos a demostrar las consecuencias cuando este caso no se maneja correctamente en Android. En Android, se usa la biblioteca Java Zip (java.util.zip), que permite recorrer rutas como se explicó anteriormente de forma predeterminada.
El formato ejecutable Dalvik de Android (.dex) tiene limitaciones en cuanto a la cantidad de clases que puede tener un solo archivo. Las apps que necesitan más clases pueden usar la biblioteca de compatibilidad de MultiDex, que se ha agregado desde el nivel 21 de la API (Android 5.0 Lollipop). Esta biblioteca guarda los archivos.dex secundarios en el directorio de datos de la aplicación. El usuario de la aplicación puede escribir en este directorio y este código se cargará y ejecutará cuando se necesite el archivo.dex.
Esto significa que un atacante puede modificar el archivo.dex sobrescribiéndolo con un archivo zip malintencionado y, lo que es peor, este archivo se cargará y ejecutará, lo que generará una vulnerabilidad de ejecución remota de código. Esto no es solo un ejemplo teórico, sino que se ha demostrado en la aplicación My Talking Tom, que cuenta con más de 100 millones de descargas en la tienda de aplicaciones. Este es un vídeo del exploit que se presentó en Black Hat.
Compruebe siempre el comportamiento de su biblioteca zip para estar al tanto de sus inseguridades. Si no puedes deshabilitar el recorrido por rutas en tu biblioteca zip, asegúrate de validar el nombre de cada entrada antes de extraerla. El nombre debe estar canonizado y la ruta resultante debe estar en el directorio en el que deseas extraer el archivo. Ya que estamos en ello, también deberías comprobar el tamaño total del archivo extraído para evitar que se produzcan bombas zip, pero esto será una entrada durante una semana más.
Si quieres juega algunos desafíos al atravesar el camino 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 tenga como prefijo un número arbitrario de "../»
- Si la biblioteca zip no se ocupa de gestionar correctamente este caso, nos permitiría escribir fuera del directorio de extracción previsto
- Si el archivo zip no es de confianza, el atacante presenta una vulnerabilidad de escritura arbitraria
응용 프로그램 보안 연구원 - R&D 엔지니어 - 박사 후보
Secure Code Warrior 귀사의 조직이 소프트웨어 개발 라이프사이클 전반에 걸쳐 코드를 보호하고 사이버보안을 최우선으로 하는 문화를 조성하도록 Secure Code Warrior . AppSec 관리자, 개발자, CISO 또는 보안 관련 담당자라면 누구든, 저희는 귀사의 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 돕습니다.
데모 예약하기
응용 프로그램 보안 연구원 - R&D 엔지니어 - 박사 후보
Esta semana vamos a hablar sobre el comportamiento predeterminado de las bibliotecas Zip. Si es un desarrollador de aplicaciones, es muy probable que lo haya usado antes. La mayoría de los recursos que se descargan a través de 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 ejemplos más concretos: texturas para juegos, paquetes de idiomas para completar automáticamente en teclados,... Muchos recursos no se incluyen automáticamente en la aplicación, sino que se descargan más adelante.
Sin embargo, tenga cuidado al utilizar esta funcionalidad, ya que los nombres de archivo de los archivos zip pueden contener información sobre el recorrido de las rutas. Cuando se extraigan, esto provocará que los archivos se creen fuera del directorio deseado. Esto se hace a menudo con la intención de sobrescribir los archivos existentes.
Supongamos que tenemos un archivo zip que contiene los dos archivos siguientes:
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 se escribió en un directorio superior al que pedimos a la biblioteca zip que extrajera el archivo.
Así que ten cuidado, si tu biblioteca zip no se ocupa de gestionar adecuadamente este caso, permitirá a un atacante escribir un archivo arbitrario en el sistema. Compruebe siempre si su biblioteca es segura. Esta regla general es válida para cualquier biblioteca, pero en particular debe comprobar el comportamiento predeterminado de su biblioteca zip para este tipo de archivos.
Vamos a demostrar las consecuencias cuando este caso no se maneja correctamente en Android. En Android, se usa la biblioteca Java Zip (java.util.zip), que permite recorrer rutas como se explicó anteriormente de forma predeterminada.
El formato ejecutable Dalvik de Android (.dex) tiene limitaciones en cuanto a la cantidad de clases que puede tener un solo archivo. Las apps que necesitan más clases pueden usar la biblioteca de compatibilidad de MultiDex, que se ha agregado desde el nivel 21 de la API (Android 5.0 Lollipop). Esta biblioteca guarda los archivos.dex secundarios en el directorio de datos de la aplicación. El usuario de la aplicación puede escribir en este directorio y este código se cargará y ejecutará cuando se necesite el archivo.dex.
Esto significa que un atacante puede modificar el archivo.dex sobrescribiéndolo con un archivo zip malintencionado y, lo que es peor, este archivo se cargará y ejecutará, lo que generará una vulnerabilidad de ejecución remota de código. Esto no es solo un ejemplo teórico, sino que se ha demostrado en la aplicación My Talking Tom, que cuenta con más de 100 millones de descargas en la tienda de aplicaciones. Este es un vídeo del exploit que se presentó en Black Hat.
Compruebe siempre el comportamiento de su biblioteca zip para estar al tanto de sus inseguridades. Si no puedes deshabilitar el recorrido por rutas en tu biblioteca zip, asegúrate de validar el nombre de cada entrada antes de extraerla. El nombre debe estar canonizado y la ruta resultante debe estar en el directorio en el que deseas extraer el archivo. Ya que estamos en ello, también deberías comprobar el tamaño total del archivo extraído para evitar que se produzcan bombas zip, pero esto será una entrada durante una semana más.
Si quieres juega algunos desafíos al atravesar el camino 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 tenga como prefijo un número arbitrario de "../»
- Si la biblioteca zip no se ocupa de gestionar correctamente este caso, nos permitiría escribir fuera del directorio de extracción previsto
- Si el archivo zip no es de confianza, el atacante presenta una vulnerabilidad de escritura arbitraria
Esta semana vamos a hablar sobre el comportamiento predeterminado de las bibliotecas Zip. Si es un desarrollador de aplicaciones, es muy probable que lo haya usado antes. La mayoría de los recursos que se descargan a través de 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 ejemplos más concretos: texturas para juegos, paquetes de idiomas para completar automáticamente en teclados,... Muchos recursos no se incluyen automáticamente en la aplicación, sino que se descargan más adelante.
Sin embargo, tenga cuidado al utilizar esta funcionalidad, ya que los nombres de archivo de los archivos zip pueden contener información sobre el recorrido de las rutas. Cuando se extraigan, esto provocará que los archivos se creen fuera del directorio deseado. Esto se hace a menudo con la intención de sobrescribir los archivos existentes.
Supongamos que tenemos un archivo zip que contiene los dos archivos siguientes:
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 se escribió en un directorio superior al que pedimos a la biblioteca zip que extrajera el archivo.
Así que ten cuidado, si tu biblioteca zip no se ocupa de gestionar adecuadamente este caso, permitirá a un atacante escribir un archivo arbitrario en el sistema. Compruebe siempre si su biblioteca es segura. Esta regla general es válida para cualquier biblioteca, pero en particular debe comprobar el comportamiento predeterminado de su biblioteca zip para este tipo de archivos.
Vamos a demostrar las consecuencias cuando este caso no se maneja correctamente en Android. En Android, se usa la biblioteca Java Zip (java.util.zip), que permite recorrer rutas como se explicó anteriormente de forma predeterminada.
El formato ejecutable Dalvik de Android (.dex) tiene limitaciones en cuanto a la cantidad de clases que puede tener un solo archivo. Las apps que necesitan más clases pueden usar la biblioteca de compatibilidad de MultiDex, que se ha agregado desde el nivel 21 de la API (Android 5.0 Lollipop). Esta biblioteca guarda los archivos.dex secundarios en el directorio de datos de la aplicación. El usuario de la aplicación puede escribir en este directorio y este código se cargará y ejecutará cuando se necesite el archivo.dex.
Esto significa que un atacante puede modificar el archivo.dex sobrescribiéndolo con un archivo zip malintencionado y, lo que es peor, este archivo se cargará y ejecutará, lo que generará una vulnerabilidad de ejecución remota de código. Esto no es solo un ejemplo teórico, sino que se ha demostrado en la aplicación My Talking Tom, que cuenta con más de 100 millones de descargas en la tienda de aplicaciones. Este es un vídeo del exploit que se presentó en Black Hat.
Compruebe siempre el comportamiento de su biblioteca zip para estar al tanto de sus inseguridades. Si no puedes deshabilitar el recorrido por rutas en tu biblioteca zip, asegúrate de validar el nombre de cada entrada antes de extraerla. El nombre debe estar canonizado y la ruta resultante debe estar en el directorio en el que deseas extraer el archivo. Ya que estamos en ello, también deberías comprobar el tamaño total del archivo extraído para evitar que se produzcan bombas zip, pero esto será una entrada durante una semana más.
Si quieres juega algunos desafíos al atravesar el camino 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 tenga como prefijo un número arbitrario de "../»
- Si la biblioteca zip no se ocupa de gestionar correctamente este caso, nos permitiría escribir fuera del directorio de extracción previsto
- Si el archivo zip no es de confianza, el atacante presenta una vulnerabilidad de escritura arbitraria
Esta semana vamos a hablar sobre el comportamiento predeterminado de las bibliotecas Zip. Si es un desarrollador de aplicaciones, es muy probable que lo haya usado antes. La mayoría de los recursos que se descargan a través de 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 ejemplos más concretos: texturas para juegos, paquetes de idiomas para completar automáticamente en teclados,... Muchos recursos no se incluyen automáticamente en la aplicación, sino que se descargan más adelante.
Sin embargo, tenga cuidado al utilizar esta funcionalidad, ya que los nombres de archivo de los archivos zip pueden contener información sobre el recorrido de las rutas. Cuando se extraigan, esto provocará que los archivos se creen fuera del directorio deseado. Esto se hace a menudo con la intención de sobrescribir los archivos existentes.
Supongamos que tenemos un archivo zip que contiene los dos archivos siguientes:
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 se escribió en un directorio superior al que pedimos a la biblioteca zip que extrajera el archivo.
Así que ten cuidado, si tu biblioteca zip no se ocupa de gestionar adecuadamente este caso, permitirá a un atacante escribir un archivo arbitrario en el sistema. Compruebe siempre si su biblioteca es segura. Esta regla general es válida para cualquier biblioteca, pero en particular debe comprobar el comportamiento predeterminado de su biblioteca zip para este tipo de archivos.
Vamos a demostrar las consecuencias cuando este caso no se maneja correctamente en Android. En Android, se usa la biblioteca Java Zip (java.util.zip), que permite recorrer rutas como se explicó anteriormente de forma predeterminada.
El formato ejecutable Dalvik de Android (.dex) tiene limitaciones en cuanto a la cantidad de clases que puede tener un solo archivo. Las apps que necesitan más clases pueden usar la biblioteca de compatibilidad de MultiDex, que se ha agregado desde el nivel 21 de la API (Android 5.0 Lollipop). Esta biblioteca guarda los archivos.dex secundarios en el directorio de datos de la aplicación. El usuario de la aplicación puede escribir en este directorio y este código se cargará y ejecutará cuando se necesite el archivo.dex.
Esto significa que un atacante puede modificar el archivo.dex sobrescribiéndolo con un archivo zip malintencionado y, lo que es peor, este archivo se cargará y ejecutará, lo que generará una vulnerabilidad de ejecución remota de código. Esto no es solo un ejemplo teórico, sino que se ha demostrado en la aplicación My Talking Tom, que cuenta con más de 100 millones de descargas en la tienda de aplicaciones. Este es un vídeo del exploit que se presentó en Black Hat.
Compruebe siempre el comportamiento de su biblioteca zip para estar al tanto de sus inseguridades. Si no puedes deshabilitar el recorrido por rutas en tu biblioteca zip, asegúrate de validar el nombre de cada entrada antes de extraerla. El nombre debe estar canonizado y la ruta resultante debe estar en el directorio en el que deseas extraer el archivo. Ya que estamos en ello, también deberías comprobar el tamaño total del archivo extraído para evitar que se produzcan bombas zip, pero esto será una entrada durante una semana más.
Si quieres juega algunos desafíos al atravesar el camino 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 tenga como prefijo un número arbitrario de "../»
- Si la biblioteca zip no se ocupa de gestionar correctamente este caso, nos permitiría escribir fuera del directorio de extracción previsto
- Si el archivo zip no es de confianza, el atacante presenta una vulnerabilidad de escritura arbitraria
%20(1).avif)
.avif)
