Infiltra tu propia aplicación React Native

Esta es una noticia que no quieres ver. Como propietario de un producto o como negocio, no quieres. Como desarrollador también, no quieres ver este titular apareciendo en el New York Times. Este realmente apareció en 2002, 2020, lo siento, porque el iPhone de Jeff Bezos fue hackeado debido a una vulnerabilidad en WhatsApp, no en iOS, como se mencionó varias veces, por supuesto, hay algunas vulnerabilidades para iOS en sí mismo. Pero esto sucedió porque WhatsApp cometió un error en algún lugar, por lo que fueron, sí, y Jeff Bezos fue infiltrado de esa manera y se escaló en iOS varias veces. Entonces, cada vez que creas una característica o creas código, por supuesto, hay una posibilidad de un error. Y cada error y característica también pueden ser una falla potencial o un punto de entrada potencial para que un actor malintencionado lo use y pueda aprovechar tu aplicación, aprovechar tu negocio. Entonces, en la investigación, se encontró que aproximadamente el 75% de las aplicaciones tienen errores o características que pueden ser utilizadas para infiltrar tu aplicación o aprovechar tu negocio. Por ejemplo, el caso de 7-eleven fue una característica interesante, que utilizaron para restablecer tu contraseña, que, por supuesto, es una funcionalidad obvia, pero pensaron, ¿qué sucede si cambias tu correo electrónico? Entonces, si cambias tu correo electrónico todo el tiempo, tal vez puedas ingresar otro correo electrónico y restablecer tu contraseña de esa manera. Suena genial, pero por supuesto, si alguien nuevo y varias personas nuevas, restablecen contraseñas de otras cuentas de usuario y luego simplemente ordenan todo lo que pueden en línea. Esa característica se utilizó de manera incorrecta varias veces y, como se menciona aquí, también les costó dinero a ellos. Otra cosa que se ve mucho en línea son las aplicaciones falsas. Entonces, utilizan tu marca o tienen tu icono, si también es muy popular, para crear aplicaciones falsas, ponerlas en la tienda de aplicaciones, por ejemplo, iOS o Android, no importa realmente, y tratar de atraerte para que descargues esa aplicación y tratar de obtener privilegios. Por ejemplo, pueden solicitar permisos de contacto para la lista de contactos en la aplicación, aunque tu aplicación normal no lo hace, la aplicación falsa sí lo hace y simplemente carga esa lista de contactos tuya en su propio servidor y trata de hacerlo de esa manera. Otro truco es, por supuesto, lo que hacen es tratar de poner anuncios en tu aplicación. Entonces, hacen una aplicación copia, solo 101, e ingresan código de anuncios en ella. Entonces, si abres la aplicación, hay anuncios que no agregaste, por lo que están obteniendo ganancias de tu aplicación también. Pensarías que Apple y Google harían un gran trabajo protegiendo tu aplicación, por supuesto, porque tienen este proceso de revisión realmente bueno, que a todos les encanta y odian. Pero aún así, hay miles de aplicaciones falsas en la tienda de aplicaciones en este momento. Por supuesto, algunas con grandes marcas, mientras que otras más pequeñas, que hacen esto todo el día. Y también, hay algunas tiendas de aplicaciones que no son realmente tiendas de aplicaciones, sino que son falsas tiendas de aplicaciones con aplicaciones correctas, por ejemplo, porque algunas aplicaciones son costosas y las personas intentan usarlas de forma gratuita. Entonces, irán a una tienda de aplicaciones que no es, por supuesto, la de Google o la de Apple, y luego descargarán la aplicación. Y por lo general, también hay código malicioso allí, porque también necesitan obtener ganancias de ti, por supuesto. En el ejemplo de Fortnite, por ejemplo, Fortnite sigue siendo un juego popular, pero ellos anunciaron que estaban haciendo una versión móvil de él. Hicieron una aplicación de Android que descargaba el juego real, digamos así, por lo que hicieron una aplicación de lanzamiento. Entonces, todos hicieron una aplicación de lanzamiento falsa, que descargaba alguna otra aplicación, que por supuesto escalaba los permisos y, por supuesto, intentaba inyectar todo en tu dispositivo móvil. Otro ejemplo es que no solo atacan tu aplicación, sino también tus herramientas que usas todos los días. Por supuesto, el falso Xcode, como lo llamamos, es un ejemplo de eso. Y no solo las herramientas, sino también tus dependencias. Entonces, todas las dependencias que tienes en tu aplicación son objetivo para llegar a tu dispositivo, ya sea en tu MacBook o laptop.

