Guía de seguridad de transporte de aplicaciones iOS (ATS)

Recientemente noté un aumento en las preguntas de nuestros clientes, y específicamente de los analistas de seguridad, sobre App Transport Security (ATS), o NSAppTransportSecurity, para aplicaciones de iOS. ATS es una práctica de seguridad crítica para nuestros clientes en servicios financieros y otras industrias reguladas. Ya existe mucha documentación ATS, pero las preguntas persisten. Una parte central de la misión de NowSecure es ayudar a las organizaciones a maximizar la seguridad de sus aplicaciones móviles. Entonces, como analista de seguridad, quería redactar una guía rápida para ATS: para analistas de seguridad, por un analista de seguridad — para cubrir temas como:

• NSAllowsArbitraryLoads y otras excepciones ATS
• Auditoría y evaluación de la implementación de ATS de una aplicación
• Por qué ATS es una medida de seguridad crucial
• Pistas que ofrecen las configuraciones de ATS para las pruebas de caja negra
• Un resumen rápido de algunas actualizaciones de ATS que vienen en iOS 11

ATS brinda una protección del lado del cliente muy necesaria para las aplicaciones de iOS, impone cifrados más fuertes y evita el uso de HTTP y el tráfico HTTPS inseguro de una aplicación, una prioridad para la mayoría de los analistas de seguridad con los que hablo. Al ayudar a mitigar los riesgos de conexiones inseguras, ATS se puede usar dentro de las aplicaciones de iOS para hacer cumplir las protecciones del lado del servidor.

Descripción general de seguridad de transporte de aplicaciones (ATS)

ATS permite a los desarrolladores de aplicaciones móviles implementar una política de seguridad de red para sus aplicaciones en el lado del cliente al prohibir el uso de protocolos de texto simple, certificados autofirmados no válidos para conexiones TLS y conjuntos de cifrado débiles. Estas políticas se configuran en la aplicación Info.plist archivo y se introdujeron en iOS 9.

Apple anunció originalmente que las aplicaciones publicadas en la tienda de aplicaciones tendrían que implementar ATS antes del 1 de enero de 2017. Sin embargo, a medida que se acercaba la fecha límite, Apple la pospuso indefinidamente y aún no ha anunciado una nueva fecha de vencimiento.

En diciembre de 2016, encontramos que el 80% de las 201 aplicaciones más descargadas en Apple® App Store® a nivel mundial optaron por no participar en ATS configurando el NSAllowsArbitraryLoads clave para YES. Más recientemente, usamos las capacidades de análisis únicas de nuestro producto NowSecure Intelligence™ para analizar 12 000 aplicaciones de iOS y su uso de ATS. Encontramos que al usar el NSArbitraryLoads excepción, aproximadamente el 63% de las principales aplicaciones de iOS optan por no participar en ATS, lo que significa que en algunos casos es posible que esas aplicaciones envíen datos confidenciales de forma insegura a través de HTTP.

Dicho de otra manera, nuestros hallazgos sugieren que el 37 % de esas 12 000 aplicaciones de iOS usan ATS predeterminado (es decir, no optan por no participar). Eso pinta una imagen un poco más prometedora que nuestros estudios anteriores, pero muchos desarrolladores de aplicaciones aún tienen trabajo por hacer. La exclusión voluntaria de ATS entra en conflicto con las buenas prácticas de seguridad.

Si los beneficios de seguridad de ATS no son suficientes para convencer a su equipo de desarrollo de que se ponga a trabajar en la implementación de ATS correctamente, infórmeles que Apple finalmente anunciará otra fecha límite. Además, varias de las teclas ATS que describo a continuación se activarán revisión adicional de la tienda de aplicaciones de la aplicación en cuestión, y su uso deberá justificarse ante Apple como parte del envío de una aplicación a la tienda. Esas claves incluyen:

• NSAllowsArbitraryLoads
• NSAllowsArbitraryLoadsForMedia
• NSAllowsArbitraryLoadsInWebContent
• NSExceptionAllowsInsecureHTTPLoads
• NSExceptionMinimumTLSVersion

No hay mejor momento que el presente para prepararse. Al hacer cumplir ATS, Apple requiere que los desarrolladores y analistas de seguridad auditen los puntos finales que admiten la funcionalidad de sus aplicaciones para hacer que esos puntos finales, sus aplicaciones y las conexiones asociadas sean más seguras. Creo que esta auditoría es uno de los beneficios reales de ATS.

