Ataques al protocolo https

Analizamos en este artículo el protocolo HTTP y lo que se denomina su versión segura, el HTTPS, que incluye los protocolos SSL y TLS. Hablaremos de los certificados de seguridad y a continuación detallaremos algunos ataques que han sufrido estos protocolos. Por último damos algunas recomendaciones para evitarlos en la medida de lo posible.

Pueden leer la primera parte de este artículo en el enlace Todo sobre el HTTPS .

Es importante que seamos consciente de que a pesar de acceder sólo a sitios seguros, la tecnología SSL/TLS no garantiza al 100% que la información sea segura. Los atacantes se han vuelto muy hábiles e ingeniosos para burlar estos mecanismos de seguridad. Ya sea por debilidad en la teoría o por una mala implementación de esa teoría o por accesos indebidos o por otros factores difíciles de predecir. Por ello, es aconsejable que tomemos algunas medidas preventivas antes de realizar transacciones delicadas online que puedan poner en riesgo tus datos. Y para ejemplificar lo que se está diciendo aquí se muestra un caso real de ataque a las comunicaciones seguras en Internet.

Caso real

Un caso real que ejemplifica el mal uso de esta tecnología fue publicado en el artículo Troyano bancario secuestra conexiones SSL, el cual se puede consultar en http://www.seguridad.unam.mx/noticias/?noti=4419.

En este artículo se detalla un troyano capaz de secuestrar conexiones SSL/TLS al momento de realizar transacciones bancarias online. A grandes rasgos lo que hace este troyano es:

Supongamos que deseamos realizar una operación bancaria online. Al ingresar a la página Web de tu banco, durante el proceso de conexión SSL/TLS, el banco envía a tu navegador su certificado y su llave pública firmados, elementos que utilizará para cifrar la información a transmitir. El troyano se interpone entre el servidor del banco y tu navegador tomando la llave pública y la información del certificado para cifrar su propio canal de comunicación, mientras tanto, del lado del navegador el troyano inserta su certificado auto-firmado, un certificado falso, de tal manera que el candadito de seguridad del navegador siempre está visible durante la conexión y así la presencia del troyano resulta imperceptible.

Conexión con protocolo HTTPSCuando envías tu información al banco, ésta es cifrada utilizando el certificado falso e interceptada por el mismo troyano, quien la manipula y transfiere al banco para que éste la procese. Empleando el certificado falso, el troyano es capaz de descifrar y leer la información que compartimos con el banco, probablemente reenviándola a un atacante.

Bug en los navegadores

Existe un bug o fallo en la manera que Internet Explorer examina los objetos HTTPS embebidos dentro de páginas HTTP normales, en una etiqueta del tipo <img src=XXXXX width=1 height=1>. Este bug se presentaba en versiones anteriores a la 7.0 y, por suerte, en la actualidad ya ha sido corregido.

Un atacante, o un troyano, podrían agregar una línea como la siguiente a cada página descargada desde un sitio HTTPS, logrando un certificado legítimo, pero robado.

<img src=”https://www.dominiofraudulento.com/nonexistent.gif” width=1 height=1>

El IE solo comprueba si el certificado correspondiente a ese servidor HTTPS está firmado correctamente, pero ignora detalles como fecha de expiración y si ha sido asignado al nombre correcto. Ésto no es un problema, si consideramos que un objeto HTTPS dentro de una página HTTP no es considerado seguro. Sin embargo, el IE marca el certificado como verdadero cuando finaliza la sesión. De esta manera, una vez que se ha visitado una página normal con esas condiciones, el IE ya no advertirá sobre la ilegalidad del certificado.

Después puede hacerse que el usuario acceda a un dominio diferente al que correspondería, como una Web espejo, capturando toda su información privada, como por ejemplo, transacciones de su tarjeta de crédito en un sitio de compras, que irían a una cuenta diferente a la que se piensa. La mayoría de los usuarios no notaría que el sitio es dominio.net, en lugar de dominio.com, por ejemplo.

Ataques del tipo DNS Spoofing

