Информационная безопасность *

Важной новостью прошлой недели стало обнародование данных об опасной уязвимости в ядре Linux, получившей название Copy Fail (мини-сайт, новость на Хабре), которая открывает относительно простой способ локального повышения привилегий. Авторы оригинального исследования не стесняются рекламировать ИИ-ассистент для анализа кодовой базы, который нашел данную проблему в течение часа. Исследователи «Лаборатории Касперского» провели анализ уязвимости и предложили варианты обнаружения атак с ее использованием.

Уязвимость получила идентификатор CVE-2026-31431 и рейтинг 7,8 балла по шкале CVSS. Ошибка была внесена в код модуля ядра algif_aead еще в 2017 году: тогда была внедрена поддержка оптимизаций in-place при работе системы шифрования AEAD. Это, в свою очередь, привело к дефекту обработки буферов, что дало потенциальному атакующему возможность контролируемо изменять содержимое кэша любого файла, доступного для чтения.

Представьте: вы открываете репозиторий g4f, видите пять строк кода — и вот уже ChatGPT отвечает на ваш вопрос, не спрашивая API-ключ и не прося денег. Мысль, которая приходит первой: «Наконец-то бесплатный доступ к сильному ИИ, остальные просто не умеют готовить». Но пока вы радуетесь, ваш запрос уже ушёл гулять по миру через десяток чужих серверов. И никто — включая вас — не знает, кто прочитал его по дороге и сохранил ли он этот текст на будущее.

Я покажу, как именно библиотека маскируется, почему реверс-инжиниринг здесь превратился в инструмент обхода защиты и во что обходится такая экономия, когда речь заходит о конфиденциальности, стабильности и законности. Если вы хотя бы раз вставляли g4f в свой проект — дочитайте до конца. Возможно, это убережёт вас от очень дорогих последствий.

Мы привыкли воспринимать LLL-редукцию как «чёрный ящик»: подали целочисленный базис, получили редуцированный базис, проверили результат. Но что, если сделать процесс редукции наблюдаемым?

В статье рассказываю о Q-LLL — exact-certified алгоритме семейства LLL, где классическая корректность сохраняется, но выбор редукционных действий управляется квантизированной Gram/Lovász-геометрией.

Главная идея:

approximate geometry observes, exact arithmetic decides, certificate proves.

Q-LLL не заменяет fplll и не меняет Lovász-критерий. Вместо этого он добавляет новый слой: quantized Gram/Lovász oracle, exact gate, fair scheduler и proof-carrying certificates, которые можно независимо проверить.

В статье разбираю:

— почему обычного sequential LLL недостаточно для больших семейств lattice-вариантов; — что такое Lovász slack и как из него получается карта геометрических дефектов; — как работает quantized Gram/Lovász oracle; — почему approximate слой не принимает математических решений; — зачем нужны exact-сертификаты и independent verifier; — как Q-LLL становится lattice-core для nonce-observatory; — какие результаты уже получены и какие ограничения честно остаются.

Это не статья про «магическую кнопку» и не claim про универсальное превосходство над fplll. Это попытка показать новый взгляд на LLL: как на управляемый, наблюдаемый и проверяемый процесс, где квантизированная геометрия направляет редукцию, а exact-арифметика остаётся источником истины.

Привет, Хабр! Согласно отчёту Trend Micro TrendAI за прошлый год число CVE во всей AI-экосистеме почти удвоилось: с 419 до 756. Цифры стартовые, но мысль простая. Тестировать нейросетевые сервисы как обычные веб-приложения в 2026-м уже недостаточно. И вот почему.

В этой статье разберу:

- что появилось нового в OWASP LLM Top 10 (версия 2025);

- какие атаки реально работают в проде, а какие так и остались в arXiv;

- чем тестируют LLM сейчас (open-source стек плюс российские игроки);

- плюс короткий практический playbook на четыре уровня.

