ZeroDay | Кибербезопасность

Linux capabilities: убираем лишний root, не ломая сервисы 👋 Приветствую в мире цифровой безопасности! Расскажу про работу с Linux capabilities, механизм, который позволяет давать процессам часть root-возможностей, а не полный доступ ко всему сразу. ⏺В чём идея вообще: классическая модель простая, либо ты root и можешь всё, либо не root и почти ничего. Capabilities дробят root на отдельные привилегии, например открывать порты ниже 1024, менять сетевые настройки или читать raw-сокеты. В итоге сервис получает ровно то, что ему нужно, и не больше. ⏺Почему это важно: большинство демонов до сих пор запускают от root просто по инерции. Если такой процесс скомпрометирован, атакующий получает полный контроль над системой. С capabilities компрометация сервиса не означает автоматический root. ⏺Сначала смотрим, какие capabilities вообще существуют:

    
        man capabilities{}
    

Там полный список, от CAP_NET_BIND_SERVICE до CAP_SYS_ADMIN, который по факту почти root. ⏺Проверяем, какие привилегии есть у конкретного бинарника:

    
        getcap /usr/bin/ping{}
    

Часто именно здесь видно, что ping умеет работать без root за счёт CAP_NET_RAW. ⏺Выдаём capability бинарнику. Классический пример, сервису нужен порт 80, но root не нужен:

    
        setcap cap_net_bind_service=+ep /usr/bin/myservice{}
    

Теперь процесс может слушать привилегированные порты, но не может, например, читать /etc/shadow или грузить модули ядра. ⏺Проверяем, что capability реально применена:

    
        getcap /usr/bin/myservice{}
    

Если всё ок, сервис можно запускать от обычного пользователя. ⏺Отдельно можно смотреть capabilities уже запущенного процесса:

    
        cat /proc/1234/status | grep Cap{}
    

Это помогает понять, чем процесс реально обладает в рантайме, а не только на уровне файла. ⏺Типичная ошибка, которую часто видят на аудитах, CAP_SYS_ADMIN. Формально это одна capability, но по факту она открывает половину ядра. Если видите её у сервиса, это почти всегда повод пересмотреть архитектуру. ⏺В связке с systemd capabilities выглядят ещё аккуратнее. Можно задать их прямо в unit-файле:

    
        [Service]
User=appuser
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE{}
    

Так привилегия существует только в рамках сервиса и не «прилипает» к бинарнику навсегда. ZeroDay | #безопасность

Responder: когда сеть сама сдаёт учётки 👋 Приветствую в мире цифровой безопасности! Поговорим о еще одном инструменте безопасности. ⏺Responder - это утилита для перехвата аутентификации в локальной сети. Он работает с LLMNR, NBT‑NS и mDNS - вспомогательными протоколами разрешения имён, которые Windows использует, если обычный DNS не ответил. ⏺Как это выглядит на практике: компьютер не может найти сервер по имени, рассылает запрос в локальную сеть, Responder отвечает «я этот сервер», после чего клиент сам инициирует подключение и отправляет данные аутентификации. Это стандартное поведение системы, а не баг. ⏺Самый простой запуск - активный режим перехвата:

    
        sudo python3 Responder.py -I eth0 -v{}
    

Responder начнёт отвечать на широковещательные запросы и принимать подключения от клиентов. ⏺Если нужно просто понять, есть ли проблема, но ничего не ломать, используют пассивный режим. Он только слушает сеть и показывает, кто и как пытается аутентифицироваться:

    
        sudo python3 Responder.py -I eth0 -A -v{}
    

Хороший вариант для первичного аудита или согласованного тестирования. ⏺Отдельно стоит режим с WPAD и proxy‑auth. В нём Responder подсовывает себя как прокси‑сервер и получает NTLM‑аутентификацию от браузеров и системных сервисов:

    
        sudo python3 Responder.py -I eth0 -Pvd{}
    

В реальных корпоративных сетях это часто оказывается самым «урожайным» сценарием. ⏺На выходе Responder собирает разные типы данных: NetNTLMv1 и NetNTLMv2 хэши, Kerberos AS‑REQ, а также логины и пароли в открытом виде из HTTP Basic, FTP, SMTP, LDAP и SQL. Все результаты складываются в каталог logs. ⏺Пример перехваченного NetNTLMv2 выглядит так:

    
        username::DOMAIN:challenge:response:blob{}
    

Такие хэши дальше анализируют или проверяют офлайн, чтобы оценить стойкость паролей. ⏺Если смотреть со стороны защиты, основные меры довольно приземлённые: отключить LLMNR и NBT‑NS через GPO, запретить WPAD и авто‑прокси, минимизировать использование NTLM в пользу Kerberos, сегментировать сеть и отслеживать неожиданные NTLM‑аутентификации. ZeroDay | #Инструмент

