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

Прожектор по ИБ, выпуск №8 (22.10.2023)

Прожектор по ИБ, выпуск №8 (22.10.2023). Записали очередной эпизод. Из основного: обсуждали Аврору ОС и отечественные смартфоны/планшеты, разобрали актуальные уязвимости с упором на Linux, немного коснулись регуляторики. К сожалению, у нас был какой-то сбой с видео, поэтому с 35:37 мы без камер. 🤷‍♂️

Мы это:

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

00:00 Здороваемся и радуемся, что прошлый выпуск вроде неплохо смотрели 🙂
01:45 Лев поучаствовал в IVADAY 2023 и ему подарили отечественный планшет от БайтЭрг
08:40 Кажется, что смартфоны нa Авроре для физиков могут появиться в ноябре. Обсуждаем зачем и кому это вообще нужно
19:23 Телеканалы и операторов связи обяжут создать ИБ-подразделения
23:17 Auth bypass в Cisco IOS ХЕ (CVE-2023-20198)
27:47 13 эксплоитов ботнета Mirai
30:37 RCE уязвимость в JetBrains TeamCity (CVE-2023-42793)
33:56 Женщина сама себя сняла с электронной очереди в детский сад в Астане
35:37 Смотрим отчёт по октябрьскому Linux Patch Wednesday
37:52 GNOME уязвим перед RCE-атаками из-за ошибки в библиотеке libcue
41:20 Охарактеризуйте олдскульную ИБ одним словом и шлите нам свои мемасики
42:38 ФБР предупредила о хакерах-вымогателях, атакующих клиники пластической хирургии в США и мире
43:43 В CISA KEV появилась новая колонка, отвечающая за использование уязвимости в атаках шифровальщиков
45:13 Практический вопрос использования методики оценки уровня критичности уязвимостей ФСТЭК
49:43 Сходка "ПоИБэшечка: К истокам" 31 октября
51:50 Прощание от Mr. X

Прослушал второй эпизод подкаста КиберДуршлаг с Эльманом Бейбутовым

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

Прослушал второй эпизод подкаста КиберДуршлаг с Эльманом Бейбутовым. Выписал тезисы.

1. Об управлении уязвимостями должно болеть у SOCоводов, т.к. активность закрепившегося злоумышленника будет выглядеть как более-менее легитимная активность пользователя и они её не поймают.
2. Людям склонно заниматься тем, что проще. Внедрять антивирусы гораздо проще, чем VM процесс.
3. VM не панацея. Нужен контроль конфигураций и действий внутреннего напушителя, нужно реагирование, нужна экосистема.
4. SIEM для VMа позволяет актуализировать инфу об активах, VM для SIEMа позволяет подсветить активы с высокой вероятностью эксплуатации (где нужно обмазать детектами).
5. Связка VM с EDR позволяет использовать EDR в качестве агента для инвентаризации и response (погасить хост, собрать инфу на доп. расследование)
6. В VM нужно интегрировать и апсечные уязвимости, и куберовые.
7. Можно такие интеграции замутить не в экосистеме одного вендора, а из разных решений через APIшки? Можно, но сложно. Из опенсурса ещё сложнее.
8. Куда дальше? Виртуальный патчинг, автоматический патчинг, детект любых уязвимостей и везде, анализ MLем.
9. Много фидов это хорошо, т.к. они друг друга дополняют, но должна быть Threat Intelligence платформа, чтобы эффективно с ними работать.
10. Вершина эволюции VMа - автопилот. Автоматизированный Patch Management, сквозной virtual patching, построение цепочки атак и отслеживание действий злоумышленника. Реализуется в метапродуктах PT.

Получил неофициальное разъяснение от ФСТЭКа по поводу использования методики оценки уровня критичности уязвимостей

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

Получил неофициальное разъяснение от ФСТЭКа по поводу использования методики оценки уровня критичности уязвимостей. Это по вопросу расчета Iinfr, который я вчера поднимал:

"Изначально задумывалось, что уязвимость оценивается для всей ИС. Но, поскольку это не прописано в методике явно, то допускаются оба сценария оценки."

Т.е. основной вариант 1 (единый Iinfr для всей инфраструктуры/информационной системы, через максимизацию значения показателей) но можно использовать и 1, и 2 (считаем Iinfr независимо для каждого уязвимого актива).

Microsoft выпустили статью об атаках с использованием RCE уязвимости в JetBrains TeamCity (CVE-2023-42793)

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

Microsoft выпустили статью об атаках с использованием RCE уязвимости в JetBrains TeamCity (CVE-2023-42793). Статья про то, что злоумышленники делают после компрометации серверов TeamCity и будет интересна скорее SOC-оводам. Но это хороший повод вспомнить об уязвимости, которую я здесь не подсвечивал.

TeamCity это один из самых популярных CI/CD-серверов. Учитывая, что JetBrains были по большей части российской компаний до своего недавнего исхода, в РФ продукты JetBrains используются более чем широко.

