Архив метки: vulnerability

Также на прошлой неделе разобрался как экспортировать уязвимости из on-prem инсталляции VulnsIO через API

Также на прошлой неделе разобрался как экспортировать уязвимости из on-prem инсталляции VulnsIO через API

Также на прошлой неделе разобрался как экспортировать уязвимости из on-prem инсталляции VulnsIO через API. Описания RestAPI в паблике пока нет, т.к. оно сейчас в активной разработке. Запрашивайте через поддержку, скинут очень качественно описанный swagger-файл. 👍 Экспортировать уязвимости просто:

1. API доступен по 443 порту, где и web-интерфейс - удобно. upd 01.09. Теперь ключ выпускается в веб-интерфейсе. Прописываем ключ в x-api-key хидер.

2. Забираем список всех активов. Одним запросом без пагинации.

3. Для каждого актива можно получить список аудитов (сканов). Получаем последний скан через .

4. Разбираем ссылки на CVE в vulnerableObjects.

📄 Выкладываю python-скрипт, в котором формирую дикт, где для каждого хостнейма хранится список cve-шек и дата сканирования.

В общем, хорошая интуитивная API-шка. 👍 Накидал скрипт очень быстро и без затыков.

На неделе разобрался как экспортировать уязвимости из RedCheck через API

На неделе разобрался как экспортировать уязвимости из RedCheck через API

На неделе разобрался как экспортировать уязвимости из RedCheck через API. Всё достаточно просто. Описание API есть в паблике, вроде оно вполне себе RESTful. Также у API сервера есть встроенный swagger. Порядок действий для экспорта уязвимостей следующий:

1. По логину-паролю пользователя RedCheck получаем токен, который нужно прописывать в заголовки запросов для аутентификации.

2. Забираем все хосты, заведённые в RedCheck.

3. Для каждого хоста через специальный метод получаем уязвимости из последнего скана. Обратите внимание, что обязательно нужно указать тип скана (для аудита уязвимостей Type=5).

4. Информация по уязвимостям хранится в структуре "ovalDefinitions", но XML парсить не придётся, т.к. всё уже удобно разложено в JSON-е. 😊 CVEшки забираем из references.

📄 Выкладываю python-скрипт, в котором формирую дикт, где для каждого хостнейма хранится список cve-шек и дата сканирования.

В общем, нормальная APIшка, жить можно. 🙂👍

Многочисленные уязвимости в компоненте J-Web (веб-консоль) операционной системы Juniper Networks Junos на устройствах серий SRX и EX

Многочисленные уязвимости в компоненте J-Web (веб-консоль) операционной системы Juniper Networks Junos на устройствах серий SRX и EX

Многочисленные уязвимости в компоненте J-Web (веб-консоль) операционной системы Juniper Networks Junos на устройствах серий SRX и EX. Путем последовательной эксплуатации четырёх уязвимостей, неаутентифицированный сетевой злоумышленник может удалённо выполнять код на устройствах.

Тем, кто ещё не импортозаместил свои джуны, нужно либо обновляться, либо отключать J-Web, либо максимально ограничивать к нему доступ. Киньте своим сетевикам.

Об атаках с использованием этих уязвимостей не пишут, но их исправили в рамках внеочередного обновления ("Out-of-Cycle Security Bulletin").

PS: сегодня я узнал, что "juniper" это можжевельник, "род вечнозелёных хвойных кустарников и деревьев семейства Кипарисовые". 🙂 А "cisco" это вид лососевых рыб, ряпушка, "озёрная сельдь".

Свежая RCE уязвимость CVE-2023-40477 в WinRAR версиях

Свежая RCE уязвимость CVE-2023-40477 в WinRAR версиях

Свежая RCE уязвимость CVE-2023-40477 в WinRAR версиях 6.23. Для успешной эксплуатации пользователь должен открыть вредоносный rar-архив, который к нему может попасть в рамках фишинговой рассылки например. Уязвимость раскрыли через ZDI.

Архиватор Рошала в России это больше чем просто архиватор. Так уж исторически сложилось. Но, несмотря на российские корни, WinRAR это ПО иностранное, т.к. "официальный издатель продуктов RARLAB" это немецкая win.rar GmbH. И, несмотря на фактическую бесплатность, это shareware, так что если WinRAR у вас в организации используется без лицензии, то к этому могут быть вопросы. Лучше выпиливайте.

Алексей Лукацкий вкинул сегодня вопрос: "Почему вендора, делающие вклад в развитие CVSS, сами его не используют, стараясь придумать что-то свое?"

Алексей Лукацкий вкинул сегодня вопрос: Почему вендора, делающие вклад в развитие CVSS, сами его не используют, стараясь придумать что-то свое?

Алексей Лукацкий вкинул сегодня вопрос: "Почему вендора, делающие вклад в развитие CVSS, сами его не используют, стараясь придумать что-то свое?" Он проиллюстрировал это тем, как Microsoft проставляет свой уровень критичности для уязвимости без привязки к CVSS, учитывая, среди прочего, вероятность реализации успешной брутфорс-атаки.

Имхо, ответ на поверхности:

1. CVSS это не священная корова. CVSS это просто опросник. С довольно произвольными полями. С довольно произвольной формулой расчёта скоринга. И сами авторы из First регулярно шатают CVSS только в путь.

2. Сделать свою систему приоритизации уязвимостей не rocket science, а свой пиар-эффект среди ширнармасс оно даёт. Особенно если написать про "внутри у ней нейронка" и про миллион анализируемых параметров.

То, что "систем приоритизации уязвимостей сегодня уже под десяток от разных компаний, организаций и регуляторов" и это "мешает установлению некоего единого языка общения между специалистами" действительно так, не поспоришь. Но это объективная реальность. От призывов, допустим, сплотиться вокруг наступающего CVSS 4.0 она не изменится.

Как мне кажется, нам в России тоже следовало бы отойти от прямого использования CVSS as is в сторону чего-то более практичного и опирающегося на отечественные методические рекомендации, но с возможностью использовать CVSS-векторы в качестве источника данных.

Моя ОСОКА здесь как пример. 😉 Про неё не забываю. После адаптации инфраструктурных метрик понимание как должен выглядеть полный вектор уже есть. Следующей этап - накодить калькулятор.

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

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

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

CVE-2017-11882 — RCE-уязвимость в редакторе уравнений Microsoft Office. Для эксплуатации злоумышленник должен создать вредоносный файл и каким-то образом убедить жертву открыть его. В случае успеха злоумышленник выполниякт произвольный код с привилегиями пользователя, открывшего вредоносный файл. Таким образом, если у жертвы есть права администратора, злоумышленник сможет получить полный контроль над системой: устанавливать программы, просматривать, изменять или уничтожать данные, создавать новые аккаунты и т.п. 🤷‍♂️

PoC для уязвимости появился через неделю после публикации и с тех пор, уже более 5 лет, она активно эксплуатируется. 🙈

Что делать? Обновляться/импортозамещаться 😏, левые офисные файлы не открывать (особенно работая от администратора), использовать AV/EDR. 😉

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

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

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

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