После статьи про Cursor и сжатие контекста я получил много комментариев. В коментах спорят: виноват компактинг? Или attention dilution? Или модель просто ослушалась? Или проблема вообще не в контексте, а в alignment?

Спор хороший, но он показывает фундаментальную проблему: у инженеров нет общей картины того, как LLM работают с контекстом. Мы видим симптомы (агент удалил базу, модель галлюцинирует, точность падает на длинной сессии), но не понимаем механизмы.

Попробуем собрать эту картинку

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

Нашел в российском дейтинг-боте Mimolet с якобы 180k MAU несколько high-уязвимостей: IDOR, отсутствие rate limiting, обход токенов и публичный доступ к медиа.

Это позволило легко получить доступ к ~12k профилям и ~24k файлам, при этом 43% анкет принадлежат несовершеннолетним. Также удалось обойти ограничения, которые связаны с премиум-подпиской.

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

История инцидента в продакшене: после планового релиза новая версия сервиса не поднялась, а откат на предыдущую версию тоже не помог. Причина оказалась не в коде, а в расхождении между тем, что было описано в Git, и тем, что реально жило в Kubernetes. Ручная правка ConfigMap несколько месяцев существовала только в кластере, пока очередной релиз не пересоздал поды и не вытащил проблему наружу. Разбираю, как мы нашли причину, почему Git не был настоящим источником правды и зачем после этого перешли на GitOps с Argo CD.

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

Мы живём в эпоху смены парадигмы взаимодействия человека с сетевыми системами, смены того, как люди подтверждают то, что они те, за кого себя выдают. Главные вопросы, которые всегда задавали пользователям, звучали так: «Что вы знаете?» (пароль, PIN-код, девичья фамилия матери), или «Как вы выглядите?» (Face ID, отпечатки пальцев). Теперь же на первый план выходит такой вопрос: «Как вы себя ведёте?».

В наши дни развитие генеративного ИИ и прогресс в разработке вредоносного ПО, вроде RAT (Remote Access Trojan, троян удалённого доступа), позволили киберпреступникам проводить широкомасштабные атаки и даже обходить такие механизмы безопасности, как Face ID или MFA (Multi-Factor Authentication, многофакторная аутентификация, МФА), которые ранее считались «пуленепробиваемыми».

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

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

Всё началось чисто по приколу. Недавно в сети поднялась шумиха вокруг уязвимости VLESS-клиентов: оказалось, что даже при использовании сплит-туннелирования (когда VPN включен только для избранных приложений), любое «шпионское» приложение на телефоне может узнать IP-адрес вашего VPN-сервера.

Уязвимость была тривиальной — ядро клиента открывает локальный SOCKS-прокси, который никак не защищен. Любая софтина на устройстве может постучаться в этот локальный порт и отправить пакет наружу. Ради академического интереса я написал Android-приложение TeapodStream, под капотом которого связал xray-core и tun2socks. Локальный прокси я посадил на случайный порт и закрыл динамическим паролем (подробнее об этом писал в прошлой статье).

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

Но... я сам не заметил, как меня затянуло.

Я раньше был уверен, что понимаю, как работает отслеживание в интернете. Очистил cookies - чист. Включил VPN - спрятался. Поставил блокировщик - стал почти невидимым. Звучит логично, правда?

Проблема в том, что всё это работает только на уровне, который уже давно не является основным.

Современные сайты не обязательно знают, кто ты. Им это и не нужно. Достаточно собрать достаточно признаков, чтобы отличить тебя от всех остальных. Версия браузера, разрешение экрана, поведение мыши, особенности рендеринга графики, сетевые характеристики - по отдельности это просто параметры. Но вместе они превращаются в отпечаток, который оказывается гораздо устойчивее, чем кажется.

И самое неприятное - этот отпечаток можно получить без cookies, без авторизации и даже без твоего явного согласия. Ты можешь открыть сайт впервые, но для системы ты уже «кто-то знакомый».

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

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

