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

Про уязвимость Authentication Bypass - GNU Inetutils (CVE-2026-24061)

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

Про уязвимость Authentication Bypass - GNU Inetutils (CVE-2026-24061)

Про уязвимость Authentication Bypass - GNU Inetutils (CVE-2026-24061). GNU Inetutils - это набор сетевых программ общего назначения, включающий, среди прочего, сервер Telnet (telnetd). Уязвимость telnetd из GNU Inetutils позволяет удалённому злоумышленнику получить root-овый shell на хосте без каких-либо учётных данных, отправляя специально сформированную переменную окружения USER, содержащую строку "-f root".

⚙️ Патч, исправляющий уязвимость, вышел 20 января. Уязвимы версии от 1.9.3 до 2.7 (включительно). Уязвимость существовала в нераскрытом виде более 10 лет. 🤷‍♂️

🛠 Подробный write-up и эксплойт были опубликованы компанией SafeBreach 22 января.

👾 GreyNoise фиксировали случаи эксплуатации уязвимости с 21 января.

🌐 Текущая оценка Shodan - 212 396 Telnet-серверов в Интернете (всего). Сколько из них используют GNU Inetutils и уязвимы пока непонятно. CyberOK обнаружили в Рунете около 500 потенциально уязвимых Telnet-серверов.

Через два месяца собираюсь выступать в секции про VM/EM/ASM на конференции Территория Безопасности 2026 и модерировать её же

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

Через два месяца собираюсь выступать в секции про VM/EM/ASM на конференции Территория Безопасности 2026 и модерировать её же

Через два месяца собираюсь выступать в секции про VM/EM/ASM на конференции Территория Безопасности 2026 и модерировать её же. 😉 В секции ожидаются минидоклады со стороны вендоров, сервис-провайдеров и клиентов. Плюс обсудим то, как мы видим развитие управления уязвимостями, экспозициями и площадью (поверхностью) атаки в российских реалиях. Приходите, будет интересно! 🙂

Так уж сложилось, что ТерБез - самая VM-ная конфа из существующих сейчас в России. Там всегда много стендов VM-ных вендоров (представлена значительная часть карты!), и, соответственно, много профильного кулуарного общения. 💬 Если вы работаете в VM-вендоре и вас там пока нет - обратите внимание. ⚠️ Если вы VM-щик - не забудьте зарегистрироваться и приходите 2 апреля в Hyatt Regency Moscow Petrovsky Park. 🚶‍➡️

Около-VM-ные темы также представлены: управление рисками и активами, мониторинг, комплаенс и харденинг, багбаунти. И это только один трек, а там их ещё три по разным направлениям ИБ. 🙃

Про уязвимость Information Disclosure - Desktop Window Manager (CVE-2026-20805)

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

Про уязвимость Information Disclosure - Desktop Window Manager (CVE-2026-20805)

Про уязвимость Information Disclosure - Desktop Window Manager (CVE-2026-20805). Desktop Window Manager - это композитный оконный менеджер, входящий в состав Windows, начиная с Windows Vista. Эксплуатация уязвимости, исправленной в рамках январского Microsoft Patch Tuesday, позволяет локальному злоумышленнику раскрыть адрес раздела ("section address") порта ALPC, относящийся к памяти пользовательского режима.

👾 Microsoft отметили, что эта уязвимость эксплуатируется в атаках. Уязвимость была добавлена в CISA KEV 13 января. Подробностей по атакам пока нет, но эксперты Rapid7 предполагают, что утечка адреса памяти могла позволить злоумышленникам обойти ASLR, упрощая создание стабильного эксплоита для повышения привилегий через DWM.

🛠 Публичные PoC-и эксплоитов доступны на GitHub с 14 января.

Продолжу тему о критериях успеха в работах по Анализу Защищённости (АЗ)

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

Продолжу тему о критериях успеха в работах по Анализу Защищённости (АЗ)

Продолжу тему о критериях успеха в работах по Анализу Защищённости (АЗ). Если провести детектирование уязвимостей в любой достаточно большой организации, неизбежно обнаружатся критические уязвимости. И это абсолютно нормально, ЕСЛИ для всех обнаруженных уязвимостей выполняются следующие условия:

