Разбирать эту атаку проще, разбив ее на этапы. Прежде всего Дилан Эйри зафиксировал тот факт, что создать учетную запись в экосистеме Google можно с любым адресом электронной почты, в любом домене. На такую почту придет письмо с просьбой подтвердить создание аккаунта. Если у вас есть доступ к этому письму, вы получите новую учетку Google. Одновременно вы получаете возможность регистрироваться и авторизоваться на любых других сервисах по протоколу OAuth, выбирая опцию Sign-in with Google. Далее идет самый важный элемент теоретической атаки: учетку Google можно создать на адрес вида login+(какая-то последовательность символов).com. Письма, отправленные на такой адрес-псевдоним, будут приходить на основную почту . Если вы имеете доступ к этому почтовому ящику, вы без труда сможете подтвердить создание новой учетной записи Google.
Таким образом в вашем распоряжении оказывается как бы дополнительная учетная запись в домене вашей организации. Используя ее и опцию Sign-in with Google, можно получить доступ к другим сервисам, которые проверяют вашу принадлежность к определенной компании по домену. Автор исследования подтвердил, что может таким образом получить доступ к переписке в Slack и конференц-звонкам в сервисе Zoom. А теперь представим, что сотрудник, провернувший подобный трюк, был уволен. Его основная учетная запись деактивируется администратором, но дополнительная — фантомная — остается, а вместе с ней сохраняется доступ к сервисам типа Zoom и Slack.
Примечательно, что Дилан Эйри сообщил о проблеме в Google еще в августе. На момент публикации данных об уязвимости она так и не была закрыта, хотя ошибка была подтверждена на стороне Google и исследователь даже получил выплату по программе Bug Bounty. Теоретически исправить ошибку просто: нужно либо запретить создавать учетки Google для доменов, зарегистрированных в Google Workspace, либо в принципе сделать невозможной регистрацию уникальных учетных записей на адреса-псевдонимы. Примечательно, что для собственного домена (google.com) компания Google запретила создание учетных записей в своем же сервисе. Организации могут нейтрализовать угрозу на своей стороне, просто запретив использование опции Sign-in with Google. Это далеко не первый случай эксплуатации «упрощенных» способов логина для доступа к приватным данным. Автор ссылается на 2017 года, в которой описан способ логина в корпоративный Slack с помощью временного адреса электронной почты, генерируемого системой техподдержки Zendesk (и другими сервисами). Эту особенность теоретически также можно применить в комбинации с ошибкой в Google OAuth и в некоторых случаях обеспечить себе доступ к корпоративным данным, даже не являясь сотрудником организации.
Что еще произошло:
11 декабря Apple обновление iOS и iPadOS до версии 17.2, в котором закрыты несколько критических уязвимостей. В частности, решена проблема в компоненте ImageIO, которая могла приводить к выполнению произвольного кода вследствие обработки определенных «подготовленных» изображений. Кроме того, обновление исправляет особенность работы с Bluetooth-устройствами, которая создавала возможность для так называемой . Суть атаки в рассылке с какого-то устройства (например, Flipper Zero с модифицированной прошивкой) широковещательных пакетов данных по протоколу Bluetooth, что приводит к отказу в обслуживании всех устройств Apple в радиусе радиовидимости.
Google прекратить поддержку сторонних (third-party) файлов куки в браузере Google Chrome во второй половине 2024 года. Данный инструмент чаще всего используется для отслеживания перемещений пользователя между сайтами с целью демонстрации «актуальной» рекламы. Вместо этого механизма Google предлагает собственный сервис Privacy Sandbox, в котором сбор информации о предпочтениях пользователей производится на стороне компании, а не рекламодателей.
В свежем по эволюции crimeware эксперты «Лаборатории Касперского» анализируют новый шифровальщик, работающий под Windows и Linux, а также вредоносное ПО для Mac OS.
