SQLi-уязвимость WP Fastest Cache поставила под удар 600 тысяч сайтов

SQLi-уязвимость WP Fastest Cache поставила под удар 600 тысяч сайтов

SQLi-уязвимость WP Fastest Cache поставила под удар 600 тысяч сайтов

В плагине WP Fastest Cache была выявлена уязвимость, позволяющая через SQL-инъекцию получить несанкционированный доступ на чтение к базе данных сайта. Патч вышел три дня назад в составе обновления 1.2.2.

В настоящее время этот WordPress-плагин активен на более чем 1 млн сайтов. Из них свыше 600 тыс., согласно статистике WordPress.org, пока используют уязвимые версии расширения.

Уязвимость, зарегистрированную под идентификатором CVE-2023-6063, обнаружила команда WPScan из компании Automattic. Проблема SQLi, по словам исследователей, возникла из-за некорректной реализации функции is_user_admin класса WpFastestCacheCreateCache.

Эта функция проверяет, является ли пользователь админом, извлекая значение $username из куки-файла. Как оказалось, переменная затем вносится в запрос без санации, что открывает возможность для SQL-инъекции.

Эксплойт не требует аутентификации и позволяет просмотреть содержимое базы данных WordPress, в которой обычно хранятся данные пользователей (IP-адреса, имейл, идентификаторы), пароли, настройки плагинов и тем, а также другая информация, необходимая для функционирования сайта.

Авторы находки оценили степень ее опасности в 8,6 балла CVSS и пообещали выложить PoC-код 27 ноября. Уязвимости подвержены все прежние выпуски WP Fastest Cache, пользователям рекомендуется как можно скорее обновить плагин до сборки 1.2.2.

Почему не стоит входить с помощью Google в важные аккаунты

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

Если пользователь потеряет доступ к Google из-за взлома, блокировки, фишинга или другой проблемы, под ударом окажутся не только Gmail и Диск, но и все сторонние сервисы, куда он входил через Google.

Это может быть что угодно: рабочие инструменты, доставка еды, такси, умный дом, сервисы ИИ, приложения для путешествий или финансов.

Есть и вопрос безопасности. Современные фишинговые атаки умеют подделывать страницу входа Google и перехватывать не только пароль, но и сессионные токены.

В таком случае злоумышленник может получить доступ к аккаунту даже при включённой двухфакторной аутентификации. Чем чаще пользователь входит в разные сервисы через всплывающие окна Google, тем выше риск попасть на такую подделку.

Ещё один минус — недостаток конфиденциальности. Когда разные сервисы привязаны к одному Google-аккаунту, компания получает более цельную картину цифровой активности пользователя: какие приложения он использует, как часто и в каких сценариях. Даже если данные обрабатываются в агрегированном виде, это всё равно расширяет цифровой след.

Более безопасная альтернатива — создавать отдельные учётные записи для важных сервисов и хранить пароли в менеджере паролей. Это менее удобно на старте, зато снижает риск единой точки отказа. Если один аккаунт будет скомпрометирован или заблокирован, остальные не посыплются вслед за ним.

Для незначительных сайтов вход через Google может оставаться быстрым вариантом. Но для банков, рабочих сервисов, почты, облаков, ИИ-инструментов, умного дома и других важных аккаунтов лучше использовать отдельный логин, сложный пароль и двухфакторную аутентификацию.

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