Originalmente desarrollado para navegadores, el protocolo SSL / TLS se convirtió más tarde en el estándar de facto para todas las comunicaciones seguras de Internet. Ahora se utiliza para la administración remota de la infraestructura virtual implementada en la nube, para transferir los detalles de pago de los clientes desde servidores de comercio electrónico a procesadores de pago como PayPal y Amazon, para enviar datos locales al almacenamiento en la nube, guardar correspondencia en mensajería instantánea y autenticación de servidor en aplicaciones móviles iOS y Android.

La lista de situaciones donde el intercambio de información altamente sensible requiere la máxima seguridad es bastante impresionante. En este artículo, examinaremos cómo se garantiza la seguridad de estas comunicaciones en la práctica.

- Protocolo SSL / TLS: querían lo mejor ...
- ... pero resultó como siempre: ejemplos de verificación fallida de certificados SSL / TLS
- Vulnerabilidades lógicas del protocolo SSL / TLS
- Otras vulnerabilidades comunes de implementación del protocolo SSL / TLS
- La causa raíz de las vulnerabilidades en el protocolo SSL / TLS
- Una cucharada de miel en un barril de alquitrán

Protocolo SSL / TLS: queríamos lo mejor ...

En teoría, una conexión segura de protocolo SSL / TLS debería garantizar la confidencialidad, confiabilidad e integridad de las comunicaciones de software de cliente y servidor, incluso en presencia de un atacante avanzado activo de la red: cuando el enemigo toma completamente la red, el DNS se envenena y los puntos de acceso y enrutadores, interruptores y WiFi son controlados por un atacante; Un atacante que, entre otras cosas, controla un backend SSL / TLS. Además, cuando el software del cliente intenta conectarse a un servidor legítimo, un atacante puede cambiar la dirección de red del servidor (por ejemplo, a través del envenenamiento de DNS) y, en lugar de un servidor legítimo, redirigir al cliente a su servidor malicioso.

La seguridad de las comunicaciones en condiciones tan duras, como usted sabe, depende completamente de la adecuación de la verificación del certificado criptográfico proporcionado por el servidor al establecer la conexión. Incluyendo la idoneidad de la implementación de un conjunto de cifrados (ciphersuite), que el cliente y el servidor utilizan al intercambiar datos. Para que la conexión SSL / TLS sea completamente segura, el software del cliente, entre otras cosas, debe verificar cuidadosamente que:

• certificado emitido por el organismo de certificación actual;
• su período de validez no ha expirado (o el certificado no ha sido revocado);
• La lista de nombres que figuran en el certificado contiene el dominio al que se está conectando.

... pero resultó como siempre: ejemplos de verificación fallida de certificados SSL / TLS

Sin embargo, en muchas aplicaciones y bibliotecas para las cuales la seguridad de la comunicación es muy crítica, el procedimiento para verificar un certificado SSL / TLS, e incluso EV-SSL, un certificado de verificación avanzado [4], no tiene éxito. En todos los sistemas operativos populares: Linux, Windows, Android e iOS. Entre los servicios vulnerables de software, bibliotecas y middleware, se pueden distinguir los siguientes [1]:

• La biblioteca Java EC2 de Amazon y todos los clientes front-end basados ​​en la nube creados sobre esta base.
• El SDK comercial de Amazon y PayPal, responsable de la entrega de los detalles de pago de los sitios (en los que se implementa la infraestructura del comercio en línea) a las pasarelas de pago.
• "Cestas" integradas, como osCommerce, ZenCart, Ubercart y PrestaShop, que no validan los certificados en absoluto.
• Código de AdMob utilizado por el software móvil para mostrar publicidad contextual.
• Componentes frontales de interfaz ElephantDrive y FilesAnywhere, responsables de interactuar con el almacenamiento en la nube.
• La biblioteca de Android Pusher y todo el software que utiliza la API Pusher para controlar la mensajería instantánea (por ejemplo, Gait.es de GitHub).
• Apache HttpClient (versión 3.x); Apache Libcloud y todas las conexiones de clientes a servidores Apache ActiveMQ, etc.
• Servicios de middleware Java SOAP, incluidos Apache Axis, Axis 2, Codehaus XFire; así como todo el software que se construye sobre la base de estos servicios de middleware.
• Herramientas de API de Elastic Load Balancing
• Implementación Weberknecht de WebSockets.
• Además de todo el software móvil creado sobre la base de las bibliotecas y los servicios de middleware mencionados anteriormente (para comprender qué son los servicios de middleware, consulte la Fig. 1); incluido el cliente iOS del proveedor de alojamiento Rackspace.

