Security Week 06: кража данных через синхронизацию Google Chrome

Security Week 06: кража данных через синхронизацию Google Chrome
Хорватский исследователь Боян Здрня (Bojan Zdrnja) обнаружил интересный метод эксфильтрации данных через средства синхронизации, встроенные в браузер Google Chrome. Функция Chrome Sync позволяет синхронизировать сохраненные пароли, закладки и историю посещения веб-сайтов между компьютерами, использующими общую учетную запись Google.

В описании атаки Здрня приводит следующую последовательность действий. Получив доступ к компьютеру жертвы, злоумышленник включает режим разработчика в Google Chrome, что позволяет загрузить расширение для него локально, а не через магазин. Таким образом в браузер подгружается вредоносное расширение, замаскированное под плагин защитного продукта.

2e669d9dd7953d83bcc8b9b228364e35.png

В коде самого расширения исследователь описывает стандартный метод взаимодействия с облачной инфраструктурой Google, который позволяет «обмениваться» произвольными данными между двумя браузерами. То есть предположительно атака выглядела так: взламываем компьютер, устанавливаем вредоносное расширение, авторизуем браузер под одноразовой учетной записью Google. На стороне атакующего достаточно залогиниться под той же учетной записью, чтобы получить данные с компьютера жертвы.

Что именно передавалось таким образом, эксперт не раскрывает, но указывает ограничения метода: максимальный размер «ключей», передаваемых через инфраструктуру Google Chrome, не может превышать 8 Кбайт, а их максимальное количество — 512. То есть за одну сессию можно передать 4 Мбайт данных. Для управления зараженным компьютером, а также для передачи токенов для доступа к корпоративным облачным сервисам этого вполне достаточно.

Здрня особо отмечает, что на пострадавшей системе не было другого вредоносного софта. Просто так перекрыть обращение к облачной инфраструктуре Google на уровне политик корпоративной сети не получится: на них завязано не только облако, но и, например, проверка наличия доступа к сети в браузере. В качестве решения исследователь предлагает применение политик, запрещающих установку в браузер любых расширений, кроме отмеченных в белом списке. Такой оригинальный метод взаимодействия с атакуемой системой можно не замечать долгое время — это откроет злоумышленникам путь к корпоративным данным, которые в нормальных условиях доступны через браузер. В большинстве случаев это может быть и корпоративная почта, и средства совместной работы над документами, и многое другое.

Что еще произошло

История с атакой на экспертов в области информационной безопасности (см. предыдущий дайджест ) получила продолжение. В браузере Google Chrome обнаружили и закрыли zero-day уязвимость в движке V8. Хотя разработчики из Google не дают комментариев на этот счет, есть предположение, что именно ее использовали организаторы атаки. Кроме того, южнокорейские специалисты нашли еще один вектор той же атаки: жертвам рассылали файлы .mhtml с вредоносным кодом, эксплуатирующим ранее неизвестную уязвимость в Internet Explorer 11. Файл якобы содержал информацию об уязвимости в браузере Google Chrome 85.

7fba877360bda7e7c52aae9337c9c99c.jpeg


Компания Netscout со ссылкой на китайских исследователей из Baidu Labs сообщает о новом методе амплификации DDoS-атаки с помощью некорректно сконфигурированного медиасервера Plex.
9f7a82c575fbdfeaadfd01063869eeb4.png
В треде по ссылке выше исследователь под никнеймом OverSoft рассказывает о плохо защищенной IP-видеокамере с функцией подсчета людей. Рассказ начинается с несменяемого идентификатора WiFi-сети и пароля к ней, и дальше становится только печальнее. Внутри камеры обнаружен Raspberry Pi Compute Module с дефолтным пользователем pi, документами, оставшимися от разработчика (включая mp3-файл) и кучей кода на Python. В итоге получается устройство, которое по идее подключается к корпоративной сети с фактически незащищенным WiFi и возможностью получить полный доступ к аккаунту со стандартным паролем и максимумом привилегий.

Команда Google Project Zero публикует обзор zero-day уязвимостей, использовавшихся в реальных атаках в прошлом году. Из 24 дыр восемь используют новый метод эксплуатации уже известной проблемы. Вывод: можно несколько усложнить жизнь злоумышленникам, если закрывать уязвимости после подробного анализа причины так, чтобы решенную проблему нельзя было вскрывать повторно.

Более месяца назад, 4 января, произошел серьезный сбой в мессенджере Slack. По результатам инцидента опубликован подробный отчет. Падение произошло по совокупности причин: в первый после праздников рабочий день в большинстве стран пользователи нагружали инфраструктуру больше, чем нужно, а средство автоматического масштабирования мощностей в Amazon Web Services не сработало так, как требовалось.

Исследование вредоносной программы Kobalos для Linux-систем раскрывает необычную цель атаки: суперкомпьютеры.

Новый пример атаки на цепочку поставок: исследователи из ESET нашли зараженное ПО NoxPlayer (эмуляция Android-приложений), распространявшееся прямо с сайта разработчика.
chrome chromesync
Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.

Ищем темную материю и подписчиков!

Одно найти легче, чем другое. Спойлер: это не темная материя

Станьте частью научной Вселенной — подпишитесь