Makrushin

Стою, жду, когда праздники закончатся 🙃

Чтобы рассказать сразу несколько новостей:

* Для авторской колонки в “Хакере” подготовил обзор перспективных исследований за 2024 год, которые точно нужно изучить, а результаты — применить в своих проектах уже в этом году. Есть что почитать на выходных.

* Опубликовал ключевые инсайты, которые накопил за период обучения на программе MBA в Президентской Академии.

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

Технологии AutoFix: исправление 2/3 багов с первой попытки

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

* наиболее “зрелые” модели LLM способны исправить примерно 2/3 всех обнаруженных уязвимостей с первой попытки, но использование пользовательских подсказок позволяет улучшить этот результат;
* коммерческие и открытые модели имеют схожие показатели производительности при разной стоимости эксплуатации.

То есть, использовать Autofix можно, но внедрять исправленный код в прод без дополнительной верификации нужно аккуратнее. Например, исправление проблемы, связанной со слабым шифрованием или использованием небезопасных протоколов, может привести к сбоям в работе приложения.

Есть и другие ограничения:

* сложности с зависимостями и импортами: модели часто не могут правильно обработать сложные зависимости и импорты в кодовой базе. Например, когда LLM предлагает переписать код для использования методов безопасной сериализации, но не предлагает импортировать библиотеку для этой задачи.
* LLM могут предлагать новые зависимости для проекта, которые могут принести новые уязвимости в этот проект;
* недостаточный контекст: модели часто предлагают исправления, которые не соответствуют шаблонам проектирования или общей архитектуре проекта.

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

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

Атаки на GitHub-разработчика в 2024 году

Тренд «Platform Engineering» стал интересен не только компаниям, которые трансформируют свои процессы, команды и инструменты согласно новым подходам. Этот тренд также интересует и злоумышленников, которые используют возможности платформ разработки для проведения атак.

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

Генеративный ИИ повышает производительность разработки. Или нет?

В одном из комментариев в моем канале в Сетке появился вопрос: “а как вы измеряете эффективность разработки?”. Вспомню ключевой тезис в дискуссии CTO Day: измеряем бизнес-результатами и скоростью выпуска новых бизнес-функций в продукте.

Встретил свежую исследовательскую работу, в которой утверждается, что использование инструментов с ИИ увеличивает производительность разработчика на 26,08%. Значит, в этой работе должны быть метрики производительности и эффективности.

Методика исследования:

* три рандомизированных контролируемых эксперимента в реальных условиях на примере трех компаний (Microsoft, Accenture, анонимная компания из списка Fortune 100). В процессе эксперимента разработчикам был случайным образом предоставлен доступ к GitHub Copilot, либо они попадали в контрольную группу без доступа.
* Анализ данных проводился с использованием двухшагового метода наименьших квадратов (2SLS). Оценки 2SLS взвешивались по разнице в использовании между экспериментальной и контрольной группами за период.
* Для оценки влияния инструмента на производительность разработчиков использовались такие показатели, как количество выполненных pull request, количество коммитов кода и количество сборок кода, а также показатели использования Copilot, такие как количество предложений и количество принятых предложений.

Вот оно! Pull request, количество коммитов кода и количество сборок — ключевые показатели для оценки. Какие есть ограничения при оценке этих метрик:

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

Действительно ли в количестве pull requests измеряется производительность разработки — вопрос все еще открытый.

Фреймворк для оценки качества правил выявления угроз

Методология Detection-as-Code уверенно приземляется не только в центрах мониторинга угроз, но и в исследовательском сообществе. Использование LLM для генерации правил усиливает этот тренд. При этом, проведение анализа качества нового правила ложится на плечи аналитика. И тут каждый тестирует, как умеет или придерживается какой-то тактики.

Если тактики нет, то можно изучить фреймворк для оценки качества правил обнаружения угроз “Shannon Signal Score”. Его автор предлагает использовать объективные и субъективные метрики, учитывая специфику организации и контекст угроз. Категории метрик:

