Mobile Application Security: How to Ensure It?

¿Qué es lo que buscan los atacantes en nuestros dispositivos móviles?

• Acceso a credenciales
• Datos personales (direcciones, datos de tarjeta de crédito, localización…)
• Acceder al almacén de datos de la aplicación
• Realizar ingeniería inversa, para localizar vulnerabilidades, credenciales embebidas o algoritmos que generen claves
• Instalación de malware o bloqueo de funciones existentes
• Acceder al dispositivo y controlar las conexiones
• Etc.

Como podemos observar, dotar a nuestra aplicación de mecanismos de seguridad que impidan realizar las acciones anteriores se convierte en algo imprescindible.

Blindaje en aplicaciones móviles: ¿por qué no es lo habitual?

La principal razón es que los desarrolladores hacen hincapié en que éstas funcionen correctamente y en una gama amplia de dispositivos, que cumplan con todos los requisitos definidos… y se focalizan sobre todo en aspectos más atractivos para el usuario como son la usabilidad, la experiencia de usuario y la interfaz gráfica.

Sin embargo, lo esencial es que seamos conscientes de que implementar mecanismos de seguridad en una aplicación móvil es igual de importante, sobre todo teniendo en cuenta el gran volumen de usuarios que pueden hacer uso de la misma.

De hecho, cada vez son más las empresas cuyas aplicaciones deben pasar por un proceso de hacking ético, que trata de hackear un sistema e identificar y reparar posibles vulnerabilidades, lo que previene eficazmente la explotación por hackers maliciosos.

Medidas básicas en seguridad para aplicaciones móviles

Cuando hagamos nuestro desarrollo mobile, debemos poner foco en varias áreas y cumplir una serie de requisitos en cada una de ellas. Para ello, podemos basarnos en el estándar de seguridad de aplicaciones móviles OWASP, que se encarga de prever requerimientos para arquitectos y desarrolladores de software que buscan desarrollar aplicaciones móviles seguras.

Esta guía define 2 niveles de verificación de seguridad, así como un conjunto de requisitos de resistencia a la ingeniería inversa.

La elección del nivel dependerá del contexto de nuestra aplicación. El nivel L1 contiene requerimientos genéricos de seguridad recomendados para todas las aplicaciones móviles. El siguiente nivel, L2, está enfocado a apps que manejan datos altamente sensibles (sector financiero, industria de la salud).

A continuación especificamos los requerimientos de seguridad más destacables que deberíamos tener en cuenta en el desarrollo de nuestra aplicación categorizados en siete áreas, si bien podemos encontrar el listado completo en la propia guía OWASP:

Almacenamiento de datos y privacidad

La protección de datos sensibles, como credenciales e información privada es, además de un imperativo legal, un aspecto crítico en la seguridad móvil.

Algunos de los requisitos que permiten prevenir el acceso a dicha información son los siguientes:

• No guardar información sensible en el almacenamiento local del dispositivo, y en caso de ser necesario, ésta debe ser cifrada usando una clave derivada del hardware de almacenamiento seguro, el cual requiere autenticación previa.
• No escribir información sensible en los logs del sistema ni en copias de seguridad.
• No exponer información sensible como contraseñas o números de tarjeta a través de la IU (interfaz de usuario) o capturas de pantalla, y desactivar la caché del teclado en los campos de texto que contienen dicha información.

Uso de claves criptográficas

A la hora de poder proteger la información sensible almacenada en nuestro dispositivo, la criptografía es un componente fundamental. A la hora de hacer uso de claves criptográficas debemos tener en cuenta los siguientes requisitos:

• No depender únicamente de criptografía simétrica cuyas claves se encuentren directamente en el código fuente de la app.
• No reutilizar una misma clave criptográfica para varios propósitos.
• Los valores aleatorios son generados utilizando un generador de números aleatorios suficientemente seguro.

Autenticación y control de sesiones

Para que una aplicación sea segura, debe contar con un mecanismo de autenticación y control de la sesión de usuario. Si bien es cierto que la mayoría de esta lógica se encuentra en el lado servidor, a continuación indicamos algunos requisitos que debemos tener en cuenta:

• La autenticación biométrica, si la hay, no está asociada a eventos (p. ej. usando una API que simplemente retorna “true” o “false”), si no basada en el desbloqueo del keychain/keystore (almacenamiento seguro).
• Para aplicaciones que gestionan información muy sensible, aplicar mecanismos de doble factor de autenticación.
• Las sesiones y los tokens deben expirar pasado un tiempo predefinido de inactividad por parte del usuario.

Comunicación con servicios

Un aspecto importante en las apps, es garantizar la seguridad en la comunicación con el servidor, asegurando la confidencialidad e integridad de los datos intercambiados. Para ello, algunos requisitos son:

• La información es enviada cifrada utilizando el protocolo TLS.
• La aplicación verifica el certificado X.509 del sistema remoto al establecer el canal seguro y sólo se aceptan certificados firmados por una CA de confianza.
• La aplicación utiliza su propio almacén de certificados o realiza pinning del certificado o la clave pública del servidor.

