Или все же LLM не способен искать уязвимости?

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

* авторы разработали фреймворк для автоматизированной оценки способностей LLM в задачах поиска и описания уязвимостей. В основе фреймворка находятся 228 сценариев уязвимого кода на С и Python.
* Все языковые модели показали недетерминированные ответы. То есть при повторном запуске на одном и том же участке кода давали разные результаты.
* Даже если модели находили уязвимость, то давали ее некорректное описание.
* Наблюдались проблемы с устойчивостью моделей: незначительные дополнения кода вводили LLM в заблуждение.

Делаем вывод: LLM пока еще не способны автономно искать и эксплуатировать уязвимости. При этом, мой опыт исследований подсказывает, что из LLM можно сделать отличного ассистента, который и корпус для фаззинга соберет, и багу потриажит.

Уязвимости на GitHub: в библиотеке Ruby, которую скачали 250 000 раз, модулях для электронных замков и популярных играх

В предыдущей статье мы проверили публичные репозитории GitHub на уязвимость к захвату (RepoJacking). Теперь копнули глубже и поискали среди них популярные библиотеки. Мы отобрали репозитории с кодом, который был опубликован как библиотека в пакетном менеджере. Проверили эти репозитории на уязвимость и выбрали самые популярные. Вот, что нашли:

* библиотека Ruby, последнюю версию которой скачали более 250 000 раз и другие Ruby-модули, опубликованные на RubyGems;
* Python-модуль управления электронным дверным замком известного производителя;
* модули для игр Counter-Strike и Minecraft;
* модуль расширения игрового движка Godot Engine;
* образы контейнеров, опубликованные на Docker Hub.

Рекомендации для разработчика написали. Результаты исследования опубликовали.

Как атакующие используют ИИ: подборка сценариев

Встретил репозиторий с набором сценариев использования ИИ в реальных атаках. Автор этой коллекции сопоставил техники матрицы MITRE ATT&CK с известными случаями применения генеративных моделей в реальных атаках.

Примеры интересных кейсов:

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

Эти же сценарии может позаимствовать Red Team для своих задач.

RPG-игра про кибербезопасность: выбор персонажа

Кто играл в Diablo или Baldur’s Gate, тот помнит окно выбора персонажа. Воин, маг, некромант, лучник, паладин - каждый из них отличается набором скиллов и начальных характеристик.

В кибербезопасности, да и в разработке вообще, также нужно выбрать свою ролевую модель. В прошлую субботу в Лужниках я рассказал про исследователя угроз - некроманта из мира ИТ.

Много пересекающихся фактов:
1. к нему обращаются за помощью, когда непонятно, что вообще происходит и где аномалия;
2. ему часто приходится воспроизводить угрозу, чтобы понять, как она работает и как с ней бороться;
3. он никогда не делает рутинную работу сам и запускает автоматизацию.

Выбор персонажа в начале не так важен. Самое главное - не становиться NPC.

Да, на этом фото есть немного магии. И нет, это изображение не сгенерировал ИИ.

Фундамент в data science: экспресс-погружение в алгоритмы ML

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

Открытые курсы по машинному обучению:
* Машинное обучение для решения прикладных задач от МГУ
* Машинное обучение от ШАД (осторожно, много математики)

Интерактивное объяснение работы алгоритмов:
* MLU-Explain
* Visual introduction to machine learning от r2d3
* Machine Learning Playground

Конспекты:
* The Illustrated Machine Learning
* Yandex ML Handbook
* Machine Learning Handbook от PerceptiLabs

Книги:
* "Грокаем машинное обучение", Серрано Луис
* "Машинное обучение без лишних слов" / "Инженерия машинного обучения", Бурков Андрей
* "Введение в статистическое обучение с примерами на Python", Джеймс Г., Уиттон Д., Хасти Т., Тибширани Р.

Не забывай конспектировать инсайты.

Обзор перспективных security-исследований

Разбор интересных исследований первого квартала 2024. На этот раз в формате #Дайджест:

* Secure by Design: принципы построения защищённых систем от Google

* Поиск секретов в скрытых git-коммитах

* Метод поиска n-day-уязвимостей в бинарном коде

* Стратегия выявления угроз: на чём сосредоточить усилия при разработке методов обнаружения?

* Распространение вредоносного кода через комментарии GitHub

* Повышение уровня наблюдаемости процессов DevSecOps

* Инсайты из аналитических отчётов

* Редкая фотография презентации нашего исследования 😉

@makrushin

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

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

GuardDog - инструмент, который при помощи Semgrep сканирует пакеты PyPI и NPM на предмет вредоносного кода. База эвристик делится на два блока: эвристики исходного кода и эвристики метаданных пакета. С его помощью исследовательское подразделение DataDog недавно обнаружило набор вредоносных PyPI-пакетов, которые атакуют специфичные рабочие станции под управлением MacOS.

Утилиту можно брать на вооружение и использовать для непрерывного сканирования локального репозитория пакетов.