1. соответствие угрозам и охват;
2. целостность обнаружения;
3. когнитивная нагрузка и операционные затраты на обнаружение, расследование;
4. потенциальный риск;
5. практическая польза.

Для количественной оценки используются статистические показатели, а для качественной – LLM. Получилась гибкая система. Кто решит внедрить - поделитесь впечатлениями.

Прощай CSRF: поиск и эксплуатация уязвимостей Client-Side Path Traversal

Из нетривиальных уязвимостей, о которых давно известно, но которые пока еще мало кто целенаправлено ищет - можно выделить категорию Client-Side Path Traversal (CSPT).

Исследователи хорошо знают проблемы, связанные с обходом каталога. Уязвимость path traversal позволяет использовать строки вида «../../../../../» для доступа к данным за пределами целевого каталога. В отличие от уязвимости на стороне сервера, CSPT дает атакующему возможность заставить жертву осуществлять запросы к интересным конечным точкам API. И эта возможность - первое условие для реализации атаки.

Второе условие: наличие интересного эндпоинта, к которому можно обратиться и осуществить какое-либо действие. Напоминает сценарий CSRF? Да. При этом у CSPT есть особенность: существующие механизмы защиты от CSRF-атак (например, токены) оказываются неэффективными для решения этого класса проблем.

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

Первый DevSecOps-хакатон от сообщества FinDevSecOps

На прошлой неделе мы провели первый DevSecOps-хакатон, который стал важным событием для безопасной разработки ПО в России. Мероприятие стало первым, где участникам было предложено построить пайплайн с учетом требований ГОСТ 56939.

Участие приняли 11 команд, из которых 7 дошли до финала. Студенческие команды не только успешно выполнили задания, но и качественно представили жюри свои решения. И я бы даже отметил, что сделали это не менее интересно, чем команды коммерческих организаций.

Работы оценивались по следующим критериям:

* покрытие security-проверками всех этапов жизненного цикла разработки;
* применение решений из различных практик DevSecOps;
* качество тонкой настройки инструментов для работы с ложными срабатываниями;
* соответствие предложенных решений требованиям ГОСТ 56939;
* возможности масштабирования решения и сложность его технической поддержки.

Одним из призов стал курс по безопасной разработке, который мы совместно с МГТУ им. Баумана подготовили для обучения AppSec-инженеров и security-чемпионов. Получается, что победители увезли с собой не только награды, но и новые навыки.

Поиск секретов и уязвимостей dangling DNS в больших данных

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

С переходом инфраструктуры в облака, второй метод может дать интересные результаты. Например, если на большом пуле IP-адресов крупных облачных провайдеров вроде Google и AWS поискать “висячие” DNS-записи (dangling DNS), которые указывают на несуществующий ресурс и доступны для захвата, то можно обнаружить много возможностей для атак subdomain takeover.

Более 78000 “висячих” DNS-записей, которые указывают на 66000 уникальных доменов верхнего уровня. Среди владельцев этих доменов есть крупные компании и бренды, а значит, злоумышленник может разместить на этих доменах свой ресурс, который будет эксплуатировать доверие пользователей.

Аналогичный подход можно применить и к поиску секретов в файлах. Если взять источник вроде Virustotal и с помощью YARA-правил поискать в нем файлы с секретами, то можно обнаружить более 15000 секретов. Среди них: 2500 ключей для подключения к инфраструктуре OpenAI, 3000 ключиков для AWS и Google Cloud.

Подход поиска уязвимостей в больших данных состоит из ключевых принципов:

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

Применяй этот подход, чтобы освежить свои исследования.

Фишинг для пользователей GitHub

Платформа ведет борьбу со спам-ботами, которые эксплуатируют ее репутацию и отправляют пользователям сообщения с вредоносными ссылками.

Особенность этого фишинга: пользователь платформы получает письмо от GitHub. Боты добавляют вредоносные ссылки в комментариях к существующим задачам (issues) открытых проектов. И затем, эти комментарии приземляются в почту в виде нотификации к пользователям этого проекта. Дальше уже все по классике: запуск вредоноса, захват GitHub-аккаунта и публикация аналогичного комментария со ссылкой в репозиториях, которые добавил в закладки этот аккаунт.

