Архив рубрики: Темы

Эксплойт из GitHub-а, как правило, со временем попадает в специализированный сплойт-пак, НО НЕ ВСЕГДА!

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

Эксплойт из GitHub-а, как правило, со временем попадает в специализированный сплойт-пак, НО НЕ ВСЕГДА! Эксплойт из GitHub-а, как правило, со временем попадает в специализированный сплойт-пак, НО НЕ ВСЕГДА! Эксплойт из GitHub-а, как правило, со временем попадает в специализированный сплойт-пак, НО НЕ ВСЕГДА!

Эксплойт из GitHub-а, как правило, со временем попадает в специализированный сплойт-пак, НО НЕ ВСЕГДА!

Вот, например, Command Injection - SAP NetWeaver (CVE-2022-22536), которая также входит в недавний расширенный англосаксонский список. Видим, что для этой уязвимости эксплойты есть только на гитхабе. И, судя по описанию, они валидные. А если мы выпустим отчёт Vulristics с --vulners-use-github-exploits-flag "False", то мы эту информацию потеряем. Так что имейте в виду и используйте опцию с осторожностью. 😉

Кстати, про Zerologon (CVE-2020-1472)

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

Кстати, про Zerologon (CVE-2020-1472)

Кстати, про Zerologon (CVE-2020-1472). На днях R-Vision выложили на Хабре подробную статью про эту уязвимость.

Уязвимость старенькая, но всё ещё актуальная, в недавний расширенный список англосаксов входит.

"Она позволяет злоумышленникам изменить пароль компьютерной учетной записи контроллера домена и получить доступ к содержимому Active Directory.

Эксплуатация Zerologon возможна на следующих не пропатченных версиях Windows Server: 2008 R2, 2012, 2012R2, 2016, 2019. В версии Windows Server 2022 уязвимость уже исправлена. Для реализации атаки достаточно наличия сетевой связности с устройства, к которому имеет доступ атакующий, до уязвимого контроллера домена."

В отчёте Vulristics уязвимость абсолютно топовая. Единственное что снижает критичность это тип - EoP, но в контексте контроллера домена это, конечно, совсем другая история. 😏

Я добавил возможность исключать ссылки на GitHub в отчётах Vulristics

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

Я добавил возможность исключать ссылки на GitHub в отчётах Vulristics
Я добавил возможность исключать ссылки на GitHub в отчётах Vulristics

Я добавил возможность исключать ссылки на GitHub в отчётах Vulristics. Для "громких" уязвимостей, например для Zerologon (CVE-2020-1472), в отчёте бывает слишком много ссылок на GitHub, большая часть из которых с эксплойтами не связана. А автоматически понять где репозитарии с эксплойтом, а где какая-то нерелевантная ерунда, весьма сложно. Да и, как правило, не особо и нужно. Реально работающий эксплойт скорее всего попадёт в специализированные сплойт-паки, хоть и с некоторой задержкой.

Поэтому, думаю у пользователей Vulristics должна быть возможность выпустить и отчёт, содержащий максимум информации по эксплойтам (пусть и несколько замусоренный), и отчёт только с учётом сплойт-паков.

Я добавил параметр --vulners-use-github-exploits-flag, который может принимать значение либо True либо False. По умолчанию значение True.

Также добавил [источник] ссылки.

DARPA запускает двухлетний конкурс AI Cyber Challenge (AIxCC) на лучшую автоматическую систему для детектирования и исправления уязвимостей в исходном коде

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

DARPA запускает двухлетний конкурс AI Cyber Challenge (AIxCC) на лучшую автоматическую систему для детектирования и исправления уязвимостей в исходном коде

DARPA запускает двухлетний конкурс AI Cyber Challenge (AIxCC) на лучшую автоматическую систему для детектирования и исправления уязвимостей в исходном коде. Участвовать в этом не советую, но формат мероприятия интересный. Возможно что-то подобное могли бы организовать в Минцифре или Сколково.

Вот так и кидайся обновлять Exchange сразу после Microsoft Patch Tuesday

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

Вот так и кидайся обновлять Exchange сразу после Microsoft Patch Tuesday

Вот так и кидайся обновлять Exchange сразу после Microsoft Patch Tuesday. Оказалось, что обновления ломают неанглоязычные инсталляции Exchange, например немецкие. 🤷‍♂️ На MS-ных страницах уязвимостей рекомендуют пока не обновлять такие инсталляции и применять workaround.

Первые впечатления от августовского Microsoft Patch Tuesday

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

Первые впечатления от августовского Microsoft Patch Tuesday

Первые впечатления от августовского 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.

🗒 Vulristics report

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч?

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

Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч?

Почему участники багбаунти нашли в прошлом году 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-щиков 😉