Vulnerability Management решения и Zero Day уязвимости (2/3)

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

Vulnerability Management решения и Zero Day уязвимости (2/3)

Если несознательный исследователь опубликует полный ресерч по уязвимости, вообще не информируя вендора, т.е. сразу сделает full disclosure, это будет классический Zero Day. Тут вопросов нет. Но есть тонкости:

➡️ Является такая уязвимость Zero Day до момента публичного раскрытия?
➡️ Если сознательный исследователь информирует вендора, является ли уязвимость Zero Day от момента обнаружения её исследователем до момента передачи данных о ней вендору и во время разработки патча вендором?
➡️ Если уязвимость была Zero Day, то после выхода патча вендором, корректно ли продолжать называть такую уязвимость Zero Day?

Есть разные мнения и определения:

1. Trendmicro: "A zero-day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched".
2. Kaspersky: "A zero-day vulnerability is a software vulnerability discovered by attackers before the vendor has become aware of it."
3. Portswigger: "A zero-day (0day) vulnerability refers to a security vulnerability for which no mitigation or patch is available at the time it is disclosed or made public".
4. ScienceDirect: "Zero-day vulnerability is defined as a security flaw that has not yet been disclosed to the vendor or developers".

Как видим, согласно некоторым определениям раскрытие информации (disclosure) требуется для отнесения уязвимости к Zero Day, а согласно другим вроде как и нет.

В глоссарии NIST нет понятия "zero day vulnerability".

В глоссарии ФСТЭК Уязвимость нулевого дня (Zero-day vulnerability) это "уязвимость, которая становится известной до момента выпуска разработчиком программного обеспечения информационной системы мер защиты информации по ее устранению, исправлений ошибок или соответствующих обновлений". Тут тоже не вполне понятно "становится известной" широкому кругу лиц или вообще, даже одному исследователю?

