Архивы автора: Alexander Leonov

Об авторе Alexander Leonov

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно прочитать здесь. Приглашаю подписаться на мой канал в Telegram @avleonovrus. Я обновляю его чаще, чем этот сайт. Вы можете обсудить мои посты или задать вопросы в @avleonovchat или в группе ВКонтакте. And I invite all English-speaking people to another telegram channel @avleonovcom.

ТОП 5 CVE, которые чаще других эксплуатировались пентестерами Positive Technologies в 2023 году

Добавить комментарий

ТОП 5 CVE, которые чаще других эксплуатировались пентестерами Positive Technologies в 2023 году. Отчёт вышел 2 июля.

Список уязвимостей:

🔻 Remote Code Execution - Microsoft Exchange "ProxyNotShell" (CVE-2022-41040, CVE-2022-41080, CVE-2022-41082)
🔻 Remote Code Execution - Bitrix Site Manager "PollsVotes" (CVE-2022-27228)
🔻 Elevation of Privilege - Polkit "PwnKit" (CVE-2021-4034)

Дальше в рифмованном виде. 😉 Трек сгенерировал в Suno.

---

По пентестам за прошедший год отчёт
Вышел у Позитивов.
Каждый кто его прочтёт,
Увидит, что там всё красиво.
28 проектов, есть что показать.
Статистика и результаты.
Умеют защищать и умеют ломать -
Молодцы ребята!
(Молодцы ребята!)

К отчёту они подошли всерьёз.
Ознакомьтесь без спешки!
Но у меня всегда один вопрос:
Где там CVE-шки?
(Где там CVE-шки?)

По отчёту уязвимости не сложно сосчитать.
Их совсем немного. Их конкретно пять.

Топ пять критичных уязвимостей.
Эксплуатируют их чаще всего в ходе пентестов.
Ужас пробирает до костей,
Когда видишь их в инфре: им не должно быть места!
Давно известны они все,
И что опасны они никто не возразит:
PollsVotes в Битриксе,
ProxyNotShell в Эксчендже,
А на Linux-ах PwnKit.

Самый популярный почтовый сервак
MS Exchange - лакомая цель любых атак.
3 уязвимости ProxyNotShell - по сути одна
Remote Code Execution. Опасность наглядно видна.

Bitrix Site Manager - популярная в России CMS.
И к тому же отечественная. Импортозамeс!
RCE в модуле "Опросы, голосования" -
Причина массовых дефейсов и для атак на инфру основание.

Ну а если злоумышленник
На Linux хост проник
И там спокойно сидит,
Нет надёжнее стратегии,
Чем поднять до root-a привилегии
Через уязвимость Polkit, PwnKit.

Это были результаты за 2023 год.
Что за тренды нам текущий год принесёт?
Кто подаст надёжный патчиться сигнал?
Подпишись на @avleonovrus "Управление Уязвимостями и прочее", Telegram канал.

MP3 файл

Потрясающее видео из "Вкусно – и точка"

Добавить комментарий

Потрясающее видео из "Вкусно – и точка". Среди бела дня какой-то левый мужик вскрывает терминал самообслуживания и устанавливает туда аппаратную закладку "малинку". При этом работники ресторана несколько раз проходят мимо и никак не реагируют.

Напомнило советскую комедию "Старики разбойники", в которой герои Никулина и Евстигнеева выносят из музея картину Рембрандта. Но в фильме похитители были одеты в рабочие халаты. Здесь же мужик в обычной одежде. 🤪

А если бы на нём был комбинезон с большими буквами "СЕРВИСНАЯ СЛУЖБА" и папка-планшет с какими-нибудь бумажками в руках? Он бы не то, что в терминал залез, он бы по всем техническим помещениям ходил беспрепятственно. 😏

Отличная демонстрация необходимости в организациях Human Vulnerability Management-а. Чтобы не боялись лишний раз задать вопрос "ты вообще кто такой?", не придерживали и не открывали двери перед незнакомцем с коробкой, знали что делать в подозрительной ситуации и т.д.

Защита на 100%?

Добавить комментарий

Защита на 100%? В канале Дениса Батранкова, если кто не знает, он известный эксперт по сетевой безопасности, вышел пост о невозможности стопроцентной защиты. Обосновывает он это как раз со стороны Управления Уязвимостями:

🔹 поток новых уязвимости слишком велик, их необходимо постоянно выявлять и исправлять, что делать трудоёмко

🔹 0day уязвимости начинают эксплуатироваться до появления патчей и от них VM в принципе не спасает

Полностью согласен. Я бы ещё со ссылкой на БОСПУУ, обратил внимание на то, что

