Blog

Las 8 principales vulnerabilidades del código móvil y cómo evitarlas

vulnerabilidades del código móvil

El código móvil está prácticamente en el bolsillo de todos hoy en día. Casi todo el mundo lleva consigo un teléfono móvil. Y debido a que cosas como las aplicaciones antivirus para dispositivos móviles son escasas (incluso inexistentes para los usuarios de iOS), muchas personas creen que los dispositivos móviles no enfrentan tantos riesgos como sus contrapartes de escritorio (o portátiles). Pero si bien lo que está en juego puede diferir, es bastante real y, con el tiempo, puede incluso volverse más ubicuo que lo asociado con la informática tradicional.

En esta publicación, analizamos las siete principales amenazas de códigos móviles y brindamos información sobre cómo mitigarlas.

1 – Mal uso intencionado o no de la plataforma

Independientemente de la marca de dispositivo móvil que utilice, iOS o Android, ambas plataformas brindan pautas de desarrollo a los desarrolladores de aplicaciones. Muchas de estas pautas están relacionadas con la seguridad. Sin embargo, muchos desarrolladores de aplicaciones violan involuntariamente las pautas de la plataforma debido a errores humanos. Y algunos desarrolladores de aplicaciones pueden hacer esto deliberadamente.

Ya sea intencional o no, esta amenaza se reduce al uso indebido de cualquier característica de la plataforma iOS o Android o a la falta de implementación de los controles de seguridad de la plataforma. Y pueden provocar los siguientes problemas:

  • Uso indebido de las funciones Touch ID o Face ID de iOS, lo que podría dar lugar a un acceso no autorizado.
  • Uso inadecuado del llavero seguro de iOS al almacenar claves de sesión dentro del almacenamiento de la aplicación (en lugar de en el llavero), lo que podría comprometer la sesión del usuario.
  • Una aplicación que solicite permisos excesivos o inadecuados podría resultar en escalada de privilegios , lo que potencialmente otorga a la aplicación acceso a más datos del dispositivo de los que debería.
  • Los intents de Android, que se utilizan para provocar una acción o solicitar datos de otra aplicación en el dispositivo, podrían revelar información confidencial o permitir el acceso no autorizado al dispositivo si están marcados como públicos.

Mitigaciones

  • Las plataformas deben implementar caja de arena , que restringe la capacidad de una aplicación para comunicarse con otras aplicaciones (este ya es el caso en iOS). Las plataformas también deberían implementar permisos de archivos predeterminados restrictivos.
  • En el lado de los desarrolladores, los desarrolladores deben aplicar la clase más restrictiva para los llaveros de iOS y cumplir estrictamente con las mejores prácticas de la plataforma para evitar una implementación débil de cualquier tipo de funcionalidad.

2 – Almacenamiento de datos inseguro

Las aplicaciones pueden almacenar datos. Y si esos datos no están suficientemente protegidos, se podría acceder a ellos si alguna vez pierde o le roban su teléfono. Incluso sin perder su dispositivo, el malware podría terminar en su dispositivo y, si sus datos no están protegidos adecuadamente, ese malware puede canalizarlos hacia los atacantes.

Por supuesto, la mitigación a prueba de balas para el almacenamiento de datos inseguro es que la aplicación no almacene ningún dato en absoluto. Pero eso puede no ser factible para muchas, si no para la mayoría, de las aplicaciones. Entonces, como desarrollador, tener los datos de usuario de tu tienda de aplicaciones está bien, siempre y cuando sigas las pautas a continuación.

Mitigaciones

  • Suponga que todos los teléfonos en los que está instalada su aplicación tienen jailbreak/rooteado. Si bien no hay nada malo, per se, en hacer jailbreak o rootear tu teléfono (si sabes lo que estás haciendo), hacerlo tiene menos beneficios que nunca. Y es posible que los usuarios menos experimentados no comprendan las implicaciones de seguridad del jailbreak/rooting. Omite el espacio aislado del sistema operativo y proporciona acceso completo al sistema de archivos. En muchos casos, un teléfono con jailbreak/rooteado también evitará el cifrado predeterminado del teléfono. En resumen, no asuma que los usuarios no tendrán acceso al sistema de archivos y cree sus aplicaciones en consecuencia.
  • A medida que crea su aplicación, asegúrese de comprender si cifrado se aplica correctamente en las ubicaciones de archivos relevantes para su aplicación y que también comprende cómo se protegen las claves de cifrado y dónde se almacenan.
  • Intente reforzar su código contra la manipulación implementando ofuscación, protección contra desbordamientos del buffer , etc.
  • Evite almacenar/almacenar datos en caché siempre que sea posible.