Лично мне НЕ нравится идея называть уязвимость Zero Day только в момент её опубликования. Почему? Если мы определяем таким образов, то в случае тайного зловредного использования уязвимости (например #Eternalblue до утечки из NSA) мы не можем сказать что это было использование Zero Day уязвимости. Публикации же (пока) не было! Хотя очевидно это было именно использование Zero Day уязвимости.

Ок, можем подкрутить и говорить, что нужно либо опубликование, либо использование. И какое использование? Вот есть исследователь, нашедший уязвимость. В ходе ресерча он эту уязвимость явно как-то использовал / тестировал на чем-то. Получается нужно не простое использование, а зловредное. А как определить зловредность? Это тоже добавляет неразберихи.

Поэтому мне кажется, что проще и непротиворечивее считать за Zero Day вообще любую уязвимость до момента появления фикса от вендора (патч или workaround). После публикации фикса называть уязвимость Zero Day оправдано только если мы говорим о каких-то прошедших событиях, когда фикса ещё не было.

Vulnerability Management решения и Zero Day уязвимости (1/3)

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

Vulnerability Management решения и Zero Day уязвимости (1/3)

Vulnerability Management решения и Zero Day уязвимости (1/3)

В моем англоязычном телеграмм-чате @avleonovchat задали вопрос: "Как найти 0day уязвимости с помощью Qualys?" Видимо этот вопрос можно расширить. Не только с помощью Qualys, а вообще с помощью любого VM-решения. И возможно ли это сделать вообще? Там завязалась довольно интересная дискуссия.

Вопрос не такой однозначный. Чтобы ответить на него, следует определиться что такое Zero Day уязвимость. Если мы посмотрим википедию, то исторически "0" это количество дней, которое есть у вендора на фикс уязвимости.

"Eventually the term was applied to the vulnerabilities that allowed this hacking, and to the number of days that the vendor has had to fix them."

Иллюстрация сгенерирована Stable Diffusion 2.1: "calendar on the wall cyber security vulnerability zero day"

Сходили с семейством на "Сказку о царе Салтане"

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

Сходили с семейством на "Сказку о царе Салтане". Ничего так. Про проблемы с ИБ в Saltan Inc. и крайне удачливый, но и крайне мутный IT-стартап GWI Done. 🙂

1. Проблемы с ИБ в Saltan Inc. видны с самого начала. Ключевой сервис GONE.c компании подвержен критической уязвимости, позволившей злоумышленникам провести атаку "человек посередине" (MitM) и выполнить действия от имени CEO Салтанова. Процедуры подтверждения решений не было, платёжка прошла, активы ушли в "бездну вод". Инцидент замяли. Крайним выставили CTO Гвидонова, которому пришлось покинуть компанию.

2. Гвидонов запускает стартап GWI Done. Разработка PoC ведётся в режиме жёсткой экономии и по Agile:

"Ломит он у дуба сук
И в тугой сгибает лук,
Со креста снурок шелковый
Натянул на лук дубовый,
Тонку тросточку сломил,
Стрелкой легкой завострил"

Гвидонову необыкновенно везёт, он знакомится с ключевым инвестором и будущим партнёром по бизнесу, влиятельной г-жой Лебедевой. Это предрешает успех всего предприятия. После первого успешного проекта получены инвестиции, гарантирующие развитие компании на годы вперед. За счёт этих средств успешно запустили блокчейн-платформу Belka.

"Из скорлупок льют монету,
Да пускают в ход по свету;"
"Князю прибыль, белке честь"

Силовую поддержку бизнеса обеспечивают, "братья" Лебедевой под руководством Черноморова.

3. Кульминационный момент это сделка о недружественном поглощения Saltan Inc. со стороны GWI Done. Ключевую роль здесь снова сыграли проблемы с ИБ в Saltan. Успешная APT атака позволила Гвидонову и Лебедевой получить доступ ко всем переговорам внутри Saltan Inc. в реальном времени (почта, месенджеры, сервис телеконференций) и купировать все попытки противодействия ТОПов Saltan. Не брезговали даже причинением лёгкого вреда здоровью ТОПов. В итоге Гвидонов и Лебедева успешно отжимают бизнес, расходятся относительно мирно с предыдущей командой, даже номинально оставляют в компании Салтанова, и продолжают жить-поживать, да добра наживать.

Мораль: связи решают, а проблемы с ИБ могут иметь самые плачевные последствия для бизнеса. 🙂

В прошлый раз про Данилу-мастера разбирал.

По наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от Nucleus

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

По наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от NucleusПо наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от NucleusПо наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от Nucleus

По наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от Nucleus. Товарищи взяли CISA KEV и добавили туда данные EPSS (Score и Percentile), CVSS из NVD, а также Treat Intelligence фид от GreyNoise. Вроде ничего хитрого, но получилось занимательно.

1. Самое очевидное это то, что можно дополнительно приоритизировать уязвимости из CISA KEV для исправления.
2. С другой стороны здесь наглядно видны проблемы источников.
2.1. Если уязвимость эксплуатируется вживую, то почему эту эксплуатацию GreyNoise не видит? С одной стороны это может быть связано с ограничением фида GreyNoise - не по всем уязвимостям могут эксплуатацию отслеживать. С другой стороны это может быть связано с тем, что CISA берет признак эксплуатации от вендора, по факту это может быть "вероятная эксплутация в единичной таргетированной атаке в полнолуние и пятницу 13-е", а подробностей нет и не будет.
2.2. Вот Exploit Prediction Scoring System (EPSS) показывает "probability [0-1] of exploitation in the wild in the next 30 days (following score publication)". Весьма весело взять уязвимости "CVE-2022" с детектами от GreyNoise и увидеть, что EPSS для них вероятность появления эксплоита оценивала довольно низко. Выделил на скриншоте 20%. Иногда оценка даже в 1-2%, как например в случае с одной из уязвимостей Exchange ProxyNotShell. В общем, EPSS это далеко не серебряная пуля.
2.3. Также интересно посортировать по CVSS. Сразу вылезают проблемы с уязвимостями, которых нет в NVD. Проблемы сортировки в таблице (но это ладно). А самое интересное уязвимости с CVSS 7, т.е. меньше High. В данном случае укладываются в Medium. То есть горячий привет тем, кто жестко фильтрует по CVSS от High и выше.

Посмотрел вебинар Positive Technologies про редизайн консоли MaxPatrol 8 и XSpider

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

Посмотрел вебинар Positive Technologies про редизайн консоли MaxPatrol 8 и XSpiderПосмотрел вебинар Positive Technologies про редизайн консоли MaxPatrol 8 и XSpiderПосмотрел вебинар Positive Technologies про редизайн консоли MaxPatrol 8 и XSpiderПосмотрел вебинар Positive Technologies про редизайн консоли MaxPatrol 8 и XSpiderПосмотрел вебинар Positive Technologies про редизайн консоли MaxPatrol 8 и XSpiderПосмотрел вебинар Positive Technologies про редизайн консоли MaxPatrol 8 и XSpiderПосмотрел вебинар Positive Technologies про редизайн консоли MaxPatrol 8 и XSpiderПосмотрел вебинар Positive Technologies про редизайн консоли MaxPatrol 8 и XSpider

Посмотрел вебинар Positive Technologies про редизайн консоли MaxPatrol 8 и XSpider. В этом обновлении логика работы не поменялась. Все управление осталось таким же. Обновили интерфейс в стиле Win11, с которым будет приятно глазу работать. Планируют сделать и темную тему.

Конечно хотелось бы увидеть финт, который сделали Tenable c Nessus. Когда-то давно у них был толстый клиент, а потом они перешли на веб-интерфейс (сначала на Flash, потом переписали на SPA), в процессе сделали вполне приличный API. Потом правда этот API официально выпилили из Nessus, но в Tenable.io он продолжает использоваться. Такой же финт, насколько я понимаю, сделали Altx-Soft с дополнительным веб-интерфейсом для RedCheck.

Было бы круто увидеть web gui для MaxPatrol 8 и XSpider, но ожидать его не приходится по ряду причин. Перечисленное исключительно моё имхо:

1. Толстый клиент MP8/XSpider гораздо более мощный по функциональности, чем у конкурентов. Чтобы сделать вегбуй требуется серьезное изменение логики и переписывание многих модулей. И это уже делается в разработке Maxpatrol VM.
2. MP8/XSpider существуют по той причине, что пока ещё не вся экспертиза и функциональность перенесена в Maxpatrol VM (комплаенс-режима, например, нет). Рано или поздно это произойдет и эти продукты контролируемо сведут с орбиты. НО пока продажи и поддержку продолжают, прекращать не планируют. Это же объясняет и почему не оправдана миграция на Linux текущих решений.
3. Логично было бы предположить появление нового поколения решений а-ля MP8 и XSpider, урезанных из Maxpatrol VM, когда будут достигнуты цели из п.2.

PS: В QA интересный вопрос был про продление про сертификатов для MP8/XSpider после 08.07.2024. Ответили, что под большим вопросом, как и для всего ПО под Windows в принципе.

Посмотрел запись вебинара ОМП и Аквариуса "Как ОС Аврора появляется на мобильных устройствах российского производства"

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

Посмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производстваПосмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производстваПосмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производстваПосмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производстваПосмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производстваПосмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производства

Посмотрел запись вебинара ОМП и Аквариуса "Как ОС Аврора появляется на мобильных устройствах российского производства". Весьма интересно.

1) В первой части про Аврору понравилось, что в ОМП всерьез занимаются проблемами информационной безопасности и исправлением известных уязвимостей.
2) Вторая часть про производство устройств в Аквариусе удивила. Я грешным делом думал, что "устройства российского производства" это просто OEM, который в готовом виде из Китая приходит. Ну или максимум конвейерная сборка из готовых модулей. Оказывается в случае Аквариуса это не так. Рассказали про полный цикл производство, включающий проектирование и изготовление печатных плат для кпк, планшетов и серверных продуктов. Понятное дело, что используемые электронные компоненты импортные, но даже текущая степень локализации впечатляет. Особенно с учетом вполне современных характеристик устройств. Круто!

