По итогам выступления на Positive Customer Day. Всё прошло вполне удачно. Спасибо большое коллегам из Positive Technologies за приглашение! Кажется это был мой первый доклад на "бумажную" тему. Хоть я, в основном, делал акценты на технические сложности при реализации методик, но всё равно. Оказалось, что у "бумажных" докладов своя специфика. Были вопросы в духе: почему регулятор написал документ так, а не иначе? Почему он что-то учёл, а что-то решил не учитывать? Зачем регулятор вообще выпустил тот или иной документ? Раньше я с таким не сталкивался и даже впал в лёгкий ступор. Можно, конечно, что-то фантазировать на эту тему, но такие вопросы явно не по адресу. 😅
В целом же, по итогам Q&A для себя сформулировал следующее:
1. В методику оценки критичности уязвимостей неплохо было бы добавить учёт использования уязвимости в реальных атаках (аналог CISA KEV) и вероятности появления эксплоита для неё (аналог EPSS)
2. В руководство по построению процесса управления уязвимостями было бы неплохо добавить:
2.1. Требования к актуальности данных об обнаруженных уязвимостях, например максимально допустимую периодичность сканирования. Не должно быть возможности сканировать раз в квартал и делать какие-то выводы на основе этого.
2.2. Требования к полноте покрытия активов. Не должно быть активов (хостов, софтов, сетевых устройств и т.д.), которые не покрываются средствами детектирования уязвимостей. Должен быть какой-то процесс подтверждения, что VM-решение умеет детектировать уязвимости для всех активов в организации. Если есть какой-то актив, для которого автоматическое детектирование уязвимостей не производится, нужно с этим что-то делать. Как минимум подсветить.
2.3. Требования к оценке качества детектирования уязвимостей. Ситуация, когда несколько средств детектирования анализируют один и тот же актив и выдают совершенно разные наборы уязвимостей ненормальная. Если так происходит, значит в каких-то решениях реализована неправильная логика и такие решения нельзя использовать в процессе управления уязвимостями ("мусор на входе - мусор на выходе"). Следует ли из этого, что должен быть процесс сертификации средств детектирования уязвимостей, такой как для PCI ASV или SCAP сканеров? Возможно.
Ещё в выступлении я, среди прочего, позволил себе предположить, что подход Positive Technologies к VM-у (который я лично всячески поддерживаю), предполагающий процесс регулярного безусловного патчинга инфраструктуры не особенно сочетается с руководством ФСТЭК по построению процесса управления уязвимостями, т.к. это руководство требует тестирования обновлений для open-source и нероссийского софта по методике ФСТЭК перед установкой. Т.е. процесс регулярного безусловного патчинга может и быть, но кажется момент с тестированием обновлений должен быть определен: тестируем/не тестируем, если тестируем, то чьими силами и в каком объёме.
@avleonovrus #PositiveTechnologies #PCDay #FSTEC #ФСТЭК #CISA #CISAKEV #EPSS #SCAP #PCIASV
В целом же, по итогам Q&A для себя сформулировал следующее:
1. В методику оценки критичности уязвимостей неплохо было бы добавить учёт использования уязвимости в реальных атаках (аналог CISA KEV) и вероятности появления эксплоита для неё (аналог EPSS)
2. В руководство по построению процесса управления уязвимостями было бы неплохо добавить:
2.1. Требования к актуальности данных об обнаруженных уязвимостях, например максимально допустимую периодичность сканирования. Не должно быть возможности сканировать раз в квартал и делать какие-то выводы на основе этого.
2.2. Требования к полноте покрытия активов. Не должно быть активов (хостов, софтов, сетевых устройств и т.д.), которые не покрываются средствами детектирования уязвимостей. Должен быть какой-то процесс подтверждения, что VM-решение умеет детектировать уязвимости для всех активов в организации. Если есть какой-то актив, для которого автоматическое детектирование уязвимостей не производится, нужно с этим что-то делать. Как минимум подсветить.
2.3. Требования к оценке качества детектирования уязвимостей. Ситуация, когда несколько средств детектирования анализируют один и тот же актив и выдают совершенно разные наборы уязвимостей ненормальная. Если так происходит, значит в каких-то решениях реализована неправильная логика и такие решения нельзя использовать в процессе управления уязвимостями ("мусор на входе - мусор на выходе"). Следует ли из этого, что должен быть процесс сертификации средств детектирования уязвимостей, такой как для PCI ASV или SCAP сканеров? Возможно.
Ещё в выступлении я, среди прочего, позволил себе предположить, что подход Positive Technologies к VM-у (который я лично всячески поддерживаю), предполагающий процесс регулярного безусловного патчинга инфраструктуры не особенно сочетается с руководством ФСТЭК по построению процесса управления уязвимостями, т.к. это руководство требует тестирования обновлений для open-source и нероссийского софта по методике ФСТЭК перед установкой. Т.е. процесс регулярного безусловного патчинга может и быть, но кажется момент с тестированием обновлений должен быть определен: тестируем/не тестируем, если тестируем, то чьими силами и в каком объёме.
@avleonovrus #PositiveTechnologies #PCDay #FSTEC #ФСТЭК #CISA #CISAKEV #EPSS #SCAP #PCIASV
VM-вендоры не умеют детектировать уязвимости, которые эксплуатируются шифровальщиками. Прочитал отчёт "Index Update Q1 2023 RANSOMWARE Through the Lens of Threat and Vulnerability Management" по данным Securin и Ivanti. Товарищи анализируют информацию об уязвимостях, которые используются 356 шифровальщиками.
В отчёте утверждается, что есть 18 уязвимостей, эксплуатируемых шифровальщиками, которые не детектируются сканерами уязвимостей ТОПовых VM-вендоров (Tenable, Rapid7 и Qualys):
CVE-2010-1592
CVE-2012-3347
CVE-2013-0322
CVE-2013-2618
CVE-2013-3993
CVE-2015-2551
CVE-2015-7465
CVE-2017-15302
CVE-2017-18362
CVE-2017-3197
CVE-2017-3198
CVE-2017-6884
CVE-2019-16647
CVE-2019-16920
CVE-2019-5039
CVE-2019-9081
CVE-2020-36195
CVE-2021-33558
Эти уязвимости эксплуатируются 59 группировками шифровальщиков, среди которых Hive, Qlocker, QNAPCrypt и UEFI.
От меня: когда я призываю к открытости баз знаний VM-вендоров, я имею ввиду именно это. Любой VM-вендор умеет детектировать только часть из всех известных уязвимостей. Кто может сказать, что тех уязвимостей, которые он умеет детектировать, достаточно и в его слепой зоне точно нет ничего критичного? Вот имеем пример, когда исследователи, получив доступ к базам знаний (детектов) VM-вендоров, подтвердили проблему с полнотой. И это мы берём самый-самый топ критичных уязвимостей и самых крутых международных VM-вендоров.
Разумеется, сравнение по детектируемым CVE идентификаторам это далеко не идеальный способ обнаружить проблемы с полнотой, но это простой способ и какое-то представление он даёт. Поэтому, призываю всех пушить отечественных VM-вендоров, чтобы информация о детектируемых уязвимостях была публичной и общедоступной для стороннего анализа. Ну или хотя бы доступной регуляторам, чтобы регуляторы сами контролировали адекватность баз знаний (детектов) VM-вендоров.
В отчёте также есть критика CVSS, NVD и CISA KEV из-за некорректного учёта эксплуатируемых шифровальщиками CVE:
• 30% CVE не имеют CVSS v2 или v3 в NVD
• 2 CVE имеют severity Low, 57 Medium в NVD
• 2 CVE находятся в статусе Rejected в NVD (CVE-2015-2551 и CVE-2019-9081)
• только 68% CVE содержатся в CISA KEV, требуется добавить ещё 131
@avleonovrus #Securin #Ivanti #Tenable #Rapid7 #Qualys #Hive #Qlocker #QNAPCrypt #UEFI #CVSS #NVD #CISA #CISAKEV #ransomware
В отчёте утверждается, что есть 18 уязвимостей, эксплуатируемых шифровальщиками, которые не детектируются сканерами уязвимостей ТОПовых VM-вендоров (Tenable, Rapid7 и Qualys):
CVE-2010-1592
CVE-2012-3347
CVE-2013-0322
CVE-2013-2618
CVE-2013-3993
CVE-2015-2551
CVE-2015-7465
CVE-2017-15302
CVE-2017-18362
CVE-2017-3197
CVE-2017-3198
CVE-2017-6884
CVE-2019-16647
CVE-2019-16920
CVE-2019-5039
CVE-2019-9081
CVE-2020-36195
CVE-2021-33558
Эти уязвимости эксплуатируются 59 группировками шифровальщиков, среди которых Hive, Qlocker, QNAPCrypt и UEFI.
От меня: когда я призываю к открытости баз знаний VM-вендоров, я имею ввиду именно это. Любой VM-вендор умеет детектировать только часть из всех известных уязвимостей. Кто может сказать, что тех уязвимостей, которые он умеет детектировать, достаточно и в его слепой зоне точно нет ничего критичного? Вот имеем пример, когда исследователи, получив доступ к базам знаний (детектов) VM-вендоров, подтвердили проблему с полнотой. И это мы берём самый-самый топ критичных уязвимостей и самых крутых международных VM-вендоров.
Разумеется, сравнение по детектируемым CVE идентификаторам это далеко не идеальный способ обнаружить проблемы с полнотой, но это простой способ и какое-то представление он даёт. Поэтому, призываю всех пушить отечественных VM-вендоров, чтобы информация о детектируемых уязвимостях была публичной и общедоступной для стороннего анализа. Ну или хотя бы доступной регуляторам, чтобы регуляторы сами контролировали адекватность баз знаний (детектов) VM-вендоров.
В отчёте также есть критика CVSS, NVD и CISA KEV из-за некорректного учёта эксплуатируемых шифровальщиками CVE:
• 30% CVE не имеют CVSS v2 или v3 в NVD
• 2 CVE имеют severity Low, 57 Medium в NVD
• 2 CVE находятся в статусе Rejected в NVD (CVE-2015-2551 и CVE-2019-9081)
• только 68% CVE содержатся в CISA KEV, требуется добавить ещё 131
@avleonovrus #Securin #Ivanti #Tenable #Rapid7 #Qualys #Hive #Qlocker #QNAPCrypt #UEFI #CVSS #NVD #CISA #CISAKEV #ransomware
В CISA KEV, каталоге эксплуатируемых уязвимостей, появилась новая колонка, отвечающая за использование уязвимости в атаках шифровальщиков. Колонка называется "Known to be Used in Ransomware Campaigns". Возможные значения: Known и Unknown. Сейчас там 184 уязвимости, которые Known. В JSON-выгрузке также есть это поле. Неплохо, но хотелось бы, конечно, не только флажок, но и подробности какие именно шифровальщики эксплуатируют уязвимости.
Также CISA завели новую страничку с мисконфигурациями, которые используются в атаках шифровальщиков. Пока там только таблица с сервисами, использование которых может быть небезопасно (RDP, FTP, TELNET, SMB, VNC). Но, возможно, эта тема разовьётся во что-то более интересное.
@avleonovrus #CISA #CISAKEV #Ransomware #RDP #FTP #TELNET #SMB #VNC
Также CISA завели новую страничку с мисконфигурациями, которые используются в атаках шифровальщиков. Пока там только таблица с сервисами, использование которых может быть небезопасно (RDP, FTP, TELNET, SMB, VNC). Но, возможно, эта тема разовьётся во что-то более интересное.
@avleonovrus #CISA #CISAKEV #Ransomware #RDP #FTP #TELNET #SMB #VNC
Прожектор по ИБ, выпуск №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
@avleonovrus #ПрожекторПоИБ #AuroraOS #LinuxPatchWednesday #IVADAY #БайтЭрг #Fplus #Cisco #CiscoIOSXE #VulnCheck #Mirai #JetBrains #TeamCity #Microsoft #GNOME #libcue #CISA #CISAKEV #Ransomware #ФСТЭК #FSTEC #Методика #CVSS #VMprocess #ПоИБэшечка
Мы это:
🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "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
@avleonovrus #ПрожекторПоИБ #AuroraOS #LinuxPatchWednesday #IVADAY #БайтЭрг #Fplus #Cisco #CiscoIOSXE #VulnCheck #Mirai #JetBrains #TeamCity #Microsoft #GNOME #libcue #CISA #CISAKEV #Ransomware #ФСТЭК #FSTEC #Методика #CVSS #VMprocess #ПоИБэшечка
YouTube
Прожектор по ИБ, выпуск №8 (22.10.2023): устройства на ОС Аврора для физиков и Linux узявимости
Записали очередной эпизод. Из основного: обсуждали Аврору ОС и отечественные смартфоны/планшеты, разобрали актуальные уязвимости с упором на Linux, немного коснулись регуляторики. К сожалению, у нас был какой-то сбой с видео, поэтому с 35:37 минуты мы без…
По случаю изучил прошлогодний CISA BOD 23-01 "Улучшение видимости активов и обнаружение уязвимостей в федеральных сетях". Собирался больше года назад, а возможность представилась только сейчас. Интересная тема с точки зрения контроля VM-процесса в организациях со стороны регулятора.
Допустим вы CISA, т.е. приблизительный американский аналог нашего ФСТЭКа. У вас есть подопечные - американские федеральные агентства. Их много, сложно даже сказать сколько. От 60 до 430+. Вы для них подсвечиваете критичные уязвимости в активной эксплуатации, по мере сил, устанавливаете к какому сроку их нужно фиксить. А с безопасностью и с уязвимостями у этих федералов всё равно полный швах. Что делать?
Безопасники CISA почесали голову и решили - давайте насаждать в федеральных агентствах базовые ИБ-процессы.
🔻 Во-первых, пусть ищут активы в своих сетках. Пофиг как. Хоть активным сканированием, хоть снифанием трафика, хоть через API какую. Главное регулярно, раз в неделю. Управление активами - это база.
🔻 Во-вторых, пусть эти активы сканируют на уязвимости. И чтобы не блекбоксом, а нормально, агентно или с привилегированной учёткой. Чтобы скан запускался каждые 2 недели со свежей базой детектов уязвимостей. Не успеваете всё просканить за 2 недели? А пофиг, всё равно запускайте следующий скан. Главное регулярность.
Тю? И всё? Просто рекомендации, выполнение которых никак не проверишь? 😏
Нет, не всё. 😈
🔻 В третьих, результаты сканирования активов требуют складывать в шайтан-поделье CDM Agency Dashboard не позже чем за 72 часа после завершения сканов на уязвимости. Откуда эти данные передаются в CDM Federal Dashboard для изучения аналитиками CISA. Также требуется скидывать "vulnerability enumeration performance data", т.е. по сути логи сканов, чтобы видно было насколько результаты сканирования адекватны.
Таким образом, регулятор очень оперативно видит состояние инфраструктуры органа/организаций, может самостоятельно делать выводы о выполнении требований по исправлению уязвимостей и проводить необходимые стимуляции. 🥕
Есть, конечно, и странности. Почему-то не написано напрямую, что инфу по обнаруженным активам тоже нужно CISA скидывать и что адекватность детектирования активов нужно подтверждать. Но, возможно, это подразумевается или добавят потом. Вообще документ прикольный, много тонких технических моментов разъясняется по-человечески.
Ещё в этом же документе есть тема, что агентства должны быть готовы по запросу CISA поискать у себя определенные активы или уязвимости, но эта ручка немножко про другое, как мне кажется.
@avleonovrus #CISA #BOD2301 #AssetManagement #VMprocess
Допустим вы CISA, т.е. приблизительный американский аналог нашего ФСТЭКа. У вас есть подопечные - американские федеральные агентства. Их много, сложно даже сказать сколько. От 60 до 430+. Вы для них подсвечиваете критичные уязвимости в активной эксплуатации, по мере сил, устанавливаете к какому сроку их нужно фиксить. А с безопасностью и с уязвимостями у этих федералов всё равно полный швах. Что делать?
Безопасники CISA почесали голову и решили - давайте насаждать в федеральных агентствах базовые ИБ-процессы.
🔻 Во-первых, пусть ищут активы в своих сетках. Пофиг как. Хоть активным сканированием, хоть снифанием трафика, хоть через API какую. Главное регулярно, раз в неделю. Управление активами - это база.
🔻 Во-вторых, пусть эти активы сканируют на уязвимости. И чтобы не блекбоксом, а нормально, агентно или с привилегированной учёткой. Чтобы скан запускался каждые 2 недели со свежей базой детектов уязвимостей. Не успеваете всё просканить за 2 недели? А пофиг, всё равно запускайте следующий скан. Главное регулярность.
Тю? И всё? Просто рекомендации, выполнение которых никак не проверишь? 😏
Нет, не всё. 😈
🔻 В третьих, результаты сканирования активов требуют складывать в шайтан-поделье CDM Agency Dashboard не позже чем за 72 часа после завершения сканов на уязвимости. Откуда эти данные передаются в CDM Federal Dashboard для изучения аналитиками CISA. Также требуется скидывать "vulnerability enumeration performance data", т.е. по сути логи сканов, чтобы видно было насколько результаты сканирования адекватны.
Таким образом, регулятор очень оперативно видит состояние инфраструктуры органа/организаций, может самостоятельно делать выводы о выполнении требований по исправлению уязвимостей и проводить необходимые стимуляции. 🥕
Есть, конечно, и странности. Почему-то не написано напрямую, что инфу по обнаруженным активам тоже нужно CISA скидывать и что адекватность детектирования активов нужно подтверждать. Но, возможно, это подразумевается или добавят потом. Вообще документ прикольный, много тонких технических моментов разъясняется по-человечески.
Ещё в этом же документе есть тема, что агентства должны быть готовы по запросу CISA поискать у себя определенные активы или уязвимости, но эта ручка немножко про другое, как мне кажется.
@avleonovrus #CISA #BOD2301 #AssetManagement #VMprocess
Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr. X
🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"
Перебрались для записи эпизода с ТГ на платформу VK Звонки. По-моему вполне удачно. В первый раз выходим в 1080p! 🙂 Это последний эпизод в этом году, следующий выпуск планируем записать уже в январе.
00:00 Здороваемся и смотрим статистику по предыдущему эпизоду
02:20 Злоумышленники получили доступ к корпоративным системам компании MongoDB
05:35 Декабрьский Linux Patch Wednesday
10:04 ФСТЭК России 50 лет
12:32 CISA BOD 23-01 и аналогичные инициативы отечественных регуляторов
20:41 Презентация POCA Мобайл и Р-ФОН
26:29 Ежегодная предновогодняя Поибешечка
32:12 Хакер, который участвовал во взломе Rockstar Games, останется в закрытой клинике до конца жизни
37:32 Сериал "Слово пацана"
40:27 Производитель косметики EOS выпустил кодовый замок для своего лосьона, чтобы мужчины не могли пользоваться им
44:56 Правительство займётся безопасностью видеоигр
48:22 Запрет на использование телeфонов в школе
51:22 В Санкт-Петербурге проведены аресты по делу о телефонном мошенничестве
53:20 Так совпало - Гарвард и ГРЧЦ Роскомнадзора поделились своими взглядами на развитие ИИ в 2024-м году
59:24 DevSecOps Maturity Model 2023
1:01:25 Прощание в стихах от Mr. X
@avleonovrus #ПрожекторПоИБ #MongoDB #MongoDBAtlas #LinuxPatchWednesday #Vulristics #ФСТЭК #FSTEC #BDU #CISA #BOD2301 #AssetManagement #VMprocess #ROSA #ROSAMobile #AuroraOS #ОМП #РФОН #RUTEQ #Поибешечка #Rockstar #СловоПацана #EOS #videogames #smartphone #ГРЧЦ #Роскомнадзор #DevSecOps
🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"
Перебрались для записи эпизода с ТГ на платформу VK Звонки. По-моему вполне удачно. В первый раз выходим в 1080p! 🙂 Это последний эпизод в этом году, следующий выпуск планируем записать уже в январе.
00:00 Здороваемся и смотрим статистику по предыдущему эпизоду
02:20 Злоумышленники получили доступ к корпоративным системам компании MongoDB
05:35 Декабрьский Linux Patch Wednesday
10:04 ФСТЭК России 50 лет
12:32 CISA BOD 23-01 и аналогичные инициативы отечественных регуляторов
20:41 Презентация POCA Мобайл и Р-ФОН
26:29 Ежегодная предновогодняя Поибешечка
32:12 Хакер, который участвовал во взломе Rockstar Games, останется в закрытой клинике до конца жизни
37:32 Сериал "Слово пацана"
40:27 Производитель косметики EOS выпустил кодовый замок для своего лосьона, чтобы мужчины не могли пользоваться им
44:56 Правительство займётся безопасностью видеоигр
48:22 Запрет на использование телeфонов в школе
51:22 В Санкт-Петербурге проведены аресты по делу о телефонном мошенничестве
53:20 Так совпало - Гарвард и ГРЧЦ Роскомнадзора поделились своими взглядами на развитие ИИ в 2024-м году
59:24 DevSecOps Maturity Model 2023
1:01:25 Прощание в стихах от Mr. X
@avleonovrus #ПрожекторПоИБ #MongoDB #MongoDBAtlas #LinuxPatchWednesday #Vulristics #ФСТЭК #FSTEC #BDU #CISA #BOD2301 #AssetManagement #VMprocess #ROSA #ROSAMobile #AuroraOS #ОМП #РФОН #RUTEQ #Поибешечка #Rockstar #СловоПацана #EOS #videogames #smartphone #ГРЧЦ #Роскомнадзор #DevSecOps
YouTube
Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr. X
🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"
Перебрались для записи эпизода с ТГ на платформу VK Звонки. По-моему вполне удачно. В первый раз выходим в 1080p! 🙂 Это последний…
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"
Перебрались для записи эпизода с ТГ на платформу VK Звонки. По-моему вполне удачно. В первый раз выходим в 1080p! 🙂 Это последний…
В последнем прожекторе по ИБ мы говорили, что недавняя SSRF уязвимость (а фактически обход аутентификации) в Ivanti Connect Secure (CVE-2024-21893) эксплуатируется в таргетированных атаках - УЖЕ НЕ ТОЛЬКО. 🙂 Пошли массовые атаки. Этому поспособствовала публикация PoC-а исследователями из Rapid7. 🤷♂️ Shadowserver сообщает о 170 засветившихся атакующих IP.
Требование CISA от 31 января поотключать эти инстансы в двухдневный срок выглядит теперь более чем мудро. Правда они рекомендовали отключить их для полного ресета, обновления и возврата в эксплуатацию, а надо было бы отключить совсем. Потому что проклятье Ivanti однозначно есть. 🧙♀️
С интересом наблюдаю за развитием событий. 🙂🍿
@avleonovrus #Ivanti #SSRF #Rapid7 #Vulristics #CISA
Требование CISA от 31 января поотключать эти инстансы в двухдневный срок выглядит теперь более чем мудро. Правда они рекомендовали отключить их для полного ресета, обновления и возврата в эксплуатацию, а надо было бы отключить совсем. Потому что проклятье Ivanti однозначно есть. 🧙♀️
С интересом наблюдаю за развитием событий. 🙂🍿
@avleonovrus #Ivanti #SSRF #Rapid7 #Vulristics #CISA
RCE-уязвимость в Fortinet FortiOS и FortiProxy (CVE-2024-21762) эксплуатируется вживую. Неаутентифицированный злоумышленник может удалённо выполнять произвольный код с использованием вредоносных HTTP-запросов. В качестве воркэраунда можно отключить SSL VPN на уязвимых устройствах. Публичного эксплоита пока нет.
Если у вас по каким-то причинам всё ещё используются фортики, то нужно оперативно патчиться. На днях CISA выпустили подробный отчёт об использовании похожей RCE уязвимости FortiOS SSL-VPN (CVE-2022-42475) в атаках группировки Volt Typhoon. Также Tenable выпустили подборку из 6 CVE уязвимостей FortiOS разных лет используемых в реальных атаках.
Кроме CVE-2024-21762, также вышли фиксы для менее критичных уязвимостей FortiOS: CVE-2024-23113 (Format String Vulnerability), CVE-2023-47537 (Improper Certificate Validation), CVE-2023-44487 (против атаки HTTP/2 Rapid Reset)
@avleonovrus #Vulristics #Fortinet #FortiOS #FortiProxy #VoltTyphoon #CISA #Tenable
Если у вас по каким-то причинам всё ещё используются фортики, то нужно оперативно патчиться. На днях CISA выпустили подробный отчёт об использовании похожей RCE уязвимости FortiOS SSL-VPN (CVE-2022-42475) в атаках группировки Volt Typhoon. Также Tenable выпустили подборку из 6 CVE уязвимостей FortiOS разных лет используемых в реальных атаках.
Кроме CVE-2024-21762, также вышли фиксы для менее критичных уязвимостей FortiOS: CVE-2024-23113 (Format String Vulnerability), CVE-2023-47537 (Improper Certificate Validation), CVE-2023-44487 (против атаки HTTP/2 Rapid Reset)
@avleonovrus #Vulristics #Fortinet #FortiOS #FortiProxy #VoltTyphoon #CISA #Tenable
Встроенный вредоносный код был обнаружен в XZ Utils версий 5.6.0 и 5.6.1 (CVE-2024-3094). XZ Utils - это набор утилит-архиваторов, который может присутствовать в дистрибутивах Linux. Вредоносный код может обеспечить несанкционированный доступ к затронутым системам. 🤷♂️ Норм так ушли на выходные называется. 😅
CISA рекомендует откатываться на 5.4.6 Stable.
Проверил на своей Ubuntu 23.10, что xz-utils здесь древнючие, версии 5.4.1-0.2. Живём. 🙂 RHEL-ы тоже не задеты.
Стоит ли такие инциденты заводить как CVE? Наверное всё же да. Потому что "Common Vulnerabilities and Exposures". Может это и не уязвимость, но точно экспозиция.
Интересно сколько подобных бэкдоров остаются незамеченными... 🙄
@avleonovrus #XZUtils #backdoor #CISA #liblzma
CISA рекомендует откатываться на 5.4.6 Stable.
Проверил на своей Ubuntu 23.10, что xz-utils здесь древнючие, версии 5.4.1-0.2. Живём. 🙂 RHEL-ы тоже не задеты.
Стоит ли такие инциденты заводить как CVE? Наверное всё же да. Потому что "Common Vulnerabilities and Exposures". Может это и не уязвимость, но точно экспозиция.
Интересно сколько подобных бэкдоров остаются незамеченными... 🙄
@avleonovrus #XZUtils #backdoor #CISA #liblzma
Прочитал прикольный FAQ от Tenable про бэкдор в XZ Utils (CVE-2024-3094).
"По мнению Red Hat, вредоносный код изменяет функции кода liblzma, который является частью пакета XZ Utils. Этот модифицированный код затем может использоваться любым программным обеспечением, связанным с библиотекой XZ, и позволяет перехватывать и изменять данные, используемые с библиотекой. В примере, рассмотренном Фройндом [исследователь, который нашёл бэкдор], при определенных условиях этот бэкдор может позволить злоумышленнику «нарушить аутентификацию sshd», позволяя злоумышленнику получить доступ к уязвимой системе." 😱
Пока известно, что эти дистрибы точно уязвимы:
🔻 Fedora Rawhide
🔻 Fedora 41
🔻 Debian testing, unstable and experimental distributions versions 5.5.1alpha-0.1 to 5.6.1-1.
А эти точно неуязвимы:
🔹 Fedora Linux 40
🔹 Red Hat Enterprise Linux (RHEL)
🔹 Debian Stable
Ссылка на исходное сообщение исследователя.
@avleonovrus #Tenable #XZUtils #backdoor #CISA #liblzma
"По мнению Red Hat, вредоносный код изменяет функции кода liblzma, который является частью пакета XZ Utils. Этот модифицированный код затем может использоваться любым программным обеспечением, связанным с библиотекой XZ, и позволяет перехватывать и изменять данные, используемые с библиотекой. В примере, рассмотренном Фройндом [исследователь, который нашёл бэкдор], при определенных условиях этот бэкдор может позволить злоумышленнику «нарушить аутентификацию sshd», позволяя злоумышленнику получить доступ к уязвимой системе." 😱
Пока известно, что эти дистрибы точно уязвимы:
🔻 Fedora Rawhide
🔻 Fedora 41
🔻 Debian testing, unstable and experimental distributions versions 5.5.1alpha-0.1 to 5.6.1-1.
А эти точно неуязвимы:
🔹 Fedora Linux 40
🔹 Red Hat Enterprise Linux (RHEL)
🔹 Debian Stable
Ссылка на исходное сообщение исследователя.
@avleonovrus #Tenable #XZUtils #backdoor #CISA #liblzma
Курьёзней трендовой январской уязвимости в GitLab, позволяющей восстанавливать пароль от аккаунта на левый email (CVE-2023-7028), только то, что в CISA заметили признаки активной эксплуатации этой уязвимости через 3,5 месяца после её публикации и появления тривиального эксплоита. 🐢 Если верить Shadowserver, то сейчас в России больше всего в мире уязвимых GitLab хостов доступных из Интернет (367). На втором месте США (356), а далее Китай (350).
@avleonovrus #CISA #GitLab #CISAKEV #Shadowserver
@avleonovrus #CISA #GitLab #CISAKEV #Shadowserver
Американцы выпустили joint Cybersecurity Advisory (CISA, FBI, HHS, MS-ISAC) против шифровальщика Black Basta. Утверждается, что по состоянию на май 2024, от Black Basta пострадали более 500 организаций по всему миру, включая бизнесы и критическую инфраструктуру в Северной Америке, Австралии и Европе. Затронуто 12 из 16 секторов критической инфраструктуры.
Шифровальщик впервые замечен в апреле 2022 года. Первоначальное заражение выполняет с помощью фишинга или эксплуатацией февральской уязвимости обхода аутентификации в ConnectWise ScreenConnect (CVE-2024-1709).
Инструментарий для подъема привилегии и горизонтального перемещения: Mimikatz и эксплуатация уязвимостей ZeroLogon (CVE-2020-1472), NoPac (CVE-2021-42278, CVE-2021-42287), PrintNightmare (CVE-2021-34527). Исправления уязвимостей были доступны годами, но в организациях их не применяли. 🤷♂️ Возможно надеялись, что периметр никогда не проломят. Вышло иначе. 😏
@avleonovrus #BlackBasta #Mimikatz #ZeroLogon #NoPac #PrintNightmare #CISA #StopRansomware
Шифровальщик впервые замечен в апреле 2022 года. Первоначальное заражение выполняет с помощью фишинга или эксплуатацией февральской уязвимости обхода аутентификации в ConnectWise ScreenConnect (CVE-2024-1709).
Инструментарий для подъема привилегии и горизонтального перемещения: Mimikatz и эксплуатация уязвимостей ZeroLogon (CVE-2020-1472), NoPac (CVE-2021-42278, CVE-2021-42287), PrintNightmare (CVE-2021-34527). Исправления уязвимостей были доступны годами, но в организациях их не применяли. 🤷♂️ Возможно надеялись, что периметр никогда не проломят. Вышло иначе. 😏
@avleonovrus #BlackBasta #Mimikatz #ZeroLogon #NoPac #PrintNightmare #CISA #StopRansomware