Comprender los 10 riesgos principales de OWASP Mobile con casos del mundo real

Tener un historial en la industria de desarrollo de aplicaciones 100 % a prueba de piratería conlleva una responsabilidad y una garantía básica de que ninguna de las soluciones digitales desarrolladas bajo nuestro nombre enfrentará una violación de seguridad.

Para lograrlo, el equipo de control de calidad de Appinventiv está familiarizado con todos los posibles riesgos de seguridad a los que se puede enfrentar una aplicación. Conocer los riesgos facilita ignorar las trampas y crear aplicaciones seguras.

Ayudarnos a estar en la cima del juego cuando se trata de garantizar la seguridad es tener un conocimiento completo de las prácticas de codificación segura de OWASP (Open Web Application Security Project). Es una comunidad en línea de especialistas en seguridad que han desarrollado documentación gratuita, materiales de aprendizaje y herramientas para crear aplicaciones móviles y web seguras.

Junto con otras cosas, también han compilado una lista de OWASP Mobile Top 10 amenazas de seguridad en aplicaciones móviles.

Si bien el documento de prácticas de seguridad de OWASP es bastante claro, a veces puede ser difícil para las empresas conectarlo con casos del mundo real.

En este artículo, le daremos una descripción general básica de los 10 principales riesgos de seguridad móvil y daremos ejemplos de las vulnerabilidades reveladas en el mundo real para cada uno de ellos. Le dará una idea de para qué nos preparamos en Appinventiv cuando trabajamos en su aplicación.

Antes de analizar los riesgos, analicemos las estadísticas.

NowSecure analizó las aplicaciones en la tienda Google Play y la tienda de aplicaciones identificó que más del 85 % de las aplicaciones infringen uno de los riesgos.

De estas aplicaciones, el 50 % tenía un almacenamiento de datos inseguro y, en algún lugar, la misma cantidad de aplicaciones funcionaba con un riesgo de comunicación inseguro . Aquí hay un gráfico que muestra el porcentaje de ocurrencia de los 10 riesgos principales de OWASP Mobile

Lista de las 10 amenazas más comunes a las aplicaciones móviles y las mejores prácticas para evitarlas

M1: uso inadecuado de la plataforma

La categoría de pruebas de seguridad OWASP consiste en el mal uso de la funcionalidad de un dispositivo o la instancia de falla al usar los controles de seguridad de la plataforma. Puede incluir permisos de plataforma, intentos de Android, uso indebido de TouchID, llavero, etc.

Caso del mundo real:

Tres aplicaciones de iOS : "Aplicación de equilibrio físico", "Monitor de frecuencia cardíaca" y "Aplicación de seguimiento de calorías" salieron a la luz para eludir la identificación táctil de Apple. Les pedían a los usuarios que usaran su huella digital para obtener información sobre el estado físico, mientras que la usaban para cobrar dinero de la App Store.

Mejores prácticas para evitar:

• El desarrollador no debe permitir el cifrado de llaveros a través de la ruta del servidor y mantener las claves en un solo dispositivo, de modo que sea imposible explotarlas en otros servidores o dispositivos.
• El desarrollador debe proteger la aplicación a través del llavero para almacenar el secreto de la aplicación que tiene una lista de control de acceso dedicada.
• El desarrollador debe obtener permiso para limitar qué aplicaciones pueden comunicarse con su aplicación.
• El desarrollador debe controlar el primero de la lista OWASP Mobile Top 10 al definir las intenciones explícitas y, por lo tanto, bloquear todos los demás componentes para acceder a la información presente en la intención.

M2: almacenamiento de datos inseguro

OWASP lo considera una amenaza cuando alguien obtiene acceso a un dispositivo móvil perdido o robado o cuando el malware u otra aplicación reempaquetada comienza a actuar en nombre del adversario y ejecuta una acción en el dispositivo móvil.

Una vulnerabilidad de almacenamiento de datos inseguro generalmente conduce a estos riesgos:

• Fraude
• El robo de identidad
• Pérdida de materiales.
• Daño a la reputación
• Infracción de política externa (PCI)

Caso del mundo real :