No es sencillo para la mente humana recordar el número: 82.98.134.14, que es la IP de esta web:http://www.tierradelazaro.com. Así que, cada vez que queramos visitar www.tierradelazaro.com estaremos consultando a un servidor de DNS para saber cual es la dirección de IP asociada al nombre de este dominio en cuestión y poder acceder a ella. Es decir, DNS, Domain Name Server o Servidor de Nombres De Dominio, es el encargado de resolver por nosotros la asociación de un nombre de dominio en una dirección de IP. Este servidor se define en la configuración de Internet del usuario encada máquina que accede a Internet.

Servidor de DNSImaginemos ahora que se puede cambiar esa configuración y definir otro servidor de DNS, uno que las asociaciones entre nombres de dominios e IPs las determine un atacante malintencionado. En el mejor de los casos no podremos acceder a nuestra Web favoritas. Aunque ésto sólo es un fastidio.

El problema viene cuando visitamos una Web que debería ser segura pero está asociada a una IP que no lo es. Un atacante puede modificar una Web legítima para que en lugar de enviar los credenciales de acceso al servidor oficial los envíe en texto plano al de éste.

Veamos un ejemplo: La web de www.facebook.com realiza sus conexiones mediante HTTPS, imposibilitando la captura de los campos de autenticación por parte de terceros. Pero si controlamos los DNS es muy fácil redirigir las conexiones a esta Web hacia nuestra propia Web espejo alojada en nuestro servidor. Nuestra versión es idéntica a la original, salvo que modificamos la función que se llama al pulsar el botón Entrar. Dicha modificación es completamente transparente, por tanto, el usuario no se daría cuenta de nada; y al atacante le permite obtener sus datos en texto plano y sin complicaciones. Lo siguiente es redirigir al usuario a la Web original de facebook.

Ataque falsificar certificados

Este es un ataque supuestamente efectuado por autoridades iraníes sobre sus internautas. Según se relata en el artículo de El Pais http://elpais.com/diario/2011/03/25/radiotv/1301007601_850215.html. Este caso de espionaje se produjo gracias a un engaño a una de las 650 agencias que regularmente emiten unos 1.500 certificados de autenticidad para páginas Web seguras, que cientos de miles de internautas usan a diario.

En las conexiones HTTPS, un navegador solo mostrará sin alarmas la página Web si ésta incluye un certificado de seguridad firmado por una AC, una agencia independiente que garantiza la autenticidad de la propia página.

El problema es que hay demasiadas agencias que emiten certificados. Fue Comodo, una empresa de software de seguridad que a la vez actúa como AC, la que admitió que su sistema había emitido certificados seguros a páginas Web de Google, Yahoo!, Microsoft, Mozilla y Skype, todos de forma no adecuada, a direcciones localizadas principalmente en Irán. Con estos certificados, un atacante podía hacerse pasar por esas compañías, aunque los internautas estuviera accediendo a páginas de su propia creación. Con los certificados, los atacantes podían crear páginas fraudulentas que por su diseño parecieran verdaderas y desde las que se pudiera espiar las comunicaciones de los usuarios. Para eso, se necesita la capacidad de redirigir direcciones IP, algo que solo pueden hacer las compañías telefónicas proveedoras de conexión, que en Irán están en manos del Gobierno.

La empresa Comodo, al averiguar que había sido víctima de un engaño en esos certificados, revocó los certificados, notificó a las páginas Web que habían sido suplantadas y presentó un informe ante el Gobierno de EE.UU. para que tome medidas. Por desgracia, ésto es algo a lo que siempre podemos estar expuestos y que tiene difícil solución, a menos que se acentúen las medidas de seguridad en las ACs.

Ataque de dirección falsa