Auditoría de implementaciones ATS

Parte de la aplicación de ATS por parte de Apple requiere que las aplicaciones justifiquen cualquier excepción. Apple quiere asegurarse de que un desarrollador tenga una buena razón para optar por no participar. Cuando una aplicación usa una excepción, puede disminuir la seguridad de una aplicación si está mal configurada. Los analistas de seguridad encargados de identificar problemas de seguridad en una aplicación móvil deben comprender las excepciones para poder auditarlas adecuadamente.

Las excepciones, también conocidas como claves, pueden indicar información sobre una aplicación antes de que comience la prueba dinámica. Si bien es importante aplicar un régimen de prueba que cubra todos los aspectos de una aplicación de iOS, independientemente de las protecciones que se apliquen, los analistas pueden usar estas claves para identificar áreas a las que podrían querer prestar especial atención durante una prueba de penetración de aplicaciones móviles.

Una vez que tenga un binario, puede comenzar a probar la configuración de ATS tan pronto como haya descargado el .ipa. Los comandos a continuación también se aplican a los archivos binarios descargados desde el Manzana® Tienda de aplicaciones® que utilizan el cifrado FairPlay®. Para ver la configuración ATS de su aplicación, use los siguientes comandos:

unzip <appName>.ipa
cd Payload/<BundleName>.app/
plutil -convert xml1 Info.plist
open Info.plist

El .ipa ahora está descomprimido y el Info.plist El archivo se convierte a un formato legible y se abre. Ahora, ubique la «Configuración de seguridad de transporte de aplicaciones» y allí encontrará la configuración actual de ATS que se verá así:

NSAppTransportSecurity : Dictionary 

Allí verá las claves principales y secundarias de ATS de la aplicación. Cada clave ayuda a los desarrolladores a configurar la implementación de ATS de la aplicación y a hacer excepciones para los dominios que no admiten ATS.

Claves, subclaves y excepciones de configuración de NSAppTransportSecurity

Para ayudar a los analistas de seguridad a comprender las diversas excepciones de ATS y cómo afectan la postura de seguridad de una aplicación de iOS, las describo a continuación.

NSAllowArbitraryLoads

El NSAllowArbitraryLoads la clave está configurada para NO por defecto. Poniendo la llave en YES optará por no recibir ATS y sus beneficios de seguridad asociados. Si al probar una aplicación encuentra esta clave establecida en YES, verifique por qué los desarrolladores decidieron optar por no participar. Además, consulte en el NSExceptionDomains excepción y si hay algún dominio listado allí. Hemos encontrado una serie de casos en los que los desarrolladores optaron por no participar en ATS a nivel mundial, pero luego optaron solo por ciertos dominios al enumerar un dominio de excepción. Un mejor enfoque es habilitar ATS globalmente, y solo optar por ciertos dominios si es absolutamente necesario (más sobre eso en la sección NSExceptionDomains a continuación).

Si la clave está configurada en YESdedique tiempo a verificar:

• Los cifrados utilizados para las conexiones de back-end de la aplicación (y que son fuertes)
• Los protocolos utilizados para enviar y recuperar datos (y que sean seguros)
• Si la aplicación tiene alguna vulnerabilidad de degradación
• Si la aplicación valida los certificados utilizados para las conexiones TLS

Si bien debe realizar pruebas en estas áreas independientemente de la configuración de ATS, un desarrollador que establezca esta clave en YES aumenta los riesgos en estas áreas.

NSAllowsLoadsForMedia

Esta excepción es para contenido multimedia protegido por gestión de derechos digitales (DRM) o encriptación. Cuando el NSAllowsLoadsForMedia la clave está configurada para YESATS está deshabilitado para el contenido enviado usando el marco AVFoundation (suele ser el caso de las aplicaciones que incluyen funciones de grabación, edición o reproducción audiovisual). Si asegurarse de que el contenido multimedia de su aplicación se envíe de forma segura a través de la red es importante para usted y esta clave está habilitada, confirme que los medios enviados por la aplicación no tengan contenido confidencial y estén protegidos mediante DRM o encriptación. Si bien es una buena práctica implementar estas protecciones incluso si el contenido se transmite a través de HTTPS, capturar el contenido transmitido a través de HTTP u otros protocolos inseguros es trivial.

