Архивы автора: Alexander Leonov

Об авторе Alexander Leonov

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

На что похожа работа специалиста по Управлению Уязвимостями?

На что похожа работа специалиста по Управлению Уязвимостями?

На что похожа работа специалиста по Управлению Уязвимостями?

Я думал сначала, что на работу врача. Но к врачу обычно приходят с какими-то жалобами. К VM-щику никто сам не пойдёт. 🙂

Потом понял. Работа VM-щика близка работе инспектора из государственного органа надзора (пожарный, санитарно-эпидемиологический, строительный и т.д.).

Судите сами:

🔹 Его приходу не рады.
🔹 Все считают, что он пришёл, чтобы навязывать какие-то дурацкие надуманные требования и мешать людям нормально работать.
🔹 В его компетенции сомневаются (иногда оправдано - не всегда тривиально натянуть общие требования безопасности на монстра, которого в организации наворотили 🤯).
🔹 К опасностям, о которых он рассказывает, относятся со скепсисом, в святой уверенности, что они, конечно же, никогда не реализуются. 😏
🔹 То, что в соседней организации эти опасности реализовались и привели к недопустимым последствиям никого особо не впечатляет - у нас-то не совсем так, у нас-то ситуация чуть другая.
🔹 Его требования стараются саботировать всеми возможными способами или выполнять в наименьшем объеме.
🔹 Когда опасность реализуется, крайним становится проверяющий - куда ж он нерадивый смотрел, ату его, под суд его!
🔹 А у остальных лапки, мы же не специалисты, мы ничего не понимали. 😏

Но есть и несколько важных различий:

🔸 Работодателем инспектора является государство и у него есть власть прекратить деятельность организации к чёртовой бабушке, если требования не будут выполнены. VM-щику платит сама организация и поэтому VM-щик может только заявление на стол положить в знак протеста. 🤷‍♂️ Так, что инструментарий у него в основном "словесные интервенции".
🔸 Инспектор фокусируется на определенной узкой теме. У VM-щика спектр нежелательных воздействий, которые он должен учитывать, хоть и ограничен областью ИБ, но всё равно очень широк. Примерно, как если бы один инспектор оценивал возможные воздействия начиная от пожаров, наводнений, эпидемий, вооруженных налетов бандитов, заканчивая вторжением инопланетян.
🔸 Инспектор выполнил проверки и ушёл другую организацию проверять. VM-щик окучивает одну организацию глубоко, постоянно и непрерывно.
🔸 Инспектору вряд ли могут сказать "покажи, что у нас самого плохого и там мы, так уж и быть, поправим, а для остальных мест обоснуй сам почему там исправлять не нужно, ты же профессионал; а везде мы исправить не можем - у нас таких ресурсов нет". 🙂
🔸 К счастью, и уязвимости ИБ реже приводят к реальным человеческим жертвам. Во всяком случае пока.

Сравнение, конечно, грубое и скорее юмористическое, но основной вайб VM-а, как мне кажется, передаёт. 😉

На днях прошла новость об RCE уязвимости в FortiOS и FortiProxy (CVE-2023-42789)

На днях прошла новость об RCE уязвимости в FortiOS и FortiProxy (CVE-2023-42789)
На днях прошла новость об RCE уязвимости в FortiOS и FortiProxy (CVE-2023-42789)На днях прошла новость об RCE уязвимости в FortiOS и FortiProxy (CVE-2023-42789)

На днях прошла новость об RCE уязвимости в FortiOS и FortiProxy (CVE-2023-42789). Она "позволяет злоумышленнику выполнять несанкционированный код или команды с помощью специально созданных HTTP-запросов". Уязвимость эксплуатируется в captive portal, который, по идее, не должен быть доступен из Интернет. Поэтому в бюллетене Fortinet пишут про "inside attacker". Признаков эксплуатации вживую пока нет. Вендор отмечает, что уязвимость найдена исследователями Fortinet Product Security Team.

На GitHub есть репозиторий якобы с PoC-ом, но достоверность его сомнительная. Выложенный код только реализует проверку доступности портала, пейлоада там нет. Репозиторий создал пользователь без какой-либо репутации и предыдущей активности. Полный код эксплоита он предлагает приобрести за ~$262. Выглядит это как скам, но если вдруг это действительно рабочий эксплоит, то вполне вероятно, что он быстро утечет в паблик.

В любом случае стоит обновляться/импортозамещаться.

Что я планирую на второй день SafeCode

Что я планирую на второй день SafeCode

Что я планирую на второй день SafeCode.

🔹 Досмотреть 2 доклада, которые я в первый день не успел посмотреть: про рекон и уязвимости мобильных приложений.
🔹 Посмотреть 2 доклада, которые изначально намечал: про архивы уязвимостей и про своё решение для безопасности контейнерных сред.
🔹 Посмотреть, что новенького в сканилке образов Яндекса и панельку с Андреем Масаловичем. 🙂

