Lo que Bad Guys 2 me enseñó sobre la asimetría de la información y la Application Security Problema que nadie quiere nombrar

01 Eran estudiantes de tu trabajo

Hay una frase en Bad Guys 2 que debería dejar helado a cualquier experto en seguridad. Cuando las Bad Girls se revelan por primera vez —Kitty Kat, Pigtail Petrova y Doom— no llegan con aires de grandeza, con armamento superior ni mejor tecnología. Llegan como admiradoras. Fans. "Estudiantes de su trabajo", como dice la película. Han estudiado a los Bad Guys tan a fondo que pueden replicar sus patrones, anticipar sus movimientos y explotar sus relaciones. Cuando los Bad Guys finalmente comprenden lo que está sucediendo, el juego ya ha terminado. La asimetría de información era total incluso antes de la escena inicial.

Los atacantes ya habían estudiado tu trabajo. Tenían tu archivo binario. Nada de ese reconocimiento apareció en tus registros.

No se trata de una ingeniosa puesta en escena cinematográfica. Es la descripción de todas las brechas de seguridad graves en aplicaciones que se han producido en la última década.

Los atacantes ya habían estudiado tu trabajo. Tenían tu código binario. Lo ejecutaron sin conexión, con desensambladores y depuradores, a su antojo, sin presión de tiempo ni sistema de alarma. Conocían tus claves criptográficas, tu lógica de autenticación, tus patrones de llamadas a la API y tu esquema de ofuscación, si es que tenías uno. Conocían tu aplicación mejor que la mayoría de tus propios desarrolladores. Y nada de ese reconocimiento quedó registrado en tus archivos de registro.

La cuestión no es si esto le está sucediendo a tu aplicación. Sí le está sucediendo. La cuestión es qué encuentran cuando lo revisan.

02 La asimetría de la información es el problema real.

La asimetría de la información es un concepto que los economistas utilizan para describir situaciones en las que una de las partes en una transacción posee mucha más información que la otra. George Akerlof ganó el Premio Nobel en 2001 por su investigación sobre cómo la información asimétrica perjudica a los mercados. Su ejemplo más conocido es el mercado de coches usados, donde los vendedores conocen el estado real del vehículo y los compradores lo desconocen, lo que genera un mercado propenso a la venta de coches defectuosos. La parte con más información gana sistemáticamente, no porque sea más inteligente, sino porque posee información que la otra parte ignora.

En seguridad de aplicaciones, la asimetría se dirige completamente hacia el atacante desde el momento en que se realiza el envío. El atacante obtiene el binario. Este binario contiene tu lógica, tus claves, tus secretos y tus supuestos de confianza. El atacante puede examinarlo sin restricciones. Tú, como desarrollador, no puedes ver qué hace el atacante con tu aplicación una vez que sale de tu entorno. Tú obtienes registros. Ellos obtienen visibilidad equivalente al código fuente de todo lo que has distribuido.

Esto no es una hipótesis. Los descompiladores y desensambladores modernos han democratizado la ingeniería inversa hasta un punto que habría parecido impensable hace veinte años. Un analista competente con herramientas gratuitas puede tomar una aplicación móvil, eliminar su capa de ofuscación en una tarde, extraer claves codificadas en cuestión de horas y mapear toda la superficie de comunicación del servidor de la aplicación en uno o dos días. Las herramientas son sofisticadas. La documentación es extensa. Las comunidades en torno a estas herramientas son activas.

Las chicas malas no necesitaban ser más inteligentes que los chicos malos. Simplemente necesitaban más información sobre ellos de la que ellos tenían sobre ellas. En la película, esa asimetría se construyó mediante la observación y la investigación minuciosas. En la seguridad de las aplicaciones, el atacante crea esa asimetría en el momento en que descarga tu aplicación de la tienda.

03 El problema de la pata carmesí: Cuando el secreto sale de la caja

El momento más instructivo de Bad Guys 2 no es el atraco, sino las imágenes grabadas.

La gobernadora Diane Foxington tiene una identidad secreta: la Pata Carmesí, su antiguo alter ego criminal. Ese secreto se ha mantenido celosamente durante años. Es la base de su autoridad pública, su legitimidad política y su relación con Wolf. Es, en todo sentido, una clave criptográfica: una pieza de información oculta de la que depende todo un sistema de confianza.

