⚙️ Недостаток использования смарт-карт в тирной модели: как одно решение может привести к уязвимости всей инфраструктуры безопасности

Когда мы внедряем смарт-карты для администраторов в Windows-инфраструктуре, мы ждём, что рисков, связанных с кражей паролей, станет меньше. Но оказывается, что штатный механизм использования смарт-карт имеет фундаментальный недостаток. Например, ваши администраторы заходят по RDP на сервер, чтобы его настроить. А сервер уже скомпрометирован — и злоумышленник может использовать проброшенные сертификаты администратора, чтобы аутентифицироваться под административной учётной записью, закрепиться в инфраструктуре и развить атаку на остальные критические системы компании с помощью скомпрометированных учёток.

🏠 Павел Черёмушкин и Анатолий Василенко из команды инженеров безопасности Яндекса детально разобрали на OFFZONE 2025, почему так происходит. А ещё предложили своё решение, так как готовые инструменты от Microsoft имеют ограничения и не покрывают все необходимые сценарии использования.

⏩ В чём проблема

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

⏩ Но есть нюанс: проброс сертификатов по RDP

Когда админ подключается к серверу с галочкой «Проброс смарт-карты», на атакованный хост пробрасываются все сертификаты со всех его смарт-карт. В этот момент злоумышленник может использовать любой из них для аутентификации под любой из учётных записей администратора. Так он может получить доступ к системам из других защищённых контуров. И через один скомпрометированный сервер будет взломана вся инфраструктура компании.

⏩ Ребята перебрали стандартные решения Microsoft для безопасного удалённого доступа. Увы, они не подошли:

🟣 Restricted Admin. Не работает на доменных контроллерах и требует прав локального администратора, поэтому не подходит для пользователей. При выполнении double hop (подключении с сервера на сервер по цепочке) аутентификация идёт от имени компьютера — это мешает администрированию сервисов, состоящих из нескольких компонент

🟣 Remote Credential Guard. Он тоже не работает на доменных контроллерах, а в новых версиях Windows его ещё и постоянно ломают. К тому же эта технология открывает новые возможности для перемещения внутри инфраструктуры

⏩ Поскольку готовых инструментов нет, Павел и Анатолий разработали инструменты, которые реализуют следующий подход:

🟣 Внедрение в процесс RDP-клиента. Использовали Application Verifier DLLs и COM Hijacking для перехвата интересных нам функций

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

Это лишь верхушка айсберга. В полном выступлении — технические детали реализации проекта, его подводные камни, разбор APDU-запросов и ответы на вопросы о break-glass-доступе.

📺 Посмотреть доклад можно здесь.

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

⚙️ Фестиваль технологий и инженерного воображения

24 сентября мы провели Yandex Neuro Scale — главную конференцию Yandex Cloud. Традиционно многие интерактивы и активности создавали сами разработчики для разработчиков.

Что происходило на площадке:

🟣 Говорящие грибы. Мы подключили мицелий к нейросетям через нейроинтерфейс. Грибы генерировали сигналы, которые YandexGPT превращала в текст, а SpeechKit — в голос

🟣 Серваки и сосиски. На стенде Infrastructure гости собирали серверы, а мы наглядно тестировали безопасность стоек с помощью пальцев-сосисок

🟣 Хаос в Контейнерленде. Мы создали отдельную вселенную, где сервисы не отвечают, поды падают, а хранилища недоступны. Участники могли попробовать себя в роли мастера K8s и исправить типичные ошибки в коде, чтобы всё спасти

🟣 Мечты о будущем можно было визуализировать на платформе SourceCraft, попрограммировав немного с ИИ-ассистентом и подправив YAML-конфиг. Все результаты стали частью частью общего «вихря образов»

Ребята прочитали более 50 докладов, провели 14 воркшопов и организовали 9 зон экспо. Кстати, на офлайн-часть конфы пришли три тысячи участников! Окунуться в атмосферу Yandex Neuro Scale можно по ссылкам ниже ⬇️

〰️ Фото
〰️ Презентации
〰️ Доклады

⏩ А полный разбор нашего техноперформанса вы можете почитать на Хабре.

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

⚪️ Как сварить ISO 27001 по рецепту Яндекс 360

Представьте, что ваша компания — это большая шумная кухня. Десятки ингредиентов-сервисов, свои вкусы и специи-процессы. Как приготовить из этого всего безопасное, вкусное и сертифицированное по мировым стандартам блюдо?

Меня зовут Люзия Алфёрова, и я консультант по информационной безопасности в Яндекс 360. Сегодня я поделюсь проверенным рецептом внедрения ISO/IEC 27001. А также приёмами, которые помогают нашей команде выдерживать технологический процесс так, чтобы ни одна деталь не была упущена, ничего не пригорело и информационная безопасность получалась стабильно высокого качества.

🍽️ Давайте заглянем на нашу кухню и узнаем, зачем нам вообще нужен этот ISO

Сертификация ISO/IEC 27001 — подтверждение того, что в компании внедрена и эффективно работает система управления информационной безопасностью, которая соответствует международным стандартам. За что она отвечает:

🟣 Единые правила игры. Все команды работают по одним и тем же базовым рецептам

🟣 Прозрачность и контроль. Мы заранее знаем, какие ингредиенты могут испортить блюдо

🟣 Доверие клиентов и партнёров. Подтверждение того, что наши сервисы безопасны

🟣 Непрерывное улучшение. Мы постоянно оттачиваем наши рецепты защиты

🟣 Баланс между стандартизацией и гибкостью. ISO/IEC 27001 помогает нам найти золотую середину

⏩ Как мы готовим основу для сертификации

Как и на хорошей кухне, мы начинаем с подготовки ингредиентов и проверки оборудования. Вот три ключевых принципа:

🟣 Единство без унификации. Мы варим архитектурный бульон вместе: общие процессы, автоматизацию, контроль. Но каждый сервис сохраняет свой уникальный вкус. Нет подчинения, есть общий ритм и постоянный обмен лучшими практиками

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

🟣 Аудит как помощь, а не наказание. Независимая команда внутреннего аудита регулярно пробует каждый сервис на вкус. Её цель — вовремя заметить слабые места и помочь скорректировать курс, а не искать виноватых

⏩ Добавляем специи по вкусу

Без базового набора специй (IAM, логирование, чек-листы) не получится ни одного блюда. Эти практики внедряются во все сервисы по умолчанию. А дальше начинается магия!

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

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

📖 Если хотите узнать все секреты от шефа, читайте полный разбор нашего фирменного рецепта на Хабре.

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

☕️ Музыка, любознательность + кофе

Спросили у ребят на OFFZONE 2025, какие навыки (кроме технических) помогают им в работе. В итоге выяснили, что хороший безопасник — это Индиана Джонс, который изучает артефакты и погружается всё глубже в подземелья кода 🤠

🐚 А вы согласны? Делитесь своим мнением в комментариях.

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

💕 Поздравляем с профессиональным праздником, инженеры!

Рассказывайте, как отметили 😎 А мы пока немного погрузимся в историю.

В 1988 году Information Systems Security Association объявила 30 ноября Международным днём защиты информации. Почему именно этот день и этот год?

💻 Дело в том, что 37 лет тому назад свыше 6 тысяч компьютеров, которые работали на сети ARPANET, пали жертвой первого массового вируса-червя. Это был эксперимент, который вышел из-под контроля: вирус создал аспирант Корнеллского университета Роберт Моррис.

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

🔒 Проблемой оперативно занялись учёные из Института Беркли. Им удалось справиться с червём и создать Computer Emergency Response Team. А кейс заинтересовал крупнейшие американские СМИ и указал на то, что сетевую безопасность нельзя недооценивать.

