Архив метки: vulnerability

Посмотрел совместный вебинар Vulners и RST Cloud про приоритизацию уязвимостей

Посмотрел совместный вебинар Vulners и RST Cloud про приоритизацию уязвимостей.

🔹 Кирилл Ермаков из Vulners рассказал про важность приоритизации узявимостей (особенно для MSSP компаний, т.к. они отвечают за безопасность клиентов) и как её можно улучшить с помощью динамически обновляемого AI Score v2. Очень понравилась его фраза: "если вы не знаете свои активы очень хорошо, выключайте вебинар и идите заниматься Asset Management-ом". Asset Management это база. 👍

🔹 Юрий Сергеев из RST Cloud рассказал как при приоритизации уязвимостей учесть данные об их эксплуатации в реальных атаках (в вашей локации, в вашей индустрии, для вашего профиля злоумышленника). Он привёл формулу и продемонстрировал как учёт этих факторов влияет на приоритизацию. Понравился пример с regreSSHion, где шуму много, но атака очень заметная и занимает много времени, поэтому эксплуатация вряд ли будет массовой.

Злоумышленники распространяют в соцсетках вредоносное приложение под видом эксплоита для regreSSHion (CVE-2024-6387)

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

Злоумышленники распространяют в соцсетках вредоносное приложение под видом эксплоита для regreSSHion (CVE-2024-6387). Как сообщают эксперты Kaspersky, атака рассчитана на специалистов по компьютерной безопасности. Злоумышленники предлагают жертвам исследовать архив, который якобы содержит рабочий эксплойт, список IP-адресов и некую полезную нагрузку.

🔻 Исходный код напоминает слегка отредактированную версию нефункционального proof-of-concept эксплоита для этой уязвимости, который уже был в паблике.

🔻 Один из Python-скриптов имитирует эксплуатацию уязвимости на IP-адресах из списка. На самом деле он запускает вредоносное ПО для закрепления в системе и скачивания дополнительной полезной нагрузки. Зловред модифицирует /etc/cron.hourly и запуск команды ls.

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

Три богатыря и Bug Bounty

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

Три богатыря и Bug Bounty. Сходили в кино на анимационный фильм "Три богатыря. Ни дня без подвига". Три короткие истории. Первая, думаю, ИБшникам зайдёт. 😉

Князь с подачи коня Юлия внедряет во дворце систему безопасности и объявляет багбаунти программу для выявления уязвимостей в ней: кто проникнет во дворец и выполнит реализацию недопустимого события (кражу короны), тот получит 100 сладких пряников.

В результате недопустимое событие реализуют, но за наградой никто не обращается. 😱🫣

Пришлось Алёше Поповичу проводить ресёрч как же злоумышленнику получилось обойти средства защиты. 😏

В итоге оказалось, что был реализован совсем не тот вектор, от которого защищались. 🤷‍♂️ Как это и бывает.

Мораль? 🙂 Тщательнее оговаривайте условия Bug Bounty программы. Она не обязательно должна быть публичной, зачастую приватная программа с ограниченным количеством проверенных участников (или даже обычный пентест) получается эффективнее и безопаснее. 😉

Microsoft будут заводить CVEшки для уязвимостей своих облачных сервисов

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

Microsoft будут заводить CVEшки для уязвимостей своих облачных сервисов. Казалось бы, ну была уязвимость в какой-то облачной CRM-ке, они её зафиксили сразу для всех, никаких действий со стороны клиентов не требуется. Толку-то на это CVE заводить? 🤔

Но в Microsoft считают, что это требуется для большей прозрачности, а новые правила CNA (CVE Numbering Authorities) требуют заводить уязвимости, которые могут нанести существенный вред, независимо от того требуется ли клиентам совершать какие-то действия для устранения уязвимостей или нет. 🤷‍♂️ Microsoft обещают помечать такие уязвимости отдельно, как например CVE-2024-35260 "The vulnerability documented by this CVE requires no customer action to resolve". В CVEorg тоже будет специальный tag.

Нужно или не нужно заводить уязвимости облачных сервисов как CVE - вопрос спорный. Но то, что из-за этой практики количество идентификаторов в CVEorg/NVD станет прирастать гораздо быстрее - факт. 🤷‍♂️

Трек про "regreSSHion" RCE от root-а в OpenSSH (CVE-2024-6387)

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

