Android Class Loading Hijacking

Mario Ballano, investigador de Symantec, ha publicado una nueva técnica que podría ser utilizada por otros programas para “secuestrar” privilegios de otras aplicaciones en Android.

En verano de 2010, HD Moore destapó un problema de seguridad en decenas de aplicaciones de terceros cuando eran ejecutadas sobre Windows. Aunque la raíz del problema era, en realidad, una programación insegura de las aplicaciones, dada la magnitud del problema Microsoft publicó un aviso de seguridad con instrucciones para mitigar el fallo.

El problema estaba en múltiples aplicaciones de terceros (y propias) para Windows a la hora de cargar librerías dinámicas (archivos DLL). Si las aplicaciones no especifican las rutas completas de las librerías que necesitan, Windows podría llegar, en su búsqueda, a “encontrar” primero las librerías de los atacantes y ejecutarlas. Al principio Moore identificó unas cuarenta aplicaciones, pero poco a poco el número comenzó a crecer. El DLL Hijacking obligó a la actualización de cientos de aplicaciones y otras tantas que nunca fueron corregidas.

La técnica descubierta en Android es similar a este “DLL Hijacking” y tampoco es un problema específico del sistema operativo, sino de si la aplicación gestiona incorrectamente la procedencia de sus dependencias. Así, para aprovecharla, sería necesario encontrar una aplicación vulnerable instalada en el teléfono y hacer que cargue librerías o plugins del atacante en vez de los suyos legítimos. Para ello, primero estas librerías deben estar localizadas en un punto donde todos puedan escribir para que sean reemplazadas. Por ejemplo, la tarjeta SD del teléfono.

Android ofrece dos clases, DexClassLoader y PathClassLoader para cargar código dinámicamente. La primera API optimiza un código y devuelve el resultado en la variable dexOutputDir, que muchos desarrolladores e incluso documentación de Android, definen como la tarjeta SD. En ella puede escribir cualquiera. Así que un atacante simplemente tendría que reemplazar ese código, y la aplicación lo cargaría creyendo que es el suyo. El atacante heredaría sus permisos.

PathClassLoader tiene un problema parecido con su parámetro libPath. Android irá a buscar librerías de sistema donde diga este valor, y muchos programadores lo establecen a la ruta de la tarjeta SD. Sin embargo esto no funcionará en ningún caso, puesto que se monta por defecto con permisos de no ejecución. Lo curioso es que se han encontrado varias aplicaciones en el Marketplace que lo intentan.

Lo ideal entonces, es que el desarrollador se preocupe de que todos los archivos son emplazados y cargados desde lugares seguros, (nunca la tarjeta SD). Desde Symantec han contactado con Google para que al menos, en la documentación oficial, se mencione este potencial problema.

Mas información en este enlace y en este enlace.

Fuente: Hispasec

Share

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.