Red Team рассматривает эту особенность как дополнительный канал доставки импланта, потому что в комбинации с техникой загрузки вредоносных файлов в GitHub CDN он позволяет уверенно обходить спам-фильтры. А Blue Team теперь внимательнее следит за почтовыми уведомлениями от GitHub.

Инструмент для поиска уязвимостей в сторонних пакетах

Продолжаем внедрять в разработку новые идеи для обеспечения безопасности сторонних компонентов. Мы уже рассматривали средство поиска плохих зависимостей PyPI и NPM, которое при помощи статического анализа кода искало вредоносные признаки. А вот недавно опубликованный инструмент DepFuzzer использует другой метод:

* инструмент составляет список всех зависимостей, указанных в файлах проекта (поддерживаются проекты для Node.js, Python, Rust, Golang);
* для каждой зависимости проверяет ее наличие в базе данных deps.dev (это общедоступная база, которая содержит информацию о зависимостях ПО);
* если зависимость не найдена в deps.dev, DepFuzzer предупреждает о потенциальной уязвимости, связанной с подменой зависимости (то есть подсказывает, что для данной зависимости злоумышленник может попытаться опубликовать вредоносный пакет с таким же именем в общедоступном репозитории);
* DepFuzzer также может проверять адреса электронной почты владельцев пакетов, чтобы выявить потенциальные уязвимости, связанные с удаленными учетными записями.

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

Спринт от идеи к курсу для подготовки security-чемпионов

В начале была проблема. В международной корпорации, где вместе с командой продуктовой безопасности я строил процессы разработки, была нехватка инженеров Application Security. На несколько тысяч разработчиков оказалось всего несколько AppSec-специалистов, и с ростом скорости производства становилось сложнее исправлять обнаруженные дефекты.

В тот период появилась очевидная идея: помимо внедрения автоматизации нужно разрабатывать и внедрять программу подготовки Security Champions - разработчиков внутри компании, которые берут на себя ответственность за продвижение и укрепление культуры безопасности в своей команде. К тому же, мой коллега - Александр Антух уже проходил этот путь в своей компании и подготовил отличный плейбук для OWASP.

Мы разработали внутренний курс, который на примере наших процессов и дефектов рассказывал разработчику и Engineering Manager’у, как правильно работать с обнаруженными проблемами. Сначала мы провели обучение в российском офисе, и потом поехали в Калькуту для того, чтобы обучить наших индийских коллег.

Затем случилось озарение: программа работает и влияет на показатели в разработке (значительно ускоряет процесс обработки дефектов), почему бы не поделиться этим опытом с коллегами? Мы организовали и провели первый двухдневный тренинг для Security Champion на крупной конференции Hack In The Box в Амстердаме. Это был концентрат из практических кейсов использования инструментов поиска дефектов на разных стадиях производства, знакомство с лучшими практиками и определение контекста для их применения, и много практической работы. В этот момент прилетел следующий инстайт.

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

Курс стал частью программы подготовки специалистов в НИЯУ МИФИ, затем частью программы подготовки магистров в МГТУ им. Баумана. Основные разделы курса также вошли в программы дополнительного образования Skillfactory и других коммерческих школ.

Сейчас тот момент, когда программа Security Champion должна обновиться с учетом трендов в области поиска уязвимостей и внедрения ИИ для автоматизации. А еще должна превратиться в интенсив.

И она обновилась и превратилась.

11 ноября вместе с командой МГТУ мы запускаем набор первого потока учеников для курса «Безопасность приложений». Будем интенсивно изучать AppSec, строить DevSecOps и составлять правильные запросы для ИИ.

Опасные архивы: символические ссылки и уязвимости Zip Slip в Golang