Знаете, кому 29 апреля стукнуло 30 лет? Спецификации FastCGI. Тридцать лет с 1996 года. Погодите. Эта заметка не про ностальгию по .fcgi-скриптам, которые на каждый запрос форкали отдельный процесс и которыми сегодня никто не пользуется. И не про CGI вообще.

Разговор о другом. У нас всех в проде между прокси и бэкендом обычно стоит HTTP. nginx перед Go-приложением, Caddy перед Python-сервисом, Apache перед PHP-FPM, неважно, поверх там HTTP/1.1 или HTTP/2. И вот Эндрю Айер на agwa.name к юбилею FastCGI собрал аргументы, что этот участок инфраструктуры всё это время сидит на не самом удачном протоколе. Айер основатель SSLMate, и в SSLMate всё крутится на FastCGI в проде уже больше десяти лет. Так что пишет не теоретически.

Заметка короткая и по делу. HN-тред собрал сотню комментариев, для 2026 года это не топ, но там пишут люди, которые знают, о чём говорят. Если попроще, аргумент такой: у HTTP как протокола между прокси и бэкендом есть два структурных бага, которых у FastCGI нет, и индустрия за тридцать лет так и не нашла повода переехать. А обсуждение в треде ушло дальше: почему вообще HTTP победил, если он хуже технически. И ответ оказался любопытнее самого аргумента.

Николай Гусев · 29 апр в 12:00 · Старший инженер внедрения, Группа Астра

«NEVER FUCKING GUESS! - и именно это я и сделал. Я угадал, что удаление staging volume через API будет ограничено staging-окружением. Я не проверил. Я не читал документацию Railway.»

- AI-агент Cursor на Claude Opus 4.6, письменное признание после удаления production-базы PocketOS

Привет, меня зовут Николай, я 23 года в DevOps, последние несколько лет - внедряю продукты Группы Астра. И за последний год я наблюдаю, как индустрия повторяет одну и ту же ошибку снова и снова: она продаёт AI-агентов как решение, а на деле продаёт проблему.

Анализ публично доступных HTTP-ответов и DNS-записей без аутентификации и активного вмешательства. Проверке подвергается только внешняя конфигурация: HTTP-заголовки, TLS/SSL, DNS, открытые порты.

Уязвимости не эксплуатируются, нагрузки на сервер нет.

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

Более того, зашифрованное сообщение можно сделать похожим на обычный текст или даже скрыть в обычном контенте — видео, звуковых файлах и тексте, который не вызовет подозрений у «цензора». Это область стеганографии

Но прямо сейчас людям нужен простой и практичный способ шифровать сообщения, максимально удобным способом. Рассмотрим самые простые онлайновые утилиты, которые позволяют это делать.

Привет, Хабр.

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза “end-to-end encryption”? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Год назад на рандом-кофе мы с коллегой обсуждали так называемую (мной) цифровую экологию и проблемы работы с большими данными, и он мне посоветовал доклад "The Unbelievable Insecurity of the Big Data Stack" с конференции Black Hat USA 2021 - в целом название полностью описывает содержание доклада. И вот только сейчас, спустя год, у меня дошли руки его разобрать и поделиться с вами своими мыслями на этот счёт. За пять лет доклад совершенно не утратил актуальности и, кажется, стал только более насущным.

Доклад делала Sheila A. Berta - специалист по offensive security из Аргентины, которая много лет занимается поиском уязвимостей и исследованием инфраструктур. В последние годы она сфокусировалась на безопасности Big Data и cloud-native систем. Это не теоретическая работа, а результат практического ресёрча.

50 дней назад я отправил critical-репорт через Immunefi. Проект ни разу не ответил. Письменные ответы mediation team о том, как на самом деле устроены vault, SLA и медиация на крупнейшей Web3 bug bounty платформе.