Ataques de compresión SSL / TLS en servidores de correo (smtp)

Los ataques de compresión como CRIME y BREACH funcionan activando la transmisión repetida de casi el mismo mensaje con solo pequeñas modificaciones, con estas modificaciones controladas por el atacante. Al observar el tamaño comprimido del mensaje, el atacante puede razonar si la cadena controlada por el atacante está contenida en el mensaje o no. Esto se utiliza para adivinar el valor de los datos confidenciales, como la cookie de sesión o los tokens CSRF en el caso de HTTP.

Con HTTP, estos ataques funcionan en casos en los que la respuesta del servidor refleja la entrada del cliente (para adivinar el token CSRF en respuesta) o al hacer que el cliente envíe la misma solicitud con leves variantes de la URL o datos del cuerpo para adivinar la Cookie en la solicitud HTTP. La entrada controlada por el atacante es posible ya que HTTP permite solicitudes entre sitios, es decir, el atacante puede hacer que el cliente realice una solicitud específica y luego ver la solicitud y la respuesta cifradas.

Pero SMTP funciona diferente. Por lo general, el atacante no puede hacer que el cliente envíe una y otra vez un correo específico con solo modificaciones leves y controladas por el atacante. Aunque se podrían crear escenarios en los que casi el mismo correo se envía de forma automática con una entrada controlada por un atacante (consulte la respuesta de @Giles ) en mi opinión, en todos los casos prácticamente relevantes, tales ataques de compresión no funcionarán con SMTP.

Aún así, es mejor no utilizar la compresión de nivel TLS (utilizada por CRIME), que es de esperar que sea la opción predeterminada en las bibliotecas criptográficas modernas de todos modos. En cuanto a la compresión de nivel de aplicación utilizada por BREACH: si bien es común usar dicha compresión en HTTP (declarada por el encabezado Content-Encoding ), no hay compresión de nivel de aplicación definida en SMTP o MIME (que es el formato de encapsulación para correos). Si bien hay un x-gzip64 propuesto, nunca lo he visto usado en la práctica o respaldado por clientes de correo reales.

El principio básico subyacente en los ataques de compresión + cifrado es que el atacante puede hacer que el remitente envíe muchos mensajes cifrados que contengan el mismo texto, incluido un valor secreto que el atacante desea encontrar, excepto un segmento controlado por el agresor. El ejemplo canónico de CRIME y BREACH es una respuesta web, que incluye una cookie (secreto que el atacante quiere encontrar) y alguna información que el atacante inyecta a través de un recurso de terceros (por ejemplo, un anuncio).

Es posible que pueda realizar un ataque similar contra SMTP si puede recopilar los mismos ingredientes: correos electrónicos casi idénticos, todos ellos que contienen el secreto que desea obtener, y que difieren solo o principalmente en algún valor que usted puede controlar Tenga en cuenta que SMTP se usa en el lado de envío, que suele ser más difícil de atacar: es fácil de indagar en los usuarios de wifi (solo tiene que instalar un punto de acceso falso), pero se necesita un atacante de alto nivel para que espíe las conexiones en un centro de datos.

Por ejemplo, suponga que está tratando de encontrar la dirección de correo electrónico de un usuario de un servicio, y que el servicio está configurado para enviar al usuario algunas alertas por correo electrónico, como un feed de RSS a correo electrónico. Si puede inyectar datos en la fuente RSS ( wibble waffle To: [email protected]: [email protected]: [email protected]: [email protected] ), entonces puede llevar a cabo un ataque de tipo CRIME para encontrar la dirección de correo electrónico. Este ataque en particular tiene muchos problemas prácticos: se basa en que el correo electrónico se envía a la víctima, por lo que es bastante llamativo (aunque puede intentar apuntar al contenedor de spam), y puede llegar a límites de velocidad (miles de solicitudes web no son más que miles de correos electrónicos a la misma cuenta probablemente quedarán atrapados por la protección contra correo no deseado).

Aquí hay otro ejemplo con un feed de noticias a correo electrónico donde puede inyectar noticias falsas. Esta vez, suponga que el correo electrónico contiene un enlace de "cancelación de suscripción" que contiene un token secreto. Envía muchas noticias falsas y encuentra el token secreto en el enlace "cancelar suscripción". Es bastante común que los servidores acepten solicitudes de cancelación de la suscripción sin autenticar al usuario, especialmente cuando todo lo que el servidor sabe es el correo electrónico del usuario (más los datos de marketing asociados) y no hay una cuenta asociada en la que el usuario pueda iniciar sesión. De esta manera, puede cancelar la suscripción fraudulenta de un usuario de su feed. Con suerte, si el servidor tiene una cuenta de usuario, el token secreto solo no le permite hacer nada más en la cuenta.

Otro secreto que te puede interesar es algún tipo de token de autorización. Supongamos que un servidor usa un token secreto enviado por correo electrónico (o cualquier otro método de comunicación en realidad) como factor para confirmar una transacción, y puede curiosear en el tráfico de ese servidor o en el tráfico del destinatario. Supongamos que este token es todo lo que necesita para confirmar la transacción. Su objetivo es activar una transacción para su beneficio (por ejemplo, una transferencia de dinero para usted) y encontrar el token asociado. Tienes la oportunidad de iniciar la transacción para que puedas controlar su descripción. Hay una manera incorrecta de que el servidor lo haga: use una OTP basada en el tiempo, que se repetirá en muchas transacciones. Es de esperar que el servidor lo haga correctamente, con un valor aleatorio adecuado que sea diferente en cada transacción.

Tenga en cuenta que, salvo en el caso de que el secreto que desea encontrar sea la dirección de correo electrónico del destinatario, puede llevar el ataque en el lado del cliente, contra IMAP o POP cifrados en lugar de SMTP.