Cómo realizar la fijación de SSL en aplicaciones de iOS

Una vez que salimos de casa, es verdad que nos lanzamos en la búsqueda de redes wifi abiertas. Ya sea que estemos en el aeropuerto o testeando la que estamos desarrollando esperando un caffèlatte en el Starbuck’s, lo mas importante es tener una conexión wi-fi abierta. Pero claro con miedo, los piratas informáticos también están en la misma búsqueda. Ellos también esperan a los usuarios inicien una solicitud de conexión en la red abierta antes de poner en funcionamiento sus Pishing’s y obtener toda nuestra información confidencial, o peor aún datos bancarios.

Si bien HTTPS es efectivo hasta cierto punto, es un protocolo SSL que se sabe que hace que los usuarios estén seguros al ser irrompible y en gran medida seguro. Pero el ataque Man-In-The-Middle (MITM) también ha encontrado formas de violar esto.

Aquí es donde SSL Pinning entra en escena como una de las mejores prácticas de seguridad de aplicaciones móviles . Hablando específicamente de plataformas, es la solución de seguridad de aplicaciones de iPhone ideal que hace un trabajo increíble al resolver el problema.

En este artículo, analizaremos el proceso de incorporación de SSL Pinning en aplicaciones de iOS para prevenir estos ataques de Man In The Middle. Un proceso que es una parte activa de la práctica de pruebas de seguridad móvil de OWASP(Open Web Application Security Project).

¿Qué es el SSL Pinning?

Cuando una aplicación móvil se comunica con un servidor, utiliza la técnica de SSL Pinning para proteger los datos transmitidos contra la manipulación y las escuchas. En un modo predeterminado, las implementaciones de SSL utilizadas en las aplicaciones confían en cualquier servidor que tenga certificados de confianza del almacén de confianza de un sistema operativo.

Con SSL Pinning, la aplicación está diseñada para rechazar todos los certificados predefinidos. Cuando la aplicación se conecta con un servidor, compara el certificado con el certificado anclado. Solo cuando hay una coincidencia, el servidor es de confianza y se establece la conexión SSL. Esto es lo que hace que SSL Pinning sea uno de los mejores consejos de seguridad de aplicaciones de iOS que siguen los desarrolladores.

¿Por qúe necesitamos SSL Pinning en iOS?

La tarea de configurar y mantener la sesión SSL se asigna a una biblioteca del sistema. Significa que la aplicación que intenta establecer una conexión no determina qué certificado debe ser confiable y cuál no.

Un pirata informático que puede generar un certificado autofirmado y agregarlo al almacén de confianza del sistema operativo puede configurar un ataque MITM contra aplicaciones que usan SSL. Esto les permite hacer cosas que funcionan de manera opuesta a los consejos de seguridad de la aplicación iOS :

• Lea y modifique todas las sesiones SSL y use el acceso para realizar ingeniería inversa del protocolo de la aplicación o para extraer las claves API de la solicitud, un ejemplo clásico de fraudes de aplicaciones móviles.
• También pueden obstaculizar las sesiones SSL al engañar a los usuarios para que instalen una CA confiable a través de páginas web maliciosas. Las CA raíz en las que confían los dispositivos también pueden verse comprometidas y pueden utilizarse para generar certificados.

Al reducir la cantidad de certificados SSL de iOS confiables , las aplicaciones están protegidas de tales ataques remotos. También ayuda a eliminar la ingeniería inversa, uno de los mayores obstáculos en las pruebas de seguridad de aplicaciones de iOS .

Tipos de implementación de certificado SSL Pinning

La implementación de la fijación SSL le ofrece dos opciones:

• Fijar el certificado: puede descargar el certificado del servidor y agruparlos en la aplicación. En el tiempo de ejecución, la aplicación compara el certificado del servidor con los que ha incrustado.
• Fijar la clave pública: puede recuperar la clave pública del certificado en el código como una cadena. En el tiempo de ejecución, la aplicación comparó la clave pública del certificado con una que está codificada en el código.

