Представители компании-разработчика сервисов распределённого хранения контента Cloudflare рассказали об обнаруженной уязвимости, которая могла стать причиной утечки личных данных пользователей сайтов её клиентов.
Скомпрометированные данные могут включать пароли, куки-файлы, аутентификационные токены в незашифрованном виде. Об этом представители компании сообщили в своём блоге.
Как отмечает Techcrunch, системой от Cloudflare пользуются более пяти миллионов сайтов. Злоумышленник, заметивший брешь, мог собирать личные данные посетителей сайтов, которые обычно должны храниться в зашифрованном виде. Кроме того, часть информации успела попасть в кэш поисковых систем, поэтому представители Cloudflare обратились к Google, Bing, Yahoo и другим компаниям, чтобы вручную устранить последствия вероятной утечки,
Баг содержался в старом коде компании, но проблема утечки памяти проявилась 22 сентября 2016 года, когда CloudFlare внедрила новый HTML-парсер, после чего системы компании стали интегрировать случайные фрагменты оперативной памяти своего сервера в содержимое веб-страниц, которые отправляются клиентам.
Спустя пять месяцев специалист по безопасности Google Project Zero обнаружил баг и сообщил представителям Cloudflare. Наиболее серьёзная утечка могла произойти между 13 февраля и 18 февраля, когда примерно один из каждых 3,3 млн HTTP-запросов к сайтам-клиентам Cloudflare подвергал данные вскрытию.
Злоумышленники могли иметь доступ к данным в реальном времени или через кэш поисковых систем. В своём заявлении представители Cloudflare отметили, что даже на пике информация утекала только из 0,00003% всех запросов. В комментариях на Hacker News технический директор компании Джон Грэхем-Камминг отметил, что команда обнаружила утечку данных как минимум с 3438 уникальных доменов клиентов компании. Один из пользователей Github опубликовал список доменов, которые могли попасть под уязвимость, утверждая, что их общее число превышает 4 миллиона — включая 2ip.ru, 4pda.ru, avito.ru, rghost.ru, forbes.ru и rosbalt.ru.
Это не выглядит масштабной утечкой, отмечает Techcrunch, однако среди клиентов Cloudflare есть дейтинговые сайты и менеджеры паролей, которые хранят по-настоящему чувствительную информацию.
Баг появился в HTML-парсере, который Cloudflare использовал, чтобы ускорить быстродействие сайта — он подготавливает сайт для работы с платформой AMP от Google и превращает HTTP-ссылки в HTTPS.
Системы самой Cloudflare также подверглись ошибке — «один из утёкших фрагментов информации был приватным ключом, который используется для связи между машинами Cloudflare», — написал Грэхем-Камминг. Ключ позволял компьютерам компании безопасно общаться друг с другом и был внедрён в 2013 году на фоне опасений о государственной слежке.
Грэхем-Камминг подчёркивает, что Cloudflare не обнаружила подтверждений тому, что хакеры успели обнаружить или использовать баг, отметив, что сотрудники заметили бы подозрительную активность в своей сети.
Команды Cloudflare в Сан-Франциско и Лондоне смогли избавиться от самой серьёзной проблемы за семь часов. Полное восстановление и избавление от бага заняло шесть дней, включая работу с поисковыми системами, которая позволила извлечь часть утекшей информации.
Сотрудник Google Тавис Орманди, первым заметивший баг, рассказал, что наткнулся на неожиданную информацию в ходе работы над своим проектом и сперва подумал, что обнаружил баг в собственном коде. После ряда тестов он понял, что утечка происходит из систем Cloudflare — Орманди наблюдал чужие ключи шифрования, куки, пароли и HTTPS-запросы, личные сообщения с крупных сайтов знакомств, кадры из веб-чатов, данные бронирования гостиниц и кредитных карт.
Позже специалист удалил полученные образцы, но опубликовал отредактированные скриншоты с частью информации, которая просочилась с сайтов 1Password, Uber, Fitbit и OkCupid. Он также отметил, что, несмотря на заявления Cloudflare, сотрудники компании недооценивают опасность для клиентов, поскольку утёкшая информация могла осесть не только в кэше поисковых систем, но и в других местах.
Сейчас для защиты Android-устройств Google использует функциональность Play Protect, которая сканирует девайс на наличие установленных подозрительных приложений. Тем не менее некоторому шпионскому софту удаётся обойти этот защитный механизм, поэтому в Android скоро может появиться возможность карантина подозрительных приложений.
На нововведение указал один из авторов издания Android Authority. Пока, судя по всему, оно находится в стадии бета-тестирования, поскольку впервые было замечено в сборке Android 14 QPR2 Beta 1.
Скорее всего, Google готовится выпустить фичу с выходом Android 15 или более поздних версий мобильной операционной системы. А пока разработчики обкатывают её на бета-версии Android 14.
Отмечается, что пока Google скрыла страницу «Quarantined Apps», предназначенную для разработчиков, однако пункт в настойках, отвечающий за карантин приложений, присутствует.
Эта функция будет работать по логике, схожей с работой инструмента Google Digital Wellbeing, который переводит софт в подвешенное состояние, чтобы избежать различных сбоев.
Попавшее в карантин приложение будет всё равно отображаться на домашнем экране, в лончере и настройках. При этом отдельные возможности таких программ будут ограничены: окна скрыты, уведомления заблокированы, активность и процессы заморожены.
У других программ не будет возможности отправлять запросы помещённому в карантин софту. К слову, для этого используются те же API, которые выполняют задачу приостановки приложений.
Для отправки программы в карантин нужны будут разрешения «QUARANTINE_APPS».
Свидетельство о регистрации СМИ ЭЛ № ФС 77 - 68398, выдано федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор) 27.01.2017 Разрешается частичное использование материалов на других сайтах при наличии ссылки на источник. Использование материалов сайта с полной копией оригинала допускается только с письменного разрешения администрации.
