Телеграм канал «Kali Linux»

BPFDoor: бэкдор, который может обойти firewall

BPFDoor - скрытный Linux-бэкдор, который связывают с китайскими APT-группами и атаками на телеком-инфраструктуру.

Он подключается к raw-сокету и анализирует входящие пакеты до того, как их обработают правила iptables или nftables. Поэтому корректно настроенный firewall сам по себе не гарантирует защиту.

Бэкдор не открывает постоянный порт и большую часть времени никак себя не выдаёт. Для активации атакующий отправляет специально сформированный пакет, после чего BPFDoor может установить обратное соединение и предоставить удалённый доступ к системе.

Обычный скан портов здесь мало поможет. При проверке стоит обращать внимание на подозрительные raw-сокеты, активные BPF-фильтры, замаскированные процессы и необычные исходящие соединения.

В статье разобраны устройство BPFDoor и способы его обнаружения:

https://hackers-arise.com/compromising-telecom-systems-deploying-and-detecting-the-bpfdoor-backdoor/

#cybersecurity #linux #infosec #telecom

Автономный ИИ-агент взломал Hugging Face, а закрытые модели не смогли помочь расследованию

Hugging Face раскрыла инцидент, который хорошо показывает будущую асимметрию кибербезопасности.

Атака началась с вредоносного датасета, эксплуатировавшего два пути выполнения кода в системе обработки данных. Затем автономный агент получил доступ к нодам, собрал облачные и кластерные учётные данные и перемещался между внутренними кластерами.

За одни выходные система выполнила тысячи действий через краткоживущие sandbox-среды. В журналах осталось более 17 000 событий.

Самая показательная часть началась во время расследования. Команда Hugging Face попыталась анализировать реальные эксплойты, команды и C2-артефакты с помощью передовых моделей через коммерческие API, но safety-фильтры блокировали запросы.

Модели не смогли отличить работу специалиста по реагированию на инциденты от действий атакующего.

В итоге анализ перенесли на самостоятельно размещённую open-weight модель GLM 5.2. Это позволило изучать вредоносный код без блокировок и не отправлять журналы, данные атакующего и упомянутые credentials внешнему провайдеру.

Возникает опасная асимметрия:

- атакующие запускают агентов без ограничений;
- защитники могут столкнуться с блокировками именно в критический момент;
- чувствительная телеметрия не всегда должна покидать инфраструктуру компании.

У команды безопасности должна быть заранее подготовленная модель, которую можно запустить локально и использовать во время реального инцидента.

Автономные кибератаки уже перестали быть сценарием из презентаций. Теперь вопрос в том, готовы ли защитные инструменты работать с той же скоростью.

https://huggingface.co/blog/security-incident-july-2026

#ai #cybersecurity #opensource #llm #huggingface

@linuxkalii

`O_DIRECT`: когда база данных обходит page cache

В Linux флаг O_DIRECT позволяет читать и писать файл почти напрямую, минуя page cache ядра.

Зачем это нужно базам данных?

У PostgreSQL, MySQL, RocksDB и других систем часто уже есть свой buffer pool.
Если ещё и ядро будет кэшировать те же страницы, получится двойное кэширование и лишняя трата памяти.

Но у O_DIRECT есть неприятное условие: всё должно быть выровнено по блоку.

• buffer
• file offset
• размер чтения / записи

Например, под 4 KB блоки нельзя просто так прочитать 123 байта в любой `malloc`-буфер.
Промахнулся с alignment — read() вернёт EINVAL.

Именно поэтому низкоуровневый I/O в базах выглядит таким странным: там важны не только данные, но и то, как они лежат в памяти.

erid: 2W5zFHxLXwf


Бесплатный урок: доверь прод ИИ. Испугались? Не бойтесь, мы друг

⭐Слёрм запускает БЕСПЛАТНУЮ вечернюю школу «ИИ для инженеров: польза и риски».

Это серия онлайн-занятий о том, как использовать ИИ в инженерной работе осознанно, безопасно и с понятной пользой.

🧩 Будем разбирать реальные инженерные сценарии:
— как ИИ помогает DevOps-, SRE- и infrastructure-командам
— как использовать LLM для алёртов, инцидентов, логов, тикетов и документации
— где ИИ реально экономит время, а где создаёт новые риски
— как проверять результат модели и не ловить галлюцинации в проде
— что делать с безопасностью, данными, compliance и юридическими ограничениями
— как встроить ИИ в рабочий процесс, а не просто иногда спрашивать у него команды.

🧩 В программе — шесть онлайн-занятий с практиками из ИТ:
— ИИ для разбора метрик и шумных алёртов
— автофикс проблем прода с ИИ
— ИИ-агенты в бизнес-задачах
— юридические риски использования ИИ
— LLM в SOC и борьба с alert fatigue
— инженерное мышление в эпоху LLM

Школа подойдёт DevOps-, SRE-, infrastructure-, platform- и security-инженерам, а также всем, кто уже пробовал ИИ в работе и хочет понять, как использовать его системнее и безопаснее.

📅 Старт — 21 июля.

💸 Участие бесплатное, занятия проходят онлайн

👉🏻 Узнать подробнее и зарегистрироваться в боте

⚡️ Почему RSA в OpenSSL не делает «обычное деление»

В реализации RSA внутри OpenSSL почти не используется прямое модульное деление. Вместо этого там работает Montgomery reduction - алгоритм, который ещё в 1985 году предложил Питер Монтгомери.

Идея простая: в RSA постоянно нужны операции вида «умножили большие числа и взяли остаток по модулю». Обычное деление на больших числах дорогое, поэтому его стараются избегать.

Montgomery reduction переводит вычисления в специальную форму, где параметр R выбирают как степень двойки. После этого часть дорогих делений превращается в сдвиги битов и более дешёвую арифметику.

Для пользователя это незаметная деталь. Но без таких трюков современный RSA был бы намного медленнее.

Есть хороший шанс, что HTTPS-соединение, которым вы пользуетесь прямо сейчас, где-то внутри уже опиралось на эту технику.

C2 без сервера, домена и открытых портов - теперь прямо внутри GitHub

Появился OctoC2 - GitHub-native C2 framework, где весь трафик идёт через api.github.com по HTTPS. Без VPS, кастомных доменов и listening server. Для сети это может выглядеть как обычная активность разработчика или CI/CD.

По README, OctoC2 использует несколько каналов внутри возможностей GitHub, поддерживает fallback между ними и шифрование payload’ов. Проект прямо помечен как инструмент только для authorized red-team и security research.

GitHub-трафик нельзя считать безопасным просто потому, что это GitHub.

Что стоит мониторить:

* странные паттерны запросов к GitHub API
* неожиданные GitHub tokens на машинах
* необычную активность private repos
* подозрительную CI/CD-активность
* долгоживущие процессы, которые постоян

github.com/dstours/OctoC2

#redteam #infosec #C2 #Hacking

Линус Торвальдс не поддержал запрет AI-кода в Linux.

ИИ - это инструмент. Такой же, как компилятор, статический анализатор или IDE. Неважно, писал разработчик код вручную или использовал ассистента. Важно, что получилось в итоге.

Плохой патч отклонят, даже если его написал человек.
Хороший патч могут принять, даже если помогала модель.

Но ответственность переложить на AI не получится.

Разработчик должен сам проверить сгенерированный код, убедиться в соблюдении лицензий и поставить собственный Signed-off-by. AI-агент не имеет права делать это за человека. Использование модели также рекомендуется отмечать через Assisted-by.

Правило осталось прежним: присылай качественный код и будь готов за него отвечать.

https://opennet.ru/65913/