Figura 1. ¿Qué son los servicios de middleware?

Además, en [2] se enumeran incluso más de cien aplicaciones móviles vulnerables (ver. Fig. 2). Incluyendo: Google Cloud Messaging de Android, Angie's List Business Center Passwords, AT&T Global Network Client, CapitalOne Spark Pay, Cisco OnPlus (acceso remoto), Cisco Technical Support, Cisco Webex, Cisco WebEx Passwords, Dominos Pizza, E-Trade, Freelancer , Google Earth, Huntington Mobile (Bank), Contador de impuestos en línea Intuit, iTunes Connect, Microsoft Skype, Oracle Now, Pinterest, SafeNet (cliente VPN), SouthWest Airlines, Uber, US Bank - Access Online, WesternUnion, WordPress, Yahoo! Finanzas, Yahoo! Mail

Figura 2. Una pequeña selección de la lista de aplicaciones móviles vulnerables

Vulnerabilidades lógicas SSL / TLS

Las conexiones SSL / TLS de todo este y muchos otros programas son vulnerables a una amplia gama de ataques MiTM. Al mismo tiempo, se puede llevar a cabo un ataque MiTM, a menudo incluso sin falsificar certificados y sin robar las claves privadas por las cuales los servidores firman sus certificados. Un ataque MiTM puede llevarse a cabo simplemente explotando las vulnerabilidades lógicas que están presentes en el procedimiento para verificar el certificado SSL / TLS en el lado del software del cliente. Como resultado, un atacante MiTM puede, por ejemplo, recopilar tokens de autorización, números de tarjetas de crédito, nombres, direcciones, etc. - de cualquier comerciante que utilice aplicaciones web de procesamiento de pagos vulnerables.

Los proveedores de software móvil, que toman el código de muestra de AdMob para conectar sus aplicaciones con la cuenta de AdMob, también son vulnerables: permiten que un atacante capture credenciales y obtenga acceso a todos sus servicios de Google. Por ejemplo, debido a la verificación incorrecta de certificados en mensajeros como Trillian y AIM, un atacante MiTM puede robar credenciales de inicio de sesión para todos los servicios de Google (incluido Gmail), Yahoo!; y también a los servicios de Windows Live (incluido SkyDrive). Otras vulnerabilidades que afectan el software web moderno que no es del navegador incluyen: el uso de expresiones regulares incorrectas al comparar un nombre de host; ignorando los resultados de la validación del certificado; cierre accidental o intencional de la verificación. [1]

Otras vulnerabilidades comunes de implementación del protocolo SSL / TLS

Y, por supuesto, no debemos olvidar que, incluso si no hay errores lógicos en la implementación del protocolo SSL / TLS (a menos que, por supuesto, alguien todavía crea en él), se pueda evitar la protección robando la clave privada [12], usando 0day exploits para teclados, navegadores, sistemas operativos, utilidades y firmware [3]; comprometiendo el enrutamiento BGP [10]; o atacar SSL / TLS sobre hardware (ver Figura 3) [8] y / o software [9] omitir canales.

Figura 3. Ataque SSL en bypass de hardware