NSAllowsArbitraryLoadsInWebContent

Por defecto, NSAllowsArbitraryLoadsInWebContent se establece en NO. Cuando la clave se establece en YES, ATS está deshabilitado para solicitudes de vista web. Por lo general, verá esta excepción si se usa una vista web dentro de la aplicación. En ese caso, querrá evaluar si la vista web envía datos confidenciales. Esto se debe a que con la clave habilitada, los datos se pueden enviar a través de HTTP u otros protocolos o conexiones inseguros.

El uso de vistas web puede introducir vulnerabilidades en una aplicación, por lo que es crucial verificar su seguridad. Por ejemplo, las vistas web pueden ser vulnerables a una serie de vulnerabilidades comunes basadas en la web, como la inyección de SQL, la falsificación de solicitudes entre sitios y los ataques de secuencias de comandos entre sitios. Para obtener información de seguridad adicional sobre el uso de vistas web, consulte nuestro mejores prácticas de vistas web.

NSpermite redes locales

NSAllowsLocalNetworking se establece en NO por defecto. Configurándolo en YES deshabilitará ATS para conexiones a través de una red local. Los casos de uso típicos para esta excepción pueden ser aplicaciones que se conectan a un dispositivo de hardware local en un escenario de Internet de las cosas (IoT). Las aplicaciones que facilitan las conexiones locales punto a punto también pueden usar esta excepción. Si se encuentra con esta excepción al probar una aplicación, replique el entorno en el que se realizaría esta conexión local para comprobar si se envían datos confidenciales a través de la red local con un método no seguro. Incluso si una aplicación se conecta a un dispositivo local, una mejor práctica de seguridad es usar una conexión TLS entre esos puntos finales.

NSExceptionDominios y subclaves

NSExceptionDomains

Utilizando el NSExceptionDomains key, los desarrolladores pueden configurar excepciones ATS dominio por dominio. Los analistas de seguridad deben tener en cuenta que las subclaves ATS dentro NSExceptionDomains reemplaza otras claves primarias. Para ejemplo, si una aplicación carga medios de un dominio específico y tanto el NSAllowsLoadsForMedia excepción y un NSExceptionDomains configuración se utiliza para ese dominio en particular, el NSExceptionDomains Los parámetros de la subclave reemplazan a los NSAllowsLoadsForMedia parámetros clave.

Los analistas de seguridad también deben tener en cuenta que, sin una configuración adicional, el uso de las subclaves debajo de la principal NSExceptionDomain clave, las conexiones entre la aplicación y un dominio enumerado aplicarán ATS en la conexión (incluso con NSAllowsArbitraryLoads ajustado a YES). Dicho de otra manera: si aparece un dominio de excepción sin ninguna configuración de las subclaves, ese dominio recibirá protección ATS completa, incluso si el NSAllowsArbitraryLoads se establece en YES. Esto puede complicar el análisis porque un desarrollador puede apagar ATS globalmente pero activarlo para dominios específicos enumerándolos dentro del NSExceptionDomains llave.

Algunos desarrolladores se sienten tentados a optar por no participar globalmente y optar por dominios específicos. Sin embargo, una mejor práctica es dejar ATS globalmente habilitado para una mejor cobertura de protección y solo eximir los dominios que su organización no controla (el caso de uso previsto para el NSExceptionDomain llave). E incluso entonces, solo si es necesario. Explique a su equipo de desarrollo que la codificación de excepciones de subclave ATS lógicas simplificará la justificación utilizada para cada excepción y facilitará la vida a largo plazo cuando Apple imponga una fecha límite. ATS debe habilitarse globalmente y las excepciones a ATS deben crearse a través del NSExceptionDomains subclaves.

Si una aplicación que está probando utiliza NSExceptionDomains y conjuntos NSAllowsArbitraryLoads a YES, asegúrese de auditar las conexiones entre la aplicación y los servicios de back-end. Idealmente, la aplicación solo se conecta a los dominios enumerados en el nivel superior NSExceptionDomains clave, sin ninguna configuración adicional en las subclaves (nuevamente, optando efectivamente por ATS para dominios específicos). Si hay conexiones a otros dominios que no están en esa lista, ATS no se aplicará para esos dominios.

NSIncluyeSubdominios