Kitty Kat tiene las grabaciones. Las usa para chantajear a los villanos y obligarlos a cooperar con su robo. En el clímax, cuando Wolf cree haber recuperado la memoria USB con las grabaciones, Kitty las sube a internet de todos modos. La identidad secreta de Diane se difunde mundialmente. El chantaje se esfuma, pero también todo lo que el secreto protegía. La credibilidad de la gobernadora, su relación, su carrera política —todo supeditado a que esa clave permaneciera oculta— se derrumban simultáneamente.

Esto es precisamente lo que ocurre cuando se extraen las claves criptográficas de una aplicación.

La clave es el secreto. El secreto es el fundamento del sistema de confianza. Una vez extraído —una vez que el atacante lo obtiene—, da igual cómo respondas. La exposición es asimétrica e irreversible. Puedes rotar la clave, parchear la aplicación, revocar el certificado. El atacante ya tiene lo que necesitaba.

El error de Wolf fue creer que tener la memoria USB significaba controlar el secreto. El secreto ya había salido de la caja. En el desarrollo de aplicaciones móviles y web, este error es estructural. Las claves integradas en los binarios no son secretos. Son información pública con un retraso temporal. El retraso es el que tarda un analista competente en examinarla.

04 El engaño de la memoria USB

Existe un modo de fallo que aparece constantemente en el pensamiento sobre seguridad de aplicaciones: la confusión entre el contenedor y el secreto. Las organizaciones tratan las claves como si su seguridad dependiera de la seguridad del lugar donde las almacenan. ¿Módulo de seguridad de hardware? Seguro. ¿Bóveda de claves cifrada? Segura. ¿Integrada en el binario de la aplicación móvil? Bueno, usamos una herramienta de ofuscación de terceros, así que…

Wolf creía que la memoria USB contenía las grabaciones. Kitty ya había hecho copias y la carga estaba programada antes de que ella entregara nada. El dispositivo físico era un simple atrezo. Un marcador de posición. Algo para entregar y así Wolf dejaría de buscar las grabaciones reales, que para entonces ya existían en una infraestructura a la que él no tenía acceso.

La ofuscación es la unidad flash. No es el vídeo.

Esto es algo que la industria aprende y olvida constantemente. La ofuscación dificulta la ingeniería inversa y aumenta los costos. Para algunos modelos de amenazas, el aumento de costos es una medida defensiva eficaz. Pero para cualquier atacante con la motivación suficiente —un Estado, una organización delictiva financiera, un competidor con recursos— la ofuscación solo retrasa el proceso, no lo defiende. La clave sigue estando en el código binario. Un analista experto la encontrará. Puede que tarde tres días en lugar de tres horas, pero el resultado es el mismo.

La criptografía clásica se diseñó bajo la premisa de que los algoritmos son públicos y las claves secretas. Todo el entramado teórico del cifrado moderno solo se sostiene mientras esa premisa sea válida. En un entorno donde la aplicación se ejecuta en hardware controlado por el atacante —cada dispositivo móvil, cada terminal de IoT, cada aplicación cliente— la premisa falla. La clave se encuentra en algún lugar del código binario.

Con tiempo y herramientas, se puede encontrar. La única arquitectura criptográfica que sobrevive a la extracción de claves es aquella en la que dicha extracción no produce ningún resultado útil.

05 Susan nunca fue Susan: La amenaza interna como canal de extracción de información

La novia de Snake, Susan, es Doom. No parece una amenaza; parece una relación. Snake, cada vez más ausente de las operaciones de los Bad Guys, comparte tiempo con alguien que ha cultivado el acceso que ella necesita. No necesita traspasar el perímetro; está dentro. Snake la deja entrar.

La posición interna es uno de los vectores de ataque más fiables tanto en el cine como en la realidad. Las Chicas Malas no necesitaban comprometer a los Chicos Malos mediante un ataque externo. Necesitaban un nodo de confianza dentro de la red de relaciones, y Snake se lo proporcionó sin saber que lo hacía.

En seguridad de aplicaciones, esto se relaciona directamente con la cadena de suministro. El vector más peligroso contra una aplicación reforzada no es la aplicación en sí, sino aquello en lo que confía. SDK de terceros. Dependencias de código abierto. Servicios API. Paquetes de análisis. Cada biblioteca externa que su aplicación inicializa en tiempo de ejecución tiene, en principio, el mismo acceso al estado de ejecución de su aplicación que su propio código. Si esa biblioteca se ve comprometida, o si era maliciosa desde el principio, la relación de confianza que haya construido en su propio código base deja de ser relevante.