🔹 В организации уже знали про уязвимость на активе, т.е. обнаруживали её с помощью собственных средств детектирования.
🔹 Уязвимость уже была оценена и ей была присвоена степень критичности.
🔹 Для устранения уязвимости уже была заведена задача на конкретного исполнителя с зафиксированным сроком выполнения (в соответствии с принятым SLA) и этот срок ещё не вышел.

Это значит, что VM-процесс в организации успешно функционирует (по БОСПУУ 😉), и АЗ успешно пройден. 🥇👏

Но если в ходе АЗ были обнаружены уязвимости, для которых перечисленные условия НЕ выполняются, это вызывает вопросы к средствам детектирования уязвимостей, используемым в организации, и к практикам их использования. 😏

Я являюсь большим сторонником использования статьи 274.1 УК РФ (ч.3 нарушение правил эксплуатации КИИ) в качестве ультимативного аргумента в разговорах об устранении уязвимостей инфраструктуры

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

Я являюсь большим сторонником использования статьи 274.1 УК РФ (ч.3 нарушение правил эксплуатации КИИ) в качестве ультимативного аргумента в разговорах об устранении уязвимостей инфраструктуры

Я являюсь большим сторонником использования статьи 274.1 УК РФ (ч.3 нарушение правил эксплуатации КИИ) в качестве ультимативного аргумента в разговорах об устранении уязвимостей инфраструктуры. Не стоит начинать любой разговор с "давай быстро патчься, а то посадят 😡". Достаточно ненавязчиво упомянуть, что такая статья существует. И зачем под этой статьёй ходить, если можно пропатчиться и спать спокойно. 🤷‍♂️😉

Эту статью хотят обновить:

🔹 Довольно размытый "вред КИИ" хотят уточнить как "уничтожение, блокирование, модификация или копирование информации в КИИ".

🔹 Добавят освобождение от уголовной ответственности, тем, кто "активно способствовал раскрытию и расследованию преступления". Возможно, в том числе тем, кто первый расскажет про грешки коллег. 😉

🔹 Добавят аналогичную статью в КоАП РФ, если нарушение не содержит признаков преступления. Будут штрафовать граждан от 5 до 10 тыс. р., должностных лиц от 10 до 50 тыс. р., юрлица от 100 до 500 тыс. р.

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)?

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

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)?

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)? Понимая под АЗ детектирование уязвимостей в инфраструктуре организации третьей стороной. Для исполнителя критерии успеха: найти максимум уязвимостей с минимумом FP и FN. А для заказчика? 🤔 Обычно для него успехом считают отсутствие обнаруженных критичных уязвимостей. А если такие есть - их нужно срочно устранить или доказать, что они некритичные. 👌

Однако организациям без работающего VM-процесса такое разовое латание дыр не особо поможет - через полгода в инфре снова будет адище. 😈 А организациям с работающим VM-процессом требование устранять уязвимости в пожарном режиме, игнорируя SLA по существующим задачам на устранение, внесёт неразбериху и может сломать VM-процесс. 🤷‍♂️

Имхо, по-хорошему, АЗ должен проверять не текущее состояние инфры (постоянно меняющееся), а состояние VM-процесса. С соответствующими критериями успеха. 😉

У Security Vision вышла новая версия Vulnerability Scanner

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

У Security Vision вышла новая версия Vulnerability ScannerУ Security Vision вышла новая версия Vulnerability ScannerУ Security Vision вышла новая версия Vulnerability ScannerУ Security Vision вышла новая версия Vulnerability Scanner

У Security Vision вышла новая версия Vulnerability Scanner. Прошлый релиз был в сентябре-октябре.

🔹 Реализовали построение графа достижимости уязвимостей на основе сетевой топологии инфраструктуры.

🔹 Улучшили карточки уязвимостей: добавили оценку вероятности эксплуатации (EPSS), данные об обнаружении уязвимых систем в публичном интернете (Shodan CVEDB и тренд по регистрации хостов в Shodan; отображается в тегах, как и EPSS), рекомендации по устранению уязвимостей от НКЦКИ.

🔹 Реализовали динамические группы активов на основе заданных критериев (типа ОС, версии, наличия уязвимостей, баннеров сервисов и т.д.).

Также добавили расчёт рекомендованных сроков устранения по методике оценки уровня критичности ФСТЭК (от 30.05.2025), улучшили экспертизу (расширили BlackBox, поддержали WMI-сканы Windows, Gentoo Linux, Modbus, устройства Palo Alto Networks), переработали управление сканами и журнал сканов.