Seguridad móvil - Vectores de ataque

Por definicin, un Attack Vector es un método o técnica que utiliza un pirata informático para obtener acceso a otro dispositivo informático o red con el fin de inyectar un "código incorrecto" a menudo llamado payload. Este vector ayuda a los piratas informáticos a explotar las vulnerabilidades del sistema. Muchos de estos vectores de ataque aprovechan el elemento humano, ya que es el punto más débil de este sistema. A continuación se muestra la representación esquemática del proceso de los vectores de ataque, que puede ser utilizado por un hacker al mismo tiempo.

Algunos de los vectores de ataque móvil son:

Software malicioso
- Virus y rootkit
- Modificación de la aplicación
- Modificación del sistema operativo
Exfiltración de datos
- Los datos salen de la organización
- Imprimir pantalla
- Copiar a USB y pérdida de respaldo
Manipulación de datos
- Modificación por otra aplicación
- Intentos de manipulación no detectados
- Dispositivos rotos en la cárcel
Pérdida de datos
- Pérdida de dispositivo
- Acceso no autorizado al dispositivo
- Vulnerabilidades de la aplicación

Consecuencias de los vectores de ataque

Los vectores de ataque son el proceso de piratería como se explicó y tiene éxito, a continuación se muestra el impacto en sus dispositivos móviles.

Losing your data - Si su dispositivo móvil ha sido pirateado o se ha introducido un virus, todos los datos almacenados se pierden y el atacante se los lleva.
Bad use of your mobile resources- Lo que significa que su red o dispositivo móvil puede sobrecargarse y no puede acceder a sus servicios originales. En el peor de los casos, el pirata informático puede utilizarlo para conectar otra máquina o red.
Reputation loss- En caso de que su cuenta de Facebook o su cuenta de correo electrónico comercial sea pirateada, el pirata informático puede enviar mensajes falsos a sus amigos, socios comerciales y otros contactos. Esto podría dañar su reputación.
Identity theft - Puede haber un caso de robo de identidad como foto, nombre, dirección, tarjeta de crédito, etc. y la misma puede usarse para un delito.

Anatomía de un ataque móvil

A continuación se muestra una representación esquemática de la anatomía de un ataque móvil. Comienza con la fase de infección que incluye los vectores de ataque.

Infección del dispositivo

La infección del dispositivo con software espía móvil se realiza de forma diferente para los dispositivos Android e iOS.

Android- Se engaña a los usuarios para que descarguen una aplicación del mercado o de una aplicación de terceros, generalmente mediante un ataque de ingeniería social. La infección remota también se puede realizar a través de un ataque Man-in-the-Middle (MitM), donde un adversario activo intercepta las comunicaciones móviles del usuario para inyectar el malware.

iOS- La infección de iOS requiere acceso físico al móvil. La infección del dispositivo también puede ser mediante la explotación de un día cero como el exploit JailbreakME.

Instalación de una puerta trasera

Para instalar una puerta trasera se requieren privilegios de administrador al rootear dispositivos Android y hacer jailbreak a dispositivos Apple. A pesar de que los fabricantes de dispositivos colocan mecanismos de detección de root / jailbreak, el software espía móvil los evita fácilmente.

Android - Los mecanismos de detección de enraizamiento no se aplican al enraizamiento intencional.

iOS - La “comunidad” de jailbreak es vociferante y motivada.

Evitando los mecanismos de cifrado y exfiltrando información

El software espía envía contenido móvil, como correos electrónicos y mensajes cifrados, a los servidores del atacante en texto sin formato. El software espía no ataca directamente el contenedor seguro. Toma los datos en el punto donde el usuario extrae datos del contenedor seguro para leerlos. En esa etapa, cuando el contenido se descifra para el uso del usuario, el software espía toma el control del contenido y lo envía.

¿Cómo puede un hacker beneficiarse de un dispositivo móvil comprometido con éxito?

En la mayoría de los casos, la mayoría de nosotros pensamos qué podemos perder en caso de que nuestro móvil sea pirateado. La respuesta es simple: perderemos nuestra privacidad. Nuestro dispositivo se convertirá en un sistema de vigilancia para que el hacker nos observe. Otras actividades de lucro para el pirata informático es tomar nuestros datos sensibles, realizar pagos, realizar actividades ilegales comoDDoS attacks. A continuación se muestra una representación esquemática.

Los 10 principales riesgos de OWASP Mobile