Выявление фишинговых ресурсов с помощью нечеткого хэширования

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

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

Эффективность метода доказали на примере известных фиш-китов и страниц, которые замечены в популярных таргетированных атаках. Исследователи вычислили нечеткий хэш (TLSH) для DOM-дерева полученной веб-страницы, сравнили ее с хэшем ранее замеченной фишинговой страницы и таким образом обнаружили угрозу.

Если думаешь, как еще улучшить свой метод поиска угроз и аномалий, то не спеши прикручивать ИИ. С многими задачами по-прежнему хорошо работают алгоритмы “до эры ML”.

Adversary-in-the-Middle: эволюция фишинга

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

Этот же сценарий является типичным для многих целевых атак. Где-то еще работает, но теряет свою эффективность по мере внедрения программ повышения осведомленности, технологий фильтрации почтового контента и MFA.

MFA не дает атакующему воспользоваться украденной учеткой, потому что для доступа к данным требуется второй фактор, который остается у сотрудника. Для обхода средств MFA атакующий сместил фокус от кражи пароля на кражу пользовательской сессии. Так появились атаки Adversary-it-the-Middle (AitM).

Техники AitM основаны на использовании прокси-инструментов между жертвой и порталом для логина (например, SSO-порталом: Okta, Google Workspace и т.д.). То есть пользователь видит реальную страницу для логина, но где-то между пользователем и этой страницей атакующий получает под свой контроль пользовательскую сессию. И даже не нужно красть пароль от учетной записи, потому что пользовательские сессии могут оставаться активными больше месяца.

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

Чей-то браузер посередине: инструменты BitM-фишинга

Для проведения AitM-фишинга существуют две основные техники: Browser-in-the-Middle (BitM) и Reverse Web Proxy.

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

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

1. Кастомизированный браузер с минимальным GUI, чтобы не отвлекать пользователя какими-либо элементами интерфейса. Для этого часто используется Chromium, развернутый на базе дистрибутива с Fluxbox.
2. VNC-сервер, который обеспечивает доступ к браузеру атакующего и устанавливается в его инфре.
3. VNC-клиент. Например, noVNC. Работает в контексте браузера жертвы и подключается к VNC-серверу. Подключение устанавливается с помощью набора JS-скриптов и HRML5-кода и не требует установки дополнительных модулей.

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

Набор утилит, которые упростят проведение BitM-атак для Red Team:

* EvilnoVNC - с использованием Docker позволяет быстро развернуть все компоненты платформы для проведения BitM-атак.
* Cuddlephish - аналогичная платформа, но на базе технологии WebRTC.

Blue Team, готовь детекты.

Обход многофакторной аутентификации с помощью Reverse Web Proxy

Ограничения BitM-атак не позволяют использовать эту технику для массового фишинга. Так как контент отображается в браузере через протоколы удаленного доступа, то пользователю достаточно изменить размер окна браузера, чтобы заметить что-то подозрительное в отображении страницы. А еще в корпоративной сети у Blue Team могут быть детекты скриптов noVNC. По этим причинам BitM хорошо подходит для точечных атак, но не годится для широкого применения.

Техника Reverse Web Proxy основана на использовании инструментов, которые перенаправляют HTTP-запросы от браузера жертвы к ресурсу через прокси-сервер атакующего.

Инструменты для реализации с похожей функциональностью:

* Evilginx - пожалуй, самый популярный фреймворк, написанный на Go. Поднимает свой HTTP и DNS сервер для перехвата учетных записей и пользовательских сессий для обхода MFA.
* Modlishka - аналогичный инструмент, разработчик которого описывает свое решение, как «point-and-click», то есть его просто настроить и автоматизировать.
* Muraena
* CredSniper

Для защиты от этой техники разработчик веб-приложения MFA должен использовать дополнительные меры. Например, добавить в свое приложение JS-код для проверки легитимности домена, который загружает страницу.

Ловушка для фишинга: JS и CSS-канарейки

Основной сценарий фишинг-атак с использованием reverse proxy выглядит примерно так:

1. Атакующий регистрирует доменное имя, похожее на доменное имя целевого веб-портала, который жертва использует для логина.
2. Размещает на фишинговом домене прокси и перенаправляет со своего домена все запросы от браузера пользователя к целевому ресурсу и обратно.
3. Перехватывает весь процесс аутентификации и извлекает из HTTP-запросов ценные данные: пароли и сессионные куки.
4. Использует перехваченные сессионные куки для обхода процесса мультифакторной аутентификации.

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

Использование reverse proxy между браузером пользователя и порталом MFA можно обнаружить с помощью JS-скрипта, встроенного в веб-страницу. Этот скрипт может выполнять роль канарейки и сигнализировать владельцу MFA-приложения и аналитику Blue Team о попытке фишинга:

