El código móvil está prácticamente en los bolsillos de todos en estos días. 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 omnipresente que los asociados con la informática tradicional.
En esta publicación, analizamos las principales amenazas de códigos móviles y brindamos información sobre cómo mitigarlas.
Indice
Mal uso intencional o no intencional de la plataforma
Independientemente de la marca del dispositivo móvil que utilices, 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 un error humano. 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 de iOS o Android o a la falta de implementación de los controles de seguridad de la plataforma. Y pueden dar lugar a los siguientes problemas:
- Uso indebido de las funciones Touch ID o Face ID de iOS, lo que podría resultar en un acceso no autorizado.
- El uso inadecuado del llavero seguro de iOS almacenando 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 solicita permisos excesivos o inapropiados podría resultar en una escalada de privilegios, lo que podría otorgar a la aplicación acceso a más datos del dispositivo de los que debería.
- Las intenciones de Android, que se utilizan para provocar una acción o para 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 sandboxing, que restringe la capacidad de una aplicación para comunicarse con otras aplicaciones (este ya es el caso en iOS). Las plataformas también deben implementar permisos de archivo predeterminados restrictivos.
Del lado del desarrollador, los desarrolladores deben aplicar la clase más restrictiva para los llaveros de iOS y adherirse estrictamente a las mejores prácticas de la plataforma para evitar una implementación débil de cualquier tipo de funcionalidad.
Almacenamiento de datos inseguro
Las aplicaciones pueden almacenar datos. Y si esos datos no están lo suficientemente protegidos, se podría acceder a ellos en caso de pérdida o robo de tu teléfono. Incluso sin perder tu dispositivo, el malware podría terminar en tu dispositivo, y si tus datos no están protegidos adecuadamente, ese malware puede canalizarlo hacia los atacantes.
Por supuesto, la mitigación a prueba de balas para el almacenamiento inseguro de datos es que la aplicación no almacene ningún dato en absoluto. Pero eso puede no ser factible para muchas, si no la mayoría, de las aplicaciones. Entonces, como desarrollador, tener los datos de usuario de la tienda de aplicaciones está bien, siempre que sigas las pautas a continuación.
Mitigaciones
- Supón que todos los teléfonos en los que está instalada tu aplicación tienen jailbreak/root. Si bien no hay nada de malo, en sí mismo, con hacer jailbreak o rootear tu teléfono (si sabes lo que estás haciendo), hay menos beneficios que nunca al hacerlo. Y es posible que los usuarios menos experimentados no entiendan las implicaciones de seguridad del jailbreak/rooting. Omite el sandboxing del sistema operativo y proporciona acceso completo al sistema de archivos. En muchos casos, un teléfono con jailbreak/rooteado también eludirá el cifrado predeterminado del teléfono. En resumen, no asumas que los usuarios no tendrán acceso al sistema de archivos y crea tus aplicaciones en consecuencia.
- A medida que creas tu aplicación, asegúrate de comprender si el cifrado se aplica correctamente en las ubicaciones de archivos relevantes para tu aplicación y también de comprender cómo se protegen las claves de cifrado y dónde se almacenan.
- Intenta fortalecer su código contra la manipulación implementando ofuscación, protección contra desbordamientos de búfer , etc.
- Evita almacenar datos en caché siempre que sea posible.
Comunicación y transferencia de datos insegura
La comunicación insegura podría filtrar información confidencial incluso si la aplicación en sí se creó de acuerdo con las pautas de la plataforma. Cosas como los ataques man-in-the-middle y el desvío de autenticación son posibles si la aplicación que inicia la comunicación con un servidor remoto no cuenta con las protecciones de autenticación y cifrado adecuadas. Si bien estas salvaguardas son cruciales en prácticamente cualquier contexto, se vuelven absolutamente críticas en el contexto de las aplicaciones bancarias y de compras, por ejemplo.
Mitigaciones
- Implementa 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 para validar el 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 a 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 robusta que el método tradicional en la medida en que ya no es necesario confiar únicamente en las autoridades de certificación (CA) para validar el certificado.
- Codifica tu 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.
No desinfectar la entrada del usuario
Si tu aplicación permite la entrada del usuario que interactúa con tu back-end (servidor remoto) sin aplicar la sanitización adecuada a esa entrada, estás abriendo la puerta a una variedad de ataques:
- Secuencias de comandos entre sitios (XSS)
- Ejecución remota de código (RCE)
- Ataques de cruce de ruta
- Ataques de divulgación de ruta completa, etc.Si el contenido del usuario se puede cargar en tu servidor sin validación (piensa en los comentarios o reseñas de los 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 las secuencias de comandos porque consideraría que provienen de una fuente confiable y correría el riesgo de ser víctima de los ataques mencionados anteriormente.
Mitigaciones
- La mitigación principal será algo obvia: si permites que el usuario ingrese en tu aplicación, desinfecta.
- Considera que todas las entradas del usuario no son de confianza. Trata la entrada de todos los usuarios de la misma manera, ya sean usuarios autenticados, usuarios internos o usuarios públicos: no confíes en ello.
- Establece el indicador HttpOnly. Establecer esta marca garantiza que las cookies no serán accesibles 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úrate de configurar verificaciones de lista blanca cuando trabajes con archivos o directorios provenientes de entradas controladas por el usuario.
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 gran cantidad de vulnerabilidades pueden permitir que un atacante eluda el mecanismo de autenticación. Cosas como permitir solicitudes de servicio de API de back-end 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 omisión.
Un atacante que explote esas vulnerabilidades podría realizar un ataque de escalada de privilegios, lo que provocaría el robo de datos confidenciales y otras cosas.
Mitigaciones
- Mantente 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 solo después de una autenticación exitosa.
- No utilices métodos de autenticación débiles, como la identidad del dispositivo. Forzar el uso de autenticación multifactor (MFA).
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 tu dispositivo y revelar información confidencial son:
- El uso de algoritmos de encriptación débiles
- Fallas en la implementación del 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 conduce a una posible omisión.
- Las claves de cifrado no se gestionan correctamente.
- El uso de cifrado personalizado (no revisado por pares) o algoritmos de cifrado y hash obsoletos, como MD5 y SHA1
Mitigaciones
- Utiliza únicamente estándares criptográficos sólidos y protocolos de cifrado recomendados por el Instituto Nacional de Estándares y Tecnología (NIST).
- Solo almacena datos confidenciales (como claves de cifrado) en el enclave seguro del dispositivo, al que solo pueden acceder los procesos protegidos.
- Salvo eso, simplemente evita almacenar información confidencial en el dispositivo siempre que sea posible.
Autorización insegura
Este punto está vinculado 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 de permisos de usuario. Una vez que te autenticas, a tu usuario se le asignan permisos para acceder a ubicaciones y archivos de red específicos. Pero, como sabemos, no todos los usuarios son iguales. Las listas de control de acceso (ACL) se utilizan para establecer los permisos de cada usuario en la red. La cuenta de usuario de tu recepcionista probablemente no necesite acceso a los archivos relacionados con la nómina.
Sin embargo, los esquemas de autorización mal implementados pueden verificar legítimamente la identidad de un usuario y no validar el nivel de permisos de ese usuario. Tu esquema de autorización necesita hacer cumplir tanto la identidad como los permisos. De lo contrario, los usuarios legítimos y los piratas informáticos tendrán acceso a información confidencial y se abrirá la puerta a ataques de escalada de privilegios.
Mitigaciones
Valida y haz cumplir 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 debes asegurarte de que esto suceda para cada usuario.
Calidad general del código
El octavo punto es una especie de categoría general para varios problemas de código móvil 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 podría exponer tus 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 dependen de bibliotecas y SDK de terceros para crear sus aplicaciones de manera 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 la funcionalidad de forma nativa sin requerir que el desarrollador codifique esa funcionalidad explícitamente; el SDK se encarga de ello.
Sin embargo, estos SDK y bibliotecas pueden contener algunos errores y es posible que no se hayan probado adecuadamente. Estás a merced del control de calidad de tus proveedores cuando utilizas herramientas de terceros porque no posees el 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 las aplicaciones móviles pueden conducir a:
- Vulnerabilidades de cadena de formato
- Desbordamientos de búfer
- Ataques de ejecución remota de código
Mitigaciones
Las mitigaciones aquí son simplemente medidas generales de sentido común para cualquier entorno de desarrollo:
- Asegúrate de comprobar si hay desbordamientos de búfer, fugas de memoria, etc. utilizando herramientas automatizadas
- Realiza revisiones del código fuente y esfuérzate por escribir un código que sea fácil de entender, que sea consistente en toda la organización y documenta tu código correctamente.
Las vulnerabilidades de código móvil son una amenaza muy frecuente. Y esa amenaza solo crecerá a medida que los dispositivos móviles continúen suplantando 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 del usuario que las plataformas informáticas más tradicionales, por lo que realmente debes ser consciente de a qué te expones cuando usas un dispositivo móvil.
Con suerte, las mitigaciones enumeradas anteriormente te ayudarán en ese sentido.