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

Спросили у ребят на 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