🐧 Linux: Debian 14 «Forky» вводит обязательные воспроизводимые сборки — и это меняет supply chain security

Коллеги, 10 мая Debian Release Team объявила о решении которого ждали годами. Debian теперь блокирует пакеты, не прошедшие проверку воспроизводимой сборки, от попадания в testing. Это работает с 9 мая, во время текущего цикла разработки Forky. Правило распространяется и на уже существующие пакеты — если обновление нарушает воспроизводимость, миграция блокируется.

Что такое reproducible builds на практике:

Когда пакет собирается воспроизводимо, компиляция одного и того же исходного кода в одном и том же окружении каждый раз даёт идентичный бинарный файл. Это позволяет любому проверить, что дистрибутируемые бинари соответствуют опубликованному исходному коду. Звучит как само собой разумеющееся — но на практике это не так. Метки времени в сборке, случайные идентификаторы, порядок файлов — всё это делает бинари разными при каждой сборке.

Почему это важно именно сейчас:
Независимо верифицируемый путь от исходного кода к бинарному файлу становится всё более критичным с точки зрения безопасности цепочки поставок. XZ Utils backdoor, атаки на npm-пакеты, скомпрометированные CI/CD пайплайны — всё это атаки на supply chain. Reproducible builds делают их детектируемыми.

# Как проверить воспроизводимость пакета в Debian прямо сейчас:
# Смотрим статус на reproduce.debian.net
curl -s "https://reproduce.debian.net/api/v0/pkgset/by_name/unstable/openssh" \
    | python3 -m json.tool | grep -E "status|suite"

# Для своей системы — проверяем установленные пакеты через debsums:
apt install debsums
debsums -c  # проверяем контрольные суммы файлов

# Для разработчиков пакетов — проверяем воспроизводимость через reprotest:
apt install reprotest
reprotest -- dpkg-buildpackage -b .
# Собирает пакет дважды в разных условиях и сравнивает результат

# Смотрим общий дашборд воспроизводимости Debian:
# https://reproduce.debian.net/
# На момент анонса: >98% пакетов уже воспроизводимы на всех архитектурах

Debian 14 «Forky» также станет первым релизом с нативным rollback, undo и историей операций в APT package manager. Выход ожидается в июне-августе 2027 года.

Итог: reproducible builds — это не академия. Это инфраструктурный фундамент доверия к пакетам. Debian сделал это обязательным. Остальным дистрибутивам теперь неловко этого не делать.

#linux #debian #security #supplychain #sysadmin #admin_future

🐧 Linux: Atomic Arch — 1500 AUR-пакетов с rootkit. Это не про Arch, это про доверие

Коллеги, 11 июня в сообществе Arch Linux произошло кое-что важное для всех — даже для тех, кто никогда не видел pacman. Потому что этот инцидент — учебник по современным supply chain атакам.

Атакующие систематически брали под контроль брошенные AUR-пакеты — проекты, покинутые оригинальными мейнтейнерами — и модифицировали их сборочные скрипты. Пакеты сохранили свои имена, историю и доверие пользователей. Изменились только инструкции сборки.

Masштаб: более 1500 пакетов скомпрометировано. Вредоносные PKGBUILD были изменены для тихой загрузки и установки двух npm-пакетов: atomic-lockfile и js-digest. Эти пакеты разворачивали Rust-написанный credential stealer, нацеленный на SSH-ключи, API токены, браузерные сессии, docker credentials и cloud API keys.

Особенность которая усложняет очистку: при получении root малварь загружает eBPF-руткит. Три BPF maps в /sys/fs/bpf/ управляют тем что скрыто: hidden_pids удаляет процессы из ps, hidden_names прячет файлы из ls, hidden_inodes скрывает по inode. Руткит также блокирует присоединение отладчика.

# Если у тебя есть Arch или Arch-based в инфраструктуре:

# 1. Проверяем установленные AUR-пакеты:
pacman -Qm  # Список всех foreign (AUR) пакетов
# Сверяем с известными затронутыми: md.archlinux.org/s/SxbqukK6IA

