marzo 20, 2020

CPDoS una nueva clase de ataques de envenenamiento de caché web destinados a deshabilitar recursos web y sitios web.

Voiced by Amazon Polly
Comparte en redes sociales

Cache-Poisoned Denial-of-Service (CPDoS) es una nueva clase de ataques de envenenamiento de caché web destinados a deshabilitar recursos web y sitios web. El flujo de ataque básico se describe a continuación y se muestra en la siguiente figura:

  1. Un atacante envía una solicitud HTTP simple que contiene un encabezado malicioso dirigido a un recurso víctima proporcionado por algún servidor web. La solicitud es procesada por el caché intermedio, mientras que el encabezado malicioso permanece discreto.
  2. El caché reenvía la solicitud al servidor de origen, ya que no almacena una copia nueva del recurso de destino. En el servidor de origen, el procesamiento de la solicitud provoca un error debido al encabezado malicioso que contiene.
  3. Como consecuencia, el servidor de origen devuelve una página de error que el caché almacena en lugar del recurso solicitado.
  4. El atacante sabe que el ataque tuvo éxito cuando recuperó una página de error en respuesta.
  5. Usuarios legítimos que intentan obtener el recurso objetivo con solicitudes posteriores …
  6. … obtendrá la página de error en caché en lugar del contenido original.

Con CPDoS, un cliente malicioso puede bloquear cualquier recurso web que se distribuye a través de Redes de distribución de contenido (CDN) o alojado en cachés proxy . Tenga en cuenta que una sola solicitud diseñada es suficiente para evitar que todas las solicitudes posteriores accedan al contenido de destino.

Existen tres variaciones de CPDoS:

  • Encabezado HTTP de gran tamaño (HHO)
  • HTTP Meta Character (HMC)
  • Anulación de método HTTP (HMO)

Encabezado HTTP de gran tamaño (HHO).

Un encabezado de solicitud HTTP contiene información vital para sistemas intermedios y servidores web. Esto incluye campos de encabezado o metadatos relacionados con el caché en tipos de medios, idiomas y codificaciones compatibles con el cliente. El estándar HTTP no define ningún límite de tamaño para los encabezados de solicitud HTTP. Como consecuencia, los sistemas intermedios, los servidores web y los marcos web definen sus propios límites. La mayoría de los servidores web y servidores proxy como Apache HTTPD proporcionan un límite de tamaño de encabezado de solicitud de alrededor de 8.192 bytes para mitigar, por ejemplo, el desbordamiento de búfer de encabezado de solicitud o los ataques ReDoS . Sin embargo, también hay sistemas intermedios que especifican límites mayores de 8,192 bytes. Por ejemplo, Amazon Cloudfront CDN permite hasta 20,480 bytes. Esta brecha semántica en términos de límites de tamaño de encabezado de solicitud puede explotarse para realizar un ataque de envenenamiento de caché que puede conducir a una denegación de servicio.

Los ataques HHO CPDoS funcionan en escenarios en los que una aplicación web utiliza un caché que acepta un límite de tamaño de encabezado mayor que el servidor de origen. Para atacar una aplicación web de este tipo, un cliente malintencionado envía una solicitud HTTP GET incluye un encabezado mayor que el tamaño admitido por el servidor de origen pero menor que el tamaño admitido por el caché. Para hacerlo, un atacante tiene dos opciones. Primero, crea un encabezado de solicitud con muchos encabezados maliciosos como se muestra en el siguiente fragmento de código Ruby. La otra opción es incluir un solo encabezado con una clave o valor de gran tamaño.

require 'net/http' uri = URI("https://example.org/index.html") req = Net::HTTP::Get.new(uri) num = 200 i = 0 # Setting malicious and irrelevant headers fields for creating an oversized header until i > num do req["X-Oversized-Header-#{i}"] = "Big-Value-0000000000000000000000000000000000" i +=1; end res = Net::HTTP.start(uri.hostname, uri.port, :use_ssl => uri.scheme == 'https') {|http| http.request(req) }
require 'net/http' uri = URI("https://example.org/index.html") req = Net::HTTP::Get.new(uri) num = 200 i = 0 # Setting malicious and irrelevant headers fields for creating an oversized header until i > num do req["X-Oversized-Header-#{i}"] = "Big-Value-0000000000000000000000000000000000" i +=1; end res = Net::HTTP.start(uri.hostname, uri.port, :use_ssl => uri.scheme == 'https') {|http| http.request(req) } 

La siguiente figura muestra un flujo de ataque HHO CPDoS en el que un cliente malintencionado envía una solicitud creada por el fragmento de código anterior. El caché reenvía esta solicitud que incluye todos los encabezados al punto final ya que el tamaño del encabezado permanece por debajo del límite de tamaño de 20,480 bytes. Sin embargo, el servidor web bloquea esta solicitud y devuelve una página de error, ya que el encabezado de la solicitud excede su límite de tamaño de encabezado. Esta página de error con el código de estado 400 Bad Request ahora se almacena en la memoria caché. Todas las solicitudes posteriores dirigidas al recurso denegado ahora se proporcionan con una página de error en lugar del contenido original.

HTTP Meta Character (HMC).

El ataque CPDoS HTTP Meta Character (HMC) funciona de manera similar al ataque HHO CPDoS. En lugar de enviar un encabezado de gran tamaño, este ataque intenta omitir un caché con un encabezado de solicitud que contiene un meta carácter nocivo. Los metacaracteres pueden ser, por ejemplo, caracteres de control como salto de línea / retorno de carro ( \n ), avance de línea ( \r ) o campana ( \a ).