Las aplicaciones de citas como Tinder, OKCupid y Bumble han sido analizadas una y otra vez por sus prácticas inseguras de almacenamiento de datos. Los fallos de seguridad presentes en estas aplicaciones varían según la viabilidad y la gravedad y la viabilidad, pueden exponer el nombre de los usuarios, los detalles de inicio de sesión, el historial de mensajes e incluso la ubicación, además de otra actividad de la cuenta personal.

Mejores prácticas para evitar:

• Para iOS, las prácticas de seguridad de OWASP recomiendan usar aplicaciones vulnerables creadas a propósito, como iGoat, para modelar amenazas en su marco de desarrollo y aplicaciones. Esto ayudará a los desarrolladores de aplicaciones ios a comprender cómo las API tratan los procesos de la aplicación y los activos de información.
• Los desarrolladores de aplicaciones de Android pueden usar el shell de Android Debug Bridge para verificar los permisos de archivo de la aplicación de destino y DBMS para verificar el cifrado de la base de datos. También deben usar la Herramienta de análisis de memoria y el Monitor de dispositivo Android para asegurarse de que la memoria del dispositivo no tenga datos no deseados.

M3: Comunicación Insegura

Al diseñar una aplicación móvil, los datos se intercambian en un modelo cliente-servidor. Por lo tanto, cuando se transmiten los datos, primero deben atravesar la red del operador del dispositivo e Internet. Los agentes de amenazas podrían explotar vulnerabilidades e interceptar datos confidenciales mientras viajan por cable. Aquí están los diferentes agentes de amenazas que existen:

• Adversario que comparte su red local: un Wi-Fi comprometido
• Dispositivos de red o portadores: torres de telefonía móvil, proxy, enrutadores, etc.
• Malware en el dispositivo móvil.

La interceptación de datos confidenciales a través del canal de comunicación terminaría en una violación de la privacidad, lo que puede conducir a:

• El robo de identidad
• Fraude
• Daño reputacional.

Caso del mundo real:

La empresa de seguridad Rapid7 reveló varias vulnerabilidades asociadas con los relojes inteligentes para niños. Esos relojes se comercializaron como los que usan los padres para rastrear a sus hijos y enviarles mensajes o hacer llamadas en su reloj inteligente.

Se suponía que los relojes debían ser contactados por números de contacto aprobados a través del modo de una lista blanca, pero la compañía descubrió que los filtros ni siquiera funcionaban. Los relojes incluso aceptaban comandos de configuración a través de mensajes de texto. Significaba que un pirata informático podía cambiar la configuración del reloj y poner en riesgo a los niños.

“Puede identificar dónde está el teléfono o el niño, puede obtener acceso al audio o hacer llamadas telefónicas a los niños”, dijo Deral Heiland, líder de investigación de IoT en Rapid7.

Mejores prácticas para evitar:

• Los desarrolladores no solo deben buscar fugas en el tráfico comunicado entre la aplicación y el servidor, sino también el dispositivo que contiene la aplicación y otro dispositivo o red local.

• La aplicación de TLS/SSL para los canales de transporte también es una de las mejores prácticas de seguridad de aplicaciones móviles a tener en cuenta cuando se trata de transmitir información confidencial y otros datos confidenciales.

• Utilice certificados proporcionados por verificaciones de cadena SSL de confianza.
• No envíe datos confidenciales a través de canales alternativos como MMS, SMS o notificaciones automáticas.
• Aplique una capa de cifrado separada a los datos confidenciales antes de enviarlos al canal SSL.

M4: autenticación insegura

Los agentes de amenazas que explotan las vulnerabilidades de autenticación lo hacen a través de ataques automatizados que utilizan herramientas personalizadas o disponibles.

El impacto comercial de M4 puede ser:

• Robo de información
• Daño reputacional
• Acceso no autorizado a los datos.

Caso del mundo real :

En 2019, un atacante cibernético pirateó un banco de EE. UU. y aprovechó la falla del sitio web del banco y eludió la autenticación de dos factores que se implementó para proteger las cuentas.

El atacante inició sesión en el sistema a través de las credenciales de la víctima robadas y al llegar a la página donde se debía ingresar el PIN o la respuesta de seguridad, el atacante usó una cadena manipulada en la URL de la web, que había configurado la computadora como reconocida. Esto le permitió cruzar el escenario e iniciar las transferencias bancarias.