Трек про "regreSSHion" RCE от root-а в OpenSSH (CVE-2024-6387). 🙂 Трек сгенерировал в сервисе Suno.

(regreSSHion! regreSSHion!)
В OpenSSH CVE-2024-6387.
Удалённое выполнение произвольного кода без аутентификации от root-а - опасность понятна всем.

Это не шутка,
Звучит достаточно жутко.
(regreSSHion! regreSSHion!)

Уязвимость нашли эксперты компании Qualys.
И написали подробный write-up, как они на эту уязвимость напоролись.

Эта уязвимость - регресс старой уязвимости CVE-2006-5051 ранее исправленной.
Для неё признаков эксплуатации вживую и эксплоитов так и не было представлено.

Регресс произошёл в октябре, 2020 год,
Когда случился на версию OpenSSH 8.5p1 переход.

Уязвимы "glibc-based Linux systems" в конфигурации по умолчанию,
А OpenBSD не подвержена, согласно описанию.

Насколько это критично? Расклад таков:
В Интернете 14 миллионов потенциально уязвимых хостов.

Это не шутка,
Звучит достаточно жутко.
(Regression! Regression!)

Qualys обещают exploit не публиковать ибо
Злоумышленники начнут атаки - и на том спасибо!

Но весьма вероятно, что эксплоит напишут другие нахрапом.
Им хватит и публичного подробного write-up-а.

Но возможно, что атак не будет, а всё это просто пиар:
6-8 часов занимает атака на 32-битную Linux систему с ASLR.

Но, чтобы отбросить сомнения,
Лучше обновиться и мониторить попытки подключения.

Запатчи уязвимости на зло врагам
И подпишись на avleonovrus "Управление Уязвимостями и прочее" в Телеграм!

MP3 файл

Upd. Судя по реакциям, трек получился неоднозначный. 😅 Согласен, с первого раза на слух воспринимается тяжело. Учту на будущее, что рифмовать нужно тщательнее и грайм не очень подходит для подобных треков, лучше что-то поспокойнее. Но сам трек пусть остаётся, если отслеживать текст в видяшке, то вроде вполне норм. 😉

БОСПУУ и светофоры

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

БОСПУУ и светофоры. То, что вы видите на схеме БОСПУУ это характеристики нормального функционирующего Vulnerability Management процесса. Есть адекватный поток продетектированных уязвимостей, он обрабатывается, задачи на устранение уязвимостей заводятся, выполнение задач отслеживается.

А что, если у вас, как в посте Алексея Лукацкого, 10% активов не покрыты детектами? И, более того, эти активы не оценены и вы не знаете есть ли там целевые или ключевые системы. Это значит, что нормального VM-процесса у вас нет. 🤷‍♂️ И ваши красивые дашборды не отображают реального состояния инфры. Можно, как описывается в том же посте, спрятаться за светофорчик: 90% есть, красим в зелёненький. 🚦👌 Но это самообман и обман руководства организации. Заканчивается это плохо. В случае инцидента светофорчик вас не спасёт.

Рекомендую не приукрашивать положение дел, а приводить VM-процесс к нормальному функционирующему состоянию, которое подразумевает контроль всех активов и всех уязвимостей.

Обновил схему Базовой Оценки Состояния Процесса Управления Уязвимостями (БОСПУУ)

8 комментариев

Обновил схему Базовой Оценки Состояния Процесса Управления Уязвимостями (БОСПУУ). Теперь там 4 компонента:

🔻 Адекватность используемых решений по детектированию уязвимостей
🔻 Анализ уязвимостей и заведение задач на устранение уязвимостей 🆕
🔻 Охват инфраструктуры, работа с активами и ответственными за устранение уязвимостей
🔻 Отслеживание выполнения SLA по задачам на устранение уязвимостей для скоупов активов

По сравнению с версией 0.0.5, разнёс работу с активами/ответственными и анализ уязвимостей/заведение задач на исправление. Подрихтовал формулировки, чтобы было меньше неоднозначного. Сознательно убрал про сканирование сетей - это укладывается в "нет активов без регулярных проверок на уязвимости".

Это всё ещё драфт, но вроде выглядит уже более-менее прилично и кажется, что всё основное в VM-процессе охватывает. Можно потихоньку отвечать на критику от Алексея Лукацкого. 😉

Если видите недочёты - не стесняйтесь, пишите в личку @leonov_av. 🙂

В непожатом виде