Приветствуем дорогих читателей! Продолжаем рубрику посвящённую разбору различных инструментов, атак и уязвимостей на беспроводные технологии. Данную статью мы посвящаем уязвимости в Bluetooth CVE-2023-45866, которая была нами затронута в одной из предыдущих статей. Рассмотрим некоторые инструменты которые успели создать под эксплуатацию данной уязвимости.

Дисклеймер: Все данные, предоставленные в статье, взяты из открытых источников. Не призывают к действию и предоставлены только для ознакомления и изучения механизмов используемых технологий.

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

Что такое определение области разведки?

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

Начало:

Мои методы разведки, как правило, разделены по категориям, поэтому я создал несколько директорий на своей локальной машине, выполнив:

mkdir -p gcash.com ~/recon/targets/gcash.com/subdomains/

mkdir -p gcash.com ~/recon/targets/gcash.com/endpoints/

mkdir -p gcash.com ~/recon/targets/gcash.com/aws/

mkdir -p gcash.com ~/recon/targets/gcash.com/dns/

Процесс разведки

- Перечисление поддоменов

- Сбор информации (сеть, DNS, технологии, порты)

- Автоматическое тестирование

Перечисление поддоменов

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

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

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

В этом разборе я покажу вам, как ошибка в конфигурации CORS привела к полному захвату аккаунта (ATO) и обходу двухфакторной аутентификации. Без лишних слов, перейдем к истории.

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

Методология

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

Цель предлагает различные тарифные планы, от бесплатных услуг до корпоративных решений. Я выбрал версию "Pro" и активировал бесплатный пробный период.  

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

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

Однако мне хотелось получить что-то взамен за свое время, ведь его у меня не так много. После того как я увидел, как несколько багхантеров делятся своими благодарственными письмами от NASA в X, я поставил себе новую цель...

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

В этой статье мы рассмотрим несколько способов выявления уязвимостей в целях на WordPress. Поехали!

Что такое WordPress

WordPress — это мощная система управления контентом (CMS), которую можно настроить с помощью обширного рынка плагинов, насчитывающего более 70 000 плагинов. WordPress можно превратить в интернет-магазин, лендинг для бизнеса или просто использовать как платформу для блогов.

Сегодня в интернете существует более 500 миллионов сайтов на WordPress, что составляет более 30% всех сайтов. Многие из них не получают должного внимания относительно безопасности, отчасти из-за нехватки знаний о распространенных уязвимостях, которые часто встречаются в целях на WordPress.

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

Нет контента? Не проблема — 1 Баг

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

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

Точка входа

Система позволяла пользователям загружать файлы для резервного копирования своих форм — обычная функция для такой платформы. Вы загружаете файл, он связывается с референсным номером (refNo) (например, R2326400539 для пользователя, которого мы назовем Джон), и позже мы можем просмотреть его на отдельной странице:

https://[redacted].com/xxx.asp?refNo=R2326400539

На первый взгляд ничего особенного. Но когда я заглянул в запрос на загрузку, то заметил параметр под названием fileUidList — строку, определяющую метаданные файла. Любопытство взяло верх: что если я изменю ее?

Я создал запрос, внедрил XSS-пейлоад в fileUidList и связал его с действительным референсным номером, например, R2326400540 в параметре njfbRefNo. Сервер без колебаний  принял мою изменённую загрузку.

Поджигаем фитиль

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

Находка: API с секретом

Все началось с веб-сайта, на котором хранятся пользовательские полисы — думайте о нем как о цифровом сейфе для страховых планов. Во время исследования я обнаружил обращение к API: /api/claims/encrypt?text=EUSP2386411060 с моим страховым полисом (EUSP2386411060). Ответом было зашифрованное значение идентификатора моего полиса, знание которого дает доступ к моему полису. Короче говоря, если ваш страховой полис EUSP2386411061, я могу зашифровать его и получить доступ к вашим данным, поскольку зашифрованное значение используется для доступа к PDF-файлу, содержащему информацию о вашем полисе.

Около года назад Apple произвела фурор в баг-баунти сообществе, привлекая внимание  различными эксплойтами и честной таблицей наград. Я взялся за дело и обнаружил критические проблемы связанные с Request Smuggling, которые затрагивали ключевые веб-приложения в инфраструктуре Apple.

Я выявил проблемы на серверах под следующими доменами:

Введение

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

Дисклеймер: Все данные предоставленные в статье, взяты из открытых источников.

Самая простая, но в то же время наиболее значимая ошибка, которую я нашёл:

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

Обнаружение

После входа в систему с правильными данными система отправляет пользователю одноразовый пароль (OTP) из 3 цифр для прохождения двухфакторной аутентификации. Пользователю необходимо было ввести правильный OTP в POST-запросе, чтобы продолжить работу.

После анализа структуры POST-запроса я обнаружил интересный параметр, который я назову RAREPARA (не настоящее название). Этот параметр отвечал за ограничение частоты запросов.

Это пример структуры запроса, но он не является реальным.

Эта статья о том, как я обнаружил уязвимость состояния гонки, которая позволила мне отключить 2FA любой учетной записи HackerOne. Я не знаю, как долго там присутствовала эта уязвимость, пока я ее не заметил и не сообщил их команде.

Вот ограниченное раскрытие информации.

Важно сначала изучить то, как работает 2FA на Hackerone. Если вы включили 2FA в своей учетной записи Hackerone, процесс аутентификации выглядит следующим образом:

Email + Password => ✅ => 2FA code => ✅ => Logged In.

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

Как отключить 2FA?

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

Давайте начнем с определения, что такое iDRAC? Воспользуемся подсказкой, сгенерированной искусственным интеллектом: «Интегрированный контроллер удаленного доступа Dell (iDRAC) — это инструмент, который позволяет ИТ-администраторам удаленно или локально управлять, контролировать и обновлять серверы Dell PowerEdge. iDRAC — это контроллер управления основной платой, встроенный в серверы Dell и включающий в себя как аппаратное, так и программное обеспечение». По сути, с его помощью, у вас есть возможность управлять своей виртуальной машиной!

Как правило, эти интерфейсы защищены логином и паролем, но при пентестах бывают случаи, когда обнаруживается, что используются учетные данные по умолчанию, либо имеются уязвимые к раскрытию хэша паролей IPMI v2.0. Итак, допустим, вы нашли учетные данные по умолчанию, которыми обычно являются root:calvin, или, скажем, вы взломали хеш полученный через уязвимость в IPMI. Что дальше? Для справки, как только вы успешно войдете в iDRAC, вы увидите следующее:

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

Торчащий API токен — это как пропуск для злоумышленников. Они могут использовать его для получения несанкционированного доступа. Если API токен предоставляет доступ к какому-либо сервису, например AWS или GitHub, злоумышленники могут воспользоваться им, что приведет к финансовым потерям компании, утрате репутации и доверия клиентов.

Если токен используется для доступа к какой-либо базе данных, то это большая проблема для компании.

Теперь давайте начнем с некоторых методов поиска открытых API токенов:

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

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

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

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

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

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

Для специалистов в области offensive security обнаружение уязвимостей удалённого выполнения кода (RCE) является настоящей жемчужиной как для black-box проектов, так и для white-box. Такие уязвимости могут проявляться по-разному, но также существуют общие подходы для их обнаружения.

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

За время моего пути в баг-баунти я сталкивался с различными интересными уязвимостями, но эта превзошла их все — уязвимость удаленного выполнения кода (RCE) в API-эндпоинте на языке R. Проэксплуатировав ее, мне удалось получить доступ к важным системным файлам и даже установить reverse shell на сервере. Эта статья написана для облегчения понимания процесса.

Приветствуем дорогих читателей! Мы продолжаем рубрику статей “Без про-v-ода” посвящённую беспроводным технологиям, атакам на них и методами защиты. В этой статье мы рассмотрим различные инструменты для MITM-атак и проверим актуальность некоторых на сегодняшний день, и на основе этой проверки найдём лучший.

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

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

Каждый день ветерана на протяжении почти десяти лет мой друг Билл Стивенс пытался найти и восстановить связь со своим армейским товарищем, с которым он вместе сражался более 20 лет назад. В течение нескольких лет Билл публиковал свои посты в Facebook, сопровождая их фотографиями из прошлого, в надежде, что каким-то образом его пост станет популярным и весть дойдет до его давно потерянного друга… но этого так и не произошло.