Почему сканеры на практике дают сбой: уроки атак Shai-Hulud на NPM История о том, как атаки на цепочку поставок ПО ломают привычную модель безопасности. Без эксплойтов, без 0day: достаточно скомпрометировать доверенный NPM-пакет, и вредонос выполняется ещё на этапе сборки или прямо на машине разработчика. ⏺В статье будет разбор атак Shai-Hulud на экосистему NPM и практический тест популярных SCA-инструментов. Показано, почему Trivy и Dependency-Track по умолчанию ничего не видят, откуда берутся ложные срабатывания у Grype и почему OSV оказывается единственным источником, реально замечающим malware-компрометации. ZeroDay | #Статья

Есть такое?) ZeroDay | #мем

SameSite Cookies: контроль сессий в браузере 👋 Приветствую в мире цифровой безопасности! Разберём механизм, который бесшумно закрывает целый класс атак на уровне браузера - управление тем, как cookies уходят между сайтами. ⏺SameSite - это атрибут cookie, который говорит браузеру, можно ли отправлять сессионную cookie при кросс-сайтовых запросах. По сути, это встроенный контроль границ доверия между сайтами. Пример корректной установки сессии:

    
        Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax{}
    

Такую cookie браузер отправит при обычной навигации, но не отправит при фоновых запросах с чужих сайтов. ⏺Почему это важно: без SameSite браузер по умолчанию прикладывает cookie к любому запросу на домен. Это основа CSRF-атак и множества логических багов, когда действие совершается «от лица пользователя», хотя он сам этого не делал. ⏺Кратко по режимам: ➡️Lax - разумный дефолт для большинства сайтов, защищает от CSRF и почти не ломает UX. ➡️Strict - максимальная изоляция, cookie не уходит вообще при переходах с других сайтов. ➡️None - cookie уходит всегда, но только вместе с Secure, иначе браузер её просто отбросит. ⏺И чуть советов на практике: всегда ставьте SameSite явно, не полагайтесь на дефолты браузеров; сессионные cookies - минимум Lax; для API и SSO сценариев с None обязательно проверяйте Secure и доменную область действия. ⏺Частые ошибки: SameSite=None без Secure - cookie игнорируется; использование Strict там, где есть внешние логины или платёжные редиректы; разные значения SameSite для одинаковых по смыслу cookies. ZeroDay | #безопасность

Компания "Доктор Веб" подвели итоги 2025 года в мире киберугроз.💥 Основные тенденции: ✅ Одна из самых активных угроз - рекламные трояны ✅ Новые таргетированные атаки ✅ Рост популярности ClickFix ✅ Снижение атак с троянскими программами-шифровальщиками ✅ Увеличение детектирований банковских троянов для Android ✅ Новые случаи заражения прошивок Android-устройств Подробный годовой обзор - здесь. #реклама О рекламодателе

3 приёма для пентеста 👋 Приветствую в мире цифровой безопасности! Расскажу сегодня еще о трех полезных фишках. ⏺HTTP Request Smuggling через неоднозначные заголовки: если балансировщик и backend по-разному трактуют Content-Length и Transfer-Encoding, можно «спрятать» второй запрос внутри первого. Прокси считает тело завершённым, backend - нет, и хвост запроса уезжает следующему пользователю. Пример TE.CL:

    
        POST / HTTP/1.1
Host: target
Transfer-Encoding: chunked
Content-Length: 4

0

GET /admin HTTP/1.1
Host: target{}
    

➡️Защита: единая HTTP-реализация на всех слоях, удаление конфликтующих заголовков, жёсткая валидация CL и TE. ⏺WebSocket hijacking через доверие к Origin: многие backend’ы считают WebSocket «внутренним» каналом и не проверяют Origin или cookies. Если пользователь авторизован, сторонний сайт может открыть WS-соединение от его имени и дергать приватные методы API.

    
        new WebSocket("wss://target/ws");{}
    

Если сервер принимает соединение без проверки Origin - канал скомпрометирован. ➡️Защита: строгая проверка Origin, отдельная авторизация для WebSocket, отказ от cookie-auth для WS. ⏺Prototype Pollution в JSON-API: если backend без фильтрации мержит пользовательский JSON в объект, можно подменить прототип и повлиять на глобальную логику приложения.

    
        {
  "__proto__": {
    "isAdmin": true
  }
}{}
    

В Node.js это часто ломает проверки ролей, feature-флаги и логику доступа. ➡️Защита: блокировка служебных ключей (proto, constructor, prototype), безопасные merge-функции, строгая schema-валидация. ZeroDay | #пентест

