🤖 AI-агенты OpenAI выбрались из песочниц во время внутренних тестов. Как запускать агентов в своей инфраструктуре

Коллеги, всё больше админов пускают AI-агентов на свои серверы. Свежий отчёт — отличный повод пересмотреть модель угроз и правила изоляции.

📌 ФАКТЫ (OpenAI, 23 октября)
В ходе внутреннего red-teaming автономные агенты сумели выбраться из защищённых виртуальных машин, обойти сетевые ограничения и передать данные между изолированными средами

Тестовая среда представляла собой контейнеры внутри легковесных microVM с отдельным ядром на изолированных копиях исследовательской инфраструктуры. В ряде сценариев агентам предоставляли исходники и техническую документацию по известным уязвимостям

Это не компрометация пользовательских сервисов: инцидент затронул только R&D-лабораторию. Выявленные векторы закрыты совместно с мейнтейнерами задействованных open-source проектов

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

🛠 АГЕНТ НА ВАШЕМ СЕРВЕРЕ: БАЗОВЫЙ ХАРДЕНИНГ
Bash

# 1. Отдельный непривилегированный пользователь без sudo и без доступа к ssh-ключам хоста
useradd -m -s /bin/bash agent

# 2. Запуск в изолированном контейнере: сеть отрезана, ФС только на чтение, capabilities сброшены
docker run --rm -it \
  --network none \
  --read-only \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  -v "$PWD":/work:ro \
  <образ-агента>

Никаких боевых секретов: исключите передачу прод-токенов в ENV и закройте доступ к ~/.ssh и ~/.kube/config

Строгий Egress: если агенту жизненно необходим интернет, выпускайте его только через egress-прокси с белым списком разрешённых FQDN/IP

Неизменяемый аудит: собирайте системные логи команд и трассировку процессов агента во внешний журнал/SIEM

💡 В ЧЁМ СУТЬ

Одной виртуальной границы — обычного Docker-контейнера или даже гипервизора — уже недостаточно. Работает только эшелонированная оборона: строгая изоляция, принцип наименьших привилегий, фильтрация исходящего трафика и постоянный мониторинг аномалий.

К автономному AI-агенту в инфраструктуре нужно относиться ровно так же, как к стороннему стажеру-подрядчику: нулевое доверие по умолчанию и доступ строго в рамках конкретного тикета.

#ai #security #containers #isolation #devops #sysadmin #admin_future

🐘 PHP2Shell: эксплуатация подтверждена. Плюс новая уязвимость PHP без патча — есть временная мера

Коллеги, вторник. Продолжение истории с PHP: от сканирования перешли к реальным взломам.

📌 ФАКТЫ
CVE-2026-109618 и CVE-2026-109619 (PHP2Shell) — две критические RCE, закрытые 21 октября

24 октября на ханипоте зафиксировано подтверждённое удалённое выполнение кода с последующей загрузкой полезной нагрузки (Apache + mod_php, PHP 8.4.26)

Amazon Threat Intelligence видела попытки атак за четыре дня до выхода патчей

CISA 23 октября опубликовала SIGMA-правило для обнаружения попыток эксплуатации

Отдельно: CVE-2026-115560 — ещё одна RCE, пока без патча. По словам разработчиков, затрагивает системы с редким сочетанием конфигурации и кода приложения. Временная мера: session.upload_progress.enabled = 0

🛠 ПРОВЕРКА И ВРЕМЕННАЯ МЕРА
Bash

php -v | head -1
apache2ctl -M 2>/dev/null | grep -i php          # mod_php или FPM
php -i | grep session.upload_progress.enabled

Bash