Este ataque es bastante simple e imaginativo. Debido a que la mayoría de los usuarios visitan páginas no protegidas con SSL antes de ser llevados a páginas cifradas con SSL/TLS, un atacante puede evitar fácilmente que éstos usen el cifrado para capturar así todo su tráfico. En el pasado, un atacante habría intentado ejecutar un ataque de MITM, man-in-the-middle, capturando el tráfico no cifrado o usando un certificado firmado por sí mismo para hacerse pasar por un sitio legítimo, pero SSL/TLS se diseñó para evitar precisamente este tipo de cosas. ¿Pero qué ocurre si la víctima nunca llega a comunicarse realmente con el sitio Web seguro? Muchos sitios utilizan páginas iniciales no cifradas en las que el usuario lleva a cabo la mayor parte de la actividad. Un atacante puede visualizar, e incluso modificar, el contenido de la comunicación sin levantar sospechas en el usuario final, tan sólo reescribiendo todos los enlaces de esas páginas que lleven a páginas protegidas o cifradas. A no ser, claro está, que el usuario sea lo suficientemente avispado como para percatarse de que faltan el candadito y el resto de detalles que se muestran cuando se está visitando una página cifrada. Que lo cierto, es que son pocos los que se fijan en esos detalles.

Podemos ver un ejemplo de este ataque en el siguiente artículo: http://www.redeszone.net/seguridad-informatica/sslstrip/

Ataque de la cadena /0

Al crear un certificado SSL y enviarlo a una autoridad certificadora para que lo firme, el único campo al que la gente suele prestar atención es a CN o common name. El campo CN especifica el nombre del servidor, como pueda ser www.dominio.org, o http://www.tierradelazaro.com. Se descubrió que los estándares de certificado X.509 y SSL definen la cadena de CN como una cadena PASCAL; por tanto, esencialmente, se declara la longitud de la cadena en la posición 0 y se pone la cadena en sí en las posiciones siguientes. Sin embargo, y dado que la mayoría del software de procesamiento de certificados está escrito en lenguaje C, dicho software suele manejar la cadena como una cadena de C; poniendo un NULL, \0, al final de la cadena para indicar dónde termina ésta. La mayoría de los programadores no se percató de las implicaciones que ésto tenía y simplemente pasaban la cadena CN a una estructura de cadena en C. El problema llega cuando alguien que legítimamente posee www.dominio.com, obtiene un certificado para www.empresacertificada.com\0www.dominio.com.

En los primeros días de los certificados SSL, cuando aún eran muy caros, eran los humanos quienes revisaban las peticiones. No sólo se solicitaban certificados, sino que también se registraban negocios, así como otros modos de probar la potestad sobre un dominio concreto. Por tanto, cualquier petición mal formada o extraña era muy probable que fuese rechazada y no se procesara. Evitando de esta manera cualquier problema. Los tiempos han cambiado. Ahora es posible obtener un certificado SSL en minutos, a través de un proceso completamente automatizado. Por tanto, podemos solicitar un certificado que parezca que pertenece a un dominio de nuestra titularidad por ejemplo: www.dominio.com. Sin embargo, cuando la aplicación es procesada por un navegador, debido a que maneja el CN como una cadena de C, sólo se leerá la primera parte, www.empresacertificada.com, ya que al encontrar el terminador NULL, /0, dejará fuera www.dominio.com, permitiendo falsificar fácilmente www.empresacertificada.com.

Lo bueno de todo ésto es que tiene fácil arreglo, las entidades certificadoras comenzaron a rechazar todos los certificados que contuvieran un carácter NULL, algo que en un escenario real nunca debería ocurrir, e implementaron filtros para evitar que volviera a pasar. En cuanto a la parte cliente, la mayoría de los navegadores Web y de los clientes y servidores con soporte para SSL han publicado actualizaciones para lidiar con el problema.

Ataque de dirección parecida

Todos hemos ido alguna vez a la página equivocada gogole.com en vez de google.com. En el pasado, las cosas eran relativamente simples: Si un atacante quería registrar un dominio que imitaba a uno real, le bastaba con saltarse o añadir alguna letra. Para defenderse de estas amenazas, lo más común era registrar todos los dominios que se prestaban a confusión. Por suerte, el número de combinaciones no era exageradamente alto. Sin embargo, esta circunstancia cambió con la llegada de los nombres de dominio Internacionales. Ahora hay varias docenas de caracteres virtualmente idénticos a las letras Romanas,como pueden ser la letras Cirílicas Es(c), Shha (h), Ye (e), Je (j), On (o), Er(p), Dze (s), Kha (x) y U (y), o las griegas omicron (O) y nu (N). Dado que no hay una forma sencilla de verificar los nombres de dominio que estamos visitando, se espera que los navegadores comiencen a proveer colas visuales con la apariencia de los nombres de dominio. Una forma de hacerlo sería marcando el texto con un color diferente en base a su país, pero ningún navegador lo hace en la actualidad.