La Infracción de SolarWinds de 2020 El ejemplo canónico a nivel de infraestructura es la vulneración de un sistema de compilación que distribuyó actualizaciones maliciosas a través de canales de confianza a miles de organizaciones. Sin embargo, este patrón se extiende habitualmente a las aplicaciones móviles. Un proveedor legítimo adquiere un SDK móvil. El nuevo propietario lanza una actualización con exfiltración de datos integrada. Todas las aplicaciones que descargaron automáticamente ese SDK ahora ejecutan código que viola todos los supuestos de confianza sobre los que se basa. El perímetro nunca se violó. La relación de confianza fue el objetivo del ataque.

Susan nunca fue Susan. Puede que tu SDK de análisis no sea tu SDK de análisis.

06 Pigtail conoce tus firmas

Pigtail Petrova, la ingeniera de jabalíes entre las Chicas Malas, es el personaje más interesante desde el punto de vista técnico de la película. Fue ella quien incriminó a los Chicos Malos. Lo hizo no por la fuerza bruta, sino mediante la imitación. Estudió los métodos de los Chicos Malos —sus señas de identidad, su forma de actuar, sus delatores— con tanta minuciosidad que pudo producir crímenes que parecían indistinguibles de los suyos. Los Chicos Malos fueron culpados de robos que no cometieron porque Pigtail podía imitar su comportamiento a nivel funcional.

Esto es ingeniería inversa aplicada a la inteligencia competitiva. Es también lo que hacen los atacantes financieros sofisticados con los sistemas de autenticación de aplicaciones.

Cuando un atacante realiza ingeniería inversa completa de una aplicación de banca móvil, no solo encuentra claves, sino también su comportamiento. Comprende la secuencia de llamadas a la API que constituye una sesión legítima. Comprende el protocolo de desafío-respuesta que la aplicación utiliza para demostrar su autenticidad al servidor. Comprende qué telemetría del dispositivo envía la aplicación, qué encabezados incluye y qué patrones de tiempo caracterizan el uso normal. Con esa información, puede crear un emulador: un cliente sintético que imita el comportamiento de la aplicación con la suficiente precisión como para superar la validación del servidor.

El servidor detecta solicitudes que aparentan provenir de una aplicación legítima. Son indistinguibles desde el punto de vista forense de las solicitudes legítimas porque el atacante realizó ingeniería inversa de la firma de la solicitud legítima y la replicó. El fraude es invisible hasta que el patrón de fraude se vuelve detectable, momento en el que el atacante ya ha realizado miles de transacciones.

07 MacGuffinite y el verdadero gol

Los cineastas provocaron risas genuinas al llamar a su objeto clave "MacGuffinita", un metal raro capaz de atraer oro magnéticamente. La broma es una referencia a Hitchcock: un MacGuffin es aquello que la trama exige que todos deseen, independientemente de su significado intrínseco. La MacGuffinita es el pretexto. El verdadero objetivo es extraer todo el oro del mundo de la Estación Espacial Multinacional. El elaborado atraco es la infraestructura para el objetivo real, que opera a una escala completamente distinta.

Los equipos de seguridad están entrenados para defender el MacGuffinite. El atacante busca otra cosa.

Cuando un atacante realiza ingeniería inversa en tu aplicación móvil, el objetivo obvio son las claves criptográficas. Pero las claves suelen ser solo un instrumento. Lo que el atacante realmente busca podría ser la capacidad de generar tokens de autenticación válidos a gran escala, lo que le permitiría tomar el control de las cuentas de millones de usuarios. Podría ser la capacidad de interceptar y modificar datos financieros en tránsito sin activar la fijación de certificados. Podría ser la capacidad de clonar la identidad de la aplicación para acceder directamente a los servicios de backend, eludiendo todos los controles que la aplicación implementa en la capa del cliente.

La clave está en el robo del reloj inteligente durante la boda. Impecable, preciso, casi imperceptible. Lo realmente interesante es lo que sucede después.

08 El perímetro siempre fue una propuesta, no un muro.

La industria de la seguridad dedicó casi dos décadas a construir perímetros de seguridad. Cortafuegos, sistemas de detección de intrusiones, segmentación de redes, arquitectura de confianza cero. El modelo subyacente: mantener a los ciberdelincuentes fuera, confiar en lo que está dentro y defender la frontera entre ambos.

