¿Con qué frecuencia se utiliza la ofuscación de código en las aplicaciones populares de Android?

Ya sea que el objetivo sea robar propiedad intelectual, acceder a información confidencial de usuarios o acceder a prácticamente cualquier cosa en un servidor backend, muchos ataques dirigidos comienzan con la ingeniería inversa de partes de las aplicaciones del lado del cliente para comprender su estructura e identificar vulnerabilidades. Incluso si el ataque final se produce en el servidor, el análisis de la contraparte del lado del cliente suele revelar información crucial sobre sus API y mecanismos de autenticación.

Por esta razón, creemos que el fortalecimiento del código es Innegociable para cualquier aplicación que utilice algoritmos originales o que opere con datos sensibles..

En 2023, OWASP definió la segunda versión de su Móvil Application Security Estándar de verificación (MASVS), que sirve como conjunto de directrices para los desarrolladores de aplicaciones que intentan proteger sus aplicaciones móviles, así como para los evaluadores de seguridad que intentan encontrar vulnerabilidades en ellas. También proporciona Application Security proveedores de productos como Digital.ai Un marco para comprender el panorama actual de la seguridad de las aplicaciones. OWASP MASVS-RESILIENCIA Los controles se adaptan perfectamente a cómo Digital.ai (y Arxan antes que él) piensa en el fortalecimiento del código y la protección contra la manipulación:

• MASVS-RESILIENCIA-1La aplicación valida la integridad de la plataforma.
• MASVS-RESILIENCIA-2La aplicación implementa mecanismos contra la manipulación.
• MASVS-RESILIENCIA-3La aplicación implementa mecanismos de análisis antiestático.
• MASVS-RESILIENCIA-4La aplicación implementa técnicas de análisis anti-dinámico.

Si bien garantizar la integridad de la plataforma, la protección contra la manipulación y el análisis anti-dinámico suelen ser más eficaces, si se implementan sin análisis anti-estático son vulnerables a que los atacantes avanzados los detecten y neutralicen fácilmente.

Teniendo esto en cuenta, comencemos por evaluar con qué frecuencia las aplicaciones actuales implementan lo siguiente: MASVS-RESILIENCIA-3 control. Para ello, analizamos 40 de las mejores aplicaciones gratuitas de Google Play, buscando indicios claros de ofuscación de código.

Lo que encontramos

Para comprender plenamente nuestros hallazgos, primero debemos describir nuestra metodología. Los lenguajes basados ​​en bytecode, como Java y Kotlin, suelen conservar los nombres de clases y métodos. Incluso cuando el código está ofuscado, estos identificadores pueden proporcionar a los ingenieros de reversa suficientes pistas para comprender la arquitectura de la aplicación y crear un ataque. El cambio de nombre, u ofuscación de nombres, elimina esa información identificativa del código. Dado que la presencia del cambio de nombre (es decir, la falta de identificadores legibles) es muy visual y fácil de detectar, la utilizamos como criterio para este análisis.

Tras descompilar las aplicaciones objetivo, las clasificamos en 3 categorías en función de la cobertura del cambio de nombre:

• No cambiar el nombreNo se cambia el nombre de ningún elemento de la aplicación, lo que indica una seguridad inexistente o débil.
• Cambio de nombre localSolo se cambian de nombre algunas partes específicas de la aplicación, lo que podría indicar el uso de una biblioteca de autoprotección de aplicaciones en tiempo de ejecución (RASP) para seguridad, o una configuración de bajo esfuerzo.
• Cambio de nombre globalLa mayor parte del código ha sido renombrado, lo que indica el uso de una solución de seguridad integral y una configuración bien pensada.

Entre las aplicaciones seleccionadas, el 37% no estaban protegidas en absoluto, el 28% solo tenían renombradas unas pocas clases y el 35% restante tenía el cambio de nombre aplicado a la mayoría de las clases.

Es importante señalar que renombrar solo ciertos componentes (28 % de las aplicaciones analizadas) puede hacer que estas partes resalten, ya que esto pone de relieve la lógica o los controles de seguridad más sensibles, que un atacante puede identificar y eliminar. En cambio, renombrar de forma más uniforme en todo el código fuente (35 % de las aplicaciones analizadas) oculta estas señales, lo que dificulta enormemente la identificación de objetivos valiosos. Esto complica mucho más la tarea de descifrar el código protegido y aumenta significativamente el tiempo necesario para realizar ingeniería inversa de la aplicación (que es, sin duda, el recurso más importante y limitado del atacante). En muchos casos, esta mayor complejidad por sí sola basta para disuadir nuevos intentos.

Estos resultados demuestran que una parte considerable de los desarrolladores de aplicaciones se preocupan al menos un poco por la seguridad de sus aplicaciones, pero al menos un tercio de las aplicaciones analizadas siguen llegando al mercado con código que puede ser inspeccionado, modificado y redistribuido fácilmente.

Qué Significa Esto?

Esto es importante porque las aplicaciones sin protección o con protección limitada son objetivos mucho más fáciles para la ingeniería inversa y la manipulación. Para la mayoría de las aplicaciones, esto puede significar la filtración de propiedad intelectual, la exposición de claves API o la revelación de la lógica de negocio que los atacantes pueden explotar. En el caso de los juegos, abre la puerta a las trampas, las modificaciones o las versiones clonadas, lo que afecta directamente a los ingresos y la integridad de la marca. La distribución actual demuestra que, si bien algunos equipos se toman la seguridad en serio, muchos aún dejan grandes partes de su código fuente expuestas.

Es evidente: la protección básica del lado del cliente aún no es un estándar universal, ni siquiera entre las aplicaciones de gran visibilidad, y existe una necesidad real de mayor coherencia y concienciación. La siguiente publicación de esta serie analizará con más detalle la mayor dificultad que supone analizar una aplicación bien protegida en comparación con una aplicación sin protección o con una implementación deficiente.