Y tratan de buscar, por ejemplo, XSKEYS para AWS u otras credenciales que desean tener, o simplemente colocan un minero de criptomonedas en tu dispositivo sin que lo sepas y obtienen beneficios de ti también. Porque en la actualidad, los proyectos de software tienen en promedio alrededor de 203 dependencias, creo que React, por supuesto, tiene algunas más, pero ese es el promedio en este momento, hay muchas formas para que ellos, los actores malintencionados, también accedan a las dependencias y luego intenten acceder a la aplicación.

Especialmente, por supuesto, también intentan hacerlo en tu máquina, para explotar eso, pero también quieren explotar la aplicación que estás creando, por lo que eventualmente llegarán al dispositivo, comprarán tu aplicación y luego intentarán obtener los datos que desean. Creo que el caso de British Airways es uno de los más destacados aquí. Utilizaron Modernizr, que es, por supuesto, un marco web para atacar, pero también lo usaron en dispositivos móviles, y lo que hicieron fue crear un keylogger dentro de Modernizr y luego lo enviaron a BA y cada página en BA recibió ese script, incluida la página de pago, por lo que todo lo que escribiste en la página de pago también se les envió a ellos. Por supuesto, todas las tarjetas de crédito, etc., se les enviaron y lo utilizaron, por supuesto, para realizar todas las compras, etc. BA fue multada con $20 millones el año pasado solo por este hack, por lo que fue un truco realmente costoso que hicieron en ellos. Y también desde el año pasado, supongo, fue el de MPM, el parcial de la interfaz de usuario, fue que agregaron un CryptoMiner para tu máquina. Entonces, si ejecutas eso o agregas la versión más reciente de esa dependencia, entonces, por supuesto, también obtienes ese CryptoMiner. Entonces, ¿qué podemos hacer al respecto?

En primer lugar, y creo que Katie hizo un gran trabajo al decir eso también, conoce tu cargador de servicios y también conoce el código nativo de tu código react native. Por supuesto, la mayoría de las personas conocerán el código JS o el código TypeScript también, pero trata de comprender las otras partes que tu aplicación React Native está utilizando también. Si no puedes hacerlo tú mismo, intenta contratar a alguien o contratar a alguien para ver qué hace el código y qué no hace para que puedas evaluar qué factores de ataque hay en tu código. Documentación, por supuesto, nuevamente agradeciendo a Katie por la React Native documentación de seguridad que hizo para la mayoría del grupo, lo cual es genial. React Native en sí mismo en el sitio web tiene algunas pautas de seguridad, así que síguelas también. Google y Apple, para el lado nativo, también tienen excelentes pautas de seguridad, así que sabrás qué hacer y qué no hacer con tus datos y detalles de seguridad, etc. Un gran reconocimiento a Julia, porque debería haber un video de YouTube aquí, pero supongo que el internet no está funcionando muy bien en este momento. Julia es de Cossack Labs, que es una empresa de seguridad de Ucrania. Ella ya tiene algunas charlas sobre React Native y seguridad desde hace algunos años. Por favor, míralas porque son realmente muy buenas para conocer cómo funciona React Native con el lado nativo también para el puente y todas las cosas que necesitas tener en cuenta. Tenemos OWASP, que es un marco de código abierto. También lo tenemos para la web. Tenemos las 10 principales vulnerabilidades de OWASP para la web. También lo tenemos para dispositivos móviles, que se muestra en la infografía aquí también. Tenemos las 10 vulnerabilidades de seguridad más utilizadas que se utilizan en la práctica. Échales un vistazo. Verifica si tu aplicación se encuentra en ese espacio y trata de mejorar en eso. También tienen otro proyecto, que es el proyecto de requisitos y verificación móvil, que principalmente, por supuesto, hay mucha documentación, pero también tiene una hoja de Excel con todas las cosas que puedes verificar para ver si tu aplicación es segura. No solo el código, sino también el proceso, etc.