De forma predeterminada, esta tecla está configurada para NO. Cuando está configurado para YES, cualquier configuración de ATS habilitada para un dominio en particular se aplicará a todos los subdominios del dominio de excepción. Y, si establece un dominio de excepción, pero no configura ninguna subclave adicional más allá de la NSIncludesSubdomains key, el dominio de excepción y sus subdominios utilizarán ATS. Si está probando una aplicación que tiene esta clave habilitada, acérquese a los subdominios de la misma manera que lo haría con el dominio principal. Además, si ATS está deshabilitado globalmente y esta clave está configurada para NOconfirme que los subdominios no están en uso en la aplicación.

NSExceptionAllowsInsecureHTTPLoads

De forma predeterminada, esta tecla está configurada para NO. Cuando esta tecla se establece en YES, la aplicación podrá enviar tráfico HTTP a ese dominio. Si ve esta tecla establecida en YES, asegúrese de echar un vistazo a la información que se envía a través de la red. Puede enviarse de forma insegura a través de HTTP. Si la información debe enviarse a través de HTTP, al menos asegúrese de que la información enviada no sea confidencial y que todas las conexiones sean seguras.

NSExceptionMinimumTLSVersion

Esta clave permite a los desarrolladores reducir la versión mínima aceptada de TLS. De forma predeterminada, TLS 1.2 y superior son las versiones aceptadas. Si ve esta excepción en su lugar, querrá verificar la configuración de TLS de ese punto de conexión, la razón por la que debe reducirse y que no infrinja los requisitos de cumplimiento de su propia organización.

NSExceptionRequiresForwardSecrecy

De forma predeterminada, esta tecla está configurada para YES. Si esta tecla está configurada para NO deshabilitará el secreto directo perfecto. Similar aNSExceptionMinimumTLSVersion key, si encuentra esta clave en una aplicación que está probando, verifique la configuración de TLS del extremo, la razón por la que debe reducirse y los requisitos de cumplimiento de su propia organización.

NSRequiereCertificadoTransparencia

De forma predeterminada, esta tecla está configurada para NO. Si la clave está configurada para YESrequerirá una marca de tiempo de Transparencia de certificado en el certificado del dominio. Transparencia del certificado es un proyecto de Google destinado a hacer que el sistema de certificados SSL sea más seguro. Si su organización o el dominio en cuestión es compatible con la transparencia de certificados, querrá habilitar esto. Certificate Transparency ayuda a auditar contra autoridades de certificación (CA) no autorizadas y certificados maliciosos, y puede ayudar a prevenir ataques de intermediarios al notificar a los equipos de DevOps si su certificado se ha visto comprometido. Cuando esta clave está habilitada, las comprobaciones de certificado asociadas con la Transparencia del certificado se realizarán antes de establecer una conexión.

Determinar si los puntos finales de su aplicación pueden admitir ATS

Si comenzó su análisis y descubrió de inmediato que su aplicación no estaba utilizando ATS o que está mal configurado, no está solo. Como mencioné anteriormente, descubrimos que aproximadamente el 63% de las aplicaciones en la tienda de aplicaciones actualmente optan por no recibir ATS usando el NSAllowsArbitraryLoads llave.

Si está interesado en habilitar ATS en su aplicación, comience poco a poco. Primero, verifique si sus terminales ya son compatibles con ATS. Hágalo usando su dispositivo MacOS y el /usr/bin/nscurl --ats-diagnostics --verbose <https://yourdomain.com> Comando Xcode para verificar si su punto final es actualmente compatible.

Aquí verá un ejemplo de salida de ese comando (haga clic para expandir):

/usr/bin/nscurl --ats-diagnostics --verbose https://example.com
Starting ATS Diagnostics

Configuring ATS Info.plist keys and displaying the result of HTTPS loads to https://example.com.
A test will "PASS" if URLSession:task:didCompleteWithError: returns a nil error.
================================================================================

Default ATS Secure Connection
---
ATS Default Connection
ATS Dictionary:

Result : PASS
---

================================================================================

Allowing Arbitrary Loads

---
Allow All Loads
ATS Dictionary:

Result : PASS
---

================================================================================

Configuring TLS exceptions for example.com

---
TLSv1.2
ATS Dictionary:

Result : PASS
---

---
TLSv1.1
ATS Dictionary:

