Cloudbleed (CVE)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 09:05, 20 июня 2019.
Cloudbleed
Cloudbleed.png
CVE identifier(s) CVE-2014-0160 [1]
Date discovered 18 February 2017 года; 2 years ago (2017-02-18)
Date patched 20 February 2017 года; 2 years ago (2017-02-20)
Discoverer Tavis Ormandy
Website www.cloudflare.com [2]

Cloudbleed – название утечки персональных данных (в том числе cookie-файлов, личных сообщений, ключей API и паролей) в всемирно известной компании CloudFlare, предоставляющей различные сервисы по обслуживанию и обеспечению безопасности сайтов. [Источник 1] Cloudflare – это сеть доставки контента выступает в качестве обратного прокси для миллионов веб-сайтов, в том числе крупных интернет-сервисов и компаний Fortune 500, для которых он предоставляет услуги безопасности и оптимизации контента «за кулисами». В рамках этого процесса системы компании изменяют HTML-страницы по мере прохождения через серверы, чтобы переписать HTTP-ссылки на HTTPS, скрыть определенный контент от ботов, запутать адреса электронной почты, включить ускоренные мобильные страницы (AMP) и многое другое. Из-за бага эта CDN-сеть месяцами сливала данные клиентов, от приватных сообщений до ключей шифрования и идентификаторов, принадлежащих пользователям известных онлайн-сервисов. По свидетельству технического директора Cloudflare Джона Грэм-Камминга (John Graham-Cumming), эта уязвимость была устранена, но до этого конфиденциальные данные пользователей таких сайтов, как Uber, Fitbit, OKCupid и т.п., какое-то время находились в открытом доступе.


Обнаружение

Проблема была обнаружена 18 февраля 2017 года сотрудником Google Project Zero Тэвисом Орманди (Tavis Ormandy), но появиться она могла ещё 22 сентября 2016 года. CloudFlare сообщила, что объём утёкших данных начал расти с 13 февраля, когда изменение в коде привело к тому, что каждый 3 300 300-ый HTTP-запрос становился общедоступным — а это серьёзно для сети такого масштаба [Источник 2]. Орманди сообщил, что он нашёл записи о бронировании отелей, пароли из менеджеров паролей, сообщения с сайтов знакомств. “Я даже не догадывался, насколько большая часть Интернета находится в Cloudflare CDN, — написал он 19 февраля. — Мы говорим о полных HTTP-запросах, IP-адресах клиентов, cookie-файлах, паролях, ключах, данных, обо всём.” После того, как представители CloudFlare увидели сообщение Орманди, они отключили три функции, использовавшие уязвимый код, и связались с поисковыми системами для удаления закешированной информации. В своем отчете Тэвисом Орманди пишет, что обнаружил слитые данные случайно, работая над другим проектом. Это были блоки неинициализированной памяти, приобщенные к запрошенным данным и исходящие, как удалось определить, с обратных прокси-серверов Cloudflare. «Похоже, в тех случаях, когда HTML-страница, защищаемая Cloudflare, содержала специфическую комбинацию несбалансированных тэгов, прокси присоединял к ответу страницы неинициализированной памяти (это работало как Heartbleed, только со спецификой Cloudflare и было гораздо хуже по причинам, которые я поясню позднее), — пишет Орманди. — В качестве рабочей версии я связал проблему с функцией ScrapeShield, которая производит разбор и обфусцирует HTML, однако из-за того, что обратные прокси разделены между клиентами, она должна была затронуть всех клиентов Cloudflare».

Причины и описание утечки

Ошибка, которая выставляла пользовательские данные, была в старом парсере HTML, который компания использовала в течение многих лет. Однако он не был активирован, пока в прошлом году не был добавлен новый парсер HTML, изменив способ использования внутренних буферов веб-сервера, когда некоторые функции были активны [Источник 3]. В результате внутренняя память, содержащая потенциально конфиденциальную информацию, просачивалась в некоторые ответы, возвращаемые пользователям, а также искателям поисковой системы. Веб-страницы с конфиденциальными данными были кэшированы и доступны для поиска поисковыми системами, такими как Google, Yahoo и Bing. Утечка была обнаружена 18 февраля. Cloudflare немедленно собрал команду реагирования на инциденты и убил функцию, которая вызывала большую часть утечки в течение нескольких часов. Полное решение было принято к 20 февраля. Остальное время, пока инцидент не был публично раскрыт в четверг, было потрачено на работу с поисковыми системами, чтобы очистить конфиденциальные данные от их тайников. "С помощью Google, Yahoo, Bing и других мы нашли 770 уникальных URI, которые были кэшированы и содержали утечку памяти",-сказал Джон Грэм-Камминг, технический директор Cloudflare в блоге. "Эти 770 уникальных URI охватывали 161 уникальный домен."URI (Uniform Resource Identifier) - это символьная строка, которая идентифицирует ресурс в интернете и иногда используется взаимозаменяемо с термином URL (Universal Resource Locator). По словам Грэма-Камминга, утечка могла продолжаться с 22 сентября, но период наибольшего воздействия был между 13 февраля и 18 февраля, когда функция запутывания электронной почты была перенесена на новый парсер. Cloudflare оценивает, что около одного из каждых 3,3 миллиона HTTP-запросов, которые прошли через его систему, потенциально привели к утечке памяти. Это около 0,00003 процента всех запросов. Несмотря на это, из-за характера открытых данных инцидент был очень серьезным, и клиенты Cloudflare могли решить принять меры, например, заставить пользователей изменить свои пароли. "Я нахожу личные сообщения с крупных сайтов знакомств, полные сообщения от известной службы чата, данные онлайн-менеджера паролей, кадры с сайтов для взрослых, бронирование гостиниц", - написал Орманди в записи в Google Project Zero bug tracker во время инцидента. "Мы говорим на весь HTTPS-запросов, клиентского IP-адреса, полные ответы, куки, пароли, ключи, данные, все." Эта ошибка аналогична уязвимости HeartBleed в OpenSSL, которая могла позволить злоумышленникам заставить https-серверы пропускать потенциально чувствительное содержимое памяти. На самом деле, Орманди даже сказал, что "потребовалась каждая унция силы, чтобы не назвать этот вопрос CloudBleed."