Un caché no consciente reenvía dicha solicitud al servidor de origen sin bloquear el mensaje o desinfectar los metacaracteres. Sin embargo, el servidor de origen puede clasificar dicha solicitud como maliciosa ya que contiene metacaracteres dañinos. Como consecuencia, el servidor de origen devuelve un mensaje de error que el caché almacena y reutiliza.

Ataque de anulación del método HTTP (HMO).

El estándar HTTP proporciona varios métodos HTTP para servidores web y clientes para realizar transacciones en la web. GET , POST , DELETE y PUT son posiblemente los métodos HTTP más utilizados en aplicaciones web y servicios web basados ​​en REST. Sin embargo, muchos sistemas intermedios, como servidores proxy, equilibradores de carga, cachés y firewalls, solo admiten GET y POST . Esto significa que las solicitudes HTTP con DELETE y PUT simplemente están bloqueadas. Para eludir esta restricción, muchas API basadas en REST o marcos web como Play Framework 1 , proporcionan encabezados como X-HTTP-Method-Override , X-HTTP-Method o X-Method-Override para los métodos HTTP bloqueados en túnel. Una vez que la solicitud llega al servidor, el encabezado indica a la aplicación web que anule el método HTTP en la línea de solicitud con el del valor del encabezado correspondiente.

POST /items/1 HTTP/1.1 Host: example.org X-HTTP-Method-Override: DELETE HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 62 Resource has been successfully removed with the DELETE method.
POST /items/1 HTTP/1.1 Host: example.org X-HTTP-Method-Override: DELETE HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 62 Resource has been successfully removed with the DELETE method. 

El fragmento de código muestra una solicitud que puede omitir una política de seguridad que prohíbe las solicitudes DELETE utilizando el encabezado X-HTTP-Method-Override . En el lado del servidor, esta solicitud POST se interpretará como una solicitud DELETE .

Estos encabezados de anulación de métodos son muy útiles en escenarios en los que los sistemas intermedios bloquean distintos métodos HTTP. Sin embargo, si una aplicación web admite dicho encabezado y también utiliza un sistema de almacenamiento en caché web como un caché de proxy inverso o CDN para optimizar el rendimiento, un cliente malintencionado puede explotar esta constelación para realizar un ataque CPDoS. La figura siguiente ilustra el flujo principal de un ataque CPDoS de ataque de anulación de método HTTP (HMO) utilizando el encabezado X-HTTP-Method-Override .

Aquí, el atacante envía una solicitud GET con un encabezado X-HTTP-Method-Override contiene POST . Un caché vulnerable interpreta esta solicitud como una solicitud GET benigna dirigida al recurso https://example.org/index.html . Sin embargo, la aplicación web interpretará esta solicitud como una solicitud POST , ya que el encabezado X-HTTP-Method-Override le indica al servidor que reemplace el método HTTP en la línea de solicitud. En consecuencia, la aplicación web devuelve una respuesta basada en POST . Supongamos que la aplicación web de destino no implementa ninguna lógica de negocios para POST en /index.html . En tales casos, los marcos web como Play Framework 1 devuelven un mensaje de error con el código de estado 404 Not Found . El caché supone que la respuesta devuelta con el código de error es el resultado de la orientación de solicitud GET https://example.org/index.html . Dado que el código de estado 404 Not Found se puede almacenar en caché de acuerdo con el HTTP Caching RFC 7231 , los cachés almacenan y reutilizan esta respuesta de error para solicitudes recurrentes. Cada cliente benigno que realiza una solicitud GET posterior a https://example.org/index.html recibirá un mensaje de error almacenado con el código de estado 404 Not Found lugar de la página de inicio de la aplicación web original.

Como mitigarlo:

Una de las principales razones de los ataques de HHO y HMC CPDoS radica en el hecho de que una memoria caché vulnerable almacena ilícitamente respuestas que contienen códigos de error como 400 Bad Request por defecto. Esto no está permitido según el estándar HTTP. El estándar de almacenamiento en caché web solo permite almacenar en caché los códigos de error 404 Not Found , 405 Method Not Allowed , 410 Gone y 501 Not Implemented . Por lo tanto, el almacenamiento en caché de páginas de error de acuerdo con las políticas del estándar HTTP es el primer paso para evitar ataques de CPDoS.

Los proveedores de contenido también deben usar el código de estado apropiado para el caso de error correspondiente. Por ejemplo, 400 Bad Request que utilizan muchas implementaciones HTTP para declarar un encabezado de gran tamaño no es el código de estado adecuado. IIS incluso utiliza 404 Not Found cuando se supera un encabezado específico. El código de error correcto para un encabezado de solicitud de gran tamaño es 431 Request Header Fields Too Large . Según el análisis de los investigadores del proyecto, este mensaje de error no es almacenado en caché por ningún sistema de almacenamiento en caché web.

Otra contramedida efectiva contra los ataques HHO y HMC CPDoS es excluir las páginas de error del almacenamiento en caché. Un enfoque es agregar el encabezado Cache-Control: no-store a cada página de error. La otra opción es deshabilitar el almacenamiento en caché de la página de error en la configuración de la memoria caché. Las CDN como CloudFront o Akamai proporcionan opciones de configuración para hacerlo.

También se puede implementar un firewall de aplicaciones web (WAF) para mitigar los ataques de CPDoS. Sin embargo, los WAF deben colocarse frente al caché para bloquear el contenido malicioso antes de que lleguen al servidor de origen. Los WAF que se colocan delante del servidor de origen se pueden explotar para provocar páginas de error que se almacenan en caché.

Más información de Cache-Poisoned Denial-of-Service (CPDoS):

https://cpdos.org/paper/Your_Cache_Has_Fallen__Cache_Poisoned_Denial_of_Service_Attack__Preprint_.pdf

Pagina del poyecto CPDoS:

https://cpdos.org/

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

A %d blogueros les gusta esto: