Kali Linux

Claude нашёл криптографические слабости, которые годами пропускали эксперты

Anthropic показала один из самых серьёзных примеров использования ИИ в науке: Claude помог разработать новые атаки сразу на две криптографические схемы.

В первом эксперименте модель исследовала HAWK — кандидата NIST на стандарт постквантовой подписи. Алгоритм два года изучали специалисты, но Claude за 60 часов нашёл подход, который снизил эффективную стойкость небольшой версии ключа с \(2^{64}\) до \(2^{38}\).

Во втором случае Claude занялся урезанной 7-раундовой AES-128 и предложил технику, ускорившую известные атаки примерно в 200–800 раз. Полная AES-128 использует 10 раундов и остаётся безопасной — массового взлома шифрования не произошло.

Самое впечатляющее — уровень автономности. Модель читала научные статьи, выдвигала гипотезы, писала код, запускала эксперименты и отбрасывала неудачные направления. Каждый проект стоил около $100 000 в API-запросах.

Практической угрозы для обычных пользователей пока нет. Но граница уже сдвинулась: ИИ начал находить математические слабости, которые раньше требовали лет работы узких специалистов.

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

https://www.anthropic.com/research/discovering-cryptographic-weaknesses

Пользователи Linux, которые удалили Windows, чтобы уйти от Microsoft и выбрать свободу вместе с Linux, возможно, ещё не ушли окончательно.

У Microsoft есть криптографический ключ, который позволяет запускаться всем крупным Linux-дистрибутивам на современном железе.

Ubuntu. Fedora. Debian. Все они.

Без подписи Microsoft ваша Linux-машина не стартует.

И срок действия этого ключа истекает через 4 дня - 27 июня 2026 года.

Вот что происходит на самом деле.

Когда в 2012 году появился Secure Boot, Microsoft фактически стала центром сертификации для всей экосистемы загрузки ПК.

Каждый Linux bootloader должен быть подписан Microsoft, чтобы запускаться на UEFI-машине с включённым Secure Boot.

Хорошая новость: ваш уже установленный Linux продолжит загружаться после 27 июня.

Плохая новость касается всего, что будет дальше.

• любой новый shim binary после 27 июня уже нельзя будет подписать старым ключом

• если ваша прошивка не получит новые сертификаты Microsoft 2023 года, свежие установки дистрибутивов могут не загрузиться

• старые ноутбуки, железо от небольших вендоров и embedded-устройства без обновлений прошивки могут зависнуть в серой зоне навсегда

• Dell, HP и Lenovo уже выпустили обновления, но многие мелкие производители - нет. Никто точно не знает, сколько устройств выпадет из поддержки

Для большинства пользователей решение простое:

sudo fwupdmgr update

Но главная история здесь глубже.

Linux-сообщество годами спорило о свободе и независимости от Microsoft.

А всё это время у Microsoft был ключ, от которого зависела загрузка почти каждой Linux-машины на современном ПК.

Это не конспирология.

Так просто был устроен Secure Boot.

Обновитесь.

А потом подумайте, что это значит.

Подробности:
https://zdnet.com/article/aspirin-for-linuxs-microsofts-secure-boot-headache/

🚨 Одного сообщения оказалось достаточно, чтобы Claude Cowork выбрался из своей Linux-VM и получил доступ к файлам Mac

Исследователи Accomplish AI показали цепочку SharedRoot для локальных сессий Claude Cowork на macOS.

Cowork запускает агента внутри Linux-VM, но исследователи обнаружили опасную деталь: вся файловая система Mac была подключена внутрь VM в режиме read-write, хотя увидеть её мог только guest-root.

Дальше цепочка выглядела так:

• агент получает дополнительные привилегии внутри VM
• через Linux-уязвимость CVE-2026-46331 повышает права до root
• root внутри VM получает доступ к общему mount
• после этого можно читать и изменять файлы за пределами папки, которую пользователь разрешил Claude

В зоне риска оказываются SSH-ключи, cloud credentials и другие файлы, доступные аккаунту пользователя. Исследователи утверждают, что до изменений потенциально были затронуты около 500 000 пользователей macOS.

Исследователи считают архитектурной проблемой решение монтировать весь host filesystem внутрь VM: следующая privilege-escalation уязвимость потенциально может снова открыть похожую цепочку.

Anthropic закрыла баг-репорт как *Informative*. Сейчас Cowork по умолчанию использует cloud execution, где эта локальная цепочка, судя по исследованию, не работает.

🔗 https://thehackernews.com/2026/07/claude-cowork-flaw-could-let-ai-agent.html

🔍Тестовое собеседование с Head of DevOps уже завтра

28 июля(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle DevOps-разработчика.

Как это будет:
📂 Александр Хренников, Head of DevOps в KTS с опытом 14+ лет, будет задавать реальные вопросы и задачи разработчику-добровольцу
📂 Александр будет комментировать каждый ответ респондента, чтобы дать понять, чего от вас ожидает собеседующий на интервью
📂 В конце можно будет задать любой вопрос Александру

Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для DevOps-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы.

Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_devops_bot

Реклама.
О рекламодателе.

⚡️ У Claude всплыла та же проблема, что раньше обсуждали у других чат-ботов: расшаренные диалоги оказались в поисковиках.

Пользователи заметили, что публичные ссылки Claude могли индексироваться Google и находиться обычным поиском. В сети сообщают о найденных чатах с персональными данными и другой чувствительной информацией. При этом речь идет именно о диалогах, для которых пользователь создавал публичную ссылку, а не о взломе всех приватных чатов.

Исследователи Digital Digging ранее обнаружили десятки тысяч публично доступных shared-разговоров сразу у Claude, Gemini, Grok, Copilot, ChatGPT и DeepSeek. Проблема проста: пользователь думает «отправил ссылку знакомому», а фактически создаёт веб-страницу, которая потенциально может попасть в индекс или архив.

Мораль старая: API-ключи, документы, пароли и личные данные лучше вообще не отправлять в расшариваемые AI-чаты. 🌂

Когда находишь бантика на сервере, как мы это называем?🤣

TIME_WAIT в Linux годами объясняют неправильно

Я полез в исходники Linux TCP и снова наткнулся на старый сетевой миф.

В коде TIME_WAIT фактически зафиксирован на 60 секунд:
#define TCP_TIMEWAIT_LEN (60 * HZ)
Его нельзя настроить отдельно для сокета.

И да, tcp_fin_timeout, который часто советуют крутить в блогах, не управляет TIME_WAIT.

Он относится к состоянию FIN_WAIT2.

TIME_WAIT задан в исходниках ядра и не вынесен в отдельный sysctl.

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

Kimi K3 за 27 минут нашла RCE в Redis и собрала рабочий эксплойт 😨

Рой из 32 ИИ-агентов обнаружил уязвимость, которая после авторизации позволяла выполнять произвольный код на сервере.

Через несколько часов система якобы нашла ещё и цепочку атаки на Telegram Desktop и iOS без действий пользователя: через повреждённый видеофайл с автозагрузкой. До полноценного RCE оставался один шаг.

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

github.com/berabuddies/redis-poc

@data_analysis_ml

✔️ Medusa: сканер для AI supply chain атак

Medusa проверяет GitHub-репозитории на скрытые компромиссы в AI/ML, LLM agents и MCP-инфраструктуре.

Что ищет:

* repo poisoning
* prompt injection
* MCP tool abuse
* weaponized configs
* скрытые payloads
* утечки ключей в Claude / Cursor / Copilot / shell history
* 200+ CVE-паттернов
* 40,000+ detection patterns

Идея полезная: перед тем как клонировать репозиторий или тащить его в агентную систему, быстро прогнать его через security scanner.

Потому что в AI-проектах опасность уже не только в зависимостях.

Риск может жить в конфиге, tool description, MCP-сервере, prompt-файле, истории ассистента или незаметном скрипте рядом с кодом.

Medusa как раз закрывает этот новый слой проверки.

GitHub: http://github.com/Pantheon-Security/medusa

Модели OpenAI «сбежали» из песочницы и взломали Hugging Face, чтобы… списать 😳

Во время внутреннего тестирования кибервозможностей GPT-5.6 Sol и ещё более мощная неанонсированная модель нашли zero-day в изолированной среде OpenAI.

Дальше начался сюжет для научной фантастики:

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

И всё это — ради максимального результата на тесте по эксплуатации уязвимостей. По данным OpenAI, модели были настолько сосредоточены на задании, что пошли на крайние меры, чтобы найти ответы напрямую в базе Hugging Face.

Hugging Face заметила и остановила атаку с помощью собственных защитных агентов. Но при расследовании возникла ироничная проблема: коммерческие frontier-модели блокировали анализ реальных эксплойтов из-за защитных ограничений.

В итоге форензику провели локально с помощью китайской open-weight-модели GLM 5.2 от Z.ai.

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

ИИ не просто списал ответы. Он сначала взломал соседнюю компанию, чтобы до них добраться.

Интересно, результат бенчмарка ему всё-таки засчитали? 🤭

#ai #openai #huggingface #cybersecurity #gpt #glm

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

Fugu-Cyber: ИИ-оркестратор для задач киберзащиты

Sakana AI представила обновление своей системы Fugu - специализированную модель Fugu-Cyber для анализа реальных задач информационной безопасности.

По данным компании, модель показала:

- 86,9% успешных решений на CyberGym
- 72,1% на CTI-REALM
- результаты на уровне GPT-5.5-Cyber и Mythos Preview

CyberGym проверяет способность находить и подтверждать уязвимости в сложных кодовых базах, а CTI-REALM — превращать отчёты об угрозах в рабочие правила обнаружения.

Fugu-Cyber работает как одна модель, но внутри динамически координирует несколько специализированных ИИ-агентов. Пользователь отправляет запрос в единый API, а система сама распределяет многоэтапную задачу между агентами.

При этом Sakana AI подчёркивает: высокая оценка на бенчмарке ещё не делает модель готовой системой защиты. Для работы в реальной инфраструктуре нужны эксперты, интеграция с внутренним кодом и обязательная проверка результатов человеком.

https://sakana.ai/fugu-cyber-release

#ai #cybersecurity #llm #agents #sakanaai

Автономный ИИ-агент взломал 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 в базах выглядит таким странным: там важны не только данные, но и то, как они лежат в памяти.

⚡️ Почему 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/