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

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

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

Мы наблюдали споры о том, способен ли ИИ автономно искать уязвимости. Затем разбирались, в каких именно этапах поиска багов исследователь может повысить свою эффективность с помощью ИИ.

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

* eyeballvul - методика оценки способностей LLM искать уязвимости в широком контексте (например, в целом репозитории кода). Автор взял более 5000 репозиториев, в которых содержится более 24000 уязвимостей, и на этой базе предложил методику оценки. База обновляется еженедельно.

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

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

Платформа разработки - зачем?

В 2023 году аналитики Gartner разогнали идею Platform Engineering, и уже в 2024 крупные компании с мульти-продуктовым портфелем начали трансформировать свои команды разработки в «платформу». Чуть позже к кому-то прийдет идея сделать security-платформу из специалистов, которые обеспечивают безопасность процессов разработки.

Зачем создавать группы, которые унифицируют процессы, называть их «Platform Engineering Team» и в итоге получать команду разработки, которая один в один похожа на команду конкурента? Есть ли бизнес-причины для повторения одних и тех же технологических решений?

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

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

Если в стратегии развития ИТ-инфраструктуры бизнеса нет ни одного из перечисленных сценариев, то не нужно изобретать велосипед и создавать команду Platform Engineering, которая не создаст ни одной инновации.

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

Исследователи Unit42 собрали актуальные техники побега из контейнеров и подготовили обзор. Инженеры DevOps и аналитики Blue Team забирают этот материал в свою коллекцию для защиты облачных сред.

В материале рассмотрены системы контейнеризации на основе изоляции пользовательского пространства (user-space), и техники не применимы для систем, которые работают на основе виртуализации. Почти все рассмотренные атаки используют два базовых механизма Linux: capabilities и namespaces.

Атрибут capabilities определяет набор действий, которые процесс может выполнить в системе. Атрибут namespaces определяет набор ресурсов, с которыми может работать процесс. Другими словами, capabilities определяет что процесс может сделать в контейнере, а namespaces - где процесс может выполнять эти действия.

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

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

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

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

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

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

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

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

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

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

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

Когда одна ветка репозитория позволяет получить ценные данные из другой удаленной или приватной ветки, мы имеем дело с новым вектором атаки: Cross Fork Object Reference (CFOR).

По аналогии с уязвимостями Insecure Direct Object Reference (небезопасные прямые ссылки на объект), атакующий использует хэши коммитов, чтобы напрямую получить доступ к данным в этих коммитах. Даже если коммит содержится в удаленном или приватном репозитории. Атакующему остается только узнать хэш коммита. Как?

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

github.com/<user>/<repo>/commit/
07f01e8337c1073d2c45bb12d688170fcd44c637

Можно использовать короткую ссылку:

github.com/<user>/<repo>/commit/07f01e

где 07f01e - короткий хэш. Его можно подобрать через пользовательский интерфейс GitHub. А уже после получения доступа к коммитам, атакующий приступает к поиску секретов.

GitHub в курсе данной проблемы и не планирует исправление, потому что это не баг, а фича.