El modelo tenía sentido cuando la aplicación residía en tu hardware, en tu centro de datos, detrás de tu cortafuegos. Empezó a tener problemas cuando la aplicación se trasladó a la nube. Falló por completo cuando la aplicación pasó a estar disponible en el móvil del usuario.

Una aplicación móvil se implementa en hardware controlado por el atacante. Un dispositivo IoT se implementa en hardware que el atacante puede controlar físicamente. Una aplicación web se carga en un navegador que el atacante puede inspeccionar. En ninguno de estos entornos se cumple el modelo de perímetro. La aplicación no se encuentra dentro del perímetro. La aplicación está fuera del perímetro, ejecutándose en un entorno hostil, desde el momento de su lanzamiento.

Este es el problema arquitectónico que la seguridad perimetral no puede resolver. Puedes lograr que tu entorno de servidor sea impecable. Cero vulnerabilidades en la infraestructura. Segmentación de red perfecta. Controles de acceso impecables en cada servicio de backend. Y luego, tu aplicación móvil se distribuye con una clave de servicio codificada y un esquema de ofuscación que un analista junior con un fin de semana libre puede eliminar. El atacante no toca tu servidor. Toca tu aplicación, que se comunica fluidamente con tu servidor.

09 La geometría de la superficie de ataque ha cambiado

Servicios financieros. Salud. Contratación de defensa. Telecomunicaciones. Todas las industrias que han digitalizado sus operaciones de atención al cliente en la última década han trasladado, sin saberlo, su superficie de ataque del centro de datos al dispositivo final. Los datos confidenciales, la lógica de autenticación, las operaciones criptográficas: todo ello se ejecuta ahora, al menos en parte, en hardware que la organización no posee ni controla.

Las implicaciones para la criptografía son específicas y a menudo subestimadas. La criptografía clásica —los cifrados AES-256, las firmas RSA, los protocolos de enlace TLS— es demostrablemente segura bajo el supuesto de que la clave es secreta. Este supuesto no es matemático, sino físico. Las matemáticas del cifrado moderno son sólidas. El problema reside en el supuesto.

Cuando una aplicación realiza operaciones criptográficas en un dispositivo controlado por el atacante, este puede observar la memoria de la aplicación en el momento en que se carga la clave, se ejecuta la operación y se genera el resultado. Un tipo de ataque, denominado ataque de canal lateral, explota precisamente esta vulnerabilidad: el consumo de energía, las emisiones electromagnéticas, las variaciones de tiempo y los patrones de acceso a la caché filtran información sobre la clave utilizada. En un ataque de caja blanca, el atacante va más allá, tratando la aplicación como una caja abierta para el análisis y extrayendo la clave directamente del código compilado.

AES-256 sigue siendo AES-256. Pero cuando la clave es accesible, el cifrado es tan seguro como la confidencialidad de la clave, y la confidencialidad de la clave es cero, o casi cero.

10. El endurecimiento binario no es ofuscación. La criptografía de caja blanca no es cifrado.

Es aquí donde el debate sobre seguridad debe ser más preciso, porque la confusión entre estos conceptos les cuesta a las organizaciones dinero real y las expone a riesgos reales.

La ofuscación transforma el código para hacerlo más difícil de leer. Renombra variables, simplifica el flujo de control, inserta código basura y cifra cadenas. Un analista perseverante acabará por descubrir la verdad. La ofuscación es una demora. Es como una memoria USB.

El endurecimiento binario es algo diferente. Instrumenta la propia aplicación con defensas que hacen que cualquier manipulación sea detectable o inoperante. Técnicas anti-depuración que detectan cuando la aplicación se ejecuta con un depurador y alteran su comportamiento. Comprobaciones de integridad que verifican el código de la aplicación en tiempo de ejecución y rechazan la ejecución si se detectan modificaciones. Controles anti-manipulación que detectan si la aplicación se ejecuta en un entorno emulado. Comprobaciones ambientales que identifican condiciones de root/jailbreak indicativas de un dispositivo adversario. El endurecimiento binario no solo ralentiza al analista, sino que cambia la economía de los ataques al hacer que los flujos de trabajo de ingeniería inversa más comunes sean poco fiables.

La criptografía de caja blanca aborda directamente el problema de la exposición de claves. En la criptografía de caja negra estándar, la clave es un dato de entrada independiente para la operación criptográfica. En la criptografía de caja blanca, la clave está integrada matemáticamente en la propia implementación, mediante una serie de transformaciones matemáticas que la hacen irrecuperable incluso cuando el atacante tiene acceso completo al código y a la memoria, y puede observar cada cálculo intermedio. La operación criptográfica sigue produciendo resultados correctos. La clave no se puede extraer de la implementación. No hay ninguna unidad flash que entregar.

