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. Хочется надеяться, что тестирование обновлений зарубежного ПО и опенсурса мы все же будем не сами делать, а это отсылка к тому самому конкурсу. Так ведь? Да? 🧐
Давайте посмотрим на сентябрьский Microsoft Patch Tuesday. В этот раз компактненько. Всего 63 уязвимости. С учетом уязвимостей вышедших между августовским и сентябрьским Patch Tuesday (как обычно, в Microsoft Edge), получается 90. Весьма и весьма немного.
1. Уязвимостей с публичными эксплоитами пока нет. Есть 3 уязвимости для которых существует Proof-of-Concept Exploit по данным из CVSS
Elevation of Privilege - Kerberos (CVE-2022-33679)
Elevation of Privilege - Azure Guest Configuration and Azure Arc-enabled servers (CVE-2022-38007)
Elevation of Privilege - Windows GDI (CVE-2022-34729)
Но вероятность, что это докрутят до боевого состояния невысока.
2. Есть 3 уязвимости с признаком эксплуатации вживую
Elevation of Privilege - Windows Common Log File System Driver (CVE-2022-37969). Можно поднять права до SYSTEM. Затрагивает массу версий Windows, есть патчи даже под EOL операционки. Кроме этой уязвимости был пучок виндовых EoP-шек без признаков эксплуатации, например Elevation of Privilege - Windows Kernel (CVE-2022-37956, CVE-2022-37957, CVE-2022-37964)
Security Feature Bypass - Microsoft Edge (CVE-2022-2856, CVE-2022-3075). Уязвимости Edge это по факту уязвимости Chromium. Обратная сторона использования одного и того же движка. Уязвимости Chrome аффектят также Edge, Opera, Brave, Vivaldi и прочее.
3. RCE от посланного IP пакета 😱
Remote Code Execution - Windows TCP/IP (CVE-2022-34718). "An unauthorized attacker can use it to execute arbitrary code on the attacked Windows computer with the IPSec service enabled by sending a specially crafted IPv6 packet to it. This vulnerability can only be exploited against systems with Internet Protocol Security (IPsec) enabled." IPsec и IPv6 зло, лол. 🙂 Но если серьезно, то скверно, что такое вообще бывает.
И это ещё не все, есть ещё Remote Code Execution - Windows Internet Key Exchange (IKE) Protocol Extensions (CVE-2022-34721, CVE-2022-34722). "An unauthenticated attacker could send a specially crafted IP packet to a target machine that is running Windows and has IPSec enabled, which could enable a remote code execution exploitation."
4. Denial of Service - Windows DNS Server (CVE-2022-34724). С одной стороны только DoS, с другой стороны работу компании можно неплохо так парализовать.
5. Memory Corruption - ARM processor (CVE-2022-23960). Фикс для очередного Spectre, на этот раз Spectre-BHB. Про практическую эксплуатабельность видимо говорить не приходится, так же как и в случае остальных уязвимостей типа Spectre, но практически все обзорщики на эту уязвимость внимание обратили.
Полный отчет Vulristics: https://avleonov.com/vulristics_reports/ms_patch_tuesday_september2022_report_with_comments_ext_img.html
Сделал блогпост и видяшку про мой опенсурсный проект Scanvus. Проекту уже год и я этой утилитой практически каждый день пользуюсь. Но вот только сейчас дошли руки нормально попиарить это дело.
Scanvus (Simple Credentialed Authenticated Network VUlnerability Scanner) это сканер уязвимостей для Linux. Задача у него получить список пакетов и версию Linux дистрибутива, сделать запрос к внешнему API для получения уязвимостей (в данный момент только Vulners Linux API поддерживается) и отобразить продетектированные уязвимости в репорте.
Scanvus может показать уязвимости для
- локалхоста
- удаленного хоста по SSH
- docker-образа
- файла c инвентаризацией
Такая простенькая утилита, которая сильно упрощает жизнь при аудитах линуксовой инфраструктуры. Ну и кроме того это проект в рамках которого я могу реализовывать свои идеи по сканированию на уязвимости.
В эпизоде разбираю содержание отчета, как поставить и настроить утилиту, режимы сканирования, ну и размышляю о том можно сделать Scanvus совсем бесплатным (сейчас это интерфейс к платному Vulners Linux API).
Video: https://youtu.be/GOQEqdNBSOY
Video2 (for Russia): https://vk.com/video-149273431_456239100
Blogpost: https://avleonov.com/2022/09/17/scanvus---my-open-source-vulnerability-scanner-for-linux-hosts-and-docker-images/
Github: https://github.com/leonov-av/scanvus
Там в очередной раз то ли поломали, то ли не поломали LastPass. Поэтому не грех поворчать про менеджеры паролей. Менеджер паролей штука безусловно полезная, поскольку позволяет использовать пароли достаточной длины и сложности. Однако, к популярным, даже среди безопасников, менеджерам паролей есть вопросики.
1. Это странно, если менеджер паролей проприетарный, т.к. непонятно как фактически пароли хранятся и нет ли там бекдора/универсального ключа/тайного способа делать перебор мастер-пароля очень быстро. Если инструмент популярный и понятно кто его разрабатывает и где этот кто-то живет, то в отсутствие этого всего поверить тем более сложновато.
2. Это странно, когда менеджер паролей опенсурсный, но настолько навороченный, что просмотреть его код глазами за разумное время невозможно. Чем больше сложного кода, тем выше вероятность, что там что-то есть из п.1
3. Это странно, когда менеджер паролей хранит какие-то данные в облаке вендора.
Лично я пользуюсь своим проектом Barapass, который накидал года 2 назад (подробнее в блоге 1,2). Консольный. Работает в Windows, Linux, MacOS. Команд минимум: расшифровать и использовать файлик, искать параметр в файле с последовательным копированием найденных значений в буфер, расшифровать файл в текстовый для редактирования, зашифровать текстовый файл. Честно скажу, редактировать и добавлять новые параметры не особо удобно, но в остальном вполне норм.
По умолчанию шифруется AES-ом, но можно вообще любую комбинацию из алгоритмов накинуть, хоть американских, хоть российских, хоть китайских, хоть каких. Комбинировать даже предпочтительно, т.к. вероятность того, что кто-то возьмется восстанавливать файл честно зашифрованный AES-ом и так-то не высока, а уж в вашей личной матрешке разбираться так и точно будут себе дороже. Проще расшифрованный пароль в буфере или в памяти незаметно поймать. Ну или использовать более грубые методы, от которых менеджеры паролей не защитят. 🙂
Записал традиционный расширенный вариант отчета по августовскому Patch Tuesday. Кратко и на русском было здесь.
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.