Так и родился наш праздник. И теперь эта дата служит напоминанием о важности кибергигиены и соблюдения мер предосторожности в Сети.

⏩ В честь этого мы делимся с вами полезными ссылками на статьи и доклады о защите информации:

🟣 Александр Каледа, Яндекс: «Наш драйвер — ответственность перед миллионами пользователей»

🟣 Составили рекомендации, как безопасно разрабатывать AI‑агентов и мультиагентные системы

🟣 Как атакуют ИИ. Руководитель ИБ «Алисы» и автономного транспорта «Яндекса» — о популярных хакерских техниках

🟣 Расследование инцидентов ИБ в облаке с Yandex Audit Trails

🟣 Что делать, когда нашёл эксплойт: шпаргалка, как помочь владельцу решения

🟣 Хакеры начинают фишинг и выигрывают у Google

🟣 Неугомонный VasyGrek: F6 изучила атаки злоумышленника в августе — ноябре 2025 года

🟣 Обход Cloudflare. Часть I

🟣 Как мошенники крадут криптовалюту под видом вакансий для QA-инженеров

🟣 В кеше — фотка, в ней — payload: новый метод скрытой доставки зловредов

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

📺 Каждый наш бинарник сам рассказывает о своих компонентах

На связи Сергей Краснов, ведущий инженер по информационной безопасности. Многие знакомы с теорией управления уязвимостями, но на практике всегда встаёт вопрос: с чего начать и как сделать процесс по-настоящему рабочим?

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

〰️ Мы поняли, что полагаться на один внешний источник данных об уязвимостях — это рискованно и не гибко

Поэтому создали внутреннюю базу уязвимостей, которая хранит данные по нашей схеме. Это даёт нам:

🟣 Независимость. Мы в любой момент можем сменить поставщика

🟣 Стабильность. Наша база всегда доступна

🟣 Расширяемость. Мы можем обогащать данные любыми полями

Просто генерировать SBOM-файлы недостаточно — их нужно уметь доставлять и сопоставлять с реально работающим кодом

Нужно понимать, что и в какой версии работает в вашей инфраструктуре. Так что мы решили, что можем вшивать SBOM прямо в исполняемые файлы на этапе линковки.

Инструменты сборки генерируют SBOM в формате CycloneDX, после чего линкер помещает эти данные в специальную секцию внутри самого бинарника. Необходимая информация становится неотъемлемой частью исполняемого файла, что позволяет сканеру безопасности контейнеров легко извлекать эту информацию прямо из контейнеров.

〰️ Как выглядит наш процесс целиком:

🟣 Собираем все SBOM и обновлённые фиды уязвимостей

🟣 Запускаем MapReduce, который доставляет код к данным

🟣 Выгружаем итоговые результаты их обработки

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

Так весь наш немаленький парк компонентов сканируется по свежим базам буквально за минуты. К тому же мы можем делать это хоть несколько раз в день, и нам не пришлось строить и поддерживать для этого отдельный сканер 😊

⏩ И это лишь часть большой работы, которую мы проделали, чтобы построить наш Vulnerability Management. Остальное ищите в полной записи доклада с Security Party на ютубе или в VK Видео.

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

🔒 Как в Яндексе защищают сервисы

Рассказываем про доклад Андрея Аникина, старшего менеджера проектов ИБ, и Владислава Альчикова, аналитика-разработчика. На митапе Security Party они показали, как устроена система управления доступом в Городских сервисах — это Яндекс Go, Маркет, Еда, Лавка и другие.

♒️ В Яндексе всеми правами сотрудников управляют через IDM-систему

Она интегрирована с 2100+ системами, а общее количество выданных ролей превышает 31 миллион (25,5 — персональные роли, а ещё 5,5 — групповые). IDM позволяет в любой момент увидеть, какие права есть у сотрудника, как их выдали и кем они были согласованы.

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

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

♒️ Риск двойной:

