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

Поговаривают, что 13 июня GlobalSign вслед за Let’s Encrypt начал без объявления войны отзыв TLS-сертификатов у российских сайтов. Что характерно, хотя вой поднялся до небес и версии выдвигаются самые разнообразные, вплоть до очередного жидомасонскогобандеровского заговора, названия конкретных пострадавших сайтов никто не приводит, их количеством никто не пугает. Сообщается лишь, что отзыв может затронуть «до 20.000 российских сайтов». Может затронуть, а может и 0 – это тоже «до 20.000».

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

Что произошло на самом деле? Два популярных у российских сайтовладельцев члена CA/Browser Forum приступили к исполнению Order 66 параграфа 3.2.2.12.2 Extended Validation Guidelines версии 2.0.2, которая вступила в силу еще 4 мая, а была утверждена 27 февраля, о чем заинтересованные лица узнали по традиции внезапно, когда грянул гром.

Краткий пересказ параграфа 3.2.2.12.2: УЦ членов CA/Browser Forum при выдаче TLS-сертификата должны проверять, что он не запрошен лицом, находящимся под санкциями страны регистрации УЦ или США. Про отзыв ранее выданных сертификатов ничего не сказано, что, разумеется, не отменяет возможности забега впереди паровоза в порядке частной инициативы и других рекордов на спецолимпиаде.

Желаете получить TLS-сертификат для сайта, владелец которого признан иноагентом или, напротив, внесен в санкционные списки Госдепа? Нет? Тогда не льстите себе, он не попадет в те самые пресловутые «до 20.000».

На прошлой неделе компания Microsoft выпустила очередной кумулятивный набор патчей для своих продуктов. В соответствии с общей тенденцией на увеличение количества обнаруживаемых уязвимостей за единицу времени, данный релиз исправляет рекордные 206 уязвимостей, из них 39 имеют статус критических. Если делить заплатки по категориям, то 63 патча закрывают уязвимости, ведущие к повышению привилегий, 56 багов обеспечивают выполнение произвольного кода, еще 30 могут приводить к утечке информации.

Наиболее опасная уязвимость имеет идентификатор CVE-2026-45657, близкий к максимальному рейтинг опасности 9,8 балла по шкале CVSS. Это ошибка в ядре Windows при обработке сетевых пакетов данных, результатом эксплуатации которой может быть удаленное выполнение произвольного кода, затрагивает она Windows 11, а также Windows Server 2022 и 2025. Такого же высокого рейтинга удостоились еще две проблемы — CVE-2026-47291 и CVE-2026-44815, они также относятся к сетевому стеку в Windows, соответственно затрагивая драйвер HTTP.sys и встроенный клиент DHCP. Кроме того, была закрыта уязвимость, позволяющая обойти BitLocker, ранее раскрытая анонимом, известным как Nightmare Eclipse. Об этом многомесячном противостоянии стоит поговорить подробнее.

Telegram запускает Digital Freedom Contest — конкурс для контент-креаторов с призовым фондом $200 000 (!). Задача: сделать вирусное видео про цифровую свободу, использовать идеи и кадры из речи Павла Дурова, выложить ролик в TikTok, Instagram, YouTube, Snapchat Spotlight или X и набрать минимум 10 000 органических просмотров.

Дедлайн — 15 июля, 23:59 по Дубаю. Результаты — в августе 2026 года.

Но у меня, как у человека из сообщества Telemt, есть один неприятный вопрос: ребята, а может сначала инфру пофиксите, на которой эта цифровая свобода вообще держится??

Когда говорят о безопасности, обсуждение быстро сводится к CVE/BDU Какая версия уязвима? Существует ли публичный эксплойт? И успел ли вендор выпустить исправление? Это конечно важно, но на практике инсталляции Bitrix могут скомпрометировать не из-за одной «критической уязвимости года».

В этой статье разберем десять проблем безопасности, характерных для самостоятельно размещаемых инсталляций 1С-Битрикс и Bitrix24. Основной акцент будет не на отдельных CVE, а на конфигурации, эксплуатации и разработке.

Запустил эксперимент: автономный AI-пайплайн принимает заявки игроков из Telegram, сам правит одну общую браузерную игру и без ручного ревью кода катит изменения в живой прод. Меряю, что при этом происходит с нагрузкой на меня как на человека-в-петле и с кодовой базой, включая техдолг. Это n-of-1, рассчитан на ~60 дней, итоговых выводов пока нет — показываю, как это устроено, почему такое не разносит прод, и зову участвовать.