Пока обновлял раздел курса про поиск и эксплуатацию уязвимостей directory traversal, наткнулся на интересное развитие старой уязвимости Zip Slip. Атакующий может загрузить специально сформированный архив (tar, jar, war, cpio, apk, rar, 7z), и если модуль, отвечающий за его распаковку, не проверяет имена файлов, атакующий может выйти за пределы каталога, в который производится распаковка.

Об этой проблеме известно с 2018 года, но уязвимых библиотек по-прежнему много. А вот об интересной особенности процесса распаковки в Golang известно совсем недавно. Запакуем в tar-архив два файла с одинаковым именем:

$ tar -tvf alice.tar
lrw-------  0 0      0           0  1 Jan  1970 rabbit_hole -> /tmp/wonderland
-rw-r--r--  0 0      0          39  1 Jan  1970 rabbit_hole

Первый файл является символической ссылкой, а второй — текстовым файлом.

Какое поведение мы ожидаем от распаковки? При распаковке файл с символической ссылкой должен быть заменен текстовым файлом.

На самом деле, оказалось, что если распаковка происходит с помощью Golang-функции os.Create(), то содержимое файла заменяется на содержимое символической ссылки. Это значит, что атакующий может создать произвольный файл в любом месте системы.

Причина такого поведения заключается в некорректной обработке символических ссылок в при распаковке tar-архивов. Поэтому защищаем свои ресурсы от “зараженных” архивов. Инструмент для проверки поможет.

*makrushin

Вести из Бауманки: новый курс "AppSec-инженер"

В прошлом году мы собирались в НИЯУ МИФИ, чтобы познакомиться с профессией "Специалист по безопасности приложений". А в этом году, мы встретились с коллегами на кафедре ИУ10 в МГТУ им. Баумана, определили требования к навыкам современного разработчика, сформулировали учебную программу, согласовали с Минцифры и на базе цифровой кафедры запустили новый трек: “AppSec-инженер”.

Всем, кто хочет преобразоваться из разработки в AppSec или из DevOps в DevSecOps — добро пожаловать на борт! 🚀

За сценой SafeCode: как Программный Комитет делает разработку безопаснее

Безопасность приложений — обязательное требование для любой компании, если она создает качественный продукт. На конференции SafeCode разработчики делятся лайфхаками по безопасной разработке.

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

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

Выбор инструментов для безопасной разработки: важность контекста и интеграции

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

SCA, SAST, DAST, IAST, MAST, WAF - эти аббревиатуры уже стали привычными. CSPM, KSPM, ASOC, ASPM, ASPE, CNAPP, DSPM, CWP, RASP, SSPM, CVM, ASM, AST - вот тут уже может поплыть даже начинающий инженер ИБ.

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

1. Контекст важнее всего.

Security-инструменты отличаются своим “шумом”: они создают слишком много предупреждений и инсайдов. Новые продукты делают упор на контекст, в котором обнаружилась проблема. При ограниченном ресурсе, это помогает выставить приоритет.

2. ASPM и ИИ - два ключевых “агента изменений” в разработке.

Application Security Posture Management (ASPM) - продукт, который помогает управлять безопасностью приложений на всех этапах разработки, и который пока еще не стал стандартом в SDL. Про потенциал ИИ уже рассказывал.

3. Курс на консолидацию.

Зрелая команда разработки использует примерно 15 инструментов безопасности. Каждый инструмент решает свою задачу и возможно, делает ее хорошо. Но эффективно управлять этим оркестром можно только, если есть “панель управления для дирижера”.

Вернемся к вопросу: нужны ли нам новые решения или старые инструменты еще справляются?

“Атаки на разработчиков” в Ярославле

Что security-исследователю делать на конференции, посвященной разработке и AI? 🤔

Пугать разработчиков

Делиться опытом в исследовании уязвимостей в цикле разработки и рассказывать о примерах атак, которые может упростить ИИ. А в конце этих историй поговорить о сценариях применения LLM для задач обеспечения безопасности в SDL. Кстати, Уставший техдир рекомендует, потому что уже слышал эти истории в своем пока еще неопубликованном подскате.

Поехали на Yappi Days - познакомимся и сделаем новую задачу для OSINT. Промокод для друзей и коллег: MAKRUSHIN30

Еще больше способов оценить наступательные способности ИИ

Сразу два новых бенчамарка стали доступны для анализа возможностей ИИ в поиске уязвимостей и тестировании на проникновение:

* Cybench - набор из 40 заданий Capture the Flag (CTF), которые содержат подзадачи для более точной оценки способностей языковых модели. Задания разбиты на категории, знакомые CTF-игрокам.

* XBOW Validation Benchmarks. Компания XBOW специализируется на разработке средств автономной симуляции атак. Ее набор состоит из 104 бенчмарков, каждый из которых содержит множество уязвимостей и множество вариантов их обнаружения.

Жду появления в классических CTF-соревнованиях команды, состоящей из LLM-агента и его оператора.

Как заметили в комментариях к посту про OSINT в Сетке, я не просто так шел по средней дамбе в Перми. Я направлялся на мероприятие «Инфофорум», чтобы в неформальной обстановке обсудить ключевые приоритеты в информационной безопасности.

Уверен, в каждом регионе появится свой центр экспертизы в кибербезопасности, который будет учитывать специфику угроз для предприятий региона. Что-то вроде локальной команды реагирования на инциденты CERT. А подобные мероприятия - это региональная точка притяжения экспертов и технологических инноваций.

Опечатки в GitHub Actions запускают вредоносные действия

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

GitHub Actions - это сервис, который позволяет автоматизировать процессы сборки, тестирования, развертывания своего приложения и множество других рутинных действий. Многообразие рутинных задач можно автоматизировать, а подходящие автоматизации можно найти в Маркетплейсе. Только есть проблема: кто угодно может создать произвольный Action и опубликовать его под произвольным именем.

Что если, кто-то создаст организацию «trufllesecurity», затем создаст Action «trufllesecurity/trufflehog» и разместит в нем код, который собирает все секреты из CI/CD? Когда разработчик вместо «uses: trufflesecurity/trufflehog» допустит опечатку и напишет «uses: trufllesecurity/trufflehog» - в его пайплайне запустится вредоносное действие.

Пока злоумышленники собирают с миру по нитке, следуем рекомендациям, чтобы не оказаться в этом клубке:
* перепроверяем названия всех используемых GitHub Actions;
* явно прописываем конкретные версии Actions;
* рассказываем своим коллегам-разработчикам о проблеме.

Коллекция уязвимостей в инструментах наступательной безопасности

Кто атакует атакующего? Тот, кто охотится за доступами к зараженной инфраструктуре. Или тот, кто пытается обнаружить злодея. Поэтому идея “hacking back”, старая как мир, по-прежнему актуальна.

Уязвимости в инструментах Red Team, а точнее - в средствах администрирования зараженной инфраструктуры, открывают новые возможности для конкурирующих между собой злодеев.

Нашел коллекцию, в которой для каждой уязвимости есть детальное описание. Это поможет экспертам по наступательной безопасности задуматься и о своей защите. И спросить себя: а не пора ли повысить уровень паранойи от минимума к оптимуму?

⭐️Добавляем коллекцию в закладки.

Провинциальный OSINT: где я?

Продолжаем отрабатывать навыки определения места по фото.

⭐️ На этот раз задача со звездочкой: определить город, где сделано это фото, и мероприятие по информационной безопасности, которое меня сюда привело.

Фото сделал специально без явных теней. Если среди нас не окажется местных жителей, то в комментариях добавлю больше локаций.

О чем может рассказать тень на фото?

Ответ: о твоем местоположении.

Полезный инструмент в коллекции OSINT-исследователя. Позволяет определить примерные координаты места, где была сделана фотография. Утилита использует параметры высоты объекта, длины его тени, дату и время, и затем проводит оценку мест, где могла появиться тень с такими параметрами.

Те, кто не хочет раскрывать свое местоположение - начинают блюрить тени на фотках. И перестают их постить.

И еще 10 золотых километров🥇

Отравление пайплайна разработки

