Makrushin

Прощай 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. Так как процесс сборки практически всегда обращается к чувствительным данным и привилегированным учётным записям, то в итоге атакующий выполняет команду «отдай мне переменные окружения» на хосте, где выполняется сборка.

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