Cuando hablamos de seguridad móvil, basamos los tipos de vulnerabilidad en OWASP, que es una organización benéfica sin fines de lucro en los Estados Unidos, establecida el 21 de abril. OWASP es una organización internacional y la Fundación OWASP apoya los esfuerzos de OWASP en todo el mundo.

Para dispositivos móviles, OWASP tiene 10 vulnerability classifications.

M1-Uso inadecuado de la plataforma

Esta categoría cubre el uso indebido de una función de la plataforma o el incumplimiento de los controles de seguridad de la plataforma. Puede incluir intenciones de Android, permisos de plataforma, uso indebido de TouchID, el llavero o algún otro control de seguridad que sea parte del sistema operativo móvil. Hay varias formas en que las aplicaciones móviles pueden experimentar este riesgo.

Datos inseguros M2

Esta nueva categoría es una combinación de M2 y M4 de Mobile Top Ten 2014. Esto cubre el almacenamiento de datos inseguro y la fuga de datos no intencionada.

Comunicación insegura M3

Esto cubre un apretón de manos deficiente, versiones de SSL incorrectas, negociación débil, comunicación de texto claro de activos sensibles, etc.

Autenticación insegura M4

Esta categoría captura las nociones de autenticación del usuario final o mala gestión de sesiones. Esto incluye:

No identificar al usuario en absoluto cuando debería ser necesario
No mantener la identidad del usuario cuando se requiere
Debilidades en la gestión de sesiones

Criptografía deficiente en M5

El código aplica criptografía a un activo de información confidencial. Sin embargo, la criptografía es insuficiente de alguna manera. Tenga en cuenta que todo lo relacionado con TLS o SSL va en M3. Además, si la aplicación no usa criptografía cuando debería, probablemente pertenezca a M2. Esta categoría es para problemas en los que se intentó criptografía, pero no se hizo correctamente.

M6-Autorización insegura

Esta es una categoría para capturar cualquier falla en la autorización (por ejemplo, decisiones de autorización en el lado del cliente, navegación forzada, etc.) Es distinta de los problemas de autenticación (por ejemplo, inscripción de dispositivos, identificación de usuario, etc.)

Si la aplicación no autentica a los usuarios en una situación en la que debería (por ejemplo, otorgando acceso anónimo a algún recurso o servicio cuando se requiere acceso autenticado y autorizado), entonces eso es un error de autenticación, no un error de autorización.

Calidad del código del cliente M7

Esta fue la "Decisiones de seguridad a través de entradas no confiables", una de nuestras categorías menos utilizadas. Esta sería la solución general para los problemas de implementación a nivel de código en el cliente móvil. Eso es distinto de los errores de codificación del lado del servidor. Esto capturaría cosas como desbordamientos de búfer, vulnerabilidades de cadenas de formato y varios otros errores a nivel de código donde la solución es reescribir algún código que se está ejecutando en el dispositivo móvil.

Manipulación de código M8

Esta categoría cubre el parcheo binario, la modificación de recursos locales, el enlace de métodos, el swizzling de métodos y la modificación de memoria dinámica.

Una vez que la aplicación se entrega al dispositivo móvil, el código y los recursos de datos residen allí. Un atacante puede modificar directamente el código, cambiar el contenido de la memoria dinámicamente, cambiar o reemplazar las API del sistema que utiliza la aplicación o modificar los datos y recursos de la aplicación. Esto puede proporcionar al atacante un método directo para subvertir el uso previsto del software para beneficio personal o monetario.

M9-Ingeniería inversa

Esta categoría incluye el análisis del binario central final para determinar su código fuente, bibliotecas, algoritmos y otros activos. Software como IDA Pro, Hopper, otool y otras herramientas de inspección binaria brindan al atacante información sobre el funcionamiento interno de la aplicación. Esto se puede utilizar para explotar otras vulnerabilidades incipientes en la aplicación, así como para revelar información sobre servidores back-end, constantes y cifrados criptográficos y propiedad intelectual.

M10-Funcionalidad extraña

A menudo, los desarrolladores incluyen funciones ocultas de puerta trasera u otros controles de seguridad de desarrollo interno que no están destinados a ser lanzados a un entorno de producción. Por ejemplo, un desarrollador puede incluir accidentalmente una contraseña como comentario en una aplicación híbrida. Otro ejemplo incluye la desactivación de la autenticación de 2 factores durante la prueba.