Ataque de renegociacion

Cuando se escribieron las especificaciones de SSL y TLS en 1990, éstas contaban con una ingeniería algo superior a la necesaria, de forma que permitían comportamientos como la renegociación que resultaron innecesarios e indeseados posteriormente. Explotando el comportamiento de la renegociación, un atacante puede insertar contenido que le permita llevar acabo una nueva clase de ataque de CSRF, Cross-Site Request Forgery. Pero no hay de qué preocuparse; la mayoría de las aplicaciones modernas poseen robustas protecciones contra ataques de CSRF, como los tokens de usar y tirar, que mutan en cada transacción para evitar la inclusión de transacciones falsas. Por desgracia, algunos sitios Web permiten determinados comportamientos que pueden derivar en problemas. El primer ejemplo de ataque en el mundo real fue Twitter. La API de Twitter permitía que un atacante introdujese cabeceras HTTP nuevas en la petición. De esta forma podía dirigir el contenido de la petición original de la víctima, de modo que se enviase como HTTP POST. Así, lo que Twitter recibía eran datos HTTP POST, la cookie del usuario, y los publicaba como un tweet público. La solución a este problema es realmente fácil: Muchos fabricantes simplemente deshabilitan la renegociación SSL en su software. Si no hay renegociación, no hay ataque.

Ataque Padding Oracle

Durante la conferencia de seguridad ekoparty, de septiembre 2010, Juliano Rizzo y Thai Duong demostraron cómo realizar ataques Padding Oracle a sitios Web ASP.NET explotando una vulnerabilidad del framework. Con ello el atacante puede descifrar cualquier información sensible guardada en el lado del cliente, e incluso descargar archivos prohibidos y tener acceso a sus datos sensibles, por ejemplo: cadenas de conexión, credenciales de seguridad, etc.

En resumen, se puede descifrar las cookies, los ViewState, tickets de autenticación, contraseñas de membresía, datos de usuario, y cualquier otra cosa cifrada usando la API del framework.

La vulnerabilidad afecta a todas las versiones de ASP.NET desde 1.x hasta la 4.0 y afecta a todos los frameworks de desarrollo de ASP.NET. Por ende productos basados en ASP.NET, como SharePoint, Team Foundation Server, entre otros, se ven afectados también. El ataque Padding Oracle no es exclusivo de dicha plataforma, de hecho un primer ataque fue dirigido hacia la plataforma JSF, específicamente a MyFaces. Se ha lanzado una implementación en JavaScript y nada descarta que en el futuro se implementen otros exploits para otros objetivos.

Serge Vaudenay, profesor del Laboratorio de Seguridad y Criptografía, LASEC, del Instituto Federal Suizo de Tecnología, EPFL, publicó en 2002 el documento Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS…, donde señala que varios sistemas de relleno, en inglés padding, de cifrado utilizados en sistemas de entrada de longitud variable pueden introducir grandes fallos de seguridad.

Cuando un mensaje cifrado de entrada de longitud variable se descifra basado en el algoritmo RFC 2040, el receptor tiene que determinar lo que es relleno, si el relleno es correcto, entonces lo descarta. Pero el RFC 2040 no especifica lo que el receptor debe hacer si el relleno no es correcto. Ésto conduce a un ataque que utilice un oráculo para cualquier bloque de secuencia que le diga si el relleno de la secuencia CBC-descifrada correspondiente es correcta de acuerdo al algoritmo RFC 2040 o no lo es.