Мы уже изучали, как злоумышленник может навредить разработчику и заразить зависимости в цепочке поставок. А вот сам CI/CD-пайплайн - дирижёр конвейера разработки - мы ещё не рассматривали. При этом GitLab и GitHub всё чаще закрывают уязвимости в своих продуктах, что говорит о внимании злодеев к ключевым технологиям в инфраструктуре.

OWASP давно опубликовал документ CICD Top 10 Risks. Значительная часть рекомендаций по защите отдана на сторону разработчика и владельца репозитория: не доверяй pull request от сторонних контрибьюторов, аккуратнее прописывай правила автоматического слияния веток кода, не запускай сборку недоверенных обновлений кода рядом со сборками основной ветки и так далее. Однако злодей активно использует уязвимости в самих CI/CD-платформах для внедрения имплантов, поэтому одних рекомендаций, требующих внимания разработчика - недостаточно.

Можно изучить подборку актуальных методов эксплуатации GitHub Actions, чтобы понять типичный сценарий атаки на CI-окружение (который также был замечен в дикой природе):

1. Атакующий изменяет конфигурационный файл CI в репозитории, к которому у него есть доступ, и внедряет в этот файл команду «отдай мне переменные окружения с ценными данными».

2. Затем заносит изменения непосредственно в основную ветку репозитория или отправляет pull request с изменениями из ветки или форка.

3. Если у атакующего нет возможности вносить изменения напрямую в файл конфигурации CI, то он может внедрить вредоносный код в файлы, на которые ссылается CI-конфиг.

4. Далее атакующий отправляет pull request, который заставляет CI-платформу запустить процесс сборки на основе вредоносного конфига.

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

🤔 Как защищаемся?

GitHub-звезды могут обмануть разработчика

Как мы обычно оцениваем репутацию какого-нибудь GitHub-репозитория? Чаще всего на основе количества звезд и активности в этом репозитории. Для кого-то из разработчиков число звезд напрямую определяет степень доверия к этому репозиторию.

В связи с этим растет количество фейковых звезд на GitHub: их уже насчитывается более 3,7 миллионов. Эти звезды создают ложное впечатление популярности проектов, которые на самом деле скрывают вредоносное ПО или какой-либо мошеннический контент. Злодеи используют их для обмана разработчиков, маскируя опасные репозитории под успешные проекты.

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

Моделируем угрозы по-быстрому: STRIDE

Бывают ситуации, когда необходимо быстро подготовить модель угроз. Например, внезапно команда разработки решила самостоятельно провести Security Design Review для новой фичи. Или только что образованной команде безопасности продукта потребовалось определить приоритеты в анализе защищенности. А еще бывает так, что в стартапе, где все занимаются всем, потребовалось выстроить процесс безопасной разработки, и нужно с чего-то начать.

Рецепт быстрой подготовки модели угроз:

1. берем методологию STRIDE;
2. садимся вместе со всеми причастными командами и совместно заполняем шаблон;
3. получаем таблицу угроз и действий для их устранения;
4. опционально: к обнаруженным угрозам добавляем оценку рисков по модели DREAD;
5. опционально: автоматизируем процесс с помощью инструмента STRIDE GPT.

Августовский #дайджест: топ постов

* Как оценить возможности ИИ в обнаружении уязвимостей?

* Побег из контейнера: обзор техник

* Платформа разработки: гайдлайны

* Доступ к данным из удаленных и приватных репозиториев GitHub

* ИИ ассистент для security-аналитика

* Подборка исследований с Black Hat 2024

* Запуск security-проекта: шаблоны и чеклисты для быстрого старта

@makrushin

Запуск security-проекта: шаблоны и чеклисты для быстрого старта

Встретил полезный ресурс с шаблонами для запуска security-проектов. Программа багбаунти, тестирование на проникновение, процедуры реагирования на инциденты и управления уязвимостями - документы пригодятся новой команде безопасности, владельцу продукта или начинающему CISO в каком-нибудь стартапе.

В репозитории содержатся:

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

