CPDoS una nueva clase de ataques de envenenamiento de caché web destinados a deshabilitar recursos web y sitios web.
 |
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:
- 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.
- 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.
- Como consecuencia, el servidor de origen devuelve una página de error que el caché almacena en lugar del recurso solicitado.
- El atacante sabe que el ataque tuvo éxito cuando recuperó una página de error en respuesta.
- Usuarios legítimos que intentan obtener el recurso objetivo con solicitudes posteriores …
- … 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.orgX-HTTP-Method-Override: DELETEHTTP/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.orgX-HTTP-Method-Override: DELETEHTTP/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):
Pagina del poyecto CPDoS:
