Архивы автора: Александр Леонов

Об авторе Александр Леонов

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно и моих проектах можете прочитать здесь. Приглашаю подписаться на мой канал @avleonovrus "Управление Уязвимостями и прочее" в MAX или в Telegram. Вы можете обсудить мои посты или задать вопросы в группе ВКонтакте. And I invite all English-speaking people to another Telegram channel @avleonovcom.

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

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

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

Компания Cortel, поставщик ИТ-сервисов, проводит открытое исследование "Защита персональных данных 2023"

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

Компания Cortel, поставщик ИТ-сервисов, проводит открытое исследование "Защита персональных данных 2023". Цель: определить как в действительности обстоят дела с ПДн и их защитой. Для этого они завели анонимный опрос на яндекс-формах.

Вопросов там немного и они по делу:

🔹 Как в вашей компании выглядит процесс защиты ПДн?
🔹 Как считаете, какова вероятность штрафа от регулятора в течение года за неисполнение ФЗ-152 в вашей организации?
🔹 Поставьте галочку, если были утечки персональных данных за 2022-2023 год. 😉
🔹 Взаимодействовали ли вы с регулятором за 2022-2023 год?

Единственное, что штраф-то штрафу рознь, надо было бы в опросе сделать поправку на размер штрафа - классические 60к или оборотный. Но так тоже норм. 🙂 Приглашаю поучаствовать в опросе, результаты исследования обещают опубликовать в канале @Cortel_cloud осенью. Подпишитесь, чтобы не пропустить и коллегам, которые за ПДн отвечают тоже перешлите. 😉

Как обучать Vulnerability Management-у?

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

Как обучать 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-систем.

Собираю комментарии и пожелания в посте в ВК. 😉

Порадовало сегодня название заведения

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

Порадовало сегодня название заведения. Интересно, что будет если подойти к ним и заявить что-то вроде: Saluton! Mi volas pilafon kaj oksikan sukon, bonvolu. 😅

Хотя вряд ли я первый, кому пришла в голову такого рода шутейка.

На сайте никаких признаков связи с детищем Заменгофа не просматривается. А жаль, могла бы быть прикольная фишечка практически забесплатно. 🙂

На самом деле после недолгого гугления в Москве нашлось множество бизнесов с "Эсперанто" в названии, которые с плановым языком никак не связаны: стоматология, юридические услуги, одежда, образование за рубежом, общепиты, стройматериалы. Не хрестоматийное ООО "Вектор", но почти что. 🙂

Англосаксонские госбезопасники из 5 стран выпустили совместный отчёт "2022's Top Routinely Exploited Vulnerabilities"

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

Англосаксонские госбезопасники из 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

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

Команды для тех, кто сам хочет построить отчет в 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-версии. 😏

Вчера выложили минутный фрагмент из Babylon 5: The Road Home

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

Вчера выложили минутный фрагмент из Babylon 5: The Road Home. Релиз-то совсем скоро уже, 15 августа.

Диалог напоминает классические диалоги Деленн и Шеридана. 👍 Но Деленн, конечно, должна говорить голосом Миры Фурлан. Иначе что-то не то. Not the one. JMS на тему использования голосов умерших актёров написал в духе, что это неэтично и такой вариант не рассматривался. Но, учитывая текущую зрелость и распространенность голосовых дипфейков (для примера - вот Высоцкий вполне убедительно КиШа поёт), думаю анимированную Деленн с голосом Миры Фурлан мы всё-таки увидим/услышим. 🙂 Хотя бы и в рамках фан-творчества.

PS: С голосовыми дипфейками ситуация на самом деле довольно пугающая, поскольку получить убедительную запись какого угодно текста каким угодно голосом становится всё проще и проще. Хочется надеяться, что правоприменительная практика будет поспевать за техническим прогрессом и к людям, чьи голоса скопировали и использовали произвольным образом, не будут докапываться почём зря.