1. Жертва открывает фишинговую ссылку, и в ее браузере срабатывает JS-скрипт.
2. Скрипт определяет контекст, в котором исполняется (например, URL), и сопоставляет актуальное доменное имя с ожидаемым доменным именем.
3. В случае несовпадения контекста скрипт отправляет сигнал на сервер Blue Team.

Делаем похожую канарейку на CSS:
1. Для невидимого глазу изображения (пиксель) создаем атрибут url(), который делает обращение к серверу Blue Team.
2. В HTTP-заголовке обращения передается значение Referer.
3. В случае несовпадения значения Referer с заданным отправляем сигнал аналитику Blue Team.

Добавляем в белый список URL различные CDN и ждем сигналы.

Двухфакторная аутентификация: низкие темпы внедрения и ограничения

Завершаем серию публикаций про кражу учетных записей экспертным комментарием для Forbes о темпах внедрения MFA и ограничениях этой технологии.

У администраторов доменов всего 9% крупнейших компаний России действует двухфакторная аутентификация, и 68% из них в качестве второго фактора используют самый простой — SMS. Это тревожная статистика: в условиях растущих киберугроз такая беспечность чревата не только взломом или «угоном» домена, но и захватом злоумышленниками ключевой IT-инфраструктуры, что повлечет за собой немалые расходы для устранения последствий.

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

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

Я хочу сыграть с тобой в одну игру 😎

Обновлен файл со списком самых популярных паролей

Файл rockyou2024.txt содержит 9,94 миллиарда уникальных паролей, многие из которых были замечены в крупных утечках. Для кого пригодится этот файл:

🔴 Red Team, пентестеры и специалисты по анализу защищенности смогут освежить листы для подбора паролей. Как показывает практика проведения пентестов, на широком скоупе иногда справлялся даже старенький файл rockyou.txt, который доступен в Kali Linux.

🔵 Blue Team, аналитики SOC и ИБ-инженеры смогут проверить парольные политики на устойчивость к брутфорсу и внести парольные комбинации в правила для выявления атак.

🟢 Обычные пользователи смогут поискать свои пароли в списке и найти еще один повод обновить секреты.

Скачать файл (45.6 Гб).

Оценка возможностей LLM в наступательной безопасности

Мы встречали исследования, в которых утверждалось, что LLM может автономно эксплуатировать известные уязвимости. Затем изучали опровержения этих исследований. В итоге пришли к выводу, что LLM может быть хорошим ассистентом при поиске багов, а команда Google Project Zero проверила эту гипотезу.

Исследователи взяли опубликованную ранее методику оценки возможностей LLM для поиска и эксплуатации уязвимостей, доработали ее и улучшили в 20 раз показатетели LLM в тестах. Ключевые принципы, которые авторы применили в своих доработках:

* пространство для рассуждений: дать модели возможность быть более «многословной» и через подробные рассуждения приходить к более точным результатам;
* интерактивная среда: дать модели возможность взаимодействовать с тестовым окружением и корректировать свои ошибки;
* инструменты: предоставить модели доступ к инструментам исследования (отладчик, интерпретатор кода Python), чтобы у нее была возможность получать детальную информацию о состоянии программы и влиять на это состояние;
* проверка результата: обеспечить автоматически воспроизводимый результат;
* стратегия отбора: дать модели возможность проверять несколько гипотез в рамках разных траекторий исследования.

В итоге LLM стал более эффективным инструментом для помощи в процессе поиска уязвимостей. Но до состояния автономной системы пока еще далеко.

Учебное пособие для аналитика киберугроз

Встретил интересный проект Pivot Atlas, который содержит справочные материалы о том, как можно использовать данные об угрозах для их анализа. Цель проекта: составить взаимосвязи и сценарии использования всех типов артефактов (IP-адреса, домены, TLS-сертификаты, сэмплы и прочее), которые помогут аналитику в расследовании инцидентов.

Пригодится в качестве справочника как для начинающих аналитиков SOC, так и для опытных исследователей угроз.

Набор сценариев защиты для облачной инфраструктуры

Коллекция техник для защиты облаков. Более 50 сценариев, которые Blue Team и DevSecOps могут брать в работу. К тому же, эти сценарии соответствуют техникам матрицы Mitre D3FEND, а значит, можно количественно оценить способности защиты для своего облака.

Захват артефактов: массовая компрометация зависимостей

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

* Уязвимость в отладчике WinDbg и ее использование для атак на разработчика

* Методика поиска уязвимых Github-репозиториев

* Результаты анализа популярных библиотек, доступных для захвата

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

#Дайджест @makrushin

ИИ ассистент для security архитектора: определение скопа для анализа защищенности

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

Модель анализирует каждый Pull Request, дополняет его соответствующей информацией из Jira и делает выводы для команды наступательной безопасности о том, где и как сфокусировать усилия в ходе ручного анализа защищенности данного релиза. С учетом частоты релизов и сотнями Pull Request в каждом, этот сценарий использования экономит усилия команды на определение приоритетов в ходе ручных проверок.

Забираем для внедрения в свой процесс безопасной разработки.