Приветствую, Хабр! Сегодня хотелось бы осветить ещё одну проблему, связанную с ToS IT-гигантов. Так уж сложилось, что в правоотношениях между UGC-платформой и пользователями сложился опасный перекос. Несмотря на то, что на подобных сервисах основа контента создается самими пользователями, крупные IT-площадки, включая книжные сервисы, вроде LiveLib, фактически создали внутри своих Пользовательских соглашений (ToS) параллельную правовую систему, согласно которой модераторы наделяются квазисудебными функциями, наказывая пользователей на основании размытых терминов «подозрительная активность», «неформат» или «на усмотрение Администрации».

Но внутренние регламенты коммерческого сайта, коим является тот же LiveLib не могут стоять выше федерального законодательства, а субъективные «усмотрения Администраторов» не должны подменять собой нормы права.

Поэтому, если платформа вводит санкцию в виде блокировки аккаунта (что согласно законодательству является односторонним отказом от исполнения обязательств), то она обязана оперировать языком жёсткой конкретики, а не субъективных домыслов модераторов. Единственным законным основанием для ограничения прав гражданина в цифровом пространстве может являться только прямое и доказанное нарушение действующего законодательства РФ.

UGC-платформа – это не суверенное государство, а лишь технический посредник. Поэтому, если действия пользователя не нарушают конкретную статью УК РФ, КоАП РФ, ГК РФ, то любая блокировка (каким бы ни был благовидным предлог Администрации) является незаконным, корпоративным произволом, ущемляющим права потребителя (статья 16 ЗоЗПП РФ).

Привет! Я Анна Корчикова, автор медиа «вАЙТИ». Недавно мы провели исследование цифровой грамотности сотрудников в крупных российских компаниях. Когда начали разбирать результаты, стало очевидно: многие повседневные цифровые привычки сотрудников создают для бизнеса реальные риски. В этой статье делюсь основными выводами исследования и тем, на что компаниям стоит обратить внимание уже сейчас. Это интересно!

В этой статье расскажем про основные классы атак и практическую структуру тестирования ИИ-моделей на уязвимости – от провоцирования галлюцинаций и многошаговых атак до проверки на утечку корпоративных данных. Отдельно объясняем, как правильно оценивать результаты сканирования ML Red Teaming, дадим рекомендации по выстраиванию защиты и безопасному использовании ИИ в корпоративной среде.

ML Red Teaming (AI Red Teaming) – это специализированная форма наступательного тестирования, при которой команда имитирует действия реальных злоумышленников против систем машинного обучения, больших языковых моделей, генеративного ИИ и агентных систем. В отличие от классического пентеста, здесь цель не просто «взломать», а найти уязвимости, присущие именно ИИ-компонентам, оценить риск и повысить реальную устойчивость используемой ИИ-модели.

Статья будет полезна специалистам по информационной безопасности, ML-инженерам, Red Team специалистам и разработчикам, которые занимаются тестированием и защитой LLM-приложений в корпоративной среде.

Взяли один агент, один навык и одну выгрузку правил Ideco NGFW – и прогнали её через GigaChat Max и Claude Opus 4.8. Рассказываем, что из этого получилось, почему «настоящего» агентского теста не вышло и сколько всё это стоило в токенах и рублях.

Зачем мы это затеяли

В прошлой статье – «Пещера Аладдина для безопасника» – мы показывали, как автономный агент Hermes с открытой библиотекой Agent Skills разбирает IPS-логи и проводит аудит правил межсетевого экрана Ideco NGFW. Тогда мы сравнивали бесплатную фронтир-модель и платную Claude Opus и сделали осторожный вывод: для первичного triage хватает дешёвой модели, а для глубокого расследования лучше брать сильную.

Тот эксперимент оставил открытым один очевидный вопрос. Все «сильные» модели в нём были западными. А что покажет российская LLM на той же задаче?

Вопрос не праздный. Если вы – банк, госкомпания или объект КИИ, отправлять выгрузку правил вашего боевого файрвола в облако Anthropic – это в лучшем случае разговор с юристами, в худшем – прямое нарушение. GigaChat от Сбера работает в российском контуре, и если он справляется с аудитом конфигураций на приемлемом уровне, это меняет картину для целого класса заказчиков.

Поэтому мы взяли один и тот же агент (Hermes), один и тот же навык аудита и одинаковые входные данные – и подставили под него две модели: GigaChat Max и Claude Opus 4.8 (задумку с тестированием Claude Fable 5 для этой же задачи реализовать не удалось, со всеми нашими ИБ-скиллами он работать отказался, даже когда был доступен).