Как Firefox «уронил» интернет в Китае 👋 Приветствую в мире цифровой безопасности! Расскажу, как браузер, цензура и сетевые протоколы сошлись так, что на 74 минуты пропал интернет у целой страны. ⏺Всё началось спокойно. Долгие годы Великий Китайский файрвол боролся с современными веб-протоколами грубо, но эффективно, просто блокировал UDP. QUIC от Google, работающий поверх UDP, резался целиком. Метод топорный, ломает кучу легитимных сервисов, но работает. Примерно как блокировка Telegram в 2018: больно всем, но «цель достигнута». ⏺В апреле 2024 ситуация изменилась. Исследователи заметили: GFW научился выборочно блокировать QUIC по доменным именам, несмотря на шифрование. DPI начал перехватывать Client Hello, вычислять ключи через DCID и пытаться расшифровывать первый пакет. Если SNI оказывался в чёрном списке - соединение просто умиралo. ⏺Mozilla решила сыграть на тонкостях протоколов. Весной 2025, с выходом Firefox 137, в браузер добавили агрессивное использование ECH и SNI-слайсинга. Теперь Client Hello мог «размазываться» по нескольким пакетам или выглядеть эвристически неоднозначным. DPI приходилось угадывать, какие пакеты относятся к какому потоку. ⏺Нашлась и логическая дыра. Если сначала отправить корректный зашифрованный Client Hello к разрешённому домену, а затем почти сразу - к запрещённому, файрвол иногда ошибочно помечал весь поток как легитимный. Второй пакет просто пролетал мимо фильтра. Цензура моргала. ⏺Ещё веселее стало с фрагментацией. Разбитый Client Hello требовал сборки состояния, а у DPI банально не хватало памяти и CPU, чтобы держать миллионы таких потоков одновременно. Фрагментированные QUIC-пакеты часто проходили без анализа вообще. ⏺В августе 2025 на USENIX Security исследователи публично показали главное: принудительная дешифровка QUIC - это архитектурная слабость GFW. Попытка проверять каждый зашифрованный пакет превращала сам файрвол в бутылочное горлышко. При определённой нагрузке оборудование либо переставало фильтровать трафик, либо уходило в режим «блокировать всё». ⏺Реализовался худший сценарий. 20 августа 2025 года китайская сеть ушла в защитный режим: порт 443 (HTTPS/QUIC) оказался недоступен для целых провинций. Интернет в КНР частично пропал на 74 минуты. Формально - «защита», но по факту - национальный сетевой сбой. ⏺Финал оказался политическим. Стало ясно, что чинить QUIC точечно невозможно без побочных эффектов. Летом 2025 китайскому юрлицу Mozilla выдвинули ультиматум: либо внедрение государственного корневого сертификата для полноценного MITM, либо уход с рынка. Firefox инфраструктуру в Китае свернули, IP Mozilla заблокировали, ECH и слайсинг перестали работать. ZeroDay | #история

Подводим итоги года и делимся планами: встреча с командой UserGate Приглашаем вас на открытую онлайн-встречу с руководителями продуктовых направлений UserGate. В программе: ➜ Итоги и планы по продуктам и направлениям Что удалось в 2025 году и какие обновления ждут uNGFW, uSIEM, uWAF, uClient, uFactor и uAcademy в 2026-м ➜ Тренды в ИБ на 2026 год На что стоит обратить внимание в динамично меняющемся ландшафте киберугроз ➜ Ответы на ваши вопросы Задавайте вопросы заранее или в чате — обсудим всё, что вам интересно ➜ Подарки участникам Подготовили 10 призов для зрителей эфира. Их получат авторы лучшего вопроса по каждому из продуктов, трое победителей квиза, а также... Узнаете на встрече ;) Спикеры: руководители продуктовых направлений UserGate Когда: 22 января 2026 года, 10:00 (МСК) Приходите, будет интересно! Зарегистрироваться

Vuls: автоматизируем контроль уязвимостей 👋 Приветствую в мире цифровой безопасности! Поговорим о еще одном инструменте безопасности. ⏺Vuls - инструмент agent-less vulnerability scanner для Linux, *BSD, Windows, macOS, контейнеров, WordPress и библиотек. Его задача — снять с админа и ИБ рутину постоянной проверки CVE. Никаких агентов на серверах: либо SSH, либо передача данных по HTTP, либо локальный запуск. ⏺По факту Vuls отвечает не на вопрос «есть ли CVE», а «где именно у меня сейчас риск». Он собирает версии пакетов, ядра, библиотек и сервисов и сопоставляет их с NVD, OVAL дистрибутивов, security advisory, CISA KEV, PoC и exploit-базами. В отчёте сразу видно: уязвимо, эксплуатируется в дикой природе или нет. ⏺Архитектура простая: один центральный узел и любое количество хостов. Можно сканировать по SSH, можно работать в server mode без SSH вообще - хосты сами отправляют данные. ⏺Есть два ключевых режима: ➡️Fast Scan - без root, минимальная нагрузка, подходит для частых прогонов. ➡️Root Scan - с привилегиями: показывает процессы, которые всё ещё используют уязвимые библиотеки после обновлений, и подсвечивает сервисы, требующие рестарта. ⏺Базовый локальный запуск:

    
        vuls scan{}
    

Классический удалённый скан по конфигу:

    
        vuls scan -config=./config.toml{}
    

Root-скан для продов и критичных систем:

    
        vuls scan --sudo{}
    

⏺Сильная сторона Vuls - это, конечно, офлайн-режим. Он спокойно работает в средах без интернета, что делает его практичным для production и compliance-зон, где внешние соединения запрещены. ZeroDay | #Инструмент