Архив рубрики: Уязвимость

Три богатыря и 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. 🙂

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

RCE от root-а в OpenSSH "regreSSHion" (CVE-2024-6387)

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

RCE от root-а в OpenSSH "regreSSHion" (CVE-2024-6387). Уязвимость нашли эксперты компании Qualys. Неаутентифицированный удалённый злоумышленник может выполнять произвольный код от root-а. Звучит жутко. 😱🙂

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

🔻 Регресс произошёл в октябре 2020 г., начиная с OpenSSH 8.5p1
🔻 Уязвимы "glibc-based Linux systems" в конфигурации по умолчанию, OpenBSD уязвимости не подвержена
🔻 В Интернете 14 миллионов потенциально уязвимых хостов
🔻 Qualys эксплоит обещают не публиковать, но весьма вероятно, что эксплоит напишут сторонние исследователи по их подробному write-up-у

Уязвимые версии:

❌ OpenSSH 4.4p1
❌ 8.5p1 = OpenSSH 9.8p1 Неуязвимые версии: ✅ 4.4p1 = OpenSSH 8.5p1
✅ OpenSSH >= 9.8p1

Upd. В описании релиза пишут, что атака 32-битной системы с ASLR в лаборатных условиях заняла 6-8 часов. Видимо процесс всё же непростой. 😉

Повышение критичности уязвимости Elevation of Privilege - Windows Kernel (CVE-2024-30088)

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

Повышение критичности уязвимости Elevation of Privilege - Windows Kernel (CVE-2024-30088). Уязвимость свежая, из июньского Microsoft Patch Tuesday. Я её выделял в обзоре, так как для неё, согласно CVSS вектору, существовал приватный Proof-of-Concept Exploit. Но подробностей не было. Было ясно только то, что в случае успешной эксплуатации, злоумышленник может получить привилегии SYSTEM. Согласно бюллетеню ZDI, уязвимость затрагивает реализацию NtQueryInformationToken и заключается в отсутствии правильной блокировки при выполнении операций над объектом.

24 июня, через 2 недели после июньского Patch Tuesday, на GitHub появился репозиторий с техническими деталями по этой уязвимости и PoC-ом эксплоита. Также доступно видео с запуском утилиты для получения привилегий SYSTEM.

В последнее время EoP/LPE уязвимости Windows очень часто докручивают до реальной эксплуатации. Обращайте, пожалуйста, на них внимание и исправляйте заранее.