Планирую просмотренное также описывать в постах, но скорее растяну это на несколько дней, а то и недель. Доклады на конфах это хорошо, но уж больно много всего происходит сейчас по части критичных уязвимостей. 😇

Послушал доклад Татьяны Куцовол (ГК «Солар») про безопасность Supply Chain на SafeCode и сделал небольшой конспект

Послушал доклад Татьяны Куцовол (ГК «Солар») про безопасность Supply Chain на SafeCode и сделал небольшой конспект

Послушал доклад Татьяны Куцовол (ГК «Солар») про безопасность Supply Chain на SafeCode и сделал небольшой конспект.

❓SCA и Supply Chain - в чём разница?

🔹 Software Composition Analysis (SCA) - выявление и исправление известных уязвимостей (CVE)
🔹 Supply Chain - текущих проблем нет, но в будущем с кодом могут быть проблемы

📔 Стандарты

🔸 SLSA (Supply-chain Levels for Software Artifacts). 4 уровня. В основном про билды. 🫤
🔸 OWASP SCVS (Software Component Verification Standard). 6 кратких контролей. 😒
🔸 CIS SSCSG (Software Supply Chain Security Guide). 100 рекомендаций в 5 категориях. 👍

😡 Техники злодеев

🔻 Хактивизм и создание токсичных репозиториев
🔻 Starjacking
🔻 Typosquatting
🔻 Dependency Confusion
🔻 Become Maintainer

📊 Метрики для оценки опенсурсных проектов

➕ Популярность
➕ Авторский состав
➕ Активность сообщества
➕ Заинтересованность в безопасности (есть )
➖ Библиотека создана недавно
➖ Первая версия подозрительно высокая

Наверняка старая шутка, но я раньше не слышал

Наверняка старая шутка, но я раньше не слышал

Наверняка старая шутка, но я раньше не слышал. Единственный безопасник в организации как агент 007:
🔸 0 сотрудников,
🔸 0 бюджета на инструменты безопасности,
🔸 7 инцидентов в неделю.

Алексей Федулаев на SafeCode сегодня рассказал. 🙂
Жиза. 😅

Антон Жаболенко (CISO Wildberries) рассказывает про комплексный Continuous Vulnerability Management в сессии "Как устроена безопасность в технологически зрелой компании?" на SafeCode

Антон Жаболенко (CISO Wildberries) рассказывает про комплексный Continuous Vulnerability Management в сессии Как устроена безопасность в технологически зрелой компании? на SafeCode

Антон Жаболенко (CISO Wildberries) рассказывает про комплексный Continuous Vulnerability Management в сессии "Как устроена безопасность в технологически зрелой компании?" на SafeCode.

Процесс включает в себя:

🔸 различные сканирования уязвимостей (как из Интернета, так и из внутренней сети)
🔸 внутренний RedTeam
🔸 пентесты (внешние подрядчики)
🔸 RedTeam (внешние подрядчики)
🔸 внутренние аудиты
🔸 публичное bug bounty

Это источники, которые генерят поток продетектированных проблем компании, чтобы Defense команда могла итеративно и циклично эти проблемы исправлять.

Такой подход применяется преимущественно в технологически зрелых компаниях, потому что он

🔻 дорогой
🔻 сложный
🔻 тяжело найти экспертов для выстраивания

Но только таким образом можно смотреть комплексно на проблемы, которые есть в компании с точки зрения ИБ.

Если использовать одну команду исследователей (подрядчиков или in-house), у неё неизбежно будет "замыливаться глаз".

Интересный доклад Андрея Карпова "Ошибки в коде: ожидания и реальность" на SafeCode

Интересный доклад Андрея Карпова Ошибки в коде: ожидания и реальность на SafeCodeИнтересный доклад Андрея Карпова Ошибки в коде: ожидания и реальность на SafeCodeИнтересный доклад Андрея Карпова Ошибки в коде: ожидания и реальность на SafeCode

Интересный доклад Андрея Карпова "Ошибки в коде: ожидания и реальность" на SafeCode. Идея в том, что у разработчика средства анализа кода (или исследователя) могут быть ожидания по типам ошибок, которые должны часто встречаться в исследуемом коде. А на практике получается, что одни типы ошибок практически не встречаются (неинициализированные переменные, деление на ноль, выход за границу массива, присвоения вместо сравнения), либо встречаются, но практически не влияют на работу приложений (нулевые ссылки и указатели).

С другой стороны, встречаются пласты ошибок, о которых и не думали:

🔸 CWE-14 (исчезновение memset)
🔸 Повторная запись в переменную
🔸 Проверка указателя после new
🔸 Опечатки вида (А == A)

Лучше не увлекаться ошибками, которые взяты из книг, а брать их из реальной жизни (свой код, сторонний код, код с ошибками, присланный пользователями анализатора).
Важно не фокусироваться на анализе потока данных и не делать инструмент анализа однобоким.