JetBrains узнали об уязвимости в начале сентября и оперативно выпустили обновление и плагин для старых версий. 21 сентября JetBrains выложили подробное описание уязвимости, после чего быстро появились рабочие эксплоиты. Сейчас даже модуль для Метасплоита есть. Атаки, о которых пишут MS, начались с начала октября.

В общем, полный набор для супер-критичной уязвимости. Исправляйте, если ещё нет. 🙂

🟥 PT относит уязвимость к трендовым с 26 сентября.

В официальном канале PT вышел рекламный ролик курса по Управлению Уязвимостями

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

В официальном канале PT вышел рекламный ролик курса по Управлению Уязвимостями. По сюжету злобный хацкер старается сломать инфраструктуру, но у него ничего не получается, т.к. для организации с выстроенным VM-процесом страшные зловреды превращаются в банан. 🍌🙂 В инфраструктуре, которая регулярно патчится особенно не развернёшься. 🤷‍♂️

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

Так что рекомендую записаться и пройти курс. Как минимум его бесплатную вводную часть. Ну а в идеале выбить у руководства бюджет на полноценный месячный курс. Не зря же я там участвовал. 😉

Старт 29 октября.

Вопрос по поводу практического применения методики оценки уровня критичности уязвимостей ФСТЭК

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

Вопрос по поводу практического применения методики оценки уровня критичности уязвимостей ФСТЭК. Наверное у каждого, кто пробовал применять методику возникал вопрос. Ну хорошо, Iinfr зависит от типа уязвимого актива. А что делать, если у меня разные типы активов (хостов) подвержены данной CVE/БДУ уязвимости? Например, у меня уязвимость Windows, которая детектируется и на десктопах, и на серверах. Какое тогда значение показателя K выбирать? Или, например, у меня уязвимости подвержены и хосты на периметре, и глубоко во в внутрянке. Тоже непонятно какое значение показателя P выбирать.

Кажется, что здесь могут быть два основных подхода:

1. Единый Iinfr для всей инфраструктуры, через максимизацию значения показателей. То есть если уязвимость есть на десктопах и серверах, то берём значение K для серверов. Если есть хоть один уязвимый хост на периметре, то берем P для средств доступных из Интернет.

✅ Плюс: в итоге получаем один уровень критичности V для уязвимости, этакий "улучшенный CVSS" и используем его так, как использовали бы CVSS.

⛔ Минус: получается, что этот максимизированный V будет аффектить все активы и задавать требования по оперативности исправления. Если у нас уязвимость на 100 десктопах и одном сервере, то будьте любезны пофиксить её на десктопах с той же срочностью, что и на сервере. Ну или сначала пофиксить на сервере, и потом пересчитать Iinfr и, соответственно, V. Получим меньшую критичность и более комфортные сроки устранения уязвимости.

2. Считаем Iinfr независимо для каждого уязвимого актива. То есть сколько у нас активов (или групп однотипных активов), столько у нас будет Iinf и, соответственно, V.

✅ Плюс: получаем атомарность, практически избавляемся от неоднозначности.

⛔ Минус: это уже будет не "улучшенный CVSS", нельзя будет сказать, а какова критичность этой CVE/БДУ, т.к. для каждого уязвимого актива она может отличаться. В прочем, с CVSS может быть та же история, если активно подкручивать Temporal часть вектора для каждого актива (на практике я правда такое не встречал).

А как правильно? 🧐 Видится, что можно жить и с первым, и со вторым вариантом. Но было бы здорово получить разъяснения ФСТЭК о том, как оно изначально задумывалось, и на это уже ориентироваться.

Upd. Получил неофициальное разъяснение от ФСТЭК. Задумывался первый вариант, но можно оба.

Выпустил отчёт по октябрьскому Linux Patch Wednesday!

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

Выпустил отчёт по октябрьскому Linux Patch Wednesday! Первый! 🥳 Результатом доволен. Топ выглядит адекватно и соответствует тому, что я подсвечивал в канале.

1. Memory Corruption - Chromium (CVE-2023-5217). Это уязвимость в библиотеке libvpx, которая была самой критичной и в октябрьском Microsoft Patch Tuesday. Есть PoC на гитхабе и признаки эксплуатации вживую.
2. Remote Code Execution - GNU C Library (CVE-2023-4911). Это Qualys Looney Tunables. Давно есть PoC, но признаков эксплуатации вживую пока нет.
3. Denial of Service - Golang Go (CVE-2023-29409). Есть PoC. Vulristics определил софт как TLS, т.к. в описании уязвимости CVE никакого намека на Go. 🤷‍♂️
4. Denial of Service - HTTP/2 protocol (CVE-2023-44487). Также был в MSPT.
…
14. Memory Corruption - Curl (CVE-2023-38545). Для этой уязвимости появились PoC-и на Github.

Остальное без эксплоитов и признаков эксплуатации вживую.

🗒 Vulristics report

Александр В. Леонов

Управление Уязвимостями и прочее