DARPA запускает двухлетний конкурс AI Cyber Challenge (AIxCC) на лучшую автоматическую систему для детектирования и исправления уязвимостей в исходном коде. Участвовать в этом не советую, но формат мероприятия интересный. Возможно что-то подобное могли бы организовать в Минцифре или Сколково.
Вот так и кидайся обновлять Exchange сразу после Microsoft Patch Tuesday. Оказалось, что обновления ломают неанглоязычные инсталляции Exchange, например немецкие. 🤷♂️ На MS-ных страницах уязвимостей рекомендуют пока не обновлять такие инсталляции и применять workaround.
Первые впечатления от августовского Microsoft Patch Tuesday. Пока ни о чём. 🫠
Формально наиболее критичная Denial of Service - .NET and Visual Studio (CVE-2023-38180), потому что есть признаки эксплуатации. Подробностей нет, но согласитесь, что как-то сомнительно. 🤡
Больше ничего нет с эксплоитами или признаками эксплуатации.
Есть несколько Remote Code Execution - Microsoft Exchange (CVE-2023-35368, CVE-2023-38185, CVE-2023-35388, CVE-2023-38182). 3 из них точно аутентификации требуют, по одной непонятно. Эту аутентификацию можно потенциально получить через Elevation of Privilege - Microsoft Exchange (CVE-2023-21709) - "This vulnerability allows a remote, unauthenticated attacker to log in as another user". Лучше обновиться.
Remote Code Execution - Microsoft Teams (CVE-2023-29328, CVE-2023-29330). Но в наших широтах вроде его перестали использовать.
Ещё есть пачка EoP в ядре и компонентах Windows.
Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч? Подсмотрел занимательный вопрос в канале Алексея Лукацкого.
С одной стороны, ответ вроде и очевиден. CVE-шки заводят в основном на уязвимости в продуктах, разные версии которых могут находиться в эксплуатации у пользователей. А в скоуп багбаунти попадают в основном самописные веб-приложения доступные из Интернет, так что пользователи в любой момент времени пользуются определенной версией веб-приложения. В этом случае фикс уязвимости решает проблему сразу и полностью для всех пользователей веб-приложения и пользы от CVE-идентификатора в этом случае не будет.
С другой стороны, есть мобильные приложения, которые тоже часто попадают в скоуп багбаунти. А у мобильного приложения уже есть версия и пользователи могут использовать разные версии мобильного приложения. И, получается, для мобильных приложений уже может быть смысл заводить CVE.
В принципе, ничего не мешает сделать багбаунти программу вообще для любых приложений. Например, на hackerone есть багбаунти для Chrome/Chromium. И для этих уязвимостей Google заводит CVE. Ничего не запрещает самому вендору заводить CVE под найденные в рамках багбаунти уязвимости кроме нежелания этого вендора.
И не сказать, что это требует каких-то особенных усилий со стороны вендора, т.к. сама багбаунти платформа может заводить CVE уязвимости для своих клиентов. В списке CVE Numbering Authority (CNA) есть 11 организаций типа "Bug Bounty Provider", включая Bugcrowd, HackerOne, ZDI:
"Provides CVE IDs for its customers as part of its bug bounty and vulnerability coordination platform"
В общем, уязвимостей меньше, потому что не для всех уязвимостей есть смысл заводить CVE. А для тех уязвимостей, для которых смысл есть, CVE идентификаторы не заводят, т.к. сам вендор уязвимого продукта этого не хочет. 🤷♂️ А сам исследователь хоть и может добиться заведения CVE идентификатора помимо воли вендора, но это не массовая история.
PS: хороший вопрос для собеседования VM-щиков 😉
Как обучать Vulnerability Management-у? Мне предложили поучаствовать в записи онлайн-курса переподготовки по ИБ для МГТУ им. Н.Э. Баумана в части VM-а. 🎓
Аудитория: слушатели курсов по профессиональной переподготовке и студенты ИБ-шники
Дедлайн: конец августа
Фронт работ: 3 ролика по 20-25 минут
Темы:
🔹 Анализ защищённости
🔹 Управление уязвимостями
🔹 Управление обновлениями
Объем небольшой, но можно сделать первый подход к полноценному семестровому курсу.
Пока у меня задумка такая:
1. Видео по анализу защищённости хочу посвятить тому, что такое уязвимости и техническим способам детектирования уязвимостей. Простые виды веб-уязвимостей продемонстрирую на своём старом проекте уязвимого приложения. Сканирование в режиме "чёрного ящика" рассмотрим на примере cpe-детектов в nmap с Vulners плагином. Для Linux уязвимостей (включая Docker-образы) рассмотрим бюллетени безопасности и SCAP-контент. Для Windows уязвимостей рассмотрим Patch Tuesday и поговорим о KB-шках. Цель - показать как работают сканеры уязвимостей, подсвятить какие там есть проблемы и сложности.
2. Видео по управлению уязвимостями планирую построить на той идее, что управление уязвимостями это не только их детектирование, а комплексный процесс, который должен быть выстроен в организации. Оттолкнемся от руководства ФСТЭК по организации VM-процесса. Разберем способы приоритизации уязвимостей (также на примере методики ФСТЭК). Коснёмся основных метрик, за которыми следует следить: покрытие хостов в инфраструктуре VM-процессом, выполнение SLA по исправлению уязвимостей. Поговорим о Vulnerability Intelligence и о том, что делать, когда для уязвимости нет автоматизированных детектов.
3. Видео по управлению обновлениями хочу построить вокруг идеи, что уязвимостей очень много, разбираться с каждой по отдельности накладно, а выход в том, чтобы договариваться с IT-шниками о процессе регулярного безусловного обновления систем. Это позволит VM-щикам избавиться от рутины и уделять больше времени наиболее критичным трендовым уязвимостям и уязвимостям, которые простым обновлением не фиксятся. Здесь хотелось сформулировать лучшие практики по общению с IT: распространенные уловки и способы их обойти, методы эскалации, идеи по метрикам/презентациям для руководства и т.п. Здесь же коснемся требований ФСТЭК по контролю безопасности обновлений и, как следствие, необходимости скорейшего импортозамещения IT-систем.
Собираю комментарии и пожелания в посте в ВК. 😉
Англосаксонские госбезопасники из 5 стран выпустили совместный отчёт "2022's Top Routinely Exploited Vulnerabilities". Т.е. ТОП повседневно эксплуатируемых уязвимостей за прошлый год. Я взял этот отчёт, выписал упоминания CVEшек и выпустил 2 отчёта Vulristics:
1. TOP 12 уязвимостей
2. Расширенный со всеми уязвимостями (42) из отчёта
В Топе на 12 уязвимостей у всех CVE есть ссылки на эксплоиты и признак эксплуатации in the wild. Все Urgent, кроме одной, т.к. она EoP и в не самом распространенном софте Workspace One. В самые критичные попали RCE в Apache Log4j2, Microsoft Exchange и Confluence.
В расширенном отчёте все CVE с признаками эксплуатации in the wild, но есть 6 уязвимостей без ссылок на эксплоиты и поэтому в критичности Critical/High. В самые критичные попали RCE в Apache HTTP Server, Apache Log4j2, Windows RDP, Microsoft Exchange.
По сравнению с прошлогодним отчётом, ушёл GitLab и экзотика типа Hikvision и Buffalo. Подборочка стала выглядеть поадекватнее.
Команды для тех, кто сам хочет построить отчет в Vulristics по комментам для CVE-шек из AA23-215A.
$ cat AA23-215A_comments.txt | grep -v "30 Additional" | egrep -o "CVE-[0-9]*-[0-9]*" | sort | uniq > AA23-215A_cves_top12.txt
$ cat AA23-215A_comments.txt | egrep -o "CVE-[0-9]*-[0-9]*" | sort | uniq > AA23-215A_cves.txt
$ python3 vulristics.py --report-type "cve_list" --cve-project-name "AA23-215A" --cve-list-path "AA23-215A_cves.txt" --cve-comments-path "AA23-215A_comments.txt" --cve-data-sources "ms,nvd,epss,vulners,attackerkb" --rewrite-flag "True"
$ python3 vulristics.py --report-type "cve_list" --cve-project-name "AA23-215A_top12" --cve-list-path "AA23-215A_cves_top12.txt" --cve-comments-path "AA23-215A_comments.txt" --cve-data-sources "ms,nvd,epss,vulners,attackerkb" --rewrite-flag "False"
Забавная подробность: 8 агентств из 5 стран выпустили, а не нашлось никого, кто бы внимательно прочитал и обратил внимание, что у них в нескольких местах идентификатор для Log4Shell написан как "CVE-2021- 44228" с пробелом. Причём как в pdf, так и в web-версии. 😏
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.