Уязвимость механизма пересылки Gmail и Outlook грозит спуфингом отправителя

Уязвимость механизма пересылки Gmail и Outlook грозит спуфингом отправителя

Уязвимость механизма пересылки Gmail и Outlook грозит спуфингом отправителя

В нескольких реализациях функции автоматической пересылки писем выявлены уязвимости, позволяющие обойти защиту и подделать домен отправителя. Проблема затрагивает тысячи организаций, доверивших отправку своей почты Microsoft, Apple либо Google.

В ходе исследования сборная команда из университетов Калифорнии (Сан-Диего), Стэнфорда и Твенте (Нидерланды) обнаружила, что почтовые сервисы Gmail, iCloud, Outlook, индийский Zohomail не верифицируют адрес отправителя при переадресации почты. Подобное упущение открывает возможность для спуфинга, ставя под удар, в числе прочих, правительство США и более 12% компаний списка Alexa 100K (Mastercard, GoDaddy, Associated Press, Washington Post, Docusign и проч.).

Для проведения атаки злоумышленнику лишь потребуется создать учетную запись для пересылки писем и добавить поддельные адреса в белый список. Отправлять поддельные сообщения можно со специально открытого аккаунта или собственного сервера.

По оценкам исследователей, найденные ими уязвимости затрагивают примерно 1,9 млрд пользователей в разных странах, а также 32% доменов .gov. Результаты исследования были представлены на конференции IEEE по безопасности и приватности, проведенной в минувшем июле в Делфте, Нидерланды.

Провайдерам были отправлены уведомления о находках; Zoho и Google проблему решили с помощью патчей, Microsoft подтвердила наличие уязвимостей, в iCloud тоже пока не нашли адекватного решения. Пользователям рекомендуется отключить автопересылку, а поставщикам почтовых услуг — перестать слепо доверять сообщениям, получаемым от коллег по цеху.

Подпишитесь на новости

Claude Code удалил 116 ГБ и сообщил, что файлы выглядят нормально

Пользователь Windows сообщил, что Claude Code при уборке временных файлов удалил около 116 ГБ данных из его домашней директории. Затем агент заверил, что остановил команду и все выглядит целым. По описанию инцидента, удаление продолжалось еще примерно 50 минут.

В отчете на GitHub пользователь рассказывает, что работал над анализом для соревнования Kaggle.

Основная сессия запустила субагента, который решил очистить собственные временные файлы, но сформировал лишнюю команду рекурсивного удаления.

Целью стала домашняя директория, указанная коротким именем Windows формата 8.3. Автор предполагает, что защитная проверка могла не распознать такой вариант пути. Точный механизм отказа защиты и режим разрешений остаются неизвестными.

Через 120 секунд задача автоматически перешла в фон. Агент запросил остановку и получил сообщение об успехе, однако, судя по описанным изменениям файловой системы, удаление продолжалось. Вероятное объяснение — дочерний процесс пережил остановку задачи.

Проверка тоже оказалась поверхностной: агент посмотрел на названия папок верхнего уровня, которые могли сохраняться, пока их содержимое исчезало.

Пользователь сообщил о потере проектов за несколько месяцев, инструментов разработки, SSH-ключей и учетных данных. В корзине удаленные файлы не оказались. Обращение помечено как ошибка высокого приоритета с потерей данных.

Особенно неприятна в этой истории уверенность агента. Наличие папки еще не означает наличие файлов.

RSS: Новости на портале Anti-Malware.ru