Entonces, es un enfoque muy amplio sobre cómo mejorar tu aplicación. Hay muchas cosas geniales allí, así que por favor échales un vistazo.

Tus dependencias, como dije, las dependencias son uno de los vectores de ataque más utilizados en estos días porque es muy fácil ingresar a ellas. La mayoría de las veces, no siempre, pero la mayoría de las veces, como con NPM u otras dependencias que usamos. Así que conoce tus dependencias. Conócelas.

Por supuesto, hay muchas, por lo que una por una, tal vez no sea imposible, pero lleva mucho tiempo. Pero debería ser el caso de que conozcas todas ellas. Si hay una actualización, siempre verifica si es correcta, cuáles son los cambios de código, etc. Y también utiliza tooling.

Hay muchas tooling en línea para realizar tu propia prueba de penetración, por ejemplo, con el marco de seguridad móvil, que es una biblioteca de código abierto con la que puedes ejecutar tu aplicación compilada. Te dirá cuáles son los problemas de seguridad que encontramos en tu aplicación. Y luego, por supuesto, puedes mejorar eso. Por lo tanto, puedes incluirlo en tu CI, por ejemplo, como etapas. También hay algunas herramientas comerciales. Puedes usar Snyk, que es un patrocinador, para verificar tus dependencias. Por lo tanto, escaneará vulnerabilidades, lo cual es genial. También podría ser un paso en tu parte de integración continua.

Y por supuesto, utiliza ESLint, por ejemplo, reglas de ESLint o algo más, para algunas otras cosas que pueden ocurrir en tus aplicaciones, como la lógica que puede ser explotada. Así que úsalo también a tu favor. Y por supuesto, lo genial es lo fácil que es hacerlo.

Así que hagamos una demostración. Hice una aplicación de React Native simple, solo un React Native en ella, y eso es todo. Eso es lo que hice, así que eso es lo que ves aquí. Agregué Jailmonkey, que es de Gantt de InfiniteRat, una excelente biblioteca para detectar si tu dispositivo tiene jailbreak o no, o si tiene root si tienes un Android. Lo que hice fue hacer una comparación, como si tiene root, entonces muestra este texto y esta imagen, y si no, muestra la otra. Y eso es todo, así que es una aplicación realmente simple. Compilé esa aplicación para iOS y Android, y veamos qué podemos hacer con ella. Primero que nada, el IPA y el APK son solo un archivo comprimido, así que puedes descomprimirlo. Y luego se creará una carpeta y podrás ver que hay un plist, por ejemplo, y podrás ver que hay activos y está la propia aplicación, que es el binario.

Y aquí está el código, que es el compilado que hace Metro. Es solo mucho código JavaScript que, por supuesto, se carga durante la ejecución y luego tienes tu aplicación. Entonces, ¿cómo se ve esa aplicación? Instalémosla en mi simulador.

