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

Кирилл Ермаков, основатель и CEO vulners.com, поделился историей провала своего стартапа 4Hackers

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

Кирилл Ермаков, основатель и CEO vulners.com, поделился историей провала своего стартапа 4Hackers

Кирилл Ермаков, основатель и CEO vulners.com, поделился историей провала своего стартапа 4Hackers. Идея была в том, чтобы сделать чат-бот на опенсурсных LLM-ках, у которого не было бы проблем с решением пентестерских задач: написание эксплоитов, составление шаблонов писем для фишинга, разработка сценариев атаки и т.п. То есть c "чувствительными" темами, на которые мейнстримные чатботы общаться не любят. 😉 Кроме того, к 4Hackers были прикручены скрапперы для решения задач OSINT-а. 🕵️‍♂️

В итоге за год проект съел $200 000 из кармана Кирилла и не взлетел. 🗿 4Hackers проработает ещё несколько недель и потом шнур выдернут. 💀

Кирилл подробно перечисляет причины провала, но суммировать их можно так:

💬 Оценка востребованности не проводилась, в итоге был разработан продукт для несуществующих пользователей.

📊 Так как сервис платный и даже без триала, то пользователи не росли и вирусного эффекта не было.

💸 Хостить такой сервис on-prem оказалось супер-дорого. 🤷‍♂️

Расширенный поиск по web-уязвимостям в Vulners

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

Расширенный поиск по web-уязвимостям в Vulners

Расширенный поиск по web-уязвимостям в Vulners.

🔻 Vulners теперь размечает значимые параметры в описании CVE уязвимостей и эксплоитов. 🤖 Например, по описанию "Code injection vulnerability in config/config_invt1.php due to improper handling of the PASSOx parameter" он автоматически определяет, что это веб-уязвимость и выделяет parameter запроса "PASSOx", url "config/config_invt1.php", position "request body" и cwe "CWE-94" (Code Injection). Эти параметры видны на странице описания уязвимости и в JSON (блок webApplicability).

🔻 По этим параметрам можно искать уязвимости в поисковом интерфейсе Vulners (бесплатно 🆓) и через API. Например, все вебные уязвимости или уязвимости с "php" в урле.

А зачем это может понадобиться?

🔹 Если у вас есть список урлов (путей), найденных краулером, можно поискать по ним потенциальные уязвимости.

И наоборот

🔹 Для размеченных уязвимостей Vulners можно проверить не доступны ли их пути в сервисах на вашем периметре.

В общем, прикольная фича. 😉👍🔥

Посмотрел совместный вебинар Vulners и RST Cloud про приоритизацию уязвимостей

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

Посмотрел совместный вебинар Vulners и RST Cloud про приоритизацию уязвимостейПосмотрел совместный вебинар Vulners и RST Cloud про приоритизацию уязвимостейПосмотрел совместный вебинар Vulners и RST Cloud про приоритизацию уязвимостейПосмотрел совместный вебинар Vulners и RST Cloud про приоритизацию уязвимостей

Посмотрел совместный вебинар Vulners и RST Cloud про приоритизацию уязвимостей.

🔹 Кирилл Ермаков из Vulners рассказал про важность приоритизации узявимостей (особенно для MSSP компаний, т.к. они отвечают за безопасность клиентов) и как её можно улучшить с помощью динамически обновляемого AI Score v2. Очень понравилась его фраза: "если вы не знаете свои активы очень хорошо, выключайте вебинар и идите заниматься Asset Management-ом". Asset Management это база. 👍

🔹 Юрий Сергеев из RST Cloud рассказал как при приоритизации уязвимостей учесть данные об их эксплуатации в реальных атаках (в вашей локации, в вашей индустрии, для вашего профиля злоумышленника). Он привёл формулу и продемонстрировал как учёт этих факторов влияет на приоритизацию. Понравился пример с regreSSHion, где шуму много, но атака очень заметная и занимает много времени, поэтому эксплуатация вряд ли будет массовой.

Linux Patch Wednesday: вот где этот майский пик!

2 комментария

Linux Patch Wednesday: вот где этот майский пик!

Linux Patch Wednesday: вот где этот майский пик! 🤦‍♂️ Также об июньском Linux Patch Wednesday. Помните, я в посте про майский Linux Patch Wednesday радовался, что, несмотря на введение правила по Unknown датам, пик в мае был незначительный. Хотя "32 406 oval definition-ов без даты получили номинальную дату 2024-05-15". Оказалось пик не был виден из-за ошибки в коде. Ба-дум-тсс! 🥸🤷‍♂️

То, что не все CVE-шки у меня попадаются в LPW бюллетени, несмотря на введение номинальных дат, я заметил на примере громкой уязвимости Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086), которой действительно нигде не было. Подебажил функцию распределения по бюллетеням, добавил тесты. Добился того, что все 38 362 CVE-шки из Linux-ового OVAL-контента действительно раскидываются по бюллетеням. Включая CVE-2024-1086. Вот она в феврале:

$ grep "CVE-2024-1086"  bulletins/*
bulletins/2024-02-21.json:        "CVE-2024-1086": [
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",

Ну и пик в мае действительно есть. Да ещё какой! 11 476 CVE! 😱 Настолько много, что я перегенерил Vulristics отчёт для него только с использованием 2 источников: Vulners и БДУ. И даже из Vulners данные подгружались не быстро. В отчёте 77 уязвимостей с признаком активной эксплуатации вживую и 1 404 уязвимости с эксплоитами, но без признаков активной эксплуатации. Т.к. по больше части это уязвимости старые, для которых просто не было понятно когда именно они были исправлены, например, Remote Code Execution - Apache HTTP Server (CVE-2021-42013), я не буду подробно их разбирать - кому интересно смотрите отчёт. Но обратите внимание, что размер отчёта очень большой.

🗒 Отчёт Vulristics по майскому Linux Patch Wednesday (31.3 мб.)

Что касается июньского Linux Patch Wedneday, который финализировался 19 июня, то там 1040 уязвимости. Тоже довольно много. Почему так? С одной стороны правило по Unknown датам добавило 977 Debian-овских OVAL дефинишенов без даты. Не 30к, как в мае, но тоже значительно. Из 1040 уязвимостей 854 это уязвимости Linux Kernel. Причём, довольно много "старых" идентификаторов уязвимостей, но заведенных в 2024 году. Например, CVE-2021-47489 с NVD Published Date 05/22/2024. 🤔 Что-то странное творит CNA Linux Kernel.

🔻 С признаками эксплуатации вживую опять Remote Code Execution - Chromium (CVE-2024-5274, CVE-2024-4947), как и Microsoft Patch Tuesday. Судя по данным БДУ, Remote Code Execution - Libarchive (CVE-2024-26256) также активно эксплуатируется.

🔸 Ещё 20 уязвимостей с публичным эксплоитом. Можно подсветить отдельно Remote Code Execution - Cacti (CVE-2024-25641) и Remote Code Execution - onnx/onnx framework (CVE-2024-5187).

🗒 Отчёт Vulristics по июньскому Linux Patch Wednesday (4.4 мб.)

upd. 30.06 Обновил отчёт.

Трендовые уязвимости мая по версии Positive Technologies

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

Трендовые уязвимости мая по версии Positive Technologies. Как обычно, в 3 форматах:

📹 Рубрика "В тренде VM" в новостном ролике SecLab-а (начинается с 17:06)
🗞 Пост на Хабре, фактически это несколько расширенный сценарий рубрики "В тренде VM"
🗒 Компактный дайджест с техническими деталями на официальном сайте PT

Список уязвимостей:

🔻 RCE в Fluent Bit (CVE-2024-4323)
🔻 RCE в Confluence (CVE-2024-21683)
🔻 RCE в Windows MSHTML Platform / OLE (CVE-2024-30040)
🔻 EoP в Windows DWM Core Library (CVE-2024-30051)

Уязвимость RCE - Confluence (CVE-2024-21683) c публичным эксплоитами на GitHub

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

Уязвимость RCE - Confluence (CVE-2024-21683) c публичным эксплоитами на GitHub

Уязвимость RCE - Confluence (CVE-2024-21683) c публичным эксплоитами на GitHub. Для эксплуатации требуется аутентификация. Уязвимы и Confluence Data Center, и Confluence Server.

🔻 Версия 8.5.9 LTS, исправляющая уязвимость, вышла 9 мая.
🔻 23 мая, после появление описания уязвимости в NVD и тикета от Atlassian, исследователь Huong Kieu изучил патч, описал уязвимость и сообщил, что у него получилось сделать PoC. В тот же день реализации эксплоита появились на GitHub.

Вероятно Atlassian придерживали информацию об исправлении уязвимости, чтобы больше организаций успели обновиться до начала активной эксплуатации. Правда, у них это не вполне получилось. Видимо они случайно опубликовали тикет 15 мая, а потом убрали до 23 мая. Но поисковик по уязвимостям Vulners всё запомнил. 😉 Так что информация об уязвимости всё это время была доступна. 🤷‍♂️

Фиды NVD и API v1.0 превратятся в тыкву через неделю

2 комментария

Фиды NVD и API v1.0 превратятся в тыкву через неделю

Фиды NVD и API v1.0 превратятся в тыкву через неделю.

"The NVD plans to retire the remaining legacy data feeds as well as all 1.0 APIs on December 15th."

Если ваша организация забирает уязвимости из NVD напрямую, скачивая архивчики с JSON или используя API v1.0, то всё это поломается с 15 декабря. Имеет смысл проверить и перейти на NVD API v2.0 (учитывайте rate limits) или другие источники данных по CVE.

Выкачивать данные по всем CVE разом было очень удобно. Можно такой экспериенс сохранить? Видятся опции:

🔹 Бесплатный неофициальный NVD CVE фид от немецкого института FKIE на GitHub. Всё как у NVD, обновления раз в 2 часа.

🔹 Бесплатный официальный CVE фид от Mitre на GitHub. Нет CPE (есть affected продукты в другом формате), CWE и CVSS вендорский и не везде.

🔹 Платная коллекция данных NVD от Vulners, обогащённая инфой по активной эксплуатации, эксплоитам, AI Score и т.д. Требуется платный API и расширенная подписка. Про работу с коллекциями у меня был давнишний пост.