Según Vaudenay, esta vulnerabilidad puede afectar a protocolos como SSL, IPSec, WTLS, SSH, existiendo la posibilidad de descifrar los datos cifrados sin tener la clave secreta. Él demuestra cómo funciona el ataque y sugiere una posible vía para solucionar la vulnerabilidad.

Cómo funciona

Se puede consultar este artículo: Automated Padding Oracle Attacks with PadBuster, que también muestra cómo funcionan los algoritmos explotados.

En resumen, los algoritmos de cifrado trabajan sobre bloques de datos, de 8 o 16 bytes por lo general, los bytes restantes son de relleno. Por ejemplo, una palabra de 6 letras “PIERNA”, se rellenará con dos bytes para convertirse en un bloque de 8 bytes.

Se le denomina oráculo, en inglés oracle, al mecanismo dentro de un sistema de cifrado capaz de proporcionar una respuesta de Válido o Inválido para un determinado texto cifrado. Por lo tanto, el Padding Oracle es un mecanismo, capaz de responder, si el relleno del texto cifrado es válido o no.

Los algoritmos de cifrado construidos en Microsoft .NET Framework, disparan unSystem.Security.Cryptography.CryptographicException con el mensaje Padding is invalid and cannot be removed en caso de que el relleno no sea válido. Así que ese es nuestro Padding Oracle a utilizar.

El ataque

Podríamos resumirlo en lo siguiente:

  • – El atacante localiza una cadena Base64, que suele ser un texto cifrado. En ASP.NET podría obtenerse fácilmente de la URL del WebResource.axd o de una cookie de autenticación.
  • – El atacante cambia un byte del texto cifrado y lo envía al oráculo, preguntando si es válido, hasta que ese byte es descifrado. Las respuestas Valido/Invalido son simplemente entendidas por el examen de las respuestas del servidor, por ejemplo, el código de error 500 significa que el texto no es válido y los 404 que es válido pero no se pudo descifrar.
  • – El ataque no está en función del código de error en sí, sino que basta vigilar cualquier comportamiento anormal de este protocolo. Incluso si el sitio Web devuelve la misma página de error en todos los casos, el atacante podría hacer uso de las diferencias de tiempo, según lo declarado por Thai Duong. Después de conseguir con éxito la clave secreta ASP.NET, la machineKey, el atacante puede crear sus propias cookies y comenzar a usar el sistema como administrador o bien podría descargar sus archivos sensibles, por ejemplo: web.config.
  • – Adicionalmente, el atacante podría utilizar la vulnerabilidad para cifrar su propio sistema de cifrado sin tener la clave de cifrado original.
Ataque BEAST

El 23 de septiembre de 2011, los investigadores Thai Duong y Juliano Rizzo demostraron una prueba de concepto llamada BEAST, Browser Exploit Against SSL/TLS, usando un applet Java para violar restricciones de políticas de mismo origen, por una vulnerabilidad de CBC largamente conocida de TLS 1.0. Lo cierto es que esta vulnerabilidad fue dada a conocer por Phillip Rogaway en 2002, pero no se conocían exploits prácticos de esta vulnerabilidad.

El ataque BEAST se puede prevenir eliminando todos los cifrados CBC de la lista de cifrados permitidos, dejando solamente el cifrado RC4, que es ampliamente soportado por la mayoría de los sitios web. Los usuarios de Windows 7 y de Windows Server 2008 R2 pueden permitir el uso de TLS 1.1 y 1.2, pero esta contramedida fallará si no es soportado también por el otro extremo de la conexión, y caerá a TLS 1.0.

Ataque CRIME

Juliano Rizzo y Thai Duong ya tuvieron una enorme repercusión cuando anunciaron en 2010 el ataque Padding Oracle que afectó ampliamente ASP.NET y en 2011 el ataque a TLS 1.0/SSL 3.0 mediante BEAST que era capaz de descifrar las peticiones cliente en tiempo real y secuestrar sesiones hacia sitios tan sensibles como los de la banca online.

Ahora en la ekoparty 2012, han presentado otra nueva técnica bautizada como CRIME para comprometer la integridad de las sesiones HTTP protegidas por SSL.