Хабр, привет!

На связи Александр Леонов, ведущий эксперт PT Expert Security Center и дежурный по самым опасным уязвимостям месяца. Мы с командой аналитиков Positive Technologies регулярно смотрим на поток информации об уязвимостях из самых разных источников: бюллетени безопасности вендоров, соцсети, блоги, телеграм-каналы, репозитории кода, базы уязвимостей и эксплойтов. Из этого многообразия мы стараемся выделять самое важное - трендовые уязвимости, которые уже используются в реальных атаках или с высокой вероятностью будут эксплуатироваться в ближайшее время.

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

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

Серия будет выходить примерно по главе в неделю. Подписывайтесь, чтобы не пропустить. А пока расскажите в комментариях: вы пришли в тему с нуля или уже строите VM и хотите свежий взгляд? Мне это поможет понять, на чём делать акценты.

Это вступление к серии «Управление уязвимостями для самых маленьких. Если вы открыли этот текст на Хабре, то про управление уязвимостями уже наверняка что-то слышали. Может, у вас в компании стоит сканер, который кто-то когда-то настроил и забыл. Может, прилетел приказ ФСТЭК, и сверху сказали «навести порядок». А может, вы просто устали кивать на совещаниях, где сыплют CVSS, EPSS и каким-то CTEM, и хотите наконец понять, что из этого работает, а что просто красивые слайды с конференции.

Реверс-инжиниринг MAX: Архитектура телеметрии и фоновой эксфильтрации в «защищённом» мессенджере

что скрывает «гос-мессенджер» MAX? Мы провели глубокий статический анализ APK и вскрыли промышленный конвейер сбора данных. Внутри: полное отсутствие E2EE, ежедневный аудит разрешений (камера/микрофон/GPS), скрытое сканирование всех установленных приложений и фоновая выгрузка файлов на сторонние серверы с последующей зачисткой следов на устройстве. Разбираем пакеты, классы и методы, которые превращают мессенджер в систему направленного наблюдения.

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

На первый-третий расчитайсь! Сервер – рас. Администратор – два. URL – три!

Открыли HTTPS 443 – значит, можно запускаться.

На практике с решениями, которые работают с Linux-каталогом, такой подход всё одно, что бить палкой крапиву. Веб-интерфейс – это только точка управления. Само решение не живёт в вакууме: ему нужно обращаться к контроллерам домена, LDAP-каталогу, Kerberos/KDC, DNS, NTP. И это не пожелания, а обязательная сетевая связность, без которой сервис просто не работает – даже если страница в браузере открывается.

Именно поэтому при согласовании с ИБ важно приносить не просьбу «дайте доступ к серверу, сколько не жалко», а схему сетевых взаимодействий.

История реальная

Проект – Linux-каталог на 600 пользователей. Крайний срок – конец квартала. Мы сделали всё: Linux-каталог развёрнут, тестирование прошло, дата запуска согласована, рубашки заправлены.

За день до старта звонит ИБ: «А где схема сетевых взаимодействий?». Схемы нет. Я думал: ну HTTPS же открыли – чего ещё надо?

Как оказалось – надо всё остальное. И вот почему.

Формально доступ к веб-морде есть. Админ может зайти, логин-пароль ввести. Но само решение не может выполнить ни одной задачи. В каталог ему не пролезть. LDAPS не согласован. Kerberos – только в наших мечтах. DNS – «ну он же работает», но в заявке нет...

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

Если у вас в начале июня внезапно завис git clone, а pip install начал валиться на каждом втором пакете — выдохните, дело не в вас и не в карме. С мая 2026 доступ к ключевым инструментам разработчика из России потихоньку деградирует. 8 июня Роскомнадзор предложил отрасли решение, и отрасль встретила его, мягко говоря, без оваций. Давайте по порядку: что сломалось, почему достаётся именно репозиториям, что это за «ГосVPN» такой, почему инженеры от него отмахиваются и что можно сделать прямо сейчас — без шаманства, обычной инженерной гигиеной.

Сразу одна важная вещь. Дальше я честно помечаю, где у меня твёрдый пруф, а где — реконструкция по одному источнику или просто разумное предположение. РКН официально отрицает блокировки PyPI и GitHub, часть атрибуций («это ТСПУ») технически правдоподобна по характеру сбоев, но ведомством не подтверждена. Так что местами я буду оговариваться — это не занудство, это честность.

Полгода назад я написал здесь разбор «почему VLESS работает» — он собрал 169 тысяч просмотров и под тысячу закладок. Я тогда уверенно заявил: REALITY не отличить от обычного HTTPS, поэтому он держится там, где всё остальное давно отвалилось. Прошло полгода — и оказалось, что я был прав ровно наполовину.