🔸 прежде чем заниматься защитой активов необходимо знать, какие активы у нас вообще есть и понимать насколько они критичны

🔸 средства детектирования уязвимостей имеют свои функциональные ограничения, которые необходимо иметь в виду

В целом, речь, конечно, не идёт ни о каком достижении 100% защиты, а об избежании стопроцентного решета, которое возникает, если Vulnerability Management-ом (и информационной безопасностью вообще) не заниматься. 🤷‍♂️

Выпустил новую версию Vulristics 1.0.6

Добавить комментарий

Выпустил новую версию Vulristics 1.0.6.

🔹 Упростил работу с данными об эксплоитах. Теперь все Data Sources приносят эти данные в едином формате и они обрабатываются единообразно. В том числе признаки наличия эксплоита в Microsoft CVSS Temporal Vector (отношу их к приватным эксплоитам). Сначала смотрю наличие публичных эксплоитов, если их нет, то приватных эксплоитов.

🔹 Поправил багу из-за которой не получалось принудительно выставлять тип уязвимости из Custom Data Source.

🔹 При упрощённом детектировании наименования продуктов для генерённых описаний уязвимостей Microsoft описание продуктов теперь подтягивается и по alternative_names.

🔹 Исправил багу с падением Vulristics при генерации отчёта Microsoft Patch Tuesday во время поиска обзора MSPT от Qualys. Теперь падать не будет, просто отчёт Qualys не будет учитываться. Чтобы учитывался, нужно прописать ссылку в файле comments_links. Пример описания добавил в help и README.

Changelog
Непожатая картинка

А можно мне, пожалуйста, не заниматься оценкой адекватности средств детектирования уязвимостей?

1 комментарий

А можно мне, пожалуйста, не заниматься оценкой адекватности средств детектирования уязвимостей? Не проверять достаточность детектов, а тем более их фактическую реализацию.

Да можно. 🙄 Я вообще мало знаю людей, кто этим заморачивается. К сожалению, большинство относится формально. Принимают всё на веру, VM-вендоров лишний раз не стимулируют. 🤷‍♂️

К чему это приводит? Маркетинг VM-вендоров решает, что детекты это коммодити, качество их никому не интересно и продажи не улучшает. Разработчики в VM-вендорах расслабляются. Главное же, чтобы на полностью обновлённой системе всё зелёненькое было, а на необновлённой красненькое. Остальное не так и важно, правда? 😏 VM-продукты деградируют.

Весь пафос VM-специалистов сыпется от того, что источник продетектированных уязвимостей неадекватный. И так оно тянется вплоть до реальных инцидентов, в которых VM-щики становятся крайними. 🤷‍♂️

В итоге имеем порочный круг лени и наплевательства, который гробит всю идею VM-а. 😔

EASM и CAASM - это просто сценарии применения сканера безопасности?

Добавить комментарий

EASM и CAASM - это просто сценарии применения сканера безопасности? Рубрика "занудно реагируем на мемасики". 🙂 У меня был пост по классам решений, включая EASM и CAASM.

EASM - это действительно сервис на основе сканера уязвимостей, который работает в режиме Pentest (без аутентификации). Так что выражение, отчасти, правда. Однако, EASM подразумевает функциональность по самостоятельному определению периметра организации (например, отталкиваясь от доменного имени) и фокус на контроле и учёте активов. Также этот сканер должен быть заточен под проблемы специфичные для периметра, например, искать админки. EASM может быть отправной точкой вендора к развитию полноценного инфраструктурного VM-а. И наоборот, VM-вендор может реализовать EASM модуль.

CAASM фокусируется на интеграции через API с другими системами, содержащими информацию об активах. Если там сканер и используется, то это побочная функциональность. Я бы не стал относить CAASM к "сценариям применения сканера безопасности".

А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей

2 комментария

А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей. Безусловно, недостаточно одной констатации VM-вендором, что тот или иной способ детектирования уязвимостей реализован в полной мере. Нужно идти ещё глубже.

Берём тот же базовый пример: детектирование уязвимостей на Linux хосте в пакетах из официального репозитория. Казалось бы - чего проще. Парсишь бюллетени безопасности (или даже готовый OVAL-контент Linux-вендора берёшь) и сравниваешь версии пакетов.

В реальности ошибиться можно много где. Самое частое:

🔹 Функция сравнения версий пакетов (например, эпоху не учитывают)
🔹 Источник безопасных версий пакетов (когда в бюллетенях source пакеты, а от них нужно перейти к версиям бинарных пакетов).

Особенно наглядно бывает, когда один хост проверяется несколькими сканерами. И в случае расхождений каждый вендор говорит, что их результаты правильные. 🤷‍♂️🤪 Пока не будет доказано обратное. 😏