3- Comunicación y transferencia de datos inseguras

La comunicación insegura podría filtrar información confidencial incluso si la aplicación en sí se creara de acuerdo con las pautas de la plataforma. Cosas como ataques de intermediario y omisión de autenticación son posibles si la aplicación que inicia la comunicación con un servidor remoto no cuenta con las salvaguardas de autenticación y cifrado adecuadas. Si bien estas salvaguardas son cruciales prácticamente en cualquier contexto, se vuelven absolutamente críticas en el contexto de las aplicaciones bancarias y de compras, por ejemplo.

Mitigaciones

  • Implementar TLS/HTTPS para cualquier comunicación a través de la web.
  • También se recomienda implementar la fijación de certificados, un método adicional de validación del certificado del servidor que agrega una capa adicional de seguridad. Además de realizar las verificaciones predeterminadas del certificado presentado por el servidor, como validar la cadena de certificados en un certificado raíz. Con la fijación de certificados, la aplicación también verificará otras características del certificado, como su número de serie y clave pública. La fijación de certificados es más sólida que el método tradicional en la medida en que ya no es necesario depender únicamente de las autoridades certificadoras (CA) para validar el certificado.
  • Codifique su aplicación para notificar a los usuarios si se detecta un certificado SSL/TLS no válido o si falla el proceso de verificación de la cadena de certificados.

4 – No desinfectar la entrada del usuario

Si su aplicación permite la entrada del usuario que interactúa con su backend (servidor remoto) sin aplicar una desinfección adecuada a esa entrada, está abriendo la puerta a una variedad de ataques:

Si el contenido del usuario se puede cargar en su servidor sin validación (piense en comentarios o reseñas de usuarios), entonces los actores malintencionados podrían cargar scripts maliciosos en los comentarios/reseñas. Una vez cargados, se enviarían a los usuarios desprevenidos que llegaran a esa página. El navegador del usuario ejecutaría automáticamente los scripts porque los consideraría provenientes de una fuente confiable y usted correría el riesgo de ser víctima de los ataques enumerados anteriormente.

Mitigaciones

  • La principal mitigación será algo obvia: si permite la entrada del usuario en su aplicación, desinféctela.
  • Considere que todas las entradas del usuario no son de confianza. Trate los comentarios de todos los usuarios de la misma manera, ya sean usuarios autenticados, usuarios internos o usuarios públicos: no confíe en ellos.
  • Establezca la bandera HttpOnly. Establecer esta marca garantiza que no se podrá acceder a las cookies a través de JavaScript del lado del cliente (como en nuestro ejemplo anterior de robo de cookies), solo a través de HTTP.
  • Asegúrese de configurar comprobaciones de la lista blanca cuando trabaje con archivos o directorios provenientes de entradas controladas por el usuario.

5 – Autenticación insegura

Es fundamental obtener la autenticación correcta al codificar una aplicación. Antes de otorgar acceso al usuario, una aplicación (móvil o de otro tipo) debe autenticar al usuario. Pero una serie de vulnerabilidades pueden permitir a un atacante eludir el mecanismo de autenticación. Cosas como permitir el backend API solicitudes de servicio sin requerir un token de acceso, almacenar contraseñas localmente en el dispositivo o permitir que se establezcan contraseñas débiles son cosas que pueden hacer que los mecanismos de autenticación de una aplicación móvil sean vulnerables a la elusión. Un atacante que aproveche esas vulnerabilidades podría realizar un ataque de escalada de privilegios, lo que provocaría el robo de datos confidenciales y otras cosas buenas...

Mitigaciones

  • Manténgase alejado de los métodos de autenticación locales. Es mejor delegar esta responsabilidad al servidor remoto. Debe configurarse de tal manera que solo permita la descarga de datos de la aplicación después de una autenticación exitosa.
  • No utilice métodos de autenticación débiles, como la identidad del dispositivo. Forzar el uso de autenticación multifactor (MFA).

6 – Criptografía débil o mal implementada

El título de esta sección prácticamente cuenta la historia. Los dos factores principales que pueden comprometer el cifrado de su dispositivo y revelar información confidencial son:

  1. El uso de algoritmos de cifrado débiles
  2. Defectos en la implementación de la proceso criptográfico

Lo anterior puede ocurrir por muchas razones diferentes, que incluyen:

  • Los parámetros de cifrado no están codificados correctamente en la aplicación, lo que provoca una posible omisión.
  • Las claves de cifrado se administran incorrectamente.
  • El uso de cifrado personalizado (no revisado por pares) o algoritmos de hash y cifrado obsoletos, como MD5 y SHA1.

