Темная сторона новой reCaptcha V3 от Google — риски конфиденциальности

Темная сторона новой reCaptcha V3 от Google — риски конфиденциальности

Темная сторона новой reCaptcha V3 от Google — риски конфиденциальности

Студент Торонтского университета Мухаммед Акрут изучил новую версию reCaptcha V3 от Google и пришел к выводу, что принцип ее работы угрожает конфиденциальности пользователей.

Если вы столкнетесь с reCaptcha сейчас, вы увидите блок с чекбоксом «Я не робот». Помимо этого, вам, возможно, придется найти на картинках все витрины, мосты или светофоры.

В случае с новой версией reCaptcha V3 все будет работать немного иначе — вы вообще не увидите процесс ее выполнения на страницах веб-сайтов. А все дело в том, что одним из способов идентификации пользователя будет специальный файл cookie.

Чтобы отделить ботов от людей, reCaptcha V3 будет искать cookie — тот самый cookie, который используется для поддержания вашей сессии Google-аккаунта активной. Акрут также обращает внимание на тот факт, что владельцам сайтов придется встроить скрипт новой капчи в каждую страницу сайта.

При таком подходе у Google открывается прекрасная возможность для отслеживания веб-ресурсов, которые посещает конкретный пользователь. Учитывая, что вся активность еще напрямую связана и с аккаунтом Google, интернет-гигант может привязать к учетной записи историю посещений ресурсов.

«Учитывайте, что reCaptcha v3 будет присутствовать на каждой странице посещаемого ресурса, прибавьте к этому использование cookies от конкретного аккаунта Google. У американской корпорации будет возможность отследить каждую посещаемую страницу. Вы даже не будете об этом знать, ведь визуальных индикаторов работы reCaptcha v3 не будет», — приводит слова исследователя Fast Company.

Опасная уязвимость в GNU Wget2 позволяет удалённо перезаписывать файлы

В популярном консольном загрузчике GNU Wget2 обнаружили серьёзную уязвимость, которая позволяет злоумышленникам перезаписывать файлы на компьютере жертвы — без её ведома и согласия. Проблема получила идентификатор CVE-2025-69194 и высокую степень риска — 8,8 балла по CVSS, то есть игнорировать её точно не стоит.

Брешь связана с обработкой Metalink-файлов — это специальные документы, в которых описано сразу несколько источников для скачивания одного и того же файла (зеркала, P2P и так далее).

По идее, Wget2 должен строго контролировать, куда именно сохраняются загружаемые данные. Но, как выяснили исследователи из Apache, на практике с этим есть проблемы.

Из-за ошибки в проверке путей злоумышленник может подготовить вредоносный Metalink-файл с «хитрыми» именами вроде ../. Это классическая уязвимость path traversal: она позволяет выйти за пределы рабочего каталога и записать файл практически в любое место в системе. Достаточно, чтобы пользователь просто обработал такой металинк — и дальше всё происходит без его участия.

Последствия могут быть весьма неприятными. В худшем случае атакующий сможет:

  • перезаписать важные системные или пользовательские файлы и вызвать потерю данных;
  • подменить конфигурации или скрипты и добиться выполнения вредоносного кода;
  • изменить настройки безопасности или файлы аутентификации, создав себе бэкдор.

Да, атака требует взаимодействия с вредоносным файлом, но с учётом последствий риск выглядит более чем реальным — особенно для тех, кто регулярно использует Wget2 в автоматизированных сценариях или CI/CD-пайплайнах.

Если вы работаете с Wget2 и Metalink, сейчас самое время внимательно отнестись к источникам загрузки и следить за выходом обновлений. В этой истории один неосторожный файл может стоить слишком дорого.

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