И снова уязвимость, которую не подсветил вообще никто из VM-вендоров, но для которой внезапно появляется два публичных PoC-а на гитхабе от известного исследователя (Filip Dragovic, #Wh04m1001). Elevation of Privilege - Windows Backup Service (CVE-2023-21752). Первый PoC любой файл может удалить, второй запускает shell с поднятыми привилегиями.
А то, что VM-вендоры подсвечивают как правило так и остается неэксплуатабельным. 🤷♂️
Выпустил эпизод про поддержку двух API в Scanvus. Потестил сканирование локалхоста, удаленного хоста по SSH и Docker образа. Все работает, но при сравнении результатов есть серьезные расхождения. До конкретных причин я в этом эпизоде на докапывался. Однако это в очередной раз подтверждает, что обнаружение уязвимостей не такое просто дело, и хорошо, когда можно использовать несколько независимых механизмов обнаружения и сравнивать результаты. 😉
Отличные новости по моему опенсурсному проекту Scanvus! Теперь вы можете проводить проверки на уязвимости Linux хостов и докер-образов не только с помощью API от Vulners.com, но и с помощью аналогичного API от Vulns.io. Особенно приятно, что весь код для поддержки нового API коллеги из Vulns.io написали и законтрибьютили сами. Оставалось только потестить, что все работает. За это им огромное спасибо!
Чем может быть полезна поддержка двух API детекта уязвимостей в Scanvus?
1. Нет привязки к одному вендору, выбирайте чьи условия вам нравятся больше.
2. Набор поддерживаемых ОС у Vulners.com и Vulns.io различается. Если какой-то Linux дистрибутив не поддерживается у одних, он может поддерживаться у других.
3. Реализации проверок независимые. Если при сканировании одного и того же хоста/образа результаты будут различаться, то будут наглядно видны ошибки/особенности реализации.
4. Scanvus выпускается под лицензией MIT, поэтому вы можете использовать его как пример работы с API Vulners.com и Vulns.io и использовать этот код в своих проектах.
Что дальше?
В настоящий момент поддержка API Vulners.com и Vulns.io реализована в равной степени, но она реализована независимо. Скрипты инвентаризации на bash для каждого из API различаются. Также используются 2 независимые функции репортинга. Скрипты для инвентаризации видится правильным унифицировать, чтобы эти результаты инвентаризации можно было бы проверить и с помощью Vulners.com и Vulns.io. Также напрашивается создание единого формата представления результатов детектирования, к которому можно будет приводить сырые результаты от API, и который можно будет использовать для построения отчетов и дальнейших интеграций. Кажется, что на примере работы Vulners.com и Vulns.io можно отладить схему добавления новых API в Scanvus.
LastPass наконец подтвердили, что у них слили хранилище паролей. Ну надо же. Всё, что я об этом думаю я в сентябре расписал, все ещё актуально. LastPass и другие навороченные менеджеры паролей не нужны и опасны. Не используйте их. Лучше используйте что-нибудь открытое, локальное и примитивное. То, что можно глазами просмотреть и проконтролировать как оно на самом деле работает. Например мой Barapass.
Приоритизация уязвимостей это вещь ненадежная. В сентябрьском Microsoft Patch Tuesday была Information Disclosure уязвимость в компоненте согласования механизма аутентификации #SPNEGO Extended Negotiation (#NEGOEX) Security Mechanism (CVE-2022-37958). Ни один из VM вендоров не обратил на неё внимание.
13 декабря известная исследовательница из #IBM Security X-Force, Valentina Palmiotti, выложила видео с эксплуатацией этой уязвимости как Remote Code Execution. На видео в Linux виртуалке выполняется python скрипт, на виртуалке с Windows 10 появляется ошибка "Your PC will automatically restart in one minute".
Уязвимость может быть проэксплуатирована при попытке аутентификации по #RDP и #SMB. Возможно по #SMTP, #HTTP и т.д. при нестандартной конфигурации. Т.е. может быть хуже, чем #EternalBlue.
Microsoft внесла изменения в описание уязвимости. Теперь это Critical RCE. NVD естественно тормозит.
IBM опубликуют подробности только в Q2 2023, чтобы дать время на патчинг.
Прочитал "Методику оценки уровня критичности уязвимостей программных, программно-аппаратных средств"
Кто-то может подумать из названия, что это наверное про CVSS. И будет отчасти прав. CVSS v3.0/3.1 это один из компонентов итоговой цифири. Причем не только Base Score. "Итоговый показатель I cvss определяется совокупностью показателей базовых, временных и контекстных метрик применительно к конкретной информационной системе". И все кроме базовых придется накликивать самим. Даже этого было бы достаточно для веселья. Но…
Есть ещё второй компонент "характеризующий влияние уязвимости … на функционирование информационной системы". 🙂 Там про тип уязвимого актива, массовость уязвимости, доступность через Интернет.
В зависимости от итогового значения выдвигаются требования по оперативности исправления. И там есть связь со вторым документом про тестирование обновлений:
"3.4. В случае если уязвимости содержатся в зарубежных программных, программно-аппаратных средствах или программном обеспечении с открытым исходным кодом, решение об установке обновления такого программного обеспечения, программно-аппаратного средства принимается оператором информационной системы с учетом результатов тестирования этого обновления, проведенного в соответствии с Методикой тестирования обновлений безопасности программных, программно-аппаратных средств, утвержденной ФСТЭК России от 28 октября 2022 г., и оценки ущерба от нарушения функционирования информационной системы по результатам установки обновления."
А уж какое там веселье. Ммм… 🙂 Но это как-нибудь в следующий раз.
Какие впечатления:
1. Методика это хорошо. Стандартизация от регулятора должна быть. Описано все просто и понятно.
2. Дополнительные критерии помимо CVSS это хорошо, критерии связанные с инфраструктурой выглядят в целом адекватно.
3. Не увидел учета такого важнейшего фактора как признак Exploitation in the wild. Когда я делаю приоритизацию с помощью своего проекта Vulristics наличие публичного эксплоита и признаков эксплуатации вживую играет наибольшую роль. Если наличие эксплоита ещё как-то учитывается (но кажется недостаточно) в CVSS Temporal Metrics, то эксплуатация вживую не отражена совсем. Кстати, давно уже пора делать наш аналог CISA Known Exploited Vulnerabilities Catalog.
4. Не увидел учет типа уязвимости. Когда я приоритизирую в Vulristics тип уязвимости также играет важную роль. Можно сказать, что тип уязвимости опосредованно учитывается в CVSS, но кажется этого также недостаточно.
5. Хочется надеяться, что тестирование обновлений зарубежного ПО и опенсурса мы все же будем не сами делать, а это отсылка к тому самому конкурсу. Так ведь? Да? 🧐
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.