Dice que es una aplicación con jailbreak, porque sí, no creo que puedas hacer root a un simulador en esta parte, así que es solo una aplicación con jailbreak, no con jailbreak, dice, así que eso está bien, un dispositivo, dice, así que está bien. ¿Pero podemos cambiar eso? Entonces, en la aplicación, vemos, veamos, vemos que hay una llamada, es jailbroken, veamos si podemos encontrar eso en el paquete. Sí, aquí está, este es mi fragmento de código, esta es la comparación que estoy haciendo en la aplicación, que es la compilada, y luego tenemos esta, esta es la función en la biblioteca, en la dependencia misma, así que también se compila en tu paquete, por supuesto. Entonces, y esto es solo una comparación, así que ¿por qué no lo hacemos verdadero todo el tiempo? Guárdalo, e instálalo de nuevo, y voilà, dice que es un teléfono con jailbreak, lo cual no existe porque es un simulador, así que con solo mirar el código y buscarlo, puedes modificar tu aplicación. Es tan simple como eso.

Entonces, por supuesto, la parte más difícil es empaquetar de nuevo, podrías decir, pero eso tampoco es tan difícil, empaquetar una aplicación y luego, por supuesto, puedes certificarla con tu propio perfil y ponerla en la tienda de aplicaciones si quieres. Por supuesto, esperemos que Apple la rechace porque es una duplicada, pero aún podrías hacerlo, o puedes ponerla en otra tienda de aplicaciones y simplemente ponerla allí. Podrías decir que es más difícil en código nativo, pero en realidad no es difícil. Tengo una versión de demostración.

Entonces, si abro la propia aplicación, el binario, tenemos el compilador, que es Hopper en este caso. Hay múltiples variantes de lo mismo, por supuesto, en la web. Por lo general, debes pagar por ellos, pero para fines de demostración, esto es genial. Cargará la aplicación. Y luego buscaré la de jailbreak, que estábamos buscando. Ahí está. Veamos qué es. Un poco lento hoy. Vamos. Sí. Entonces, esto es una referencia, como lo llaman, a una función. Así que vamos a ir a esa referencia. No la estructura, sino la función en sí. Y luego dice IERC a la función. Así que puedo hacer doble clic en ella. Y si hago la versión gráfica, entonces verás que también es una comparación. Así que tomará dos pilas.

Esto también, si lo reviso, podría ir hasta el final, supongo. Y decir, como, está bien, esto también es cierto. Así que esto es, por supuesto, el código compilado. Por lo general, también debes hacer cosas en hexadecimal. Pero el booleano es muy fácil, porque puedes usar verdadero o falso, por supuesto. Y luego lo vuelves a empaquetar, lo cual no puedo hacer ahora, porque tengo una versión de evaluación de esto. Así que versión de demostración.

Puedes volver a empaquetar el binario y listo. Y mostrará los mismos resultados también. Entonces, en el código nativo, tampoco es tan difícil de hacer. En Android, tenemos lo mismo. Tenemos tooling, por supuesto, para abrir el APK o AAV, dependiendo de lo que tengas. Y lo que ves es que mostrará todas las clases. Si eres de Java, sabes lo que son. Todas las clases están aquí. Y, por supuesto, en los recursos tenemos el mismo paquete que ya vimos en el ejemplo anterior para iOS, y simplemente lo cambiamos también y lo volvemos a compilar. Así que, por supuesto, hemos hecho eso, es lo mismo.

Pero si usamos variables de entorno, por ejemplo, que se hace muchas veces, y miro las variables de entorno que tenemos aquí en mi aplicación, que es una clave de Google Maps, bueno, bueno, veamos si podemos tomar esa y buscarla en mi aplicación de Android. Así que si la busco, inmediatamente ves que está ahí. Abierto para que todos lo vean. Así que, por supuesto, el caso aquí es no poner claves en tus variables de entorno, simplemente obtenerlas de la web o algo más, porque, como te he mostrado aquí, en un minuto la mayoría de las personas pueden buscarla. Por supuesto, puedes ofuscar la aplicación de Android, lo cual es genial. Pero aún así, si sabes dónde buscar, y también esta no se volverá a ofuscar, puedes buscar el patrón y aún encontrarla. Así que para la última parte, veamos si mi Internet está funcionando. ¿Lo tenemos? No. Bueno, eso es agradable. Bueno, eso es agradable. ¿Lo tuve en cuenta? Veamos. Disculpa por eso. No tengo uno.