Вместе с командой ИУ10 МГТУ им. Баумана мы накатили обновление в образовательную программу кафедры «Защита информации» и подготовили проект, который добавит разработчику новые суперспособности.

Перевернем календарь и запустим трансформацию ⚡️

Подборка исследований с Black Hat 2024

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

Возьмем доклады Black Hat, изучим материалы и самостоятельно выделим перспективные направления. Моя подборка:

* “From Weapon to Target: Quantum Computers Paradox” - исследование вопросов безопасности квантовых компьютеров и процесса квантовых вычислений. Несмотря на активное обсуждение влияния квантовых вычислений на классическую криптографию, вопросы безопасности самих квантовых систем остаются малоизученными. Авторы анализируют уязвимости и возможные векторы атак на квантовые вычислительные инфраструктуры, включая программное обеспечение и облачные сервисы. Примеры выявленных проблем: кража токенов аутентификации, изменение квантовых цепочек программ в SDK, а также атаки на квантовые процессоры.

* “SnailLoad: Anyone on the Internet Can Learn What You're Doing” - интересная техника составления профиля пользователя без каких-либо вспомогательных инструментов посередине (без агентов на его рабочей станции или прокси-серверов в его сети). Канал утечки данных находится в задержках сети, которые появляются, когда пользователь взаимодействует с онлайн-контентом. Анализируя эти задержки, злоумышленник может точно определить действия пользователя, что может привести к раскрытию конфиденциальной информации и деанонимизации. Эта техника подчеркивает уязвимость даже защищенных сессий браузера перед сложными атаками на основе временных характеристик (timing-атаки).

* “Listen to the Whispers: Web Timing Attacks that Actually Work” - и еще одно исследование timing-атак, но уже в контексте безопасности веб-приложений. Приведены примеры ситуаций, когда атакуемая система раскрывает конфиденциальные данные из-за разных временных задержек при обработке запросов. Техника пригодится для обнаружения скрытой поверхности атаки и определения некорректных настроек прокси-серверов.

* “Deep Backdoors in Deep Reinforcement Learning Agents” - техника интеграции «вредоносных нейронов» в нейронную сеть. В исследовании описаны сценарии компрометации ИИ-агентов на этапе их обучения и последствия неправильных решений, которые эти агенты могут принимать в промышленности, автономном транспорте и кибербезопасности.

⭐️ Подборка исследований Black Hat 2023.

#дайджест @makrushin

ИИ ассистент для security-аналитика

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

* Аналитик загружает в LLM техники атак, описанные в формате блогпоста или отчета об угрозе.
* В запросе к LLM аналитик указывает синтаксис, в котором должно быть описано правило детекта.
* Модель генерирует правила детекта. Некоторые правила могут иметь неправильный синтаксис или быть результатом галлюцинации. Аналитик выявляет некорректные правила и корректирует свой запрос (промпт).

Самый ресурсоемкий для аналитика этап - это составление точного промпта. Поэтому важно отработать навык prompt engineering.

Так как написание правил - это процесс, который зачастую происходит в свободное от обработки инцидентов время, то данный сценарий залетает в бэклог к лидеру Security Operations.

Ага, примерно так security-инженер видит новую команду Платформы

Платформа разработки: гайдлайны

Тому, кто ответил на вопрос «зачем?» нужна своя платформа, и решил трансформировать свои процессы, инструменты и команду в Платформу Разработки, предстоит определиться с подходом и ответить на вопрос «как?».

Заряжаемся материалами, в которых утверждается, что методология ускоряет производство продуктов и снижает когнитивную нагрузку на разработчика. Затем погружаемся в создание Internal Developer Platform:

Этап 1: разработчики бизнес-функций работают с Платформой как клиенты с витриной в магазине - обслуживают сами себя. Поэтому определяем путь разработчика «от запроса до результата», разделяем этот путь на функциональные слои и собираем технологии, которые помогут этот путь пройти.

Этап 2: создаем референсную архитектуру.

Этап 3: описываем MVP (Minimum Viable Platform).

Этап 4: определяем роли и экспертов для команды разработки.

И не забываем про Этап 0.