Cloudbleed: когда CDN сам становится вектором утечки

18 февраля Cloudflare опубликовал разбор бага, который нашёл Tavis Ormandy из Google Project Zero. Суть неприятная: из-за ошибки в HTML-парсере (написанном на C, с указательной арифметикой - привет) Cloudflare годами мог выплёскивать куски оперативной памяти своих серверов прямо в HTTP-ответы. Эти ответы оседали в кеше поисковых движков и CDN-прослоек. То есть токены сессий, заголовки авторизации, куки, случайные куски чужого трафика - всё это могло лежать проиндексированным в Google, пока Ormandy не начал смотреть на странные артефакты в ответах.

Cloudflare говорит, что баг активнее всего проявлялся в период с 13 по 18 февраля, а саму проблему они закрыли за несколько часов после уведомления. Но парсер с уязвимостью жил в продакшне с сентября 2016 года. Пять месяцев.

Почему это важно для нас конкретно

Cloudflare - популярная штука: дешёвый DDoS-митигейшн, CDN, SSL-терминация, WAF. Многие клиенты ставят его «сверху» и забывают. И вот тут Cloudbleed показывает неочевидную вещь: CDN - это не пассивная труба. Это активный посредник, который терминирует TLS, читает заголовки, модифицирует HTML. Если в нём баг - он сидит ровно между пользователем и вашим приложением, со всеми вытекающими.

Схема доверия большинства клиентов выглядит примерно так: «мы за Cloudflare, значит нас защищают». Cloudbleed напоминает, что Cloudflare - это ещё и поверхность атаки. Причём поверхность, которую вы не контролируете напрямую.

Что мы сделали

Первым делом - прошлись по клиентам и выяснили, кто вообще за Cloudflare. Это неочевидно: часть клиентов ставила его самостоятельно «чтобы был», часть - по рекомендации внешних подрядчиков, и не всегда это зафиксировано в инфраструктурной документации.

Проверка простая - dig плюс сверка диапазонов AS13335 (Cloudflare). Из нескольких десятков доменов за нами нашлось несколько за Cloudflare, причём пара - сюрприз для нас самих.

Дальше аудит делился на два направления.

Первое - заголовки кеширования. Cloudflare кеширует контент агрессивно. Если у приложения не выставлены правильные Cache-Control заголовки, страницы с динамическим контентом (включая фрагменты авторизованных ответов) могут оседать в кеше. Смотрели на Cache-Control: no-store и private для аутентифицированных эндпоинтов, на отсутствие s-maxage там, где его быть не должно. Находки были - несколько приложений отдавали Cache-Control: max-age=3600 на страницах с персональными данными. Не критично в нормальных условиях, но в контексте Cloudbleed - уже интересно.

Второе - сессионные токены. Смотрели на несколько вещей: срок жизни, ротация после логина, флаги HttpOnly и Secure на куках. В двух случаях нашли куки без HttpOnly - значит, читаемы из JS. В одном - сессия не инвалидировалась после логаута на сервере, только чистился cookie на клиенте. Это не баг Cloudflare, это обычные ошибки приложений - но Cloudbleed заставил их проверить.

Что конкретно рекомендовали

• Сменить сессионные токены принудительно для приложений, которые проходили трафик через Cloudflare в период с сентября 2016 по 18 февраля 2017. Инвалидировать все активные сессии.
• Выставить Cache-Control: no-store на всех эндпоинтах, которые возвращают что-то авторизованное или персональное.
• Проверить флаги кук - HttpOnly, Secure. Базово, но регулярно пропускается при разработке.
• Зафиксировать в инфраструктурной карте, кто за Cloudflare, кто за собственным nginx, кто вообще без проксирования. Чтобы в следующий раз не выяснять это в процессе реагирования.

Осадок

Cloudbleed - редкий случай, когда баг оказался у инфраструктурного провайдера, а не в коде клиента. Cloudflare сработал быстро: уведомление получено, патч выкатили за несколько часов, разбор опубликовали честный. Но это не меняет факта: несколько месяцев данные могли утекать, и никто этого не замечал - ни клиенты, ни сам Cloudflare.

Это хороший повод переосмыслить модель угроз: CDN, WAF, любой SSL-терминатор в цепочке - это не просто защитный экран, это ещё один компонент с потенциальными уязвимостями. Его тоже нужно включать в аудит безопасности инфраструктуры, а не считать нейтральной прослойкой.

Работа по клиентам завершена. Открытых вопросов по срочному реагированию нет. Системные правки в заголовки и куки идут в плановом режиме.