Но в отличие от HeartBleed, который имел потенциал для предоставления закрытых ключей SSL/TLS, такие ключи не были затронуты в инциденте Cloudflare. "Cloudflare запускает несколько отдельных процессов на пограничных машинах, и они обеспечивают изоляцию процессов и памяти",-сказал Грэм-Камминг. "Утечка памяти произошла из процесса, основанного на NGINX, который выполняет обработку HTTP. Он имеет отдельную кучу от процессов, выполняющих SSL, повторное сжатие изображений и кэширование, что означало, что мы быстро смогли определить, что закрытые ключи SSL, принадлежащие нашим клиентам, не могли быть слиты." Однако один закрытый ключ, который просочился, был использован для защиты соединений между машинами Cloudflare. Чтобы быть в безопасности, пользователи интернета могут рассмотреть возможность изменения своих онлайн-паролей, что они должны делать на регулярной основе, чтобы опережать нарушения данных. "Cloudflare стоит за многими из крупнейших потребительских веб-сервисов (Uber, Fitbit, OKCupid, ...), поэтому вместо того, чтобы пытаться определить, какие сервисы находятся на Cloudflare, вероятно, наиболее разумно использовать это как возможность повернуть все пароли на всех ваших сайтах", - сказал исследователь безопасности Райан Лакей в блоге.

Воздействие ошибки

внутреннее

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

внешнее

Больше беспокоил тот факт, что куски HTTP-запросов в полете для клиентов Cloudflare присутствовали в сброшенной памяти. Это означает, что информация, которая должна была быть частной, может быть раскрыта. Это включало заголовки HTTP, куски данных POST (возможно, содержащие пароли), JSON для вызовов API, параметры URI, куки и другую конфиденциальную информацию, используемую для аутентификации (например, ключи API и токены OAuth). Поскольку Cloudflare работает с большой общей инфраструктурой, HTTP-запрос к веб-сайту Cloudflare, уязвимому для этой проблемы, может выявить сведения о несвязанном другом сайте Cloudflare. Дополнительная проблема заключалась в том, что Google (и другие поисковые системы) кэшировали часть просочившейся памяти с помощью обычных процессов обхода и кэширования. Мы хотели убедиться, что эта память была вычищена из тайников поисковой системы до публичного раскрытия проблемы, чтобы третьи лица не могли охотиться за конфиденциальной информацией. Наша естественная склонность состояла в том, чтобы как можно быстрее получить Новости об ошибке, но мы чувствовали, что обязаны заботиться о том, чтобы тайники поисковых систем были очищены перед публичным объявлением. Команда infosec работала над тем, чтобы идентифицировать URI в кэшах поисковых систем, в которых произошла утечка памяти, и очистить их. С помощью Google, Yahoo, Bing и других мы нашли 770 уникальных URI, которые были кэшированы и которые содержали утечку памяти. Эти 770 уникальных URI охватывали 161 уникальный домен. Утечка памяти была удалена с помощью поисковых систем. Компания Cloudflare в своем отчете рассказала, что они предприняли другие поисковые экспедиции, которые искали потенциально утечку информации на таких сайтах, как Pastebin, и ничего не нашли.

Источники

  1. Cloudbleed bug: Everything you need to know // cnet.com. URL: https://www.cnet.com/how-to/cloudbleed-bug-everything-you-need-to-know/ (дата обращения: 23.05.2019).
  2. Cloudflare Reverse Proxies are Dumping Uninitialized Memory // buds.chromium.org. URL: https://bugs.chromium.org/p/project-zero/issues/detail?id=1139 (дата обращения: 23.05.2019).
  3. Incident report on memory leak caused by Cloudflare parser bug // blog.cloudfare.com [2009 – 2019]. URL: https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ (дата обращения: 24.05.2019).

Примечания

  1. CVE// cve.mitre. [2009-2019] URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2014-0160 (дата обращения: 23.05.2019).
  2. Cloudflare // cloudflare.com. [2009 - 2019 ]. URL: https://www.cloudflare.com (дата обращения: 23.05.2019).