Mitigaciones

  • Utilice únicamente estándares criptográficos y protocolos de cifrado sólidos recomendados por el Instituto Nacional de Estándares y Tecnología (NIST).
  • Almacene únicamente datos confidenciales (como claves de cifrado) en el enclave seguro del dispositivo, al que solo pueden acceder los procesos protegidos. Salvo eso, simplemente evite almacenar información confidencial en el dispositivo siempre que sea posible.

7 – Autorización insegura

Este punto está ligado al punto 5: autenticación insegura. La autenticación y la autorización son dos cosas diferentes. Sin embargo, uno implica el otro. La autenticación determina las autorizaciones de uno. Estamos hablando aquí de permisos de usuario. Una vez que se autentica, a su usuario se le asignan permisos para acceder a ubicaciones y archivos de red específicos. Pero, como sabemos, no todos los usuarios son iguales. Listas de control de acceso (ACL) se utilizan para establecer los permisos de cada usuario en la red. La cuenta de usuario de su recepcionista probablemente no necesite acceso a archivos relacionados con la nómina.

Sin embargo, los esquemas de autorización mal implementados pueden verificar legítimamente la identidad de un usuario sin validar el nivel de permisos de ese usuario. Su esquema de autorización debe hacer cumplir la identidad y los permisos. De no hacerlo, se otorgará a los usuarios legítimos y a los piratas informáticos acceso a información confidencial y se abrirá la puerta a ataques de escalada de privilegios.

Mitigaciones

Valide y aplique los permisos otorgados a un usuario autenticado haciendo referencia a la información presente en los sistemas backend (los servidores de autorización) en lugar de utilizar la información (identificadores) proporcionada por el dispositivo móvil. Y desea asegurarse de que esto suceda para cada usuario.

8 – Calidad general del código

El octavo punto es una especie de categoría general para varios problemas de códigos móviles relacionados con la codificación incorrecta de las aplicaciones cliente que instalamos en nuestros teléfonos inteligentes y tabletas.

Codificar una aplicación es un trabajo complejo y detallado. Un solo carácter adicional en el código puede provocar un comportamiento no deseado dentro de la aplicación. Y parte de ese comportamiento no deseado puede ser peligroso y exponer sus datos confidenciales a actores malintencionados. Las malas prácticas de codificación pueden abrir la puerta a todo tipo de vulnerabilidades explotables.

Además de eso, muchas aplicaciones (¿la mayoría de ellas?) dependen de bibliotecas y SDK de terceros para crear sus aplicaciones de forma más rápida y sencilla. Esto puede ahorrarle algo de tiempo al desarrollador de la aplicación, en la medida en que los SDK de terceros integren de forma nativa la funcionalidad sin necesidad de que el desarrollador codifique esa funcionalidad explícitamente: el SDK se encarga de ello.

Sin embargo, es posible que estos SDK y bibliotecas contengan algunos errores y es posible que no se hayan probado adecuadamente. Estás a merced del control de calidad de sus proveedores cuando utilizas herramientas de terceros porque no eres el propietario del código. Y la mayoría de las veces, cuando se descubre que una aplicación alberga errores a nivel de código, la única solución es reescribir parte del código y enviar una actualización de la aplicación a los usuarios.

Los errores a nivel de código en aplicaciones móviles pueden provocar:

Mitigaciones

Las mitigaciones aquí son simplemente medidas generales de sentido común para cualquier entorno de desarrollo:

  • Asegúrese de probar si hay desbordamientos del búfer, pérdidas de memoria , etc. utilizando herramientas automatizadas
  • Realice revisiones del código fuente y esfuércese por escribir código que sea fácil de entender, que sea coherente en toda la organización y documente su código adecuadamente.

Envolver

Ahí lo tienes. Las vulnerabilidades del código móvil son una amenaza muy frecuente. Y esa amenaza no hará más que crecer a medida que los dispositivos móviles sigan reemplazando a los dispositivos informáticos más tradicionales. Y realmente deberíamos prestar atención a las vulnerabilidades del código móvil porque los dispositivos móviles tienden a proporcionar menos control al usuario que las plataformas informáticas más tradicionales, por lo que realmente es necesario ser consciente de a qué se expone cuando utiliza un dispositivo móvil.

Con suerte, las mitigaciones enumeradas anteriormente le ayudarán en ese sentido.

Como siempre, mantente a salvo.

^