Interacción con la plataforma móvil

La interacción entre las aplicaciones y los sistemas operativos se debe llevar a cabo teniendo en cuenta los siguientes aspectos:

• La app requiere la cantidad de permisos mínimamente necesaria.
• La aplicación no expone ninguna funcionalidad sensible a través de mecanismos IPC salvo que dichos mecanismos estén debidamente protegidos
• Deshabilitar JavaScript de los Webviews salvo que sea necesario.
• Las WebViews se configuran para permitir el mínimo de los esquemas (idealmente, sólo https). Esquemas peligrosos como file, tel y app-id están deshabilitados.

Calidad del código

A pesar de que las apps no son tan vulnerables a ataques de tipo Cross-Site Scripting, los desarrolladores deben seguir una guía de buenas prácticas para que el código sea seguro:

• La aplicación debe ser firmada y provista con un certificado válido, así como ser publicada en modo release.
• La aplicación captura y gestiona debidamente las posibles excepciones.
• Las funcionalidades de seguridad gratuitas de las herramientas, tales como minificación del byte-code, protección de la pila, soporte PIE y conteo automático de referencias, se encuentran activadas.
• Hacer uso de herramientas que permitan analizar el código fuente para detectar posibles vulnerabilidades como por ejemplo SonarQube.

Mecanismos contra la manipulación e ingeniería inversa

Debemos evitar que un atacante pueda manipular nuestra aplicación o realizar la ingeniería inversa del código. Para ello, existen varios mecanismos que se deben implementar:

• Firmado de la aplicación: Una de las técnicas de seguridad más importantes en Android es el firmado de las aplicaciones utilizando claves públicas y privadas.

A la hora de compilar una aplicación con todos los elementos que la componen (textos, gráficos, código…) cada desarrollador debe asegurarla con su certificado para que la firma identifique la aplicación y resulte posible saber si fue modificada o se mantiene intacta. Esta es la única manera de saber si una app es falsa o es auténtica: en el caso de que se haya modificado la firma, de tenerla, no se corresponderá con el desarrollador original.

• Anti-Tamper: Las técnicas anti-tamper dificultan que un atacante pueda modificar un software, realizando ingeniería inversa y validando su integridad para su posterior uso modificado. Para ello, se verifica que la firma de la aplicación sea la original y se aplican mecanismos de comprobación del checksum.
• Ofuscación del código: La ofuscación del código permite compactar, optimizar y hacer ilegible el código renombrando semánticamente clases, campos, métodos y nombres. El resultado es un aplicativo más pequeño y complejo de realizar ingeniería inversa sobre él, dificultando la comprensión de los mismos ante los ojos maliciosos.
• Verificación del origen del instalador: Con esta técnica se comprueba que la aplicación ha sido distribuida desde el origen confiable, evitando que tengamos en nuestro terminal una copia del apk que haya podido ser infectada con malware.
• Anti-Debug: Las técnicas anti-debug dificultan o detectan la depuración de una aplicación, con el objeto de poder aplicar determinadas acciones que eviten que un atacante continúe con el proceso. El mecanismo más sencillo es a través de una propiedad en el propio manifiesto de la app, si bien se recomienda comprobar dinámicamente y en varios puntos si la depuración está teniendo lugar o no.
• Anti-Emulador: Si nuestra aplicación se está ejecutando en un emulador fuera del proceso de desarrollo, indica que alguien más que nosotros está tratando de analizar la aplicación. Por ello, una buena práctica es comprobar que en una versión release, no se está accediendo a la aplicación mediante un emulador que facilite atacar la seguridad de la misma.
• Anti-Root: Se debe evitar siempre que sea posible que una aplicación se ejecute en terminales rooteados, dado que son terminales mucho más vulnerables y que permiten acceso a la memoria reservada del sistema y de la aplicación, comprometiendo la persistencia y por ende la privacidad de los datos que se manejan.
• Anti-Clone: mecanismo para evitar que la aplicación pueda ser clonada, a este respecto se definirán las propiedades adecuadas para evitar hacer una copia de la aplicación instalada y obtener el binario que un posible atacante podría utilizar para aplicar técnicas de ingeniería inversa.
• Dispositivo confiable: Google dispone de una API anti-abuso (SafetyNet Attestation API), permite evaluar si el dispositivo Android en el que se ejecuta una aplicación es confiable.

Conclusión

Cada día hacemos uso de más aplicaciones móviles y cada vez éstas almacenan una mayor cantidad de información sensible del usuario. Por ello es muy importante estar al día sobre nuevas medidas de seguridad que vayan surgiendo, y aplicarlas de manera proactiva sobre nuestros desarrollos. El objetivo no tiene que ser sólo que el usuario interactúe con una buena UX, si no que también lo haga con total seguridad.

“Ser consciente de las vulnerabilidades es ya la mitad de la seguridad”.