SSL/TLS opcionalmente soporta compresión de datos. En el mensaje ClientHello, el cliente establece la lista de algoritmos de compresión que conoce, y el servidor responde, en el ServerHello, con el algoritmo de compresión que se utilizará.

Los algoritmos de compresión son especificados por identificadores de un byte y TLS 1.2, según determina el RFC 5246, define únicamente el método de compresión nula, es decir, sin compresión. Cuando se utiliza la compresión, se aplica en todos los datos transferidos, como un stream largo. En particular, cuando se utiliza con HTTPS, la compresión se aplica en todas las sucesivas peticiones HTTP en el stream, la cabecera incluida. El algoritmo de comprensión DEFLATE funciona mediante la localización de subsecuencias repetidas de bytes.

Supongamos que el atacante es un código javascript que puede enviar peticiones arbitrarias a un sitio destino, por ejemplo un banco, y se ejecuta en la máquina atacada; el navegador enviará dichas solicitudes con la cookie del usuario del banco, el valor de la cookie que el atacante tiene después. Además, vamos a suponer que el atacante puede analizar el tráfico entre el ordenador del usuario y el banco, para ello, el atacante debe tener acceso a la misma LAN o al punto de acceso WiFi de la víctima, o se ha apropiado de un router de entre medias, posiblemente cerca del servidor del banco.

Para este ejemplo, supongamos que la cookie en cada solicitud HTTP es la siguiente:

> Cookie: secret=7xc89f+94/wa
El atacante conoce la parte Cookie: secret = y desea obtener el valor de secret. Entonces, programa su código Javascript para emitir una petición que contenga en su cuerpo la secuencia Cookie: secret = 0. La solicitud HTTP se verá así:

POST / HTTP/1.1 Host: thebankserver.com (…) Cookie: secret=7xc89f+94/wa (…)

Cookie: secret=0
Cuando DEFLATE vea que, hay repeticiones de secuencias Cookie: secret = y representan la segunda parte con un tokenmuy corto, uno que dice: “la secuencia anterior tiene una longitud de 15 y se encontraron n bytes anteriormente”, DEFLATE tendrá para emitir un token adicional para el ‘0’.

La solicitud va al servidor. Desde el exterior, el atacante ve un bloque opaco, recordemos que SSL cifra los datos, pero puede ver su longitud con una resolución de bytes cuando la conexión utiliza RC4; con cifrado de bloques que hay un poco de relleno o padding pero puede ajustar el contenido de las peticiones por lo que, en la práctica, puede conocer también la longitud de las peticiones comprimidas.

Ahora, el atacante lo intenta de nuevo con Cookie: secret=1 en el cuerpo de la petición. Luego, Cookie: secret=2, y así sucesivamente. Todas estas peticiones se comprimen con el mismo tamaño, excepto el que contiene Cookie: secret = 7, que comprime mejor, 16 bytes de subsecuencia repetida en lugar de 15, y por lo tanto será más corta. El atacante ve eso. Por lo tanto, en unas pocas docenas de peticiones, el atacante habrá adivinado el primer byte del valor de secret.

A continuación, sólo tiene que repetir el proceso Cookie: secret = 70, Cookie: secret = 71Cookie: secret = 7x y así sucesivamente, y obtener, byte por byte, el valor de secret completo.

Por lo tanto, para que el ataque CRIME tenga éxito, se requieren algunos aspectos:

  • – Que la compresión SSL/TLS se utilice en ambos extremos.
  • – Que el atacante pueda ejecutar un agente Javascript en la víctima.
  • – Un sniffer que tenga acceso a la sesión cifrada cliente-servidor.

Otros factores facilitarían además el ataque:

  • – El uso de RC4 en lugar de cifrado de bloques como CBC.
  • – La proximidad del sniffer al punto final del agente de la víctima podría proporcionar información más rápidamente, acortando el tiempo requerido para completar el ataque.
Ataque BREACH