Además, los atacantes pueden realizar ataques MiTM prácticamente invisibles, abusando del mecanismo de almacenamiento en caché de sesión SSL / TLS implementado en la clase SSLSessionCache. Este mecanismo verifica la validez de los certificados solo en la conexión inicial; ni es capaz de cancelar adecuadamente una sesión de comunicación después de eliminar certificados del dispositivo. Además, después de reiniciar el dispositivo Android (a través de las opciones "Reiniciar" o "Apagar"), puede continuar viendo el tráfico encriptado de algunas aplicaciones que no se iniciaron después del reinicio, pero que funcionaron antes del reinicio. Entonces, por ejemplo, con Google Maps sucede. En [2], se describe cómo, gracias a estos defectos de almacenamiento en caché, un atacante puede establecer y eliminar de forma completamente transparente "certificados invisibles" para el usuario, y luego establecer una conexión de red con cualquier aplicación.

Figura 4. Retrospectiva de cifrado vulnerable

Otras vulnerabilidades comunes en la implementación del protocolo SSL / TLS incluyen cifrado vulnerable (ver Figura 4) [5], reutilización de GCM (modo Galois / Counter; contador con autenticación Galois) [6], truco con CNG (CryptoAPI-NG ) en Schannel (ver. Fig. 5) [7], verificación incorrecta de la cadena de confianza [2], verificación incorrecta del nombre de host [11].

Figura 5. Truco de GNC: sacando secretos de Schannel

Una verificación incorrecta de la cadena de confianza es una situación en la que la aplicación web acepta absolutamente cualquier certificado que indique el nombre de host correcto, sin verificar con qué autoridad de certificación se firmó. Esto le permite interceptar y descifrar contraseñas y / o números de tarjetas de crédito. Y en algunos casos incluso hacer una inyección de código malicioso. En el software de Android, esta vulnerabilidad penetra, por ejemplo, cuando se crea una interfaz X509TrustManger personalizada que ignora las excepciones de CertificateException. O cuando un desarrollador de software inserta una llamada al método SslErrorHandler.proceed () en el código de un componente de WebViews. [2]

Una verificación de nombre de host incorrecta es una situación en la que una aplicación web acepta un certificado sin asegurarse de que el host del que proviene este certificado esté en la lista de hosts de confianza. En el software de Android, esta vulnerabilidad penetra, por ejemplo, cuando se crea una interfaz HostnameVerifier, que devuelve VERDADERO bajo cualquier condición. O cuando un desarrollador de software inserta una llamada al método SslErrorHandler.proceed () en el código de un componente de WebViews. [2]

La causa raíz de las vulnerabilidades en el protocolo SSL / TLS

La causa raíz de la gran mayoría de estas vulnerabilidades es el terrible diseño de API de las bibliotecas SSL / TLS (incluidas JSSE, OpenSSL y GnuTLS). Además del diseño igualmente terrible de las bibliotecas de transferencia de datos (como cURL, Apache HttpClient y urllib), cada una de las cuales es un contenedor de alto nivel para las bibliotecas SSL / TLS. Sin mencionar los servicios de middleware (como Apache Axis, Axis 2 o Codehaus XFire), que son un envoltorio de nivel aún más alto y que aumentan aún más la "bola de nieve" de diseño terrible. En lugar de mantener un diálogo con un desarrollador de aplicaciones (a menudo lejos de la programación del sistema) en un lenguaje que comprenda (en términos de confidencialidad y autenticación), abstraído de los detalles de bajo nivel de la implementación del protocolo SSL / TLS, estas API descargan un montón de parámetros SSL / TLS de bajo nivel en el pobre. incomprensible para él. Requieren software de alto nivel para exponer correctamente las opciones de bajo nivel; implementa funciones de verificación de nombre de host y se encarga de la interpretación de los valores devueltos por las operaciones de bajo nivel.

Como resultado, los desarrolladores de aplicaciones usan incorrectamente la API SSL / TLS: interpretan erróneamente la diversidad de sus parámetros, opciones, efectos secundarios y valores de retorno. Por ejemplo [1]:

