МТС RED ART: обзор перспективных security-исследований
Всем привет! Меня зовут Денис Макрушин, я отвечаю за создание технологий кибербезопасности в MTC RED и возглавляю команду перспективных исследований МТС RED ART (Advanced Research Team).
Сегодня проведу разбор самых интересных исследований первого квартала 2024. Под катом — новые методы поиска уязвимостей и секретов в исходном коде, инструменты и принципы построения безопасной разработки и многое другое.
Secure by Design: принципы построения защищённых систем от Google
Пока исследователи и центры мониторинга разбирают бэкдор, который умело спрятан в новых версиях широко используемой библиотеки liblzma, мы ознакомимся с отчётом Secure by Design at Google. В нём инженеры безопасности пересмотрели принципы построения современных приложений.
Цель отчёта — сократить разрыв между концептуальными требованиями Secure by Design и их практическим применением. Ключевые инсайты:
Инженеры Google столкнулись с вызовом: скорость изменений в программном обеспечении и в особенности в облачном ПО настолько высокая, что не позволяет реализовать существующие требования безопасности. Они актуальны скорее для физических систем, поскольку в физических системах после тщательного проектирования архитектуры риск появления дефектов на этапе производства существенно ниже, чем в ежедневных обновлениях ПО.
Ключевое требование — дизайн, ориентированный на пользователя. «Наша задача заключается в проектировании и внедрении продуктов и сервисов, которые обеспечат безопасность наших пользователей», — утверждают авторы документа. На практике это означает необходимость формировать требования безопасности и архитектуру продукта, отталкиваясь от действий пользователя. Для каждого действия нужно оценить, может ли оно привести к неблагоприятным последствиям, а если да, то каким образом. При этом разработчик — тоже пользователь.
Дизайн-мышление в терминах инвариантов.
Объясню, что такое инвариант. Это свойство системы, которое не изменяется при любых действиях пользователя или атакующего. В контексте безопасности инвариант означает неизменяемое состояние системы. Например, весь сетевой трафик, проходящий через незащищённые каналы, всегда защищён с использованием надёжного протокола.
Инварианты безопасности помогают исключить какие-либо требования к пользователям и сфокусировать архитектора на требованиях к системе, с которой он работает. При этом реализация всех инвариантов может быть проверена автоматически на этапе анализа качества ПО.
Когда-то появилась концепция «неизменяемой инфраструктуры» (Immutable Infrastructure). Теперь инварианты дают архитектору возможность сделать реализацию архитектуры «неизменяемой» на этапе разработки.
Поиск секретов в скрытых git-коммитах
Искать секреты в исходном коде мы уже умеем. Но в git-репозиториях остались интересные места, до которых стандартными способами не доберёшься. Речь о скрытых коммитах — информации об изменённых файлах в репозитории, которая была удалена и не отображается в истории проекта.
Когда разработчик вносит изменения (коммиты) в репозиторий, а потом по какой-то причине хочет их отменить, он выполняет команды:
git reset --hard HEAD^
git push origin -fПервая строка отменяет последний коммит и все последние изменения в файлах целевого репозитория. А вторая применяет все изменения в этом репозитории. То есть эти команды удаляют последние внесённые изменения.
Тут появляется важная особенность, которую отметили исследователи: если коммит недоступен в истории изменений, это не означает, что его нельзя восстановить. И тогда все коммиты, которые содержали секреты и затем были удалены разработчиком, можно восстановить и извлечь из них ценную информацию.
Пример скрытого коммита
Исследователи опубликовали инструмент для извлечения скрытых коммитов публичного GitHub-репозитория и их анализа. Для репозиториев GitLab эта техника тоже работает, а ещё есть готовый инструмент. Security-чемпионы и специалисты по безопасности приложений берут этот подход в работу.
Метод поиска n-day-уязвимостей в бинарном коде
Люблю и иногда практикую фаззинг для поиска дефектов в ПО. Если сегодня взять какой-нибудь непопулярный таргет, подготовить стенд и запустить тесты, то в течение недели можно найти пачку интересных багов.
К уже известным техникам добавилось свежее исследование, которое точно нужно воспроизвести: BinGo: Identifying Security Patches in Binary Code with Graph Representation Learning.
Это интересный метод поиска security-патчей в бинарном коде приложений. Он актуален для тех случаев, когда владелец приложения скрытно исправляет какие-либо уязвимости в своём коде без регистрации CVE или без описания в change log. Помогает выявлять n-day-уязвимости.
Метод основан на представлении бинарного файла в виде Code Property Graph — промежуточном представлении кода, изначально разработанном для анализа его безопасности. CPG включает в себя абстрактное синтаксическое дерево, граф потока управления и зависимости данных.
Ключевые этапы метода поиска n-day-уязвимостей
Особенность этого метода заключается в разработанной модели обнаружения security-исправлений, которая сравнивает бинарные файлы до и после исправления. Для этого она использует сиамскую нейронную сеть, которая позволяет выделить сходство или различие между бинарями.
Уровень обнаружения security-патчей среди прочих модификаций бинарного кода — 80,77%. Отлично! Осталось подобрать интересные таргеты.
Что, если использовать метод определения security-патчей для выявления закладок в бинарном коде?
Есть гипотеза, что метод и система определения security-исправлений в бинарном коде могут применяться для выявления вредоносных модификаций (закладок или имплантов) в приложениях. Чтобы проверить гипотезу, можно провести исследование. Этапы могли бы быть такими:
Подбор примеров (семплов) модификаций кода — то есть закладок.
Формирование CFG для подобранных семплов.
Обучение сиамской сети для определения сходства заданного CFG с целевым CFG, полученным от семплов.
Возможно, кто-то из читателей захочет её проверить.
Стратегия выявления угроз: на чём сосредоточить усилия при разработке методов обнаружения?
Как достичь эффективности в выявлении угроз при ограниченном ресурсе? Как оценить качество методов обнаружения? Встретил серию статей от автора, который ищет ответы на эти вопросы.
Security-инженеры и аналитики SOC знают, что ключевая цель при выявлении угроз — это создать механизмы для обнаружения и предотвращения как можно большего количества методов, которые использует злоумышленник. То есть эта цель превращается в решение задачи: не допустить, чтобы атакующий прошёл все этапы своего пути до своей цели и остался незамеченным. С этого момента начинается игра вероятностей: насколько вероятно, что атакующий пойдёт по пути, который не заметит защищающийся?
Помогает такая модель:
Представляем каждую технику матрицы Mitre ATT&CK в виде точки.
Представляем путь атакующего от получения первичного доступа до продвижения к цели в виде определённой последовательности таких точек.
Техники матрицы, у которых есть множество подтехник, тоже раскладываем на группы точек. Размер группы увеличивает вероятность выполнения этой техники.
Каждую подтехнику выполняем с помощью разных процедур и инструментов: это добавит ещё больше точек в группы.
Следуем тактике выявления: чем больше процедур в рамках одной подтехники охватывает метод обнаружения, тем лучше этот метод. Эффективный метод обнаружения — тот, который выявляет процедуру с наибольшим количеством связей с другими процедурами.
И вот тут гипотеза, которую можно проверить в рамках исследовательской работы: составить граф всех процедур Mitre ATT&CK и определить узлы с наибольшим количеством связей. Пример на рисунке отмечен жёлтым.
Пример графа процедур Mitre ATT&CK
Эти узлы станут базой для выстраивания системы защиты и помогут определить приоритеты в условиях ограниченных ресурсов. Аналитик центра мониторинга получит ещё одну возможность количественно обосновать необходимость разработки нового детекта или покупку «того самого» средства защиты.
Распространение вредоносного кода через комментарии GitHub
Исследователи обнаружили троян, который распространяется под видом игровых читов и крадёт инфу с заражённой станции. Сам зловред вряд ли чем-то примечателен, зато интересен способ его распространения. Источник, в котором опубликован загрузчик трояна, — официальные GitHub-репозитории Microsoft.
Пример URL с вредоносным кодом:
https://github[.]com/microsoft/vcpkg/files/14125503/Cheat.Lab.2.7.2.zipGitHub позволяет злоумышленникам обходить правила блокировки на основе чёрных и белых списков.
Как троян там оказался:
Злодей создаёт комментарий к любому коммиту или issue в репозитории Microsoft.
В комментарий загружается вложение с произвольным файлом.
Файл будет загружен в GitHub CDN и привязан к проекту с уникальной ссылкой. Формат ссылки:
https://www.github.com/{project_user}/{repo_name}/files/{file_id}/{file_name}Комментарий может быть не опубликован, но при этом ссылка становится активной.
Атакующий может прикрепить вредоносный файл к любому репозиторию. Пока что единственный вариант уберечь свой проект от подобного использования — отключить комментарии.
Повышение уровня наблюдаемости процессов DevSecOps
Университет Карнеги-Меллона представил фреймворк Polar, который повышает наблюдаемость данных внутри платформы разработки ПО. Цель — увеличить скорость и качество управленческих решений внутри существующего DevSecOps-пайплайна.
В основе архитектуры фреймворка находится графовая БД, которая отвечает за управление данными и их представление в виде графа. В основе этого графа находится отношение между несколькими ролями, которые работают с данными:
Observers — компоненты, отвечающие за мониторинг ресурсов и сред.
Information Processors — связующие звенья, которые преобразуют необработанные данные от Observers в структурированные данные графовой БД.
Policy Agents — ведут контроль всех компонентов системы и с помощью конфигураций обеспечивают их работу в рамках заданных параметров.
В итоге граф — это модель данных, которая показывает актуальные взаимосвязи в операционной деятельности бизнеса.
Архитектура фреймворка
Использовать такой граф можно, например, чтобы проанализировать существующие процессы DevSecOps для последующей оптимизации и снижения показателя Time to Deploy.
Инсайты из аналитических отчётов
В отчёте подразделения Palo Alto Unit42 отмечен тренд: использование скомпрометированных учётных записей становится ключевой тактикой атакующих для обеспечения первичного доступа в организацию. Если в 2022 году для этой задачи в основном использовался фишинг, то уже в 2023 году эта техника отошла на второй план. На взломанные утечки приходится 20,5% от всех зафиксированных инцидентов.
Исследователи Google опубликовали отчёт с разбором 0day-уязвимостей, которые эксплуатировались в 2023 году. Интересные факты:
Проанализировано 92 уязвимости: из них 61 обнаружена в продуктах и платформах для конечных пользователей. Остальные — в корпоративном софте. Интерес злоумышленников к пользовательским данным по-прежнему стабилен.
Атакующие смещают фокус к компрометации сторонних компонент и библиотек. Сохраняется тренд атак на цепочку поставок.
Снижается доля 0day, использованных для атак с целью финансовой выгоды. Этот пункт можно объяснить тем, что использование дорогих средств эксплуатации для подобных атак экономически нецелесообразно. Для злодея есть более дешёвые альтернативы, которые ведут к такому же результату.
Исследовательское подразделение Fortinet опубликовало отчёт об угрозах второго полугодия 2023. Интересное:
Атаки начинаются в среднем через 4,76 дня после публикации новых эксплойтов к известным уязвимостям.
Некоторые обнаруженные уязвимости остаются неисправленными более 15 лет.
Пока на этом всё. Если подборка была полезной и интересной, ставьте лайки, и я продолжу делать такие обзоры регулярно.