На днях пролетала новость по поводу уязвимости FreeBSD CVE-2022-23093 про RCE и ping

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

На днях пролетала новость по поводу уязвимости FreeBSD CVE-2022-23093 про RCE и ping

На днях пролетала новость по поводу уязвимости FreeBSD CVE-2022-23093 про RCE и ping. Можно было предположить, что достаточно послать какой-то хитрый ICMP Echo (ping) пакет на уязвимый хост и получить RCE.

К счастью, судя по бюллетеню FreeBSD-SA-22:15.ping.asc, проблема заключается в обработке ответа на ping от внешнего хоста.

"ping reads raw IP packets from the network to process responses in the pr_pack() function."

Т.е. уязвимый FreeBSD-шный хост должен начать пинговать хост злоумшышленника. Хост злоумышленника должен ждать этот ping и в ответ выдать нестандартную бяку, которая покрашит процесс на FreeBSD-шном хосте, и это возможно (!) приведет к RCE от рута, т.к. ping устанавливается с setuid bit. Но из-за того, что процесс ping запускается в песочнице ("capability mode sandbox"), атакующему будет сложновато нанести какой-то реальный вред системе.

Обновлять FreeBSD-ные хосты нужно (а EOL-ные выкорчевывать), но всерьез рассматривать эту уязвимость сложновато.