Historias de noticias recientes1 han llamado la atención sobre un artículo de investigación («Spinner: Detección semiautomática de fijación sin verificación de nombre de host»2) publicado esta semana destacando las vulnerabilidades de intermediario (MITM) en varias aplicaciones móviles públicas. La vulnerabilidad surge de una falla al validar que el nombre de host en el certificado coincida con el host real al que se conecta una aplicación. Llamar la atención y explicar los problemas de seguridad de las aplicaciones móviles es bueno tanto para las empresas como para los consumidores.
Afortunadamente para los clientes de NowSecure, NowSecure Platform™ siempre ha probado las aplicaciones móviles para la fijación de certificados y la validación adecuada de certificados, incluida la validación del nombre de host. La misión de NowSecure es educar a los clientes sobre las últimas amenazas de seguridad móvil y ayudarlos a maximizar la seguridad de las aplicaciones móviles que usan y desarrollan. Debido a que varias organizaciones nos han preguntado sobre el problema, en esta publicación explicaremos cómo NowSecure siempre ha probado este problema y brinda recomendaciones prácticas sobre lo que las empresas deben hacer para protegerse.
NOTA: Si no es un cliente protegido pero tiene una aplicación en producción y le preocupa su exposición, envíenos un correo electrónico a [email protected] explicando su problema y le responderemos rápidamente para ver cómo podemos ayudarlo.
Cómo NowSecure protege a los clientes contra esta vulnerabilidad móvil
NowSecure conoce desde hace mucho tiempo esta debilidad particular en la seguridad de las aplicaciones móviles. Y debido a que abordamos las pruebas de seguridad de las aplicaciones móviles desde el punto de vista del atacante, siempre hemos identificado esta falla en cualquier aplicación que probamos y brindamos recomendaciones sobre cómo mitigar el riesgo. Para resumir, los clientes de NowSecure cuyas aplicaciones han sido probadas con NowSecure Platform y/o por nuestros expertos servicios de pruebas de penetración y recomendaciones seguidassus aplicaciones están a salvo de este ataque.
Al probar la seguridad, la privacidad y el cumplimiento de las aplicaciones móviles, no basta con observar el código subyacente. En este escenario de amenaza, simplemente revisar el código podría resultar en un «aprobado» porque el código indicaría que el desarrollador implementó la fijación de certificados. Es por eso que las pruebas de seguridad de aplicaciones móviles deben incluir el conjunto completo de análisis estático, dinámico y de comportamiento.
En NowSecure, vamos más allá. Nuestra tecnología automatizada (NowSecure Workstation™, NowSecure AUTO™ y NowSecure Platform) y el equipo experto en pruebas de penetración evalúan las aplicaciones móviles desde la perspectiva del atacante para ejecutar un MITM exploit contra la aplicación para una evaluación de seguridad más profunda y precisa.
Debido a que NowSecure en realidad ejecuta múltiples ataques de red cuando prueba una aplicación, sabemos si podemos interceptar datos. No nos detenemos en la detección de un certificado anclado; por ejemplo, entre otras técnicas, intentaremos establecer una conexión no segura con la aplicación mediante un certificado con un nombre de host no válido o mediante un certificado que no sea de confianza. NowSecure Platform alertará sobre el hecho de que los intentos de validación o fijación de certificados no fueron efectivos.
Errores internos de asignación de certificados: falta de validación del nombre de host
Los autores del artículo evaluaron un total de 400 aplicaciones y descubrieron que 8 de ellas simplemente validaban la autoridad certificadora (CA), es decir, el emisor del certificado, y no el nombre de host. En ese escenario, el problema de seguridad es que una persona malintencionada podría obtener un certificado de la misma CA para ejecutar un ataque (MITM) en la aplicación y su usuario y sustraer los datos enviados por la aplicación y destinados al host.
Desde entonces, todas las aplicaciones vulnerables han sido parcheadas según los investigadores. Sin embargo, llama la atención el hecho de que algunos desarrolladores no anclan ni validan los certificados correctamente. La fijación adecuada de certificados sigue siendo una contramedida muy eficaz para los ataques MITM, pero puede ser difícil de implementar y no debe excluir otras comprobaciones de validación de certificados. Si la fijación de certificados se realiza incorrectamente, los desarrolladores pueden tener una falsa sensación de seguridad.
Algunos informes sugieren que el documento expone fallas en la fijación del certificado, lo cual es fundamentalmente incorrecto. La fijación de certificados es una de las mejores formas de proteger las aplicaciones móviles y sus usuarios de los ataques MITM: la falla informada está en la implementación de la fijación de certificados en lugar del uso de la fijación de certificados en sí misma como una estrategia central de seguridad de aplicaciones móviles. En otras palabras, si usa la fijación de certificados en sus aplicaciones móviles, lo aplaudimos. Continúe así: solo asegúrese de implementarlo correctamente probando sus aplicaciones antes de la implementación.
Después de haber probado millones de aplicaciones de Android e iOS durante la última década, hemos evaluado una gran cantidad de implementaciones de asignación de certificados. A continuación, hay tres preguntas que debe hacer sobre sus prácticas de fijación de certificados para determinar si las está implementando correctamente y si está protegiendo su aplicación contra vulnerabilidades, como no verificar el nombre de host en un certificado.
¿La aplicación fija la autoridad de certificación (CA)?
- Esto significa que la aplicación confía mucho en la CA al aceptar cualquier certificado para el dominio en cuestión firmado por esa CA mediante un certificado raíz (el punto final de la cadena de confianza del certificado).
- Las prácticas de seguridad y validación para la emisión de certificados pueden variar de una CA a otra, y varias CA se han violado en los últimos años con la creación de certificados falsos como resultado.
- Una persona malintencionada podría usar un certificado emitido por la misma CA y secuestrar la conexión.
- La combinación de este enfoque y la falta de validación del nombre de host debilita seriamente la seguridad de las conexiones de host de una aplicación.
¿La aplicación está anclada a un certificado intermedio?
- Un certificado intermedio es un paso hacia abajo en la jerarquía del certificado raíz mencionado anteriormente, pero tiene problemas similares.
- Los certificados en la parte inferior de la cadena de confianza (certificados de «hoja» que se analizan a continuación) se pueden firmar mediante un certificado intermedio.
- Y así, si una persona malintencionada puede obtener un certificado para el dominio en cuestión firmado por un certificado intermedio, nuevamente, ese atacante puede secuestrar la conexión porque la aplicación confiará en su certificado.
¿La aplicación fija la clave pública del certificado de hoja real?
- NowSecure ha recomendado esta mejor práctica de seguridad de aplicaciones móviles durante años: en lugar de anclarlo solo a la CA o al certificado intermedio, recomendamos anclarlo al certificado de hoja real.
- Cada certificado incluye una clave pública asociada con la clave privada, que se puede anclar dentro de la aplicación.
- Este enfoque garantiza que la aplicación solo confíe en los certificados que ha firmado, que un atacante no puede suplantar.
- Algunas personas afirman que este método hace que la rotación de claves caducadas sea una molestia, pero, como explicaremos a continuación, hay formas de anclar la clave pública y facilitar la rotación de certificados sin tener que actualizar y volver a lanzar una aplicación (lo que le permite reemplazar un certificado y aún funcionan las versiones anteriores de la aplicación incluso sin una actualización).
Cómo hacer la fijación de certificados en aplicaciones móviles y cuenta para la caducidad/rotación de certificados
Los desarrolladores a veces toman atajos como la fijación de CA (o evitan la fijación de certificados por completo) para evitar tener que lanzar nuevas versiones de la aplicación cuando los certificados caducan y es necesario cambiarlos. Sin embargo, existe un método para implementar correctamente la fijación de certificados y permitir la rotación de certificados sin interrupciones en el servicio:
- Pin basado en el módulo de la clave pública, que representa un identificador único para la clave privada
- Al comparar el módulo de clave pública y el módulo de clave privada, puede asegurarse de que la aplicación confíe en el certificado adecuado (o, lo que es más importante, que no confíe en ningún otro certificado)
- Anclar usando el módulo le permite renovar la clave pública e intercambiarla siempre que la clave privada no cambie
- Incluya dos firmas de módulo en la aplicación: una para uso activo y otra para uso futuro con la clave privada almacenada sin conexión
Para obtener información más detallada sobre la implementación de la fijación de certificados en sus aplicaciones de Android e iOS, consulte nuestra publicación de blog «Prevención de ataques de intermediarios móviles».
Si le preocupa que la tecnología o las prácticas de seguridad de su aplicación móvil actual no identifiquen la fijación de certificados o la verificación del nombre de host del certificado, podemos mostrarle cómo la tecnología o los servicios de NowSecure pueden mejorar su enfoque actual y hacer que sus aplicaciones móviles sean más seguras y compatibles: envíenos un correo electrónico ahora en [email protected] o rellena nuestro formulario de contacto.
2 http://www.cs.bham.ac.uk/~garciaf/publications/spinner.pdf
Relacionado:
Pruebas de penetración del servidor web: definición, lista de verificación y herramientas
Musk aumentará la suscripción a Twitter Blue a $ 8, las marcas de verificación verificadas serán secundarias
La lista de verificación de seguridad definitiva para lanzar una aplicación móvil en Nigeria
Nuevos teléfonos móviles – Gadgets de alta tecnología extremadamente elegantes