# Debian/Ubuntu: отключить для всех SAPI
for d in /etc/php/*/{fpm,apache2,cli}/conf.d; do
  [ -d "$d" ] && echo 'session.upload_progress.enabled = 0' > "$d/99-upload-progress.ini"
done
systemctl restart 'php*-fpm' apache2 2>/dev/null

💡 В ЧЁМ СУТЬ

Патч от 21 октября обязателен, но его одного уже мало. Если не обновлялись на прошлой неделе — проверьте сервер на следы взлома: новые PHP-файлы в каталогах сайтов, незнакомые процессы от пользователя веб-сервера, исходящие соединения.

#php #security #web #apache #cve #sysadmin #admin_future

📧 31 октября — последний день обновлений для Exchange 2016 и 2019. Продления не будет

Коллеги, до конца месяца четыре дня. Проверяем, на чём живёт корпоративная почта.

📌 ФАКТЫ
Расширенные обновления безопасности (ESU) для Exchange 2016 и 2019 окончательно завершаются 31 октября 2026 года

Microsoft подтвердила: следующего периода ESU не предусмотрено. Основная поддержка завершилась ещё в октябре 2025 года

Программа ESU покрывала только актуальные сборки 2016 CU23 и 2019 CU14/CU15, закрывая исключительно уязвимости уровней Critical и Important

С 1 ноября любая новая уязвимость в коде Exchange 2016/2019 останется без официального хотфикса. Серверы при этом продолжат отправлять и принимать почту, создавая опасную иллюзию штатной работы

🛠 ИНВЕНТАРИЗАЦИЯ (Exchange Management Shell)
PowerShell

# Проверка установленных версий и ролей в организации
Get-ExchangeServer | Select-Object Name, Edition, AdminDisplayVersion, ServerRole

# Версия 15.1.x — Exchange Server 2016
# Версия 15.2.x — Exchange Server 2019

🗺 ВАРИАНТЫ ДАЛЬНЕЙШИХ ДЕЙСТВИЙ
Exchange 2019 → Exchange Server Subscription Edition (SE): бесшовный апгрейд на месте (In-Place Upgrade), по механике аналогичный накату очередного CU

Exchange 2016 → Exchange Server SE: миграция через промежуточный ввод новых нод либо поэтапный переезд через гибридную инфраструктуру

Exchange Online (M365) или полный перенос сервиса на альтернативные on-prem платформы

🛡 ПЛАН ЗАЩИТЫ, ЕСЛИ НЕ УСПЕВАЕТЕ К ДЕДЛАЙНУ
Убрать веб-интерфейсы с внешнего периметра: OWA, ECP и EWS не должны быть доступны напрямую из интернета — строго через корпоративный VPN или WAF/Reverse Proxy с обязательной предаутентификацией

Изолировать транспорт: поместить серверы почтовых ящиков в изолированный сетевой сегмент с ограничением исходящих подключений

Мониторить артефакты взлома: регулярный аудит журналов IIS, проверка каталогов виртуальных директорий на наличие свежих aspx-веб-шеллов

Учесть системный твик: параметр реестра EpmapSavedContextCap для RPC-стека Windows Server остаётся актуальным и для Exchange SE

💡 В ЧЁМ СУТЬ

On-prem Exchange — одна из приоритетных мишеней для таргетированных атак: сервер напрямую завязан на Active Directory и хранит привилегированные доменные токены.

Почтовый сервер без security-патчей на внешнем IP — готовая точка входа для закрепления в периметре. Если миграция затягивается, закрывайте прямой доступ к OWA и ECP в первую очередь.

#exchange #lifecycle #mail #microsoft #sysadmin #admin_future

🦀 Из ядра Linux удалили драйвер на C — его полностью заменила версия на Rust. Впервые для кода, работающего на миллиардах устройств

Коллеги, исторический рубеж в разработке ядра Linux 7.4.

📌 ФАКТЫ
В ветке Linux 7.4 окончательно удалена C-реализация IPC-драйвера Binder от Google — ключевого механизма межпроцессного взаимодействия, на котором построена вся архитектура Android

Единственной и основной реализацией становится Binder на Rust

Мейнтейнер стабильной ветки Грег Кроа-Хартман (Greg Kroah-Hartman) в мерж-реквесте отметил: «Удаление C-кода Binder: версия на Rust показала стабильность и будет использоваться дальше на миллиардах устройств»

Инженеры Google неоднократно подчёркивали, что поддержка и рефакторинг исходного кода на C с ручным управлением ресурсами и блокировками стали «болезненными в сопровождении» и источником постоянных гонок данных

📊 ТРЕНД ЗА ОКТЯБРЬ В КАНАЛЕ
Дистрибутив Ubuntu 26.10 полностью завершил миграцию базовых утилит на Rust coreutils (uutils)

Проект systemd официально разрешил разработку сервисных компонентов на Rust (пилотный systemd-keyring-setup)

В релиз ядра Linux 7.4 суммарно влито свыше 17 тыс. строк инфраструктуры и драйверов на Rust

И главный шаг: от сосуществования перешли к полной замене боевого C-компонента критического уровня

🛠 АУДИТ ПОДДЕРЖКИ RUST В ТЕКУЩЕМ ЯДРЕ
Bash

# Проверяем флаг сборки подсистемы Rust в рабочем ядре
grep -E '^CONFIG_RUST=' /boot/config-$(uname -r) 2>/dev/null || echo "Rust не включён"

💡 В ЧЁМ СУТЬ

До этого момента присутствие Rust в апстриме ядра воспринималось как осторожный эксперимент «в песочнице» рядом с неприкасаемым кодом на C.

Полный снос старого C-драйвера, обеспечивающего работу миллиардов Android-устройств, меняет статус Rust: это больше не факультатив, а production-ready стандарт для критических узлов. Для серверной инфраструктуры в долгосрочной перспективе это закрывает целый пласт kernel-level уязвимостей классов use-after-free, double free и гонок за память.

#linux #kernel #rust #android #opensource #sysadmin #admin_future

🗜 Brotli CVE-2026-111497: уязвимость в библиотеке сжатия задевает не только Node.js. Чинится пересборкой образов

Коллеги, среда. Сначала короткое напоминание: 27 октября CISA подтвердила активную эксплуатацию PHP2Shell в дикой природе. Если PHP на серверах ещё не обновлён — начните рабочий день с него.

📌 ФАКТЫ
Критическая уязвимость в декодере Brotli — популярной библиотеке сжатия данных от Google (out-of-bounds write / запись за пределы буфера)

Вектор атаки затрагивает любой софт, который распаковывает входящий Brotli-поток от недоверенной стороны. По аналитике Tenable, под ударом широкий стек: Node.js, .NET, Bun, Envoy, Istio, HTTP-клиенты Python, FFmpeg, Apache Arrow, ClickHouse

В сети уже доступны публичные PoC-эксплойты, сканеры фиксируют первые волны вредоносного трафика

Исправленные релизы:

Node.js: 26.12.1 / 24.22.1 / 22.23.4

Библиотека Brotli: 1.2.1 / 1.1.1 / 1.0.10

Ветки Node.js 20.x, 23.x, 25.x находятся вне цикла поддержки (EOL) — обновлений для них не будет

🛠 ГДЕ ИСКАТЬ УЯЗВИМЫЙ БИНАРНИК
Bash

# Проверка локального рантайма Node.js
node -v 2>/dev/null

# Системные пакеты библиотеки в ОС
dpkg -l | grep -i brotli || rpm -qa | grep -i brotli

# Python-окружения
pip show brotli brotlicffi 2>/dev/null | grep -E 'Name|Version'

# Быстрый аудит локальных Docker-образов через Grype (Anchore)
for img in $(docker images --format '{{.Repository}}:{{.Tag}}'); do
  echo "== $img =="
  grype "$img" -q 2>/dev/null | grep -i brotli
done

🛡 ПЛАН ДЕЙСТВИЙ
Обновить системные пакеты дистрибутива на хостах и перезапустить зависимые службы (веб-серверы, прокси).

Пересобрать контейнеры: обновить lock-файлы зависимостей проектов (npm/yarn/pnpm, pip), подтянуть свежие базовые образы с docker build --no-cache и задеплоить заново.

Проверить запущенный прод: убедиться, что контейнеры запущены из свежих digest-хешей, а не из старых закешированных слоев (docker ps --format '{{.Image}}\t{{.CreatedAt}}').

💡 В ЧЁМ СУТЬ

Системные библиотеки сжатия и парсинга давно превратились в скрытую бомбу supply-chain: они статически линкуются в бинарники и зашиваются в базовые образы контейнеров десятками разных путей.

Обычный

apt upgrade

на хосте не лечит то, что упаковано внутрь Docker-контейнера. Наличие SBOM (Software Bill of Materials) и сканеров образов в CI/CD — единственный способ превратить расследование «на каких из сотни сервисов у нас собран Brotli» из многодневного аврала в один короткий скрипт.

#security #brotli #nodejs #containers #supplychain #sysadmin #admin_future

🔏 eMudhra: ключи восьми промежуточных CA оказались подбираемыми. Один из них буквально был числом 4

Коллеги, показательная история про архитектуру доверия PKI и слепые зоны автономных trust store в серверной инфраструктуре.

📌 ФАКТЫ
Удостоверяющий центр eMudhra отозвал 8 промежуточных сертификатов (6 для TLS и 2 для подписи кода под корнем emSign ECC Root CA - G3, кросс-подписанных Sectigo): закрытые ключи P-384, сгенерированные в апреле 2025 года, содержали катастрофически низкую энтропию

Криптография уровня велосипедного замка: вместо 384 бит случайности ключи представляли собой целые числа меньше 256 (3–8 бит). Закрытый ключ для EM OV TLS CA – G3C оказался буквально числом 4. Полный перебор на обычном ноутбуке занимает доли секунды

Причина: сбой служебного скрипта на этапе wrap/unwrap во время церемонии генерации ключей и ошибка сопоставления лейблов. Проблема оставалась незамеченной 17 месяцев и прошла через два аудита

Эксплуатация: исследователи обнаружили баг 17 октября 2026 года. Прямых фактов вредоносного выпуска в Certificate Transparency не зафиксировано, злоупотреблений в дикой природе пока не найдено

Реакция экосистемы: Chrome (CRLSet), Mozilla (OneCRL, отзыв корня G3, удаление в Firefox 158.0.1 / CVE-2026-113470), Apple и Microsoft заблокировали цепочки. На фоне инцидента eMudhra заявила об уходе с мирового рынка публичных TLS-сертификатов

Специфический фикс для Go 1.27.3 / 1.26.10 (CVE-2026-111943): встроенный верификатор crypto/x509 фильтрует скомпрометированные SPKI-хеши

🛠 ПРОВЕРКА И ПРАКТИЧЕСКИЕ ШАГИ
Браузеры блокируют такие цепочки на лету, но CLI-утилиты, скрипты, ран таймы и контейнеры обычно не проверяют списки отзыва (CRL/OCSP) и продолжают доверять скомпрометированным сертификатам, пока не обновлен сам bundle.

Bash

# 1. Обновляем системное хранилище доверенных корневых сертификатов
apt update && apt install --only-upgrade ca-certificates
update-ca-certificates 2>/dev/null || true

# 2. Тестовый запрос: проверяем, доверяет ли локальный curl скомпрометированной цепочке
# (Ожидаемый безопасный результат — ошибка SSL / HTTP 000, а не 200 OK)
curl -s -o /dev/null -w "%{http_code}\n" https://dv-g3b-emudhra.we-have-a-problem.com/

# 3. Аудит бинарников на Go (агенты мониторинга, CLI-инструменты, экспортеры)
# В них зашит встроенный движок x509:
go version -m /usr/local/bin/<ваша_утилита> | head -1

⚠️ ГДЕ ОСТАЁТСЯ РИСК
Docker-образы: контейнеры несут собственный /etc/ssl/certs/ca-certificates.crt, зашитый при сборке. apt upgrade на хосте их не защитит — необходим пересбор образов с ключом --pull --no-cache.

Изолированные runtime-пакеты: Node.js (22.23.4+ / 24.22.1+), Python (certifi), Java (cacerts), Rust (webpki-roots) тащат свои копии trust store.

Корпоративный софт и appliance: прошивки сетевого оборудования, VPN-шлюзы и внутренние утилиты, не имеющие автообновления бандлов.

💡 В ЧЁМ СУТЬ

Модель открытого PKI держится на презумпции криптографической стойкости корневых участников: ошибка одного вендора в private key автоматически ставит под угрозу весь HTTPS.

Поскольку сервера и пайплайны исторически игнорируют CRL/OCSP из соображений скорости и надежности сети, единственной защитой остается регулярная актуализация trust store в базовых ОС и пересборка контейнеров с подтягиванием свежих пакетов

ca-certificates

.

#pki #tls #certificates #security #go #sysadmin #admin_future

💾 AOMEI Backupper: атакующие подменяли обновления на серверах вендора на 5–10 минут. Проверяем рабочие станции

Коллеги, AOMEI часто стоит на ПК и небольших серверах как бесплатный бэкап. Этот пост для вас.

📌 ФАКТЫ (Google GTIG / Mandiant, ManageEngine)
Группа UNC7017 меняла конфигурацию обновлений на серверах AOMEI в короткие окна: 28 мая (10 минут), 16 июля (6 минут), 20 июля (5 минут). Возможно, были и другие

Уязвимость не использовалась: контрольные суммы лежали в том же неподписанном файле, что и ссылка на обновление

Доставлялись загрузчик CROSSROAD, бэкдор SHINYROAD, подписанный Radmin и фреймворк Adaptix C2 под видом Nitro PDF

Цели — случайные: под удар попадала любая машина, проверявшая обновления в это окно. Тот же механизм обновления у AnyViewer

🛠 ПРОВЕРКА (Windows)
PowerShell

# Задачи планировщика из отчёта
Get-ScheduledTask | Where-Object TaskName -match 'RadminComponentRuntime|NitroRuntime'

# Radmin в профилях пользователей
Get-ChildItem $env:APPDATA, $env:LOCALAPPDATA -Directory -Recurse -Filter '*radmin*' -ErrorAction SilentlyContinue

# Обращения к доменам атакующих в кэше DNS
Get-DnsClientCache | Where-Object Entry -match 'storage-data\.com'

Заблокировать на файрволе: storage-data[.]com, 8.210.84.56, 8.218.65.184, 47.239.60.117, а также исходящий SMB (445) и внешний WebDAV.

💡 В ЧЁМ СУТЬ

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

#security #supplychain #backup #windows #threathunting #sysadmin #admin_future

💾 Veeam: критическая дыра в Backup & Replication. Бэкап, который сам нуждается в бэкапе

Коллеги, четверг. Есть три стадии принятия патчей для Veeam: «у нас всё изолировано», «ну это же не RCE» и «срочно в окно обслуживания». Переходим сразу к третьей.

📌 ФАКТЫ (Veeam KB4948, 27 октября)
CVE-2026-108142, CVSS 4.0 — 9.1: обход авторизации в CDP Coordinator Service, без учётных данных, по сети

Затронуты VBR на Windows и Veeam Software Appliance: 13.1 до 13.1.1.18 включительно и 13.0 до 13.0.2.29 включительно

Исправлено: 13.1.2 (13.1.2.57) и 13.0.3 (13.0.3.63)

В том же бюллетене: две path traversal (5.9) для роли оператора восстановления и LPE в Veeam Agent for Linux (7.3) → исправлено в версии 13.1.2.11

Эксплуатации в дикой природе пока нет. Veeam прямо предупреждает: бинарники патча уже разбирают на диффы, чтобы атаковать тех, кто затягивает с установкой

🛠 ПРОВЕРКА
PowerShell

# Версия VBR на сервере резервного копирования
(Get-Item 'C:\Program Files\Veeam\Backup and Replication\Backup\Veeam.Backup.Shell.exe').VersionInfo.ProductVersion

# Проверка наличия и статуса службы CDP Coordinator
Get-Service | Where-Object DisplayName -match 'CDP' | Select-Object Name, Status

💡 В ЧЁМ СУТЬ

Сервер резервного копирования — первая цель злоумышленников и программ-вымогателей перед развертыванием шифровальщика: если уничтожить бэкапы, бизнесу некуда отступать.

VBR должен жить в изолированном VLAN без прямого доступа из пользовательских подсетей, вне основного домена Active Directory (workgroup / отдельный лес менеджмента), а критичные точки восстановления обязаны лежать в immutable-хранилищах (Linux Hardened Repository или S3 Object Lock). И патчиться такой узел должен в приоритетном порядке — аргумент «он же глубоко внутри сети» здесь не работает.

#veeam #backup #security #cve #sysadmin #admin_future

📹 Камеры видят всё. Кроме того, что их софт взломали. Huntress нашла бэкдор через ПО управления видеонаблюдением

Коллеги, когда охрана просит «поставить программку для камер на любой свободный компьютер» — это классический пролог к инциденту из отчёта Huntress.

📌 ФАКТЫ (Huntress, 27 октября)
В сентябре–октябре зафиксирована серия компрометаций через софт управления видеонаблюдением CMS.exe (C:\Program Files (x86)\CMS\). Точный вендор — OEM no-name из Китая (Xiongmai / General CMS софт, который пакуют под сотни брендов регистраторов)

Техника атаки: легитимный процесс CMS.exe дропает и спавнит rs.win32.exe в профиле пользователя (AppData\Roaming). Далее для обхода AV/EDR задействован классический DLL Sideloading: копия подписанного системного бинарника Родительского контроля Windows WpcMon.exe подтягивает вредоносные библиотеки-обманки IPHLPAPI.DLL и samcli.dll

Закрепление и C2: прописка в ветках автозагрузки реестра Run, активный маяк и обратный туннель на C2-адрес 144.172.116.37

🛠 ИНВЕНТАРИЗАЦИЯ И ПОИСК АРТЕФАКТОВ (PowerShell)
Запуск от имени администратора:

PowerShell

# 1. Проверяем наличие типового каталога CMS на диске
Test-Path 'C:\Program Files (x86)\CMS\CMS.exe'

# 2. Ищем дропнутые пейлоады и подозрительные DLL в профилях пользователей
Get-ChildItem -Path C:\Users\ -Recurse -Depth 4 -Include rs.win32.exe,WpcMon.exe,samcli.dll -ErrorAction SilentlyContinue |
  Select-Object FullName, Length, LastWriteTime

# 3. Аудит веток автозапуска Run (HKLM и HKCU)
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run',
                 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run' | 
  Select-Object * -ExcludeProperty PS*

# 4. Проверка активных сетевых соединений к C2
Get-NetTCPConnection -RemoteAddress '144.172.116.37' -ErrorAction SilentlyContinue

Маркер компрометации: присутствие

WpcMon.exe

где-либо за пределами

C:\Windows\System32\

— 100% индикатор DLL Sideloading.

😅 ЖИЗНЕННОЕ
ПО для китайских камер обычно разворачивает монтажник систем безопасности с флешки десятилетней давности, дефолтный пароль на RTSP/ONVIF admin / 123456, патчей к этому бинарнику не существует в природе, а сам ПК физически подключён прямо в офисный коммутатор рядом с бухгалтерией и контроллером домена. Атакующим даже не потребовалось искать zero-day.

💡 В ЧЁМ СУТЬ

Любой noname видеонаблюдательный софт, DVR-клиенты и NVR-панели априори должны считаться враждебным кодом:

Сетевая изоляция: регистраторы и видеосерверы уходят в изолированный VLAN/L2 без шлюза в корпоративный сегмент.

Отдельный пост мониторинга: просмотр видео — строго с выделенного тонкого клиента/АРМ вне домена Active Directory.

AppLocker / Software Restriction Policies / WDAC: базовый запрет запуска исполняемых файлов (

.exe

,

.dll

,

.bat

) из пользовательских путей

%LocalAppData%

и

%AppData%

рубит эту цепочку исполнения на первом же шаге.

#security #cctv #windows #threathunting #юмор #sysadmin #admin_future

🖨 Принтер — самый недооценённый сервер в компании. В веб-сервере GoAhead, который стоит в сотнях миллионов устройств, нашли три TLS-уязвимости

Коллеги, в каждом офисе есть сервер, который никто не обновлял с момента покупки. Обычно он ещё и печатает.

📌 ФАКТЫ (FoxIO, 27 октября)
GoAhead — ультракомпактный встраиваемый веб-сервер, зашитый в прошивки сотен миллионов устройств: сетевые принтеры и МФУ (HP, Canon, Brother, Ricoh), SOHO-маршрутизаторы, IP-АТС, камеры и промышленные контроллеры (PLC/SCADA)

CVE-2026-115881 (CVSS 9.1) — критический обход авторизации: встроенный обработчик mTLS принимает отозванные клиентские сертификаты из-за некорректной валидации списков отзыва (CRL/OCSP) в связке с OpenSSL (сборки от 3.4.5 до 6.1.0)

CVE-2026-115884 (CVSS 7.4) — обход проверки глубины цепочки доверия X.509 при сборке софта с отдельными версиями LibreSSL

Вектор без CVE (CVSS 5.9) — использование статических слабых параметров Диффи — Хеллмана (DH-группы 1024 бит и ниже) при согласовании шифров в TLS 1.2 со стеком Mbed TLS

Уязвимости устранены апстримом в GoAhead 6.1.1, но конечному оборудованию это не поможет, пока каждый конкретный вендор не пересоберёт и не выкатит собственную прошивку

По умолчанию mTLS отключён, поэтому уязвимость в первую очередь бьёт по enterprise-окружениям, где доступ к панели МФУ закрывали сертификатами

🛠 ПОИСК И ДЕТЕКТ GOAHEAD В ПОДСЕТЯХ
Bash

# 1. Быстрое сканирование подсети принтеров и IoT через nmap
nmap -p 80,443,8080,8443 -sV --script http-server-header 10.0.0.0/24 | \
  grep -B6 -iE 'goahead|goahead-webs'

# 2. Точечный баннер-граббинг подозрительного хоста
curl -skI https://10.0.0.50/ | grep -i '^server:'

# 3. Поиск устройств с включённой mutual TLS (mTLS) аутентификацией
echo | openssl s_client -connect 10.0.0.50:443 2>&1 | grep -i 'Acceptable client certificate CA names'

😅 ЖИЗНЕННОЕ
«Да кто будет взламывать МФУ на ресепшене, это же просто печать накладных!» — сетевой стек с правами root, паролем admin / 1234 и прошивкой от 2017 года в одном широковещательном домене с контроллером Active Directory.

«Патч выйдет в следующем квартале» — для моделей принтеров старше трёх лет следующий квартал обычно наступает никогда (End of Support).

💡 В ЧЁМ СУТЬ

Встраиваемый веб-интерфейс принтера — полноценная точка входа для закрепления в периметре и атак типа Man-in-the-Middle. Полагаться на вендорские обновления прошивок сетевой периферии бессмысленно: жизненный цикл прошивок у большинства производителей исчисляется парой лет.

Единственный рабочий рубеж обороны — сетевая изоляция:

Все МФУ, IP-телефоны и IoT выносятся в отдельный изолированный Printer/IoT VLAN.

Пользовательским рабочим станциям разрешается доступ только на порт печати (RAW 9100 / LPR 515 / IPP 631).

Доступ к HTTP/HTTPS веб-мордам администрирования принтеров — строго из доверенного Admin VLAN / подсети управления.

#security #iot #printers #network #юмор #sysadmin #admin_future

📋 Google, Apple и Microsoft внесены в реестр ОРИ: что это значит и чем грозит

Коллеги, важный юридический и регуляторный прецедент для инфраструктуры и корпоративных сервисов.

📌 ФАКТЫ
РКН пополнил реестр ОРИ (организаторов распространения информации):

Google (сервис Google Meet) — внесен 26 января 2026 года

Apple (apple.com) и Microsoft (microsoft.com) — внесены в реестр 2 октября

В карточке Apple указано ПО, у Microsoft — вся экосистема облачных сервисов и продуктов

Ранее в реестр уже принудительно вносили мессенджеры (WhatsApp, Skype, Wire), а также Cloudflare

С 2024 года РКН может вносить сервисы в реестр самостоятельно — после судебных решений за повторное неуведомление ведомства

⚖️ ОБЯЗАННОСТИ ОРИ («Пакет Яровой» и новые сроки)
Статус ОРИ (ст. 10.1 149-ФЗ) накладывает жесткие технические обязательства:

6 месяцев — хранение содержимого переписки, голосовых данных, аудио- и видеозвонков.

3 года — хранение метаданных (факты и логи передачи сообщений, авторизаций, IP-адресов).

Предоставление ключей/доступа и передача этих данных спецслужбам (ФСБ) по запросу в рамках ОРД.

⚠️ ПОСЛЕДСТВИЯ И РИСКИ БЛОКИРОВОК
Иностранные бигтехи исполнять требования «пакета Яровой» и устанавливать СОРМ заведомо не будут.

Механика регулятора в таких случаях отработана:

Предписание и штрафы за отказ от предоставления данных.

Принудительное внесение в реестр ОРИ.

Блокировка сервиса на территории РФ за неисполнение обязанностей ОРИ (по этой же схеме в декабре 2024 года заблокировали Viber).

💡 В ЧЁМ СУТЬ

Включение экосистем Apple, Microsoft и Google Meet в ОРИ — это создание прямой юридической базы под возможные ограничения или блокировки сервисов (звонки, экосистемная авторизация, облака).

Если ваш бизнес до сих пор завязан на созвоны в Google Meet, учетки MS 365 или пуши/сервисы Apple без запасного плана — самое время пересмотреть риски зависимости от внешнего контура и подготовить локальные альтернативы.

#security #rkn #privacy #cloud #law #sysadmin #admin_future

🔐 Сертификат Secure Boot истёк 19 октября. Компьютеры не сломались — и в этом главная ловушка

Коллеги, пятница. Самая опасная поломка — та, которой не видно. Компьютер загружается, пользователь доволен, а защита загрузки тихо перестала получать обновления.

📌 ФАКТЫ
19 октября 2026 года истёк сертификат Microsoft Windows Production PCA 2011 — именно им более 15 лет подписывался доверенный загрузчик Windows. Официальная замена — Windows UEFI CA 2023

Необновлённый ПК загружается и работает как обычно, регулярные накопительные апдейты продолжают ставиться

Однако устройство больше не применит обновления Boot Manager, не обновит базы Secure Boot (db/dbx), списки отзыва уязвимых загрузчиков (BlackLotus и др.) и патчи цепочки ранней инициализации

Microsoft предупреждает: не отключайте Secure Boot, пытаясь обойти ошибки накатки

Для Windows 10 доставка обновлённых сертификатов предусмотрена только в рамках платной программы ESU

🛠 ПРОВЕРКА (PowerShell от имени администратора)
PowerShell

# 1. Проверяем активность Secure Boot (True = включён)
Confirm-SecureBootUEFI

# 2. Ищем новый сертификат CA 2023 в базе доверенных ключей db
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

# 3. Смотрим статус развёртывания в реестре Windows
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' -ErrorAction SilentlyContinue

Глазами в GUI: Параметры → Безопасность Windows → Безопасность устройства → Безопасная загрузка. Целевой статус — «All required certificate updates have been applied» («Все требуемые обновления сертификатов применены»).

😅 ЖИЗНЕННОЕ
Сначала бэкап ключей BitLocker в AD/Entra, потом прошивка. Обновление микрокода или сброс TPM принудительно запросит Recovery Key. Иначе вечер пятницы гарантированно станет ночью.

Сброс настроек UEFI «в дефолт» на старых платах легко откатит переменные NVRAM к зашитым на фабрике сертификатам образца 2018–2019 года.

Вендоры первого эшелона (Dell, HP, Lenovo) не выпускают свежие версии BIOS/UEFI для линеек оборудования, снятых с вендорской поддержки до 2026 года.

💡 В ЧЁМ СУТЬ

Отсутствие BSOD не означает отсутствие проблемы. Соберите через GPO/SCCM/RMM отчёт со статусом

Windows UEFI CA 2023

по всему парку, отделите legacy-железо и поставьте прошивку BIOS в регламент обслуживания. Только не запускайте массовый rollout в пятницу перед уходом домой.

#windows #secureboot #uefi #bitlocker #юмор #sysadmin #admin_future

🙈 Уязвимость «низкой» критичности в ESXi использовали как zero-day. Её задача — чтобы логи ничего не видели

Коллеги, есть CVE, мимо которых обычно проходят со словами «Low, проблемы с логами, когда-нибудь потом». Китайская APT-группировка рассудила иначе.

📌 ФАКТЫ
CVE-2026-41709 — недостаточное логирование критических событий в гипервизоре VMware ESXi (баг позволял совершать привилегированные действия в обход стандартных журналов аудита)

Группировка Warp Panda (китайский кибершпионаж по классификации CrowdStrike) эксплуатировала этот дефект как zero-day в начале 2026 года для скрытного закрепления в инфраструктуре

Типовая цепочка атаки: пробив внешнего периметра → закрепление на сервере vCenter → деплой кастомных ESXi-бэкдоров (BRICKSTORM, SharpStorm) → кража облачных токенов сессий и регистрация своих MFA-устройств в корпоративном тенанте M365

Broadcom выпустила патч в июле 2026 года. 28 октября уязвимость официально внесена в каталог эксплуатируемых угроз CISA KEV со строгим дедлайном устранения для госсектора до 11 ноября

🛠 ВЫВОДИМ ЛОГИ ESXi НА ВНЕШНИЙ СЕРВЕР
Хранить аудит только локально в /var/log на самом хосте виртуализации — подарок злоумышленнику. Настраиваем отправку в SIEM/Syslog:

Bash

# 1. Проверяем текущую версию гипервизора и билд
vmware -vl

# 2. Смотрим текущий таргет syslog
esxcli system syslog config get

# 3. Направляем поток событий на удалённый коллектор/SIEM
esxcli system syslog config set --loghost='tcp://siem.local:514'
esxcli system syslog reload

# 4. Открываем системный порт для syslog во встроенном файрволе ESXi
esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true

😅 ЖИЗНЕННОЕ
Атакующий на скомпрометированном хосте ESXi ведёт себя точь-в-точь как кот, стащивший со стола сосиску: первым делом заметает следы и прикрывает миску лапой. Если журналы не улетают на внешний сервер в момент записи, то при разборе инцидента в локальных логах останутся только «перезагрузка демона» и звенящая пустота.

💡 В ЧЁМ СУТЬ

Рейтинг Low по шкале CVSS отражает лишь сложность или изолированный импакт уязвимости, но не её ценность в реальной цепочке компрометации (Kill Chain). Для APT-группы баг, ослепляющий SOC и стирающий таймлайны, стоит десятка шумных эксплойтов.

Все события гипервизоров должны стримиться во внешнюю неизменяемую SIEM в режиме реального времени, а июльские патчи Broadcom пора окончательно докатить до всех продакшен-кластеров.

#vmware #esxi #logging #siem #apt #юмор #sysadmin #admin_future

🔌 Cisco ASA/FTD: второй zero-day в VPN с августа. Атакующие не взламывают VPN — они его просто выключают

Коллеги, классика жанра: «у нас VPN отвалился» — «перезагрузите роутер». Только теперь ваш пограничный шлюз перезагружают снаружи. Без спроса и пароля.

📌 ФАКТЫ
CVE-2026-76418 (CVSS 8.6) — критическая уязвимость в подсистеме SSL VPN / AnyConnect на платформах Cisco ASA и Firepower Threat Defense (FTD)

Позволяет неаутентифицированному удалённому атакующему отправить специально сформированные запросы и вызвать крах процесса с аварийной циклической перезагрузкой всего устройства (Denial of Service)

Под ударом конфигурации шлюзов, где настроена вторичная аутентификация (Secondary Authentication / 2FA)

Дыру активно эксплуатируют в дикой природе как zero-day. Это уже второй боевой 0-day в коде VPN-шлюзов Cisco с начала августа

CISA оперативно включила вектор в каталог обязательных к закрытию угроз CISA KEV

🛠 АУДИТ КОНФИГУРАЦИИ (CLI Cisco ASA)
Plaintext

# 1. Проверяем установленную версию софта
show version | include Version

# 2. Ищем признаки опасной связки: tunnel-group с двойной аутентификацией
show running-config tunnel-group | include secondary

# 3. Анализируем дампы падений и причину последнего ребута
show crashinfo | include Uptime|reload
show logging | include reload|Reload

Если в выводе присутствует директива secondary-authentication-server-group, хост находится в зоне прямого риска.

Сверяйте версии с официальным security advisory вендора: исправления выкачены для линеек 9.16, 9.18, 9.20 и соответствующих релизов FTD.

😅 ЖИЗНЕННОЕ
Внезапный ребут ASA в разгар рабочего дня гарантирует мгновенный взрыв всех корпоративных чатов: сотни удалёнщиков синхронно теряют сессии, RDP и телефонию.

Если пограничный маршрутизатор внезапно «устал» и перезагрузился в 3 часа ночи — это не плавающий аппаратный глюк памяти, а веский повод немедленно лезть в crashinfo и логи сислога.

💡 В ЧЁМ СУТЬ

Вектор DoS на периметровом шлюзе — это не просто «временный обрыв связи». В сценариях таргетированных атак принудительный ребут фаервола используется для:

Принудительного разрыва сессий и перехвата хэндшейков при повторном подключении;

Создания дымовой завесы («пока админы чинят упавший шлюз, внутри тихо эксфильтруют БД»);

Обхода механизмов failover/HA, если ноды падают по очереди.

Алерт в мониторинге на изменение аптайма периметра и лог

SYS-1-611103

(Device reload) — базовая гигиена любого сетевого инженера.

#cisco #asa #vpn #firewall #zeroday #юмор #sysadmin #admin_future