Cache-Poisoned Denial-of-Service (CPDoS). Часть 1 Что это за | 🇺🇦 DevOps простыми словами

Cache-Poisoned Denial-of-Service (CPDoS). Часть 1

Что это за вид атаки и как работает?
Если атакующий нашел у вас такую уязвимость, то вы в какой-то момент заходя на свой сайт, вместо 200ОК увидите, что-то из 4xx-5xx. Пойдете проверить свой бекенд, и увидите, что с ним все в порядке. Однако проблема есть, рассмотрим разные варианты этой атаки ниже.

Стандартный способ использовать данную атаку против ваших сайтов предполагает, что перед вашим сайтом стоит какой-то кеширующий сервер: CDN, либо CDN+Varnish(или подобный). Например, у всех сайтов на популярном сайтбилдере WebFlow перед их серверами стоит Varnish.

curl -I https://somesite.webflow.com/
HTTP/2 200
server: openresty
via: 1.1 varnish, 1.1 varnish
x-served-by: cache-iad-kjyo7100124-IAD, cache-dub4350-DUB
...

Это значит, что клиент открывая их страницу обращается к Varnish, который в свою очередь идет на условный Origin бекенд somesite-backend.example.com и запрашивает у него страницу, отдает вам, и складывает себе в кеш. Далее все клиенты получают эту страницу из кеша.

Но что, если, Origin вернет не нормальную страницу, а скажем 400 Bad Request? Правильно - Varnish сохранит ее у себя в кеше, и будет отдавать дальше всем клиентам!

Ок, разобрались как работает. Правда мой сайт живет в Хецнере на огромном серваке всегда отдает 200ОК, у нас 99,9999% аптайм вообще-то, нам то что?
Как заставить ваш бекенд отдать НЕ 200ОК:

- HTTP Header Oversize (HHO)
Атака HHO заключается в том, что вы посылаете GET запрос с заведомо большим HTTP header. И тут важный момент: промежуточный кеш должен пропускать такие хедеры по размеру больше, чем может принять ваш бекенд. Как это выглядит на пальцах:

Client: HTTP GET with X-Bad-Header: "Very-Big Value-01123581321345589144233377610987"
↓↓↓
Cache: Looks good to my internal headers limits
↓↓↓
Origin: Oh, too big header for me. 400 Bad Request
↓↓↓
Cache: 400 Bad Request saved into Cache

Дело сделано, все следующие после этого трюка клиенты получают от кеша 400-й ответ.

- HTTP Meta Character (HMC)
Подобный к HHO вид, только в хедере вы добавляете мета символ, вроде \n, \r, \a. Кеш пропускает этот хедер на бекенд, который не может это обработать, и отвечает что-то типа Character not allowed и 400 Bad Request, все, кеш отравлен!

- HTTP Method Override Attack (HMO)
Этот метод как вы могли догадаться направлен на переопределение заголовка X-HTTP-Method. Далеко не все фреймворки/бекенды поддерживают X-HTTP-Method-Override, однако для тех кто поддерживают вы можете переопределить HTTP метод, проскочив кеш, например так:

curl -H "X-HTTP-Method-Override: POST" https://somesite.example.com/index.html получив в ответ "404 Not Found, POST on /index.html not found". Кеш опять отравлен, все остальные клиенты как и в примерах выше будут получать 404, вместо вашей стандартной страницы.

Будет справедливым вопрос: но, ведь на всех PoP(Point of Presence) наверняка уже лежат правильные ответы с 200ОК?
Все верно! Поэтому, злоумышленнику нужно проскочить со своим вредоносным реквестом в тот момент, когда на PoP закончился TTL обьекта, и PoP пойдет за ним на Origin сервер. Здесь просто пишется довольно незадачливый код, который в условном loop пытается отслылать свои реквесты на точку, в надежде на то, что вредоносный реквест будет первым после окончания TTL и отравит таким образом кеш. Это может занять не так много времени, как могло бы показаться.

Что происходит, если отравить одну точку CDN такими методами?
В зависимости от того как работает система внутреннего распространения кеша у того или иного провайдера, такой отравленный кеш как минимум расползется по ближайшим точкам присутствия в регионе, как максимум по всем PoP в мире. Но, теоретически, атакеру не сложно будет обнаружить все PoP провайдера и пройтись по каждой, чтобы отравить наибольшее количество точек.