В феврале ТСПУ перешёл на поведенческий анализ, а в июне — на то, что в чатах называют «заморозкой по fingerprint». И тут разом перестали подключаться мои собственные конфиги — и конфиги тысяч других людей. Приложение бодро рапортует «connected», а трафика нет. А привычный совет «обнови клиент» вдруг превратился в пустой звук.

Вот я и вернулся — посмотреть, что осталось от моих же выводов. Это разбор со стороны клиентского устройства — угла, который обычно недозанят. Что на самом деле творится в телефоне, когда «всё зелёное, а интернета нет». Как устроена новая детекция. И как измерить её самому, чтобы не потерять доступ к легальным сервисам, которые попали под ложные срабатывания.

Пара слов о том, чему верить. Тема скользкая, источников мало, и я не хочу делать вид, что у меня на руках спецификация системы. Поэтому дальше честно помечаю, где у меня твёрдый пруф, а где — реконструкция по одному источнику. Самое важное сразу: ядро всей новой схемы (разделы 2–4) собрано по одному структурированному первоисточнику — посту в Obsidian/Zapret, где автор разбирает поведение через инструмент dpi-ch. Это не выписка из документа РКН и не консенсус исследователей ТСПУ. Академические работы (ensafi/IMC 2022, gfw.report) такой схемы вообще не описывают — как и кодового имени, под которым она ходит в обсуждениях. Так что всё про конкретные пороги — «>3 хендшейка», «350–400 мс», «120/600 с» — это инженерная реконструкция чёрного ящика по одному наблюдению, а не доказанное устройство системы. Числа читайте как рабочие гипотезы.

Предыстория

1 день назад я опубликовал первую статью про WebScan из Песочницы Хабра. Честно — не ожидал ничего особенного. Думал придут 50 человек, может кто-то поставит звезду на GitHub.

Вышло иначе.

За первые сутки статью прочитали 548 человек. Потом пошли 10К охват, закреплённый пост на канале с 29К подписчиков, Google AI который начал рассказывать про WebScan всем кто спрашивал про bug bounty инструменты на Python. И 12 звёзд на GitHub от людей которых я не знаю.

Это была лучшая мотивация чтобы не останавливаться.

Честно о трудностях

Я подал заявку на Cyber Verification Program от Anthropic чтобы использовать Claude без блокировок для кибербезопасности. Отказали за час. Причина — случайно нажал No на вопросе про MFA. Одна кнопка, один отказ.

Coverage был 84% — я думал 87%, оказалось это была progress bar pytest а не реальная цифра.

Nuclei на Go оказался медленнее WebScan на Python. Я сам не верил пока не провёл бенчмарк.

Имя webscan на PyPI уже занято. Пришлось переименовать в webscan-security.

Всё это решалось — просто не всё шло по плану.

Что изменилось за неделю

v1.0 → v2.0 это не просто версия. Это другой инструмент.

Плагины: 7 → 19

Добавились: XSS, Blind SQLi, Path Traversal, Open Redirect, SSRF, GraphQL интроспекция, SSL/TLS анализ, Tech Fingerprint, Subdomain Enumeration через DNS и crt.sh, CVE lookup через NVD API (350,000+ уязвимостей в реальном времени), Secrets detection (AWS, OpenAI, Anthropic, GitHub ключи в исходниках).

Crawler

WebScan теперь сам обходит цель — парсит ссылки, формы, JavaScript эндпоинты. Раньше сканировал только то что ему давали. Теперь сам находит что сканировать.

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

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

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

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

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

Когда речь заходит о безопасности рабочего места, обычно вспоминают операционную систему, антивирус, средства защиты конечных устройств, контроль устройств, почту, сетевой периметр. Браузер часто оказывается где-то сбоку: «ну, его тоже надо как-то настроить». На практике именно браузер становится одним из самых чувствительных клиентских приложений. Он работает с данными, авторизацией, расширениями, загрузками, сертификатами, прокси, паролями, обновлениями, внешними службами и внутренними порталами.

У Firefox для этого есть корпоративные политики. Их можно описывать в policies.json, раскладывать по рабочим станциям и получать управляемый браузер. Но между «политики существуют» и «администратор или специалист по информационной безопасности может уверенно сопровождать их в реальной организации» есть большая дистанция.

Так появился Browser Policy Manager — свободный продукт под лицензией MPL-2.0 для управления корпоративными политиками Firefox.