Otro ataque llamado BREACH por sus siglas en ingles de Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext cuya traducción es reconocimiento y exfiltración del navegador a través de compresión adaptativa del hipertexto, es capaz de obtener los datos encriptados que mandan los sitios Web protegidos por el protocolo SSL/TLS a los usuarios que interactúan con dichas páginas. El ataque fue dado a conocer en BLACKHAT 2013, un evento de seguridad informática orientado al sector empresarial. Dicho ataque está inspirado por el ataque CRIME y aprovecha un comportamiento conocido de la compresión DEFLATE utilizada en las conexiones HTTPS para, mediante la inyección de un contenido previamente conocido en la conexión HTTPS, obtener el secreto de la sesión SSL, lo que le permite descifrar todo el tráfico SSL de esa sesión a partir de ese momento.

Los investigadores Angelo Prado, Neal Harris y Yoel Gluck demostraron el ataque en la BLACKHAT contra la aplicación Web Outlook Web Access (OWA). Una vez abierta la aplicación Web y lanzado el ataque BREACH, en tan solo 30 segundos habían conseguido extraer la información del canal seguro. El ataque se basa en la inyección de texto plano en una petición HTTPS y medir los cambios en las respuestas comprimidas.

Para un token de una longitud de 32 caracteres y un alfabeto de 16, el atacante necesitará una media de aproximadamente 1.000 peticiones si no se necesitan mecanismos de recuperación adicionales. En la práctica, se ha comprobado que es posible recuperar tokens CSRF con menos de 4.000 peticiones. Navegadores como Google Chrome o Internet Explorer son capaces de realizar esas peticiones en menos de 30 segundos, incluyendo las llamadas de vuelta al centro de comando y control del atacante, que puede ser un sitio controlado por el atacante con un iframe apuntando al servidor vulnerable, o directamente con la intercepción y modificación del tráfico no asegurado.

Supongamos que la respuesta encriptada de un sitio que se envía a un usuario es de 64 bytes y que el contenido de dicho paquete incluye el correo “admin@tierradelazaro.com”. BREACH podría comenzar incluyendo “@” en el paquete que se envía de regreso a la página y al comparar notaria que el tamaño en bytes es menor, eso quiere decir que el signo “@” está incluido dentro del paquete original. Posteriormente incluiría “@a”, otro con “@b” y otro con “@t”. De todos los paquetes previamente mencionados solamente el que contiene “@t” mantendría una longitud en bytes menor al de la respuesta original debido a que no estaría agregando caracteres nuevos. BREACH continuaría con este proceso hasta conseguir los datos encriptados, entre ellos el correo.

Esta técnica se puede utilizar para extraer otros tipos de texto cifrado incluidos en las respuestas Web. Si el sitio objetivo envía variables especiales para prevenir ataques de CSRF, la credencial contendrá casi siempre el mismo tamaño, comorequest_token= o parecido, seguido por una larga cadena de texto como bb63e4ba67e24d6b81ed425c5a95b7a2.

Un atacante comenzaría añadiendo el texto request_token=a. Dado que el tamaño de la carga útil cifrada crece, sería obvio suponer que esa cadena es incorrecta. Por el contrario, al añadir request_token=b, y al no crecer la cadena cifrada, se tiene una idea de que el primer carácter después del signo igual es b. Para completar el ataque, sólo es necesario hacer unas pocas miles de peticiones dirigidas al servicios web y, en cuestión de minutos, se pueden obtener secretos más avanzados.

Ataque Lucky Thirteen

Los ataques descubiertos, y que han sido bautizados con el nombre de Lucky Thirteen, pueden ser utilizados para desencriptar datos cifrados bajo los protocolos de seguridad SSL, TLS y DTLS. El protocolo DTLS, Datagram Transport Layer Security, está basado en TLS y se utiliza para el cifrado de las conexiones entre las aplicaciones que se comunican a través de UDP, User Datagram Protocol.

Los desarrolladores de muchas bibliotecas SSL están lanzando parches para una vulnerabilidad que podría ser explotada para recuperar información, como las cookies de autenticación del navegador, desde comunicaciones cifradas. Estos parches son la respuesta al descubrimiento de nuevas vías para atacar implementaciones SSL, TLS y DTLS que utilizan el modo de encriptación cipher block chaining, CBC, las cuales han sido desarrolladas por los investigadores Nadhem J. AlFardan y Kenneth G. Paterson de la Universidad Royal Holloway College de Londres.