Mejores prácticas para evitar:

• El equipo de seguridad de la aplicación debe estudiar la autenticación de la aplicación y probarla mediante ataques binarios en modo fuera de línea para determinar si se puede explotar.
• Los protocolos de seguridad de prueba de aplicaciones web de OWASP deben coincidir con los de las aplicaciones móviles.
• Utilice métodos de autenticación en línea tanto como sea posible, al igual que en el caso del navegador web.
• No habilite la carga de datos de la aplicación hasta que el servidor haya autenticado las sesiones de los usuarios.
• Los lugares donde los datos locales son eventuales, asegúrese de que estén encriptados a través de una clave encriptada derivada de las credenciales de inicio de sesión de los usuarios.
• La solicitud de autenticación persistente también debe almacenarse en el servidor.
• El equipo de seguridad debe tener cuidado con los tokens de autorización centrados en el dispositivo en la aplicación, ya que si el dispositivo es robado, la aplicación puede volverse vulnerable.
• Dado que el acceso físico no autorizado a los dispositivos es común, el equipo de seguridad debe hacer cumplir la autenticación de credenciales de usuario regular desde el extremo del servidor.

M5: Riesgos criptográficos insuficientes

Los agentes de amenazas en este caso son los que tienen acceso físico a los datos que se cifraron incorrectamente. O cuando un malware actúa en nombre del adversario.

La criptografía rota generalmente resulta en estos casos:

• Robo de información
• Robo de Propiedad Intelectual
• Robo de código
• Violaciones de privacidad
• Daño reputacional.

Caso del mundo real :

A veces, una alerta del Equipo de Respuesta a Emergencias Cibernéticas de DHS Industrial Control Systems y el aviso de Philips advirtieron a los usuarios sobre una posible vulnerabilidad en la aplicación Philips HealthSuite Health para Android .

El problema, que se remontaba a una fuerza de cifrado inadecuada, abrió la aplicación a los piratas informáticos que podían acceder a la actividad del ritmo cardíaco, la presión arterial, el estado de sueño, el peso y el análisis de la composición corporal de los usuarios, etc.

Mejores prácticas para evitar:

• Para resolver este uno de los riesgos móviles más comunes de OWASP Top 10 , los desarrolladores deben elegir algoritmos de cifrado modernos para cifrar sus aplicaciones. La elección del algoritmo se ocupa de la vulnerabilidad en gran medida.
• Si el desarrollador no es un experto en seguridad, debe abstenerse de crear sus propios códigos de cifrado.

M6: Riesgos de autorización insegura

En este caso, los agentes de amenazas pueden acceder a la aplicación de otra persona, por lo general a través de ataques automáticos que utilizan herramientas personalizadas o disponibles.

Puede dar lugar a los siguientes problemas:

• Robo de información
• Daño reputacional
• Fraude

Caso del mundo real :

Los especialistas en seguridad de la información de Pen Test Partners piratearon Pandora , un sistema inteligente de alarma para automóviles. En teoría, la aplicación se usa para rastrear un automóvil, apagar el motor si es robado y bloquearlo hasta que llegue la policía.

En el otro lado de la moneda, un pirata informático puede secuestrar la cuenta y obtener acceso a todos los datos y las funciones de alarma inteligente. Además, podrían:

• Seguir los movimientos de los vehículos
• Habilitar y deshabilitar el sistema de alarma
• Bloquear y desbloquear las puertas del coche
• corta el motor
• En el caso de Pandora, los hackers accedieron a todo lo que se hablaba dentro del coche a través del micrófono del sistema antirrobo.

Mejores prácticas para evitar:

• El equipo de control de calidad debe probar periódicamente los privilegios de los usuarios mediante la ejecución de tokens de sesión de privilegios bajos para los comandos confidenciales.
• El desarrollador debe tener en cuenta que los esquemas de autorización de usuarios fallan en el modo fuera de línea.
• La mejor manera de evitar este riesgo es ejecutar comprobaciones de autorización de permisos y roles de un usuario autenticado en el servidor, en lugar del dispositivo móvil.

M7: Riesgos de mala calidad del código