🟣 Компрометация аккаунта. Если учётную запись сотрудника взломают, злоумышленник получит доступ не только к текущим, но и ко всем старым забытым системам

🟣 Нелегитимное использование. Сам сотрудник может сознательно использовать старые права в корыстных целях

♒️ Как находят неиспользуемые доступы

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

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

🟣 Агрегация и анализ. Логи объединяются в рамках одного дня, чтобы работать с актуальным и управляемым объёмом данных

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

♒️ Сезонность и редкие роли

Ребята научили систему учитывать контекст. Например, роли в Самокатах зимой могут не использоваться, но это не делает их избыточными. Если все сотрудники перестали использовать роль, система увеличивает порог неактивности в 2–3 раза.

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

♒️ Также команда внедрила трёхуровневую систему контроля:

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

〰️ Алерты на аномалии. Если обычно в день отзывается 2–3 роли, а внезапно их становится сотни, нужно срочно проверить, не сломался ли процесс

〰️ Анализ перезапросов. Если отозванную роль быстро запрашивают снова, надо понять, почему именно так произошло

♒️ Чего удалось добиться от реализации всех перечисленных процессов

〰️ Отозвали на старте 25% от всех активных на тот момент ролей

〰️ Сэкономили десятки часов в неделю на различных ручных операциях

〰️ Улучшили безопасность и, самое главное, не сломали ни один процесс

📺 Полный доклад Андрея и Владислава можно посмотреть на ютубе и в VK Видео.

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity

⏩ Как безобидный Math.sqrt(0) чуть не сломал браузеры

Каким будет корень из нуля? Ответит даже школьник: 0. Но если задать этот вопрос JIT-компилятору Maglev внутри движка V8, то при определённых обстоятельствах он сначала скажет «ноль», а потом решит сэкономить на проверке безопасности и отдаст злоумышленнику доступ к памяти браузера 🤠

👨‍💻 Всем привет, на связи Павел Кузьмин, инженер по информационной безопасности в Яндексе. Я занимаюсь практической безопасностью Яндекс Браузера и проекта Chromium. Сегодня я расскажу про CVE-2025-9864 — уязвимость, которую я нашёл в движке V8.

Она проявлялась только при сочетании двух условий:

🟣 После полной сборки мусора (Major GC), которая освобождала память и меняла состояние контекста

🟣 При компиляции функции в Maglev, когда движок переключался на оптимизированное выполнение

В таком сценарии Math.sqrt(0) приводил к тому, что узел Float64Sqrt в IR-графе Maglev приобретал тип kHoleyFloat64. Это заставляло преобразовывать результат в HeapNumber (объект в куче), при этом не записав это преобразование в Remembered Sets.

Критическая ошибка возникала на следующем шаге. Компилятор видел, что исходно в ячейке хранился Smi, и пропускал write barrier — механизм, который сообщает сборщику мусора о новых ссылках на объекты в куче.

Как итог, если после этого сборка мусора запускалась вновь, HeapNumber удалялся как неиспользуемый, но указатель на него оставался активным. Получался классический use-after-free, который открывал путь к read/write-примитивам в куче V8.

🦾 Как починили?

Мы изменили тип узла Float64Sqrt с HoleyFloat64 на обычный Float64. Теперь ноль не превращался в HeapNumber, а корректно оставался Smi. Write barrier больше не пропускался, и цепочка разрушилась. Патч уложился в одну строку.

📖 А полную статью читайте на Хабре. В ней я рассказываю:

🟣 Как устроена архитектура V8
🟣 Почему write barrier — это не просто «галочка», а жизненно важный механизм
🟣 Как превратить use-after-free в read/write-примитивы и модифицировать объекты в памяти
🟣 Почему даже с такой уязвимостью взломать браузер через песочницу — та ещё задача

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

Подписывайтесь:
💬 @Yandex4Security
📹 @YandexForSecurity