• La biblioteca PHP del Servicio de pagos flexibles de Amazon intenta habilitar la validación del nombre de host configurando el parámetro CURLOPT_SSL_VERIFYHOST en TRUE (en la biblioteca cURL). Sin embargo, el valor predeterminado correcto para este parámetro es 2; si le asigna un valor VERDADERO, este parámetro es invisible para el desarrollador que le asignó el valor 1, y así sucesivamente. la verificación del certificado está deshabilitada.
• Biblioteca de PHP PayPal Payments Standard: obtuvo el mismo error; Además, en el momento en que se actualizó la implementación anterior y vulnerable (es decir, se eliminó un error y se agregó otro).
• Otro ejemplo es Lynx, un navegador orientado a texto. Verifica los certificados autofirmados, pero solo si la función de verificación de certificados GnuTLS devuelve un valor negativo. Sin embargo, esta función devuelve 0 para algunos errores; incluso en los casos en que los certificados están firmados por un organismo no confiable. Debido a esto, la cadena de confianza en Lynx está rota.

Además, los desarrolladores de aplicaciones a menudo malinterpretan qué tipo de seguridad garantiza una biblioteca SSL / TLS en particular. Por lo tanto, en la naturaleza se pueden encontrar casos clínicos cuando en aplicaciones que necesitan comunicaciones seguras (por ejemplo, interactuando con un procesador de pagos), se utiliza una biblioteca SSL / TLS que no verifica en absoluto los certificados SSL / TLS. Los casos más prosaicos, pero aún más asesinos, son cuando el desarrollador de cualquiera de las capas de software intermedias desactiva silenciosamente el procedimiento para verificar los certificados SSL / TLS (puede hacer esto, por ejemplo, para probar el sistema, y ​​después de probarlo, olvídalo). Al mismo tiempo, el código del programa de alto nivel que utiliza esta capa intermedia garantiza que se realice la verificación del certificado. T.O. Los errores SSL / TLS a menudo están ocultos en las profundidades de una o varias capas intermedias de bibliotecas a la vez, lo que hace que sea casi imposible detectar este problema.

Por ejemplo, en JSSE (Java Secure Socket Extension), la interfaz extendida API SSLSocketFactory omite silenciosamente la verificación del nombre del host si el campo "algoritmo" en el cliente SSL está configurado en NULL o en una cadena vacía, y no en HTTPS. Aunque este hecho se menciona en la guía de referencia de JSSE, muchas implementaciones de protocolo SSL de Java usan SSLSocketFactory sin realizar la validación del nombre de host ...

Una cucharada de miel en un barril de alquitrán

Por lo tanto, de hecho, resulta que en la mayoría de los softwares web modernos que no son navegadores, la verificación de los certificados SSL / TLS está completamente deshabilitada o implementada incorrectamente. La Figura 7 muestra la clasificación de las vulnerabilidades actuales del protocolo SSL / TLS. Algunas de estas vulnerabilidades, pero no todas, se han descrito y / o mencionado anteriormente. Puede familiarizarse con las vulnerabilidades mencionadas pero no descritas leyendo los materiales enumerados en la bibliografía.

Figura 6. Clasificación de vulnerabilidades relevantes para SSL / TLS

Bueno, para agregar una cucharada de miel al barril de alquitrán, vale la pena señalar que en [1] se describió en detalle / claramente / popularmente / de manera competente cómo se debe implementar SSL, con referencia a la RFC. Nunca hemos encontrado una mejor descripción, que sería técnicamente precisa y al mismo tiempo comprensible. También en [1], se analizan las bibliotecas SSL más comunes, con clasificación según el nivel de abstracción (nivel bajo / nivel alto). Todo con diagramas y algoritmos concisos en pseudocódigo. Las vulnerabilidades de productos específicos se describen en detalle, con código incorrecto y códigos de error. Entonces, si de repente alguien nuevamente desea crear tal implementación del marco SSL / TLS, que será una excepción al dicho "querían lo mejor, pero resultó como siempre", entonces [1] es un comienzo ideal para esto.