Solo intentaré usar mi teléfono. Lo verifiqué antes. Disculpa por eso. Veamos si puedo hacerlo en un segundo. Vamos. Veamos si tenemos Internet. Porque quería mostrar, si usas Code Pooch, por ejemplo, obtiene el código fuente de Internet. Entonces, también, eso puede ser una vulnerabilidad también.

Entonces, si hago clic en esto, con suerte, sí. Dice que tiene una actualización. Genial. Si veo lo que se envía por Internet, veo aquí que mi aplicación está buscando algo. Entonces, buscando la actualización. Y dice, sí, tengo una actualización con una URL de descarga. Eso es bueno. Entonces, si hago clic en eso, obtendrá ese paquete de Internet y aplicará la configuración cambios.

Entonces, ¿qué pasaría si pudiéramos redirigir eso a algo, como con un ataque mínimo, a algo que poseo? Entonces, voy a... Veamos. No, no. Eso no es correcto. Mm-hmm. No. Este. Este. Entonces, voy a decir que esta URL irá a mi propio dispositivo, luego servirá una solicitud HTTPS, y necesito... Porque ya apliqué la actualización, necesito instalar la aplicación nuevamente, porque de lo contrario piensa que ya tiene la actualización correcta. Entonces, instalaré la aplicación. Obtener la actualización, que está aquí. Es solo un archivo zip de CodePush, que también tiene el paquete principal y los recursos. Veamos si funciona.

Dice, bien, lo voy a instalar. Y voilà, es diferente porque también sobrescribí esos. Así que, muchas gracias y mantente seguro.

Muchas gracias, Wouter. Tenemos algunas preguntas de la audiencia. ¿Estás listo? Sí, claro. Muy bien. Bueno, lo primero, ¿cuál es la mejor manera para que los equipos se responsabilicen mutuamente en cuanto a seguridad? ¿Existen buenas herramientas para que los grupos gestionen esto? Es algo bueno. Las herramientas no creo que sean el caso, sino más bien un proceso. Por supuesto, las solicitudes de extracción (PRs) y las revisiones de código son importantes. Así que, si alguien actualiza, por ejemplo, una dependencia, siempre se debe preguntar, ¿lo revisaste? O si alguien realiza un cambio en una funcionalidad, siempre se debe preguntar, ¿verificaste nuestra lista de verificación de seguridad? Eso está bien. La automatización de las herramientas, por supuesto, es importante. No creo que `herramientas` sea la palabra correcta allí. Pero definitivamente debería haber un proceso establecido. Sí. Creo que los procesos son herramientas. Eso también es cierto.

¿Dónde podemos aprender más sobre las precauciones básicas de seguridad para React Native, por ejemplo? Bueno, creo que, como dije en el sitio web de React Native, hay mucha documentación, o Katie ha creado una documentación realmente excelente sobre las pocas cosas que acabo de mostrarte sobre cómo prevenir eso. Así que definitivamente deberías tenerlo en cuenta, sí. Bien. Y tal vez mi pregunta personal. ¿Por qué estás aquí en el lado bueno ayudándonos y no pirateando aplicaciones? ¿Por qué no estás ahí afuera ganando dinero? Porque soy consciente, supongo. Siempre es una pregunta muy buena. Porque, por supuesto, tú mismo puedes ser un actor malintencionado, como explotar a las personas. Y, por supuesto, no queremos eso. Así que supongo que principalmente porque tengo conciencia y no quiero estar en el lado malo y siempre pensar en todo lo que he hecho mal en mi vida. Sí. Principalmente. Gracias. Eres un héroe que merecemos y que realmente necesitamos. Muchas gracias, Walter. Gracias.