No se trata de mejoras graduales en el perímetro de seguridad. Son una premisa arquitectónica diferente: en lugar de intentar mantener a los atacantes alejados de tu aplicación, creas una aplicación que permanece segura incluso cuando los atacantes tienen acceso total a ella.

11 Inteligencia de amenazas basada en aplicaciones: saber cuándo las malas ya están dentro

El problema fundamental de los villanos en la película es su reactividad. Reaccionan ante sucesos inesperados porque desconocían lo que se estaba gestando en su contra. No supieron de las villanas hasta que ellas decidieron revelarse, en el momento y bajo sus propias condiciones.

La seguridad de las aplicaciones siempre ha tenido el mismo problema. El ataque se descubre a posteriori. Los registros se revisan después de la brecha de seguridad. El análisis forense reconstruye las acciones del atacante. El lapso entre la intrusión inicial y su detección —lo que en el sector se denomina tiempo de permanencia— suele oscilar entre semanas y meses. Durante ese lapso, el atacante opera con una asimetría de información totalmente a su favor.

La solución lógica consiste en instrumentación que adelanta la detección en la cadena de ataque: antes de que se complete la extracción de claves, antes de que se utilice el token de sesión falsificado, antes de que el cliente emulado realice su primera llamada fraudulenta. Las aplicaciones que pueden observar su propio entorno de ejecución e informar sobre anomalías (actividad de depuración, patrones inusuales de acceso a la memoria, ejecución en emuladores, código manipulado que se ejecuta en servicios en vivo) generan telemetría que reduce el tiempo de permanencia del atacante.

Cuando tu aplicación puede indicar que se está ejecutando en un depurador, el analista que estudia tu binario deja de ser invisible. Cuando tu aplicación informa que una versión pirateada está llamando a tus servidores, la suplantación de identidad de Pigtail no pasa desapercibida durante meses. La asimetría de la información comienza a colapsar.

12. La pregunta clave antes de realizar el envío

Antes de que los Malos emprendieran cualquier misión, Wolf tenía un plan. Este plan partía de la base de que existían ciertas asimetrías de información a su favor. Sabían cosas que el objetivo desconocía. Poseían capacidades que el objetivo no podía prever. El plan funcionaba mientras existiera dicha asimetría.

Las Chicas Malas revirtieron la situación. Construyeron una imagen más completa de los Chicos Malos de la que estos tenían de sí mismos, al menos en lo operativo. El plan fracasó porque la asimetría de información en la que se basaba ya se había invertido.

Antes de lanzar su próxima aplicación, hágase una pregunta: ¿encontrará algo útil el atacante que realice ingeniería inversa de su código binario?

Si la respuesta es afirmativa —si existen claves, firmas de autenticación replicables o lógica que comprometa la confianza al quedar expuesta—, entonces su plan depende de una asimetría de información que el atacante acabará por cerrar. En algún lugar, están estudiando su trabajo.

Claro que los malos acaban ganando. Es una película para toda la familia. Pero ganan cambiando la asimetría de la información: se infiltran en el plan de Kitty, comprenden su verdadero objetivo y actúan basándose en información que ella desconocía. Así es como se gana en seguridad de aplicaciones. No se gana esperando que las malas nunca estudien tu trabajo. Ya lo han hecho. Se gana asegurándose de que lo que estudiaron no les diga qué hacer a continuación.

Digital.ai Protección de la aplicación

Digital.aiplataforma de Aborda esto desde la capa binaria. El endurecimiento binario protege la aplicación contra los flujos de trabajo más comunes de ingeniería inversa y manipulación: anti-depuración, verificación de integridad, detección ambiental y autoprotección en tiempo de ejecución. La criptografía de caja blanca integra claves en las implementaciones de forma que su extracción sea matemáticamente imposible, en lugar de simplemente inconveniente. La inteligencia adaptada a la aplicación proporciona telemetría sobre lo que le sucede a la aplicación en entornos reales, ya sea que se esté analizando, modificando o suplantando su identidad.

El objetivo no es ralentizar al analista, sino asegurar que lo que encuentre, incluso con acceso completo, no le reporte ninguna ventaja operativa. Si la memoria USB está vacía, Kitty no tiene nada que subir.