Elegir entre los dos métodos de fijación SSL depende de la configuración de su servidor y de las necesidades individuales. Cuando elija la primera opción, tendrá que cargar la aplicación cuando el servidor cambie su certificado o dejaría de funcionar. Al elegir la segunda opción, es posible que infrinja la política de rotación de claves, ya que la clave pública no cambiará.

Veamos ahora cómo hacer que estos métodos sean las mejores prácticas de seguridad de aplicaciones de iOS.

Cómo implementar SSL Pinning en las aplicaciones iOS

En el caso de URLSession, el método principal para manejar la fijación de SSL es URLSession: didReceiveChallenge: deploymentHandler: delegate. Teneis que configurar la clase para que se ajuste a URLSessionDelegate en vuestro BaseProvider y con una extensión de esta clase podeis usar algo así:

Veis que es el mismo método, el caso de arriba es cuando tenemos el certificado que nos entrega le squad de ciberseguridad de nuestro backend, siempre que sea posible, de no ser así, el caso de abajo os permitirá controlar la fijación SSL.

“La funcion de arriba es el mejor de los casos y es fundamental que todos los actores del proyecto lo tengan claro, hay que tener siempre un certificado y para eso se le paga a los especialista de cuberseguridad.”

“La función “ solicita credenciales al delegado en respuesta a una solicitud de autenticación del servidor remoto “. Luego, los desarrolladores compararán los certificados del servidor con uno guardado en el paquete de la aplicación. Si los dos certificados se encuentran idénticos, la autenticación lo dejará pasar y el cliente podrá conectarse al servidor.”

Comprensión de los 10 riesgos principales de OWASP Mobile con casos del mundo real

Junto con otras cosas, también han compilado una lista de las 10 principales amenazas de seguridad de OWASP Mobile 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 desde casos del mundo real.

Os daré una descripción básica de los 10 principales riesgos de seguridad móvil y le daremos ejemplos de las vulnerabilidades reveladas en el mundo real para cada uno de ellos. Os dará una idea de para qué debemos prepararnos cuando trabajamos en aplicaciones móviles.

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

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

De estas aplicaciones, el 50% ha tenido un almacenamiento de datos inseguro y en algún lugar la misma cantidad de aplicaciones estaba funcionando 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 para las aplicaciones móviles y las mejores prácticas para evitarlas

M1: uso inadecuado de la plataforma

La categoría M1 de prueba de seguridad de OWASP consiste en el uso indebido de la funcionalidad de un dispositivo. Puede incluir permisos de plataforma, Widget, App Clip, uso indebido de TouchID, KeyChain, etc.

M2: almacenamiento de datos inseguro

OWASP lo considera una amenaza cuando alguien obtiene acceso a un dispositivo móvil perdido / 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 conlleva estos riesgos:

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

M3: Comunicación insegura

Al diseñar una aplicación móvil, los datos se intercambian en el modelo cliente-servidor. Entonces, cuando se transmiten los datos, primero deben atravesar la red del operador del dispositivo e Internet. Los agentes de amenazas podrían aprovechar las vulnerabilidades e interceptar datos confidenciales mientras viajan por cables. Estos son los diferentes agentes de amenazas que existen:

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

La interceptación de datos sensibles 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.

M4: Autenticación insegura

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

El impacto empresarial de M4 puede ser:

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

M5: Riesgos de criptografía insuficientes

Los agentes de amenaza en este caso son los que tienen acceso físico a datos que fueron encriptados incorrectamente. O cuando un malware actúa en nombre de un 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.

M6: Riesgos de autorización inseguros

En este caso, los agentes de amenazas pueden acceder a la aplicación de otra persona, generalmente a través de ataques automatizados que utilizan herramientas personalizadas o disponibles.

Puede dar lugar a los siguientes problemas:

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

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 pueden ser problemas técnicos que pueden conducir a una degradación del rendimiento, un uso intensivo de la memoria y una arquitectura de front-end que funcione de manera deficiente.

M8: Riesgos de manipulación de códigos

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.

M9: Riesgo de ingeniería inversa

Un atacante normalmente descarga la aplicación de destino 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.

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 backend. El atacante explotaría funcionalidades extrañas de sus propios sistemas sin la participación de los usuarios finales.

Buen finde a todos!!