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

Охота за багами – это смесь как технических навыков, так и упорства с любопытством. Иногда самые простые баги остаются незамеченными из-за простых предположений. Эта история не о каком-то революционном эксплойте; она о терпении и о том, почему всегда стоит доводить дело до конца.

Цель: Простой вход с использованием OTP

Цель, которую я тестировал — назовем её redacted.com, — была хорошо проработана и прошла множество проверок. Вот как работало приложение:

• Пользователи входили в систему, используя адрес электронной почты.
• На их почту отправлялся одноразовый 6-значный код (OTP).
• Этот код вводился для доступа к аккаунту — никаких паролей.

Механизм был достаточно простым, что делало его идеальным для тестирования уязвимостей OTP, связанных с перебором.

Сегодня я покажу, как модифицировать powershell shellcode runner для загрузки и выполнения нагрузки в обход Windows Defender.

Я буду использовать shellcode runner, который применял ранее.

Для демонстрации я использую виртуальную машину Windows с временно отключённым Defender. Я скопирую код и создам на его основе новый файл, используя PowerShell ISE.

Содержание

- Что такое уязвимости загрузки файлов?
- Выявление уязвимостей при загрузке файлов
- Эксплуатация простых уязвимостей загрузки файлов
- Продвинутая эксплуатация уязвимостей при загрузке файлов
- Заключение

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

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

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

Начало атаки

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

Но давайте попробуем что-то на странице авторизации...

Если вы знакомы с концепцией IDOR (Insecure Direct Object Reference), то знаете, что эта уязвимость может быть где угодно: в URL, теле запроса, запросах GET или POST, а также в cookie.

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