Result : PASS
---

---
TLSv1.0
ATS Dictionary:

Result : PASS
---

================================================================================

Configuring PFS exceptions for example.com

---
Disabling Perfect Forward Secrecy
ATS Dictionary:

Result : PASS
---

================================================================================

Configuring PFS exceptions and allowing insecure HTTP for example.com

---
Disabling Perfect Forward Secrecy and Allowing Insecure HTTP
ATS Dictionary:

Result : PASS
---

================================================================================

Configuring TLS exceptions with PFS disabled for example.com

---
TLSv1.2 with PFS disabled
ATS Dictionary:

Result : PASS
---

---
TLSv1.1 with PFS disabled
ATS Dictionary:

Result : PASS
---

---
TLSv1.0 with PFS disabled
ATS Dictionary:

Result : PASS
---

================================================================================

Configuring TLS exceptions with PFS disabled and insecure HTTP allowed for example.com

---
TLSv1.2 with PFS disabled and insecure HTTP allowed
ATS Dictionary:

Result : PASS
---

---
TLSv1.1 with PFS disabled and insecure HTTP allowed
ATS Dictionary:

Result : PASS
---

---
TLSv1.0 with PFS disabled and insecure HTTP allowed
ATS Dictionary:

Result : PASS
---

================================================================================

Es posible que se sorprenda al descubrir que muchos de los servicios utilizados por su aplicación ya son compatibles con ATS. Por ejemplo, Facebook Audience Network ofrece soporte completo para ATS (Documentación de ATS de Facebook). Para ver un gran ejemplo de cómo configurar el entorno de Amazon Web Services (AWS) de una aplicación para ATS, eche un vistazo a este Guía práctica de ATS del blog de seguridad de AWS.

Para obtener detalles más específicos sobre la implementación de ATS en las aplicaciones de iOS, consulte el documentación de manzana.

Esté atento a las actualizaciones de iOS 11 ATS

Apple pronto lanzará iOS 11 y se esperan algunas actualizaciones de ATS como parte de eso:

• TLSv1.3 recibirá soporte preliminar
• 3DES será eliminado de la lista aprobada de cifrados
• Ya no se aceptarán certificados firmados con SHA1
• Los certificados firmados con claves RSA deben tener longitudes de clave de 2048 bits o más

Para obtener más información sobre estas actualizaciones y ATS, consulte la sesión WWDC 2017 “Sus aplicaciones y estándares de seguridad de red en evolución.” Si está interesado en las actualizaciones de seguridad de iOS 11 más allá de ATS, regístrese en nuestro seminario web «Actualizaciones de seguridad de Android ‘O’ e iOS 11: lo que necesita saber» programado para el 14 de septiembre.

Esté atento también a la transparencia de certificados mejorada y al soporte de engrapado del Protocolo de estado de certificados en línea (OCSP): ambas tecnologías ayudan a verificar que su certificado no se haya visto comprometido. Finalmente, no se sorprenda si Apple finaliza el soporte para AES-CBC en ATS en el próximo año más o menos. Se ha demostrado que el modo de encriptación de encadenamiento de bloques de cifrado (CBC) hace que los sistemas criptográficos sean vulnerables a ataques como un ataque de oráculo de relleno.

Conclusión: Recuerde, ATS no es una panacea

ATS es una medida de seguridad del lado del cliente y no reemplaza la seguridad del lado del servidor. La seguridad del lado del cliente se puede eludir cuando un atacante tiene acceso físico a un dispositivo. Por lo tanto, mientras que ATS protege las aplicaciones de iOS y sus usuarios al ayudar a prevenir los ataques de degradación de SSL y el uso de cifrados débiles, los desarrolladores y los equipos de DevOps aún necesitan proteger el back-end de una aplicación, por ejemplo, implementando HTTP Strict Transport Security (HSTS), deshabilitando débil cifrados, etc. La seguridad del lado del cliente refuerza la seguridad del lado del servidor y es solo una capa de un enfoque de defensa en profundidad para asegurar una aplicación móvil.

Para saber cómo NowSecure y NowSecure Platform pueden ayudarlo a administrar el riesgo de seguridad de la aplicación móvil y, más específicamente, a auditar las configuraciones ATS de su aplicación, envíenos un correo electrónico a [email protected] o rellena nuestro formulario de contacto.