Según afirman estos autores. Los ataques surgen de un error en la especificación TLS, en lugar de un fallo en implementaciones específicas. Los ataques se aplican a todas las implementaciones TLS y DTLS que sean compatibles con TLS 1.1 o 1.2, o con DTLS 1.0 o 1.2, que son las versiones más recientes de las dos especificaciones. También se aplican a las implementaciones de SSL 3.0 y TLS 1.0, versiones que incorporan contramedidas a ataques previos de Oracle. Esto significa que es probable que casi todas las bibliotecas usadas para aplicar algunos de los protocolos de seguridad más importantes de Internet sean vulnerables a los ataques Lucky Thirteen.

Cómo funciona

El ataque Lucky Thirteen es un nuevo ataque criptográfico basado en una variante del ataque Padding Oracle en el momento de la verificación de integridad del MAC. Todos los conjuntos de cifrado TLS y DTLS que incluyen el modo de cifrado CBC son potencialmente vulnerables a los ataques.

Lucky Thirteen utiliza una técnica conocida como Padding Oracle en el motor de cifrado principal en TLS, responsable de realizar el cifrado y garantizar la integridad de los datos. Los datos se procesan en bloques de 16 bytes utilizando una rutina conocida como MEE, MAC-then-Encode-then-Encrypt, que pasa los datos a través de un algoritmo MAC; a continuación, los codifica y los cifra. La rutina añade un relleno al texto cifrado para que los datos resultantes queden perfectamente alineados al límite de 8 ó 16 bytes. Este relleno más tarde se extrae al momento de descifrar TLS.

El ataque comienza con la captura de texto cifrado a medida que viaja a través de Internet. Usando una debilidad antigua de CBC en TLS, los atacantes reemplazan los últimos bloques con varios bloques escogidos y observan la cantidad de tiempo que le lleva responder al servidor. Los mensajes que contienen un relleno correcto tardarán menos tiempo en procesarse. Un mecanismo en TLS hace que la transacción falle cada vez que la aplicación se encuentra con un mensaje que contiene datos alterados. Mediante el envío de grandes cantidades de mensajes TLS y el muestreo estadístico de tiempos de respuesta, se puede adivinar el contenido del texto cifrado.

Aproximadamente toma 2^23 sesiones extraer todo el contenido de una cookie en una autenticación TLS normal, y si lascookies están codificadas en Base64, se podría extraer en 2^19 sesiones. Ya que el acercamiento al problema es similar, para hacer los ataques más eficientes, se pueden incorporar métodos como BEAST y CRIME utilizando JavaScript.

Recomendaciones:
  • – Evita hacer uso de computadoras y redes públicas, sobre todo si vas a utilizar el servicio de banca online, realizar cualquier tipo de compra o transferir información valiosa para ti.
  • – Instala un antivirus y procura mantenerlo actualizado.
  • – Es importante mantener actualizado tu navegador, ya que si no lo haces, eres más susceptible a ataques. Consulta el sitio web oficial del navegador que elijas y obtén la versión más reciente.
  • – Mantén tu Sistema Operativo actualizado, esto mejora la seguridad.
  • – Cuando utilices HTTPS, verifica la vigencia del certificado, ésto lo puedes hacer observando en el periodo de validez del mismo. Verifica que se muestra el candadito cerrado en el navegador y que estás accediendo al dominio que quieres acceder.
  • – Verifica periódicamente que tu configuración de Internet, sobre todo la IP de tu servidor de DNS es correcta.
  • – Realiza copias de seguridad de tus documentos y de tus datos más sensibles.
  • – Y enciende una vela a la Virgen, pues aún haciendo todo lo de arriba y teniendo mucho cuidado, nada garantiza la total seguridad.

Comentarios

Deja un comentario

Tu e-mail no será publicado. Los campos requeridos están marcados con *