# 2. Проверяем установки ПОСЛЕ 11 июня:
grep "installed" /var/log/pacman.log | \
    awk -F '[][]' '{print $2, $4}' | \
    awk '$1 >= "2026-06-11"' | head -30

# 3. Проверяем наличие eBPF rootkit:
ls /sys/fs/bpf/ 2>/dev/null
# Подозрительные: hidden_pids, hidden_names, hidden_inodes

# 4. Если затронутый пакет установлен — TREAT AS COMPROMISED:
# НЕ просто удали пакет — руткит уже выполнился
# Шаги:
# - Изоли систему от сети
# - Сразу ротируй ВСЕ credentials с другой машины:
#   SSH keys, GitHub PATs, npm tokens, AWS/GCP/Azure credentials
#   Docker registry tokens, всё в .env файлах, shell history
# - Загрузись с Arch ISO, проверь /etc/systemd/system/ на лишние юниты
# - Всерьёз рассмотри полную переустановку

# 5. Превентивные меры для будущего:
# В makepkg.conf — всегда просматривать PKGBUILD перед сборкой
export PKGBUILD_REVIEW=1
# Или использовать paru с --fm для просмотра через файловый менеджер:
paru -S --fm nvim package_name

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

Тот же вектор работает в npm (orphaned packages), PyPI, Cargo. Проверяй orphaned packages и пакеты с недавней сменой мейнтейнера в любом реестре.

Итог: любой AUR-пакет установленный между 11-12 июня — под вопросом. Если нашёл затронутый — считай систему полностью скомпрометированной и ротируй credentials. Пакет-менеджером это не починить.

#linux #supplychain #arch #aur #security #sysadmin #admin_future

🧠 Skills: IBM и Red Hat нашли 400+ неизвестных уязвимостей в Java-библиотеках. А вы знаете, сколько JAR-файлов у вас на серверах?

Коллеги, важная новость из мира Enterprise Open Source — отличный повод прокачать навык инвентаризации зависимостей в инфраструктуре.

📌 ФАКТЫ
Программа Lightwell: совместная инициатива IBM и Red Hat закрыла более 400 ранее неизвестных уязвимостей в популярных Java-библиотеках.

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

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

Текущий статус: точные названия библиотек и идентификаторы CVE пока держатся под эмбарго — исправления постепенно уходят в апстрим по процедуре ответственного раскрытия (Coordinated Vulnerability Disclosure).

🛠 ИНВЕНТАРИЗАЦИЯ JAVA НА СЕРВЕРАХ ЗА 5 МИНУТ
Bash

# 1. Считаем общее число JAR-файлов в локальной файловой системе (без сетевых шар)
find / -xdev -name '*.jar' 2>/dev/null | wc -l

# 2. Топ каталогов с наибольшей концентрацией JAR (где прячется JVM-софт)
find / -xdev -name '*.jar' 2>/dev/null | xargs -r dirname | sort | uniq -c | sort -rn | head

# 3. Инспекция «толстых» JAR/fat-JAR (Spring Boot) без полной распаковки архива
unzip -l app.jar | grep -E 'BOOT-INF/lib/.*\.jar' | awk '{print $4}'

# 4. Сборка полного SBOM (Software Bill of Materials) на лету через Syft
syft dir:/opt -o table | grep -i java-archive

💡 В ЧЁМ СУТЬ

Java прячется даже там, где вы её не ждёте:

В экосистеме 1С:Предприятие (1C:EDT, Сервер взаимодействия);

В CI/CD и мониторинге (Jenkins, Elasticsearch, Logstash);

Во внутренних системах документации (Confluence, Jira);

Во встроенных веб-консолях управления СХД, KVM и ИБП.

Урок Log4Shell показал: найти уязвимый компонент на сотне серверов занимает в разы больше времени, чем накатить патч. Снятый заранее SBOM превращает неделю судорожного поиска в один моментальный

grep

.

#skills #java #sbom #supplychain #security #devops #linux #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

💾 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