En estos casos, las entidades pasan las entradas que no son de confianza a las llamadas de método realizadas en el código móvil. Un efecto de esto puede ser problemas técnicos que pueden conducir a una degradación del rendimiento, un uso intensivo de la memoria y una arquitectura front-end deficiente.

Caso del mundo real :

El año pasado, WhatsApp reparó una vulnerabilidad que los piratas informáticos estaban aprovechando para instalar un malware de vigilancia llamado Pegasus Spyware en los teléfonos inteligentes. Todo lo que tenían que hacer era realizar una llamada de audio de WhatsApp en los números de teléfono objetivo.

Con unos simples pasos, los piratas informáticos pudieron ingresar a los dispositivos de los usuarios y acceder a ellos de forma remota.

Mejores prácticas para evitar:

• De acuerdo con las prácticas de codificación segura de OWASP , el código debe reescribirse en el dispositivo móvil en lugar de corregirlo en el lado del servidor. Los desarrolladores deben tener en cuenta que la codificación deficiente en el lado del servidor es muy diferente a la codificación deficiente en el nivel del cliente. Es decir, tanto los controles del lado del servidor débiles como los controles del lado del cliente deben recibir atención por separado.
• El desarrollador debe utilizar herramientas de terceros para el análisis estático a fin de identificar desbordamientos de búfer y pérdidas de memoria.
• El equipo debe crear una lista de bibliotecas de terceros y verificar periódicamente si hay versiones más nuevas.
• Los desarrolladores deben ver todas las entradas del cliente como no confiables y validarlas independientemente de si provienen de los usuarios o de la aplicación.

M8: Riesgos de alteración del código

Por lo general, en este caso, un atacante aprovecha la modificación del código a través de formas maliciosas de las aplicaciones alojadas en las tiendas de aplicaciones de terceros. También pueden engañar a los usuarios para que instalen una aplicación mediante ataques de phishing.

Mejores prácticas para evitar:

• Los desarrolladores deben asegurarse de que la aplicación pueda detectar cambios de código en tiempo de ejecución.
• Se debe verificar el archivo build.prop para detectar la presencia de ROM no oficial en Android y para averiguar si el dispositivo está rooteado.
• El desarrollador debe usar sumas de verificación y evaluar las firmas digitales para ver si se ha producido una manipulación del archivo.
• El codificador puede asegurarse de que las claves, el código y los datos de la aplicación se eliminen una vez que se detecte la manipulación.

M9: Riesgo de ingeniería inversa

Un atacante normalmente descarga la aplicación objetivo de la tienda de aplicaciones y la analiza dentro de su entorno local con un conjunto de herramientas diferentes. Después de lo cual, pueden cambiar el código y hacer que la aplicación funcione de manera diferente.

Caso del mundo real :

Pokemon Go se enfrentó recientemente a las miradas de violación de seguridad cuando se descubrió que los usuarios habían realizado ingeniería inversa de la aplicación para conocer la vecindad de los Pokémon y atraparlos en minutos.

Mejores prácticas para evitar:

• La mejor manera de proteger una aplicación contra el riesgo, según la seguridad móvil de OWASP , es usar las mismas herramientas que los piratas informáticos usarían para la ingeniería inversa.
• El desarrollador también debe ofuscar el código fuente para que sea difícil de leer y luego aplicar ingeniería inversa.

M10: Riesgo de funcionalidad extraña

Por lo general, un pirata informático observa la funcionalidad extraña dentro de una aplicación móvil para descubrir las funcionalidades ocultas en los sistemas de back-end. El atacante explotaría la funcionalidad extraña de sus propios sistemas sin la participación de los usuarios finales.

Caso del mundo real :

La idea de la aplicación Wifi File Transfer era abrir un puerto en Android y permitir conexiones desde la computadora. ¿ El problema ? Ausencia de autenticación, como contraseñas, lo que significa que cualquiera podría conectarse a un dispositivo y obtener su acceso completo.

Mejores prácticas para evitar:

• Asegúrese de que no haya código de prueba en la compilación final
• Asegúrese de que no haya un interruptor oculto en los ajustes de configuración
• Los registros no deben contener ninguna descripción del proceso del servidor backend
• Asegúrese de que los OEM no expongan los registros completos del sistema a las aplicaciones.
• Los puntos finales de la API deben estar bien documentados.