Из-за бага CDN-сеть Cloudflare месяцами сливала данные клиентов, от приватных сообщений до ключей шифрования и идентификаторов, принадлежащих пользователям известных онлайн-сервисов. По свидетельству технического директора Cloudflare Джона Грэм-Камминга (John Graham-Cumming), эта уязвимость была устранена, но до этого конфиденциальные данные пользователей таких сайтов, как Uber, Fitbit, OKCupid и т.п., какое-то время находились в открытом доступе.

О возможности утечки CDN-провайдеру сообщил десять дней назад исследователь Тэвис Орманди (Tavis Ormandy) из Google Project Zero. По словам Грэм-Камминга, проблема была связана с работой трех «неосновных» функций, которые уже отключены. Одна из них была активирована 22 сентября, однако наиболее активно данные сливались с 13 февраля до момента получения уведомления от Орманди.

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

«Похоже, в тех случаях, когда HTML-страница, защищаемая Cloudflare, содержала специфическую комбинацию несбалансированных тэгов, прокси присоединял к ответу страницы неинициализированной памяти (это работало как Heartbleed, только со спецификой Cloudflare и было гораздо хуже по причинам, которые я поясню позднее), — пишет Орманди. — В качестве рабочей версии я связал проблему с функцией ScrapeShield, которая производит разбор и обфусцирует HTML, однако из-за того, что обратные прокси разделены между клиентами, она должна была затронуть всех клиентов Cloudflare».

Данный баг получил условное наименование Cloudbleed, из-за схожести с Heartbleed, уязвимостью в OpenSSL трехлетней давности, которая также способствовала утечке данных. По словам Орманди, в ходе анализа он обнаружил среди данных, отданных другим пользователям, слитые криптоключи, куки, пароли, данные POST и запросов HTTPS к разным сайтам, размещенным у Cloudflare. Своими находками исследователь поделился с провайдером, а затем опубликовал твит о том, что крупнейшая CDN-сеть сливает данные клиентских HTTPS-сессий, в том числе с Uber, Fitbit, 1Password, OKCupid и других часто посещаемых сервисов.

Операторы 1Password поспешили заявить, что Cloudbleed не затронула их данные, так как их сервис предназначен для предотвращения подобных утечек в ходе TLS-связи. Представитель Uber в ответ на запрос Threatpost подчеркнул, что их пользователей эта проблема мало затронула: «На самом деле через Cloudflare проходит незначительная часть трафика Uber. Пострадали лишь несколько токенов, и они уже заменены. Пароли остались в сохранности».

OKCupid еще не закончила расследование. «Вчера вечером Cloudflare предупредила нас о баге, и мы выясняем его последствия для пользователей OKCupid, — заявил представитель компании журналистам Threatpost. — Предварительное расследование показало, что в открытом доступе оказалось минимальное количество данных, возможно, жертв и вовсе не было. Если окажется, что какие-то пользователи пострадали, мы обязательно оповестим их и примем меры защиты».

Fitbit в комментарии Threatpost заявила, что затронутым пользователям придется сменить пароли. «В настоящее время мы расследуем инцидент на сервисе Cloudflare, чтобы понять, каким образом он отразился на наших пользователях, — заявил представитель Fitbit. — Всем, кто заметил какие-то проблемы, следует сообщить об этом по адресу security@fitbit.com. В качестве меры предосторожности можно сменить пароль к аккаунту, затем выйти и вновь войти в мобильное приложение под новым паролем. Мы рекомендуем не использовать повторно пароли, ассоциированные с почтовым адресом или любым другим аккаунтом, так как подобная практика повышает степень уязвимости к вредоносному поведению».

Остальные затронутые веб-службы от публичных заявлений воздержались. Тем временем на GitHub был создан трекер, в списке которого числятся 4,3 млн сайтов, которые потенциально могли пострадать от Cloudbleed.

В своей блог-записи Грэм-Камминг пояснил, что при некоторых условиях пограничные серверы Cloudflare могли при обработке выйти за пределы конца буфера и вернуть блок памяти, содержащий закрытую информацию. Представитель провайдера подчеркнул, что утечка не затронула клиентские ключи SSL, так как завершение SSL-соединений происходит на изолированном экземпляре NGINX.

Грэм-Камминг полагает, что в утечке повинен парсер HTML, который задействуют три функции. По данным Cloudflare, в период с 13 по 18 февраля один HTTP-запрос из 3,3 млн приводил к утечке из памяти, что эквивалентно 0,00003% запросов.

Год назад Cloudflare заменила HTML-парсер на основе Ragel собственной разработкой, cf-html. Баг, о котором идет речь, присутствовал и в компиляторе Ragel, однако не проявлялся из-за специфики использования буферов NGINX. Новый парсер изменил буферизацию и повлек слив данных. Использующие его функции Automatic HTTP Rewrites (включена 22 сентября), Server-Side Excludes (работает с 30 января) и Email Obfuscation (с 13 февраля) были отключены в масштабах всей CDN-сети или пропатчены после получения отчета о баге.

«Когда мы узнали, что баг проявляется при активации cf-html (причины на тот момент были неизвестны), мы отключили все три функции, которые его используют, — пишет Грэм-Камминг. — Каждая функция, предоставляемая Cloudflare, имеет особый флаг, который мы называем global kill («глобальная отмена»). Мы активировали global kill функции Email Obfuscation через 47 минут после того, как узнали подробности проблемы, global kill для Automatic HTTPS Rewrites был активирован на 3 часа 5 минут позднее. Изменения в функции Email Obfuscation появились 13 февраля и явились основной причиной слива памяти, поэтому ее отключение быстро прекратило почти все утечки».

«За пару секунд эти функции были отключены по всему миру, — продолжает эксперт. — Мы удостоверились в полном прекращении утечек с помощью контрольных URI и попросили Google также убедиться, что утечек больше нет». Единственная проблема, которая осталась, — это слитые данные, осевшие в кэше поисковых систем. В настоящее время Cloudflare работает вместе с Google и другими провайдерами над удалением этой информации из кэшей.

«Мы помогаем вычищать кэшированные страницы, самопроизвольно индексированные Google, — подтвердил Орманди. — Это, конечно, полумера, однако мы делаем все, что в наших силах. Клиентам Cloudflare придется решать, хотят ли они делиться секретом и уведомлять пользователей о фактах, которые нам известны. Мне неведомо, была ли эта проблема замечена и использована со злым умыслом, однако я уверен, что другие поисковые роботы собрали данные, а пользователи сохранили или кэшировали контент, даже не зная, что оказалось в их распоряжении. Мы обнаружили (и вычистили) кэшированные страницы, содержащие закрытые сообщения с хорошо известных сервисов, личностную информацию с крупных сайтов, использующих Cloudflare, и даже незашифрованные запросы к API от популярного менеджера паролей, отправленные по HTTPS».

Категории: Аналитика, Уязвимости