Архив рубрики: Темы

Фишинговая атака на администраторов сайтов на WordPress

Фишинговая атака на администраторов сайтов на WordPress

Фишинговая атака на администраторов сайтов на WordPress. Гениально и просто. 🙂 Админам сайтов приходит поддельное письмо, якобы от WordPressOrg, с призывом установить плагин для исправления RCE уязвимости CVE-2023-45124. На NVD для этой уязвимости CVE ID Not Found, но, учитывая какой там сейчас бардак, это бы и меня не особо смутило. 😅

В письме ссылка на фишинговый сайт с описанием вредоносного плагина, отзывами, оценками, всё как на официальном сайте с плагинами. Плагин скачивается как zip-архив. После установки и активации плагина создаётся админская учётка wpsecuritypatch, пароль от неё передается на сервер злоумышленников, устанавливается P.A.S. бэкдор, плагин и учётка скрываются в админке. 😈

Разумеется, похожую атаку могут проворачивать и для какой-нибудь другой CMS-ки, того же Битрикса. Будьте внимательнее.

Собираюсь выступить на Код ИБ 2023 | ИТОГИ в этот четверг с мини-докладом про трендовые уязвимости

Собираюсь выступить на Код ИБ 2023 | ИТОГИ в этот четверг с мини-докладом про трендовые уязвимости

Собираюсь выступить на Код ИБ 2023 | ИТОГИ в этот четверг с мини-докладом про трендовые уязвимости. Зачем нужно выделять трендовые уязвимости и почему делать это по открытым данным весьма непросто. Плюс пара слайдов про то, какие трендовые уязвимости выделил в 2023 году один отечественный 🟥 VM вендор (конспиративная формулировка, т.к. иду как "независимый эксперт" 😉🤷‍♂️) .

Выступление будет в секции "Анализ защищенности и расследование инцидентов", начало в 12:00. Внезапно попал в одну секцию с Андреем Масаловичем (КиберДед)! 🙂 После коротких выступлений там ожидается "Дискуссия с экспертами", должно быть занимательно.

Прожектор по ИБ, выпуск №14 (02.12.2023): 5000 р компенсации за утечку ПД и легализация белых шляп

Прожектор по ИБ, выпуск №14 (02.12.2023): 5000 р компенсации за утечку ПД и легализация белых шляп

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

00:00 Смотрим статистику по прошлому эпизоду
03:26 Максим сходил на Технологии SOC
05:45 Финансирование государственных ИБ систем
08:52 Интересная уязвимость раскрытия данных в ownCloud (CVE-2023-49103)
11:59 Уязвимость Chrome в распространенной библиотеке Skia (CVE-2023-6345).
15:25 «Яндекс.Еда» заплатит по 5 тысяч рублей двум пострадавшим от утечки данных
19:00 Персональный заход: аферисты обновили схему для доступа к аккаунтам на «Госуслугах»
20:44 Легализации «белых» хакеров
23:22 Прощание от Mr.X

Поучаствовал в вебинаре с Давидом Ордяном, CEO Metascan, про безопасность периметра

Поучаствовал в вебинаре с Давидом Ордяном, CEO Metascan, про безопасность периметра

Поучаствовал в вебинаре с Давидом Ордяном, CEO Metascan, про безопасность периметра. Вебинар проходил в рамках курса Inseca по VM, который я сейчас активно прохожу (3 недели уже прошло, осталось ещё 3). 🙂 Выписал тезисы по вебинару.

Цель в том, чтобы прийти к идеальному состоянию периметра:

🔹 Периодичность проверки каждого хоста на внешнем периметре составляет 24 часов.
🔹 На периметре отсутствуют уязвимости критичностью выше X.
🔹 Назначение каждого порта на внешнем периметре известно ИБ, понятно с какими активами во внутрянке он связан и кто за них отвечает.

Чтобы этого достичь нужны ресурсы, а значит нужно начать с продажи идеи ИБ руководству компании. Как это сделать?

🔻 Нужны союзники со стороны сетевиков и админов. Хорошо помогает сбор рабочей группы с ними.
🔻 Контроль периметра со стороны ИБ должен быть регулярным процессом организации с планерками, реагированием на аномалии и т.д.
🔻 Нужно научиться говорить на бизнес-языке. Идеально продемонстрировать возможность совершения недопустимого события. Но даже XSS-ки с потенциальным имиджевым риском может быть достаточно.

На что обратить внимание:

🔸 ИБ должно участвовать в управлении DNS и публикации сервисов.
🔸 Должен быть реестр сетевых портов. Отдельно выделяем сервисы, которых не должно быть на периметре в принципе (telnet, ssh, rpc, sql и т.д.), и сервисы, которые не были нормально продетектированы - нужно дорабатывать детекты.
🔸 Брутилки, как правило, заточены под конкретные протоколы - разбирайтесь с утилитами (или берите коммерческие сервисы-комбайны). В Метаскане, например, 28 инструментов.
🔸 Вендор настолько хорош, насколько хорош его RnD. Пусть покажет, что умеет писать детект. Готовые движки не пойдут: "в Nessus никогда не будет Битрикса". И что вы будете с этим делать?
🔸 Ошибочная выкладка файлов на периметре (папка с логами, дампами, скрипт с захардкоженными паролями и т.п.), чем вы это будете ловить? Это не CVE.
🔸 Случайно опубликованную админку сканер не найдет, нужны специальные инструменты.
🔸 Сканеры web-приложений должны поддерживать web2.0. В современных приложениях client-side rendering. Должен использоваться виртуальный браузер.

Преимущества сканов с аутентификацией из блог-поста Tenable

Преимущества сканов с аутентификацией из блог-поста Tenable

Преимущества сканов с аутентификацией из блог-поста Tenable. Подборка неплохая и касается любых VM-решений.

1. Гораздо более подробное профилирование активов. "Вы купите дом, который видели только снаружи? Конечно нет! Вам нужно будет увидеть интерьер и проверить все комнаты. Сканирование без аутентификации обеспечивает только вид «снаружи дома»."

2. Возможность проводить анализ безопасности конфигураций в соответствии с лучшими практиками и требованиями регуляторов.

3. Более достоверная информация об уязвимостях. Уязвимости браузеров, мессенджеров, программных библиотек и компонентов вы не найдете без аутентификации.

4. Вендоры ПО стали выставлять меньше информации наружу - сложнее делать баннерные детекты. RCE Barracuda ESG (CVE-2023-2868) затрагивала только физические устройства. А понять физическое это устройство или виртуальное можно было только после аутентификации. 🤷‍♂️

5. PCI DSS v.4 будет требовать проводить сканирования с аутентификацией.

Забавная интерпретация статистики от Tenable

Забавная интерпретация статистики от Tenable

Забавная интерпретация статистики от Tenable. У них вышел блог-пост "Увеличьте эффективность сканирования на наличие уязвимостей с помощью сканов с аутентификацией". По теме вопросов нет - сканирование с аутентификацией это важно и нужно. Но КАК они к этому подводят. 🙂

В первом абзаце пишут "значительное количество пользователей Tenable Nessus склонны к сканированию без аутентификации".

Ого! И как об этом узнали? 🧐

"Конфигурации сканирования, которые мы наблюдаем в SaaS-продуктах Tenable, говорят сами за себя: наши клиенты запускают неаутентифицированные сканирования в 20 раз чаще, чем аутентифицированные. Почему такой существенный разрыв?"

И дальше пишут о том, что дело в недостаточной осведомленности клиентов. 🤤

А может настоящие причины разрыва в том, что SaaS продукт Tenable (TenableVM / ex-TenableIO) в основном используют как периметровый сервис, а для сканов внутрянки с аутентификацией берут что-то более подходящее, тот же заброшенный on-prem Tenable SC? 😏

Снова эксплуатируемая вживую уязвимость Chrome и снова в распространенной библиотеке (Skia, CVE-2023-6345)

Снова эксплуатируемая вживую уязвимость Chrome и снова в распространенной библиотеке (Skia, CVE-2023-6345)

Снова эксплуатируемая вживую уязвимость Chrome и снова в распространенной библиотеке (Skia, CVE-2023-6345). Skia — это библиотека 2D-графики с открытым исходным кодом, которая предоставляет общие API-интерфейсы, работающие на различных аппаратных и программных платформах. Согласно документации, служит графическим движком для Google Chrome и ChromeOS, Android, Flutter, Mozilla Firefox и Firefox OS (лол, давно видимо доку не правили 😏), а также многих других продуктов.

"Целочисленное переполнение в Skia в Google Chrome до версии 119.0.6045.199 позволяло удаленному злоумышленнику, скомпрометировавшему процесс рендеринга, потенциально выполнить выход из песочницы с помощью вредоносного файла".

Похоже затронет множество продуктов, полный перечень которых мы толком и не узнаем. 🤷‍♂️ Можно поставить в один ряд с уязвимостями libwep и libvpx.