Заканчивается приём заявок на Pentest Award 2024 от Awillix. Заявки принимаются до 23 июня.
Если у вас или у ваших коллег есть ресёрчи подходящие под следующие номинации, обязательно подавайтесь:
🔹 Hack the logic
🔹 Раз bypass, два bypass
🔹 Ловись рыбка
🔹 Пробив WEB
🔹 Пробив инфраструктуры
🔹 Девайс
"Не упускайте шанс побороться за звание лучшего этичного хакера, получить призы и потусить с единомышленниками в камерной атмосфере на церемонии награждения."
ITшникам не до уязвимостей. Мне написал подписчик, которого триггернули мои слова в посте про Vulnerability Management как порождение хаоса в IT.
"Почему есть потребность в VM-е? Потому что IT без живительной стимуляции со стороны не могут поддерживать удовлетворительный уровень безопасности инфраструктуры организации. "
Привожу его сообщение:
"У меня есть некоторый опыт работы в ИТ, включая ИБ-шные компании. ИТ нужна не живительная стимуляция со стороны, а ресурсы и нормально простроенные процессы. Я не видел ещё ни одной конторы, в которой бы подразделения ИТ не были бы тотально перегружены (из-за нехватки людей, большого количества задач или неудовлетворительной организации процессов их работы — в частности, недостаточного внимания к автоматизации IT ops.
Потому что в условиях, когда критериями является "чтобы не падало", и чтобы никто не жаловался [на сроки исполнения]", и очередь задач в десятки на одного сотрудника — совсем не до VM.
Вспоминаются слова одного руководителя ИБ-шной компании: "Смотрю я на наше ИТ, и постоянно возникает желание разгонать всех нахер, и нанять других, порасторопнее". В то время как ИТ страдала совсем не от недостатка расторопности — люди херачили днями и ночами."
Полностью согласен. Проблема не в том, что специалисты не осознают важность исправления уязвимостей, а в процессах организации. Они строятся таким образом, что ITшникам становится совсем не до уязвимостей. И не до информационной безопасности в целом. 🤷♂️
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 Обновил отчёт.
Коллеги из команды MaxPatrol SIEM-а запилили офигенные скетчи про самопальный SIEM в организациях. 😁 Отсылка к культовой передаче из 90х очевидна. Мне ещё напомнило ролики "I'm a Mac I'm a PC".
🎞 Самостоятельное построение SEIM-системы
🎞 Поддержка нового источника
🎞 Мониторинг источников
🎞 Валидация событий информационной безопасности
➡️ Онлайн-запуск MaxPatrol SIEM 8.2 пройдет 27 июня в 14:00, регистрируйтесь!
Надо бы по самопальному VM-у подобные придумать. 😅
Есть идеи, что можно было бы обыграть? Пишите в комментарии.
Резко повысилась критичность уязвимости Elevation of Privilege - Windows CSC Service (CVE-2024-26229). Уязвимость из апрельского Microsoft Patch Tuesday. В апреле эту уязвимость вообще никто не подсвечивал.
"На Танечку внимания никто не обращал" ©
Microsoft про неё писали "Exploitation Less Likely". Известно было только то, что в случае успешной эксплуатации злоумышленник может получить привилегии SYSTEM.
Но через 2 месяца, 10 июня, на GitHub появился рабочий эксплоит. 🤷♂️ Сюрприз! Критичность уязвимости скачкообразно повысилась.
Можно было это как-то прогнозировать? Имхо, вообще никак. Ещё одно подтверждение, что прогнозирование трендовости это, конечно, хорошо и правильно, но регулярный безусловный патчинг согласно установленному SLA (AIT) не отменяет.
Небольшая подробность. Автор эксплоита уточнил CWE уязвимости.
Было: CWE-122 - Heap-based Buffer Overflow
Стало: CWE-781 - Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code
До End of Life CentOS 7 осталось 2 недели. Самое время проверить не осталось ли где-то в инфраструктуре хостов с этой операционной системой. Куда мигрировать с CentOS 7 не особо понятно. RedHat превратили CentOS в нестабильный дистрибутив CentOS Stream и начали бороться с традиционными альтернативами в виде Alma и Rocky. Можно, конечно, посмотреть в сторону SberLinux, RedOS и Роса «Кобальт», но, имхо, будущее RPM-based дистрибутивов совместимых с RHEL в России достаточно туманно и стоит целиться скорее в Астру или Альт. Судя по статистике, в мире в основном бегут на Ubuntu.
Vulnerability Management как порождение хаоса в IT. Тема очевидная и несколько избитая. Почему есть потребность в VM-е? Потому что IT без живительной стимуляции со стороны не могут поддерживать удовлетворительный уровень безопасности инфраструктуры организации. 🤷♂️
А как бы было хорошо: ITшники сами устанавливают регламент по обновлениям (включая экстренные обновления) и сами следят за его выполнением, сами разбираются в харденинге и внедряют его. А ИБ только периодически проводят аудиты и поражаются насколько же всё грамотно выстроено и работает как отлаженный смазанный механизм. И, со слезами умиления на глазах, закупают ITшникам всякие вкусняшки, поют соками-водами и долго трясут руки героям невидимого фронта. Нет, без шуток. Мой идеальный VM это полное отсутствие VM-а вообще, ввиду его ненужности, ведь безопасность в организации наступает сама, by design, без каких-либо избыточных костылей.
Но вот что-то в реальной жизни так решительно не получается. И чем больше масштаб организации, тем больше хаоса, адища, скверны и пагубы там образуется со временем. Возможно оттого, что цели разные. У кого-то учёт в рублях, а у кого-то в сутках. Когда в IT платят за то, чтобы просто надёжно работало, нужно быть отбитым фанатиком, чтобы ещё и по собственной инициативе постоянно обновлять своё хозяйство для исправления уязвимостей. Сложная задача становится сложной задачей со звёздочкой. И зачастую без какой-либо положительной мотивации, скорее наоборот - втыки за то, что опять что-то отъехало после обновления. И всё равно продолжать это делать. Потому, что "так надо", "так правильно". Мало таких буйных и не надолго их хватает.
Поэтому дорога одна - вниз, в адище и хаос. Из которого, после инцидентов или под воздействием регуляторной дубины, рождается то, что должно с ним как-то бороться - Vulnerability Management. Порождение по природе своей ограниченное, компромиссное и неполное. Ну а что вы хотели? От осинки не родятся апельсинки.
По определению неполная база известных уязвимостей становится отправной точкой для ещё более неполной базы уязвимостей с формализованными детектами. Детектами, которые не всегда могут достоверно найти уязвимость ввиду многообразия способов установки ПО. Затем набор продетектированных уязвимостей о большей части которых неизвестно вообще ничего подвергается анализу и приоритизации: "а ну малыш, давай, попробуй отгадай" какая из них станет трендовой завтра и через какую организацию поломают. 🙂 Чистый кайф.
И, к сожалению, ничего лучшего для борьбы с IT-хаосом пока не придумали. 🤷♂️
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.