Вновь поприветствую всех заинтересованных телеслушателей и радиозрителей, что кликнули на мою статейку.
В ходе недавних своих размышлений мне четко и ясно захотелось выпустить своеобразную "многологию" из статей на разные темы веб-пентеста и пентеста Active Directory, которая бы содержала все основное и нужное для заинтересованных лиц. Без лишних деталей и ненужных словес, плетенных по древу. Лишь то, что, по моему опыту, действительно способно приводить к компрометации, а значит, и к профиту для пентестера N, который очень хочет, чтобы некая организация с ним поделилась.
Подробности я освещу в комментарии в этой теме, в первом комментарии после этой статьи.
P.S. - я не то, чтобы от избытка ума страдаю, потому, в случае неточностей или каких-то своих замечаний, в случае желания обсудить то, что я не успел осветить в статье, попрошу Вас, уважаемые читатели, сразу писать свои мысли в комментарии. Я всем постараюсь по мере сил и времени ответить. Больше таких вступлений у нас не будет. Также, я решил оставить тот же публицистический стиль, который был применен в возможно знакомой вам статье о RCE в реакте, но структуры статей я решил видоизменить, сделать более удобоваримыми и информативными. Потому, у нас будет некое содержание. Перейдем сразу к делу, и приятного вам прочтения.
Содержание:
1) Введение и матчасть.
2) Образцовые ситуации: Рассмотрим примеры уязвимости и ее импакта на PortSwigger.
3) Актуальные практики нахождения и эксплуатации уязвимости в дикой природе: инструментарий, методология.
4) Источники, интересные ресурсы.
Введение и матчасть
Современные тенденции разработки веб-приложений характеризуются поражающим ростом сложности бизнес-логики этих самых приложений, как и общей сложности видимой нами инфраструктуры.
Личные кабинеты, сбор всей возможной информации маркетологами, чтобы кормить вас новой таргетированной порцией в эдсах, сложнеющие год от году в своей структуре платежки(обработки заказов, остановки заказов, изменения в них на лету), и бедные разработчики, что поднимают все это действо, день ото дню отращивающее все новые и новые API-роуты.
И тут в игру вступает как раз таки человеческий фактор: "забыл про эндпоинт", "забыл поправить сурсы", "новый и не оттестированный по максимуму функционал".
В совокупности ровно такие ситуации и подпадают под отдельную классификацию девиантного поведения веб-прилки - в общий класс нарушений, названных Broken Access Control: когда веб-приложение дуркует очень своеобразным образом, неудовлетворительно проверяя возможность доступа у конкретного юзера к чужой информации/несанкционированным для него функциям. Пользак просто получает доступ к тому, к чему ему не можно.
Как раз такие "доступы" очень разные в зависимости от ситуации: когда мы можем втупую менять чужие аватарки, когда - вообще получать доступ к админовым и тестовым функциям бизнес-логики.
В зависимости от места, куда мы получили доступ в ходе эксплуатации, и рознится опасность уязвимости. Понятное дело, что просто смене аватарок у профилей других, не имеющих к тебе отношения, юзеров не присвоят "критикал импакт"; потенциальному черненькому душой парню тоже нет особого смысла с этим париться в каких-либо нуждах кроме дефейса и прочей галиматьи.
Но ситуация способна радикально измениться, когда в один момент мы получаем доступ к чему-то админскому, к логике создания и изменения прав аккаунтов, к логике помощи пользователям вроде "Забыл пароль?".
Не менее интересно бывает и изучать ту часть приложения, которая отвечает за платежные системы и заказы: такие штуки особенно опасны.
Не только потенциальным доступом к чужой инфе, но и, в редких случаях, созданием левых платежных заявок от имени других юзеров, их изменением или удалением.
Изучим эту совокупную группу разных уязвимостей, воспользовавшись ресурсом OWASP.
Но для начала, стоит поговорить об актуальности того, что мы сейчас рассматриваем.
Перейдем на OWASP Top-10:
Статистика умеет удивить, не правда ли?
Согласно тому, что мы видим в нынешней "горячей десятке", уязвимости нарушенного контроля уже на протяжении 4 лет держут свое заслуженное главенство в этой десятке.
Как и говорилось в начале, отдельным стимулом к тому выступает тенденция на всеобщее усложнение структуры таких приложений. Но однако, стоит также заметить, что начиная с эпохи "AI-бума" постепенно втерлась в обыденную жизнь разработчика и всевозможная автоматизация, зиждящаяся на нейронках всех применений. Проблемы, связанные как с привычкой "писать нейронкой", так и с привычкой использовать всевозможные автоматизационные фреймворки на их основе, включают в себя как раз таки эти "маленькие, но удаленькие" моменты, входящие в класс Broken Access Control. Этот огромный и "прожорливый" класс также забрал в себя прочие, ранее бывшие "отдельными", уязвы. Например, IDOR в 2017-ом, CSRF & SSRF ближе к нашим дням.
Рассмотрим стату Common Weakness Enumeration, связанную с этой группой.
Обширно, ничего не скажешь.. много самых разных возможных фейлов: тут тебе и опен-редиректы(возможность редиректить в стороны, что по дефолту прилке не положены, что открывает дорогу к грамотному чейну на фишинг и так далее), и приколы с кузницей запросов как на стороне клиентов(CSRF, принужденные выманить заветные запросы из браузера жертвы с нужными сведениями внутри), так и на стороне сервера(SSRF, когда мы можем отправлять запросы уже со стороны сервера произвольно, манипулируя изъянами его логики).
Наиболее "опасными" и простыми в реализации(без кучи шагов в чейне эксплуатации) вариантами будут нарушенные проверки авторизации, IDOR и SSRF: эти три CWE вполне себе желанны у черных душой парней и по наши дни. Отдельную роль в "сложных атаках" играют и Path Traversal: при правильном применении возможно выстроить далеко не слабую цепочку. Но сегодня, прежде чем подведем вывод о группе Broken Access Control, мы сфокусируем наше внимание именно на IDOR.
Из рассмотренных нами сведений становится ясно, что Broken Access Control - это группа типичных уязвимых паттернов, относящаяся к изъянам куда чаще не применимых технологий, а логики, выстроенной в приложении. Туда могут относиться разные уязвимости, но подавляющее большинство типичных уязвимых паттернов(инше говоря - антипаттернов) относятся к неправильной авторизации и неудовлетворительному качеству ее проверки.
Группа перешла в топ-1, который держит по сей день, уже в отчете OWASP Top-10 в 2021 году:
Рассмотрим отдельный паттерн неправильного и опасного поведения, в народе прозванный "IDOR". IDOR - Insecure Direct Object Reference - неправильное поведение приложения, характеризующееся возможностью у пользака обращаться к объектам, используя определенный идентификатор. Говоря иначе, приложение не проверяет авторизацию юзера Вани, не смотрит, кто он вообще такой и имеет ли Ваня доступ к ресурсу Пети, например, к информации о его профиле. Зато оно видит, допустим, уникальный id, присвоенный именно анкете юзера Пети, и сразу же дает ему туда доступ. Так можно описать классический случай IDOR, однако, сам по себе insecure direct object reference куда сложнее как паттерн поведения и подпадает сразу под несколько CWE, присвоенных группе Broken Access Control.
Короче говоря, че мы имеем на данный момент:
1) Имеешь авторизацию Вани на веб-аппке(допустим, кука), знаешь user_id Пети, и при этом швыряешь значит реквест в эндпоинт /api/v3/users с user_id=petya. Получаешь почему-то не Unauthorized и не инфу о своем профиле, а данные Пети. Его имейл, его сведения о профиле, все, Петю сдеанонили по сайтику. И это - первый, классический и самый узнаваемый случай: CWE-639, он же по-умному и по-англичански обзываемый секьюрити ресерчерами как Authorization Bypass Through User-Controlled Key. Ключиком нам выступит этот айдишник. Однако, нередки и случаи, когда сюда подпадает и CWE-285 - нарушается проверка, действительно ли сей объект принадлежит конкретному юзеру на сессии. Чаще всего в "иконичном айдоре" пересекаются как раз эти два викнесс-паттерна.
2) Можешь вообще не авторизуясь за Ваню играться с данными Пети? Критичность вули уже очень сильно возрастает(хотя тут я с ними и не согласен, создать акк под силу каждому пентестеру, и спарсят данные и там, и тут). Но тогда CWE-639 отступает, потому что из названия понятно, мы же должны байпасснуть авторизацию. Ну а у нас все перетекает в класс unauth-вуль.
Но в сухом итоге все эти паттерны будут узнаваться ресерчерами именно как IDOR.
Что же получается? Когда у нас есть какой-то объект, будь то файл или запись, мы зовем этот объект "объектом данных". Таким образом, можно сделать следующий вывод: IDOR - это уязвимый паттерн работы веб-приложения, подпадающий под CWE-639, CWE-285, либо под оба этих common-weakness паттерна, характеризуемый существованием объекта данных. В случае, если авторизация при доступе к ресурсу происходит ненадлежащим образом, паттерн CWE-285 становится доминирующим; в иных случаях(например, наличие определенного UUID и доступ к файлам только по нему, как в случае с CWE-639) в описании паттерна IDOR находят применение либо CWE-639, либо CWE-285 совместно с CWE-639. Когда мы каким-то образом можем получить доступ к этому объекту данных, минуя авторизацию или не нуждаясь в ней, это и будет считаться для нас IDOR; преимущественно IDOR в большинстве своих случаев ассоциирован именно с CWE-639. Посмотрим на картиночку, которая может показать это наглядно.
Тут все становится относительно понятно. Прямой доступ к чужим объектам без надлежащего контроля.
Уязвимость бесспорно коварна: получи доступ к информации о чужих профилях, и спарсишь весь сервис, просто перебирая юзерайдишники и прочие идентификаторы. Базу выгрузишь без SQLi и прочей магии, которую мы тоже позже в рамках этой серии статей рассмотрим. Получи доступ к логике чужих профилей и, допустим, корзин (как на всяких шоп-сайтах), и хоть подменяй адреса доставок, хоть вообще в нулину снимай все балансы пользаков. И именно этим она и интересна нам прежде всего.
Образцовые ситуации: Рассмотрим примеры уязвимости и ее импакта на PortSwigger.
Прежде чем перейти в кейсы из области "реального мира", а не "ой, братик, я опять застряла в стиралке", чем является большинство CTF на разных обучающих платформах, посмотрим на классические простейшие примеры этой уязвы. Поможет нам в этом не менее известная платформа для обучения, выпущенная нашими белыми коллегами из компании PortSwigger (берп, легенда, никогда не перейду на Caido полностью).
Идем в раздел веб-лаб под названием Authentication, смотрим на раздел Access Control Vulnerabilities. Здесь и будет то, что нам нужно: начинаем решать.
Лаба #1.
Заходим на первую лабу. Возьмем в качестве примера первую попавшуюся на глаза из раздела #access-control-vulnerabilities - user role can be modified in user profile, что нам и нужно. Уже по названию становится понятно, что внутри есть что-то на нашу сегодняшнюю тематику. Сразу включаем прокси Burp Suite: будем двигаться на пассивном краулинге, с нашими плутаниями по аппке нарастет и дерево в разделе Target.
Встречает нас обычный шоп из портсвиггеровых лабок:
Нам дают и дефолтные креды портсвиггера: сразу становится понятно, что в My account заглянуть все же стоит. В самом описании говорится про панельку на эндпоинте /admin, пробуем зайти в нее с дефолт кредов. Ожидаемо, нас не пускает. Логинимся в веб-панельку, посмотрим, есть ли нечто интересное внутри запроса.
Ненаход: в этот раз смотреть нам честно говоря не на что. Дефолтные перемсы "юзернейм" и "пассвуд", ничего интересного нет. Стоит посмотреть на внутрянку нашего юзерпрофиля, однако, виднеется только одна функция:
Окак, функция только одна. В целом, что нам терять? Терять нам нечего, клацаем. Введя наш имейл, разумеется. На веб-странице ничего интересного не произошло, может, нечто интересное есть в самом реквесте? Посмотрим.
Что ж, да, мы не разочарованы. Есть некий апи-ответ, джейсоновый, и есть как раз таки ключик roleid - некий идентификатор "роли" юзера на этом сервисе. В начале перед лабой говорится, что там надо поставить двойку, и будет пропуск в панельку. Ставим, смотрим.
Надо же, наход. Удаляем терпилу Карлоса к чертям.
Нереалистично? Да. Похоже на одно из лиц этой уязвимости? Да, х2. Мы знаем определенный объект - идентификатор нашей юзер-роли, и даже имея при этом свою обычную авторизацию, отправив этот идентификатор, получаем права. CWE-639.
Лаба #2.
Для большего понимания решим еще одну лабу, в этот раз с чутка другим видом того же поведения, что также воспринимается аналитиками как паттерн IDOR.
Дали нам дефолт креды Питера и опять тот же магазинчик.
Логинимся: тут судя по всему иначе никак. Смотрим на поведение веб-прилки при логине:
Опять порожняк, ничего толком нет, кроме классического Found, уведомляющего нас об успешной, вот же радость, авторизации. В этот раз видим мы в самой морде нашего личного кабинета апи-ключик, который на это поле с верифаем ну никак не влияет. Зато видим еще и нечто странное: новый GET-параметр, который висит сверху в урле и не дает покоя. id=wiener.
Подменим втупую на carlos, не выходя из браузера:
Выдаем наше решение, как видно, коробка уже все. Опять же, пример довольно нереалистичный, но право на жизнь определенное он все же имеет.
Эти коробки при всей своей вычурности способны научить главному навыку при поиске таких отклонений: смотреть на все подряд и кликать все подряд, авось что-то да и получится. Да и становится понятно, что импакт от таких вуль нельзя описать универсально для каждого кейса и он рознится от случая к случаю. То админка, то потенциальный ATO - Account Takeover, то и вовсе вуля становится помощником и одним из звеньев более "капитальной атаки", как, например, это работает с CTF на HackTheBox под названием Era - всем советую на досуге решить, кстати. Интересная, отчасти реалистичная машинка.
Рассмотрим более подробно логику поиска и эксплуатации в условиях реальных и подобающих.
Актуальные практики нахождения и эксплуатации уязвимости в дикой природе: инструментарий, методология
На примере решенных лабок стало понятно, что один из векторов поиска - просто шарахаться по веб-приложению в поисках потенциальных слабых мест, параллельно изучая все, на что может упасть взгляд. По-умному эта методика зовется "пассивный краулинг" - методика активной разведки, при которой мы ничего намеренно не краулим и не перебираем, как в случае условного фаззинга директорий, всем, однозначно, знакомого. Мы лишь "записываем" все реквесты и респонсы, пришедшие в результате "легитимного"(от рук самого пользователя) использования веб-приложения. В Burp это висит отдельной базовой возможностью, далеко не обязательно использовать Interceptor, чтобы перехватить какой-то из запросов - все те, что прошли через прокси бурпа, автоматически окажутся в истории.
Однако, стоит отметить общий набор мер, который может помочь в поиске подобного рода уязвимостей:
1) Просто пользуйтесь приложением, пристально все изучая. Особенно это касается опций в личных кабинетах, авторизации, регистрации, создания платежек - все те моменты, которые могут быть связаны с API-логикой.
2) Активный краулинг. Краулеры вроде katana и hakrawler могут очень помочь в поиске нужных роутов и эндпоинтов, а также неплохо справляются с "большими" объектами под тестирование, где этих "важных" эндпоинтов могут быть сотни.
3) Чтение сурсов. Это действительно важный источник сведений, который может много чего подсказать. Как минимум, необходимый набор GET/POST параметров для конкретного эндпоинта, чтобы понимать, как строить реквесты - далеко не все будет вам ясно из простого использования веб-аппа, где-то(например, админские или тестовые, "забытые" функции) вам быть не можно =)
Помимо понятных довольно мер, можно также выделить следующие "негласные правила": смотреть стоит прежде всего на эндпоинтах, либо принимающих какие-то уникальные идентификаторы(id, включая айди юзеров и так далее, все уникальные ключики), либо дающих доступ к какой-то функции на основе данных из запроса и авторизации(например, функции смены имейла на профиле юзера, где в формате POST следует отправить юзерайди и новый имейл). Допустим, что у вас есть путь .../api/v3/users/get-info. Если на нем существует какое-то аномальное поведение(например, выдача сведений при авторизационных хидерах, куки то или отдельный хидер, по id другого пользователя), стоит проверить также и остальные пути, включающие .../api/v3/users/... Вполне возможно, что нарушенные механизмы авторизации встретятся и у соседушек.
Порой встречаются инструменты документирования API, например, Swagger. Это тоже крайне полезная находка: Swagger может дать понимание, как использовать те или иные эндпоинты и как происходит информационный обмен с API-интерфейсом в веб-приложении.
Чтобы понять логику тестирования в случае, если ранее вы почему-то никогда не касались этой вули, возьму пример, недавно попавший в мою практику. Информационный ресурс достаточно вредоносного содержания, в комментариях к этой статье будут дальнейшие подробности. Уязвимости там могут быть достаточно "понятными" и "типовыми" для ознакомления с методологией "на живой цели". Описывать дальнейшую логику будем наглядно, производя полноценный "аудит" по уязвам этой группы.
Перейдем по ссылке и познакомимся с ресурсом.
Нас встречает вот такая мордашка, на которой происходят авторизация либо регистрация. Сделано довольно топорно, но в довольно прикольной неоновой теме, пусть нам это сейчас не сильно и важно. Первым делом стоит собрать ту информацию о нашей цели, которую мы можем собрать из открытых источников. Я сделал довольно просто и "на глаз", ведь наша сегодняшняя цель - рассмотреть только одну конкретную группу уязвимостей, а там главное копошиться именно в логике.
Перейдем к Wappalyzer и FOFA, чтобы понять, с чем имеем дело.
Стек незамысловатый, довольно даже обыденный, я бы сказал. У нас есть DDoS Guard, доступ обеспечивается как раз через его реверс-прокси, о чем нам радостно рапортует шодан. Однако, развертка здесь грамотностью не славится, и первый же запрос в FOFA выдает нам истинный IP-адрес сервера(Origin IP):
Адрес пингуется, дальше - больше: при проверке оказалось, что у нас есть прямой доступ(direct access) к веб-приложению по истинному адресу его сервера, о чем нам радостно рапортовал уже другой инструмент, httpx-toolkit:
Адрес для нас в данном случае - довольно ценная находка, и кратко объясню, почему именно. Теперь, если мы захотим пофаззить, мы будем делать это не через реверс-прокси DDoS Guard, что, очевидно, может принести некоторые затруднения и блокировки. Можно "не тихушничать" и делать куда более расточительные на веб-ресурсы конфиги фаззеров. Главное правило для нас сейчас - делать все так, чтобы ничего не упало, мы ведь - незаметная интервенция =)
В случае правил платформ для багхантеров все в целом почти такое же. Мы можем применять разные методики тестирования, но DoS/DDoS (даже нечаянно) во многих случаях непозволителен.
Увидев, что поле регистрации открыто, я сразу же включил девтулсы и подключил свой прокси, в этот раз Caido. Приступим к изучению и создадим учетку. Это поможет нам в нуждах тестирования.
Клацаем "зарегистрироваться", и получаем следующую картину:
Весьма интересно. Сразу видим API, по наитию и собственному опыту понимаю, что тестирование будет довольно приятным - хендлеры имеют довольно предсказуемые названия, без роскоши и фантазии). Куда неприятнее тот факт, что через куку какого-то черта передается IP-адрес клиента, посетившего ресурс, что уже само по себе сюр, но тут даже без малейших попыток "спрятать".
Сам эндпоинт auth выдавал 403(Forbidden), вероятно, закрыли его после первой попытки разведать, довольно успешной, но без подробного документирования). Что для нас в целом-то не проблема.
Увидев такой стек, как и увидев такие приятные API-роуты, первое, что пришло мне в голову, - попытаться запустить внутрь автоматизированного краулера. Соберем побольше информации о имеющихся веб-директориях, авось, увидим что-то интересное. Параллельно есть смысл постучать в gau и waybackurls - они тоже порой дают много полезностей, например, эндпоинты, в инструкции краулеров не попадающие, но имеющие в себе тем не менее много хорошего для нас материала. Таковыми нередко бывают тестовые эндпоинты, оставленные на проде случайно.
Gau показал себя не шибко полезным в этом конкретном кейсе, найдя кучу .svg-мусора и пару обфусцированных .js:
Куда большую пользу в этот раз нам принесла katana. Найдено некоторое количество довольно значимых уже на первый взгляд эндпоинтов и пара API-роутов, все это стоит сразу же сохранить в отдельный текстовый файл:
Пока отложим наши находки из katana. Все равно нам дается сешшн-токен(кука), и без него мы вряд ли уйдем куда-то далеко, с начала тестируем то, что можем протестировать, и так идем по нарастающей. Эта методика наиболее эффективна. Из доступных нам эндпоинтов у нас сейчас в полном доступе есть некий api/v3/auth, пойдем да постучимся, покрутим его то так, то эдак. С самого начала я решил попробовать авторизовать своего бобра, на что получил следующий результат:
Да, нам не ответили абсолютно. Это может свидетельствовать как об Internal Server Error, где до сих пор проблемы с отображением в Caido, так и о 403. Короче говоря, авторизовывать нашего бобра не хотят. Что ж, посмотрим на логин, поменяем креденшиалы на дефолтные встречаемые, посмотрим на реакцию. Ииииии, да. Сделано тут все крайне глупо и недальновидно, ничего не скажешь...
Да, все верно =)
Объясню, что это может означать. В случае, если у нас неверный "логин", который в базе не встречается(регу же они закрыли, судя по всему, новые учетки просто не поставляются), мы видим уведомление bad login. Если пароль, которого нет ни у одного из юзеров, результат аналогичен, только отличается вывод: bad password. Маленький Information Disclosure в ответе от API - мы видим то, чего видеть нам так то не можно. Но это же нам и поможет, мы знаем, что пароли и юзернеймы можно побрутить по отдельности, собрав только результаты, имеющиеся у них в авторизациях, а потом отсеять "гуды" и пробрутить уже перекрестно. С имеющимися в базе логинами и паролями. Процесс геморройный? Да, согласен, даже очень. Но делать нечего, проект отгремел свое и ушел далеко на вторые планы у его овнера, регу нам уже вряд ли откроют).
Я не буду в этой статье углубляться в подробности использования фаззеров, но сразу скажу, что использовал самопис. Для его использования учел факт direct access - прямого доступа к нашему серверу без реверс-прокси, чтобы сильно не драконить DDoS Guard. Зарядил 80 прокси, оставил это на вечер.. и увидел на утро заветные строчки с 200 OK:
Первый действительно хороший "тук" от нашего с вами подхода дотошных Шерлоков, толкающихся от того, что есть уже, учитывая все факты. Забираем креденшиалы, авторизуемся в веб-панельке, пристально смотря в девтулсы: надо посмотреть, как себя ведет при авторизации это веб-приложение. Там может быть раскрыто много нужных нам эндпоинтов, параметры и сама структура запросов к ним. Это все для нас очень важно и сыграет немалую роль в дальнейшем тестировании.
Что ж, вот то, что мы можем с вами видеть:
Панелька крайне бедная, только 2 опции есть у нас на данный момент. Что у нас еще есть? Правильно, внимательные глаза заметят почему-то 2 запроса к auth-эндпоинту после креста, где логин намеренно неверный.
Первую мы уже могли видеть, это result: ok, уведомляющий нас об успешной авторизации, с чем мы его и поздравляем. Он выдает нам session-токен, куки-файл, который используется у нас в целом для любого авторизованного действия. Но второй выглядит куда более интересно:
Этот эндпоинт говорит нам о правах нашего юзера уже после авторизации, принимая к себе куку в качестве содержимого POST-запроса. Очевидно, это нужно для нашей фронтенд-логики, раз запрос произошел именно сейчас. Еще, мы видим, что мы - админ, но прав у нас маловато. Видимо, мы какой-то особый "админ", например, только по тг-менеджменту, или еще по какой гадости. Скорее всего, ролей у юзеров несколько - оставим в заметки в нашем Sublime сразу же этот факт, который потом стоит проверить.
А пока, провернем один фокус с "митм", подменив "пару строчек" в нашем ответе от сервера. Посмотрим, как отреагирует фронтенд у нас в браузере. И, вот, что у нас на это в ответ прилетело:
Что ж, теперь мы понимаем, насколько "причудливая" у нас архитектура. На самом деле, полнейший дебилизм, но оставлю свои замечания при себе). Лучше внимательно осмотрим кнопки и направления, куда они у нас ведут. И, что же мы видим, многие из кнопок ведут нас на эндпоинты, что уже находила катана, например:
Есть целая куча потенциальных точек отказа, куда нам определенно стоит постучать. Диалоги, месседжи, слишком много интересного, чтобы это игнорировать. Так как из веб-формы мы определенно ничего толкового не наделаем(я проверил это парочкой тестов), создаем новый файлик, в котором будем вести заметки. Я предпочитаю саблайм, он красивый, а так, хоть gedit бейте, хоть что. Но очень советую вам именно гуишные редакторы: это очень удобно.
Ровно с этого момента можно начинать движения в сторону нашей определенно организованной методики авторизованного тестирования. Суть такова: мы собираем все потенциальные точки для всевозможных Access Control-аномалий поведения. Места, где контроль за правами юзера уж очень нужен. Сама веб-прилка нам явно намекнула, что прав что-то смотреть у нас "нет", но почему бы не проверить?
Что получилось на первый же взгляд:
Вот так вот составил себе карту, чтобы понимать, в какую сторону копать и какие пути искать в дальнейшем. А теперь интересная закономерность, которую стоит проверять. Все дело в том, что отдельные юзерские эндпоинты, найденные катаной, у меня совпали в двух точках с роутами на API. Это видно по /articles, который виден как на пути /api/v3/, так и на обычной "морде". Попробовали поподставлять, и нашли "связь" "бекенда и фронтенда" - тут она не шибко сложна и все просто, одноименные панельки для юзера и одноименные роуты на API для получения данных к "морде".
Дополняем карту отдельными апи-хендлерами, все, что могли увидеть с наших этапов тестирования(в основном я юзал сведения с katana, считая их приоритетно полезными). Но что делать потом?
Все правильно, тыкать наобум. Намеренно пытаясь сломать самыми разными подвохами. Так, в сущности, и работают уязвимости бизнес-логики в немалой своей части. Мы то убираем куки(по одной), смотря, как откликается эндпоинт(401 Unauthorized или 200 OK), то начинаем подставлять чужие/рандомные значения, если есть какие-то идентификаторы в GET/POST запросах. Мы проверяем все, что может поломаться, а если точнее:
1) Как отреагирует эндпоинт, если к нему подойти совсем без авторизации? Если у вас есть кука, обозначающая вашу сессию/их несколько, или отдельный хидер, уберите его. Посмотрите на реакцию: будет ли ответ?
2) Как отреагирует эндпоинт, если, допустим, имея авторизацию одного юзера(хидер/кука) мы попытаемся подсунуть чужой/рандомный идентификатор?
3) Если эндпоинт выдает нам определенные данные, что, если добавлять их в свой запрос? Что, если их видоизменять?
Задавая эти вопросы самому себе, переносим все те эндпоинты, что нас наиболее сильно интересуют, в нашу карту аудита. Что получаем в итоге? Довольно хорошо структурированную систему, в которой мы будем тестить их по одиночке, делая свои заметки.
Открываем Caido, берем тот токен сессии, который был нам любезно выдан GET-формой эндпоинта api/v3/auth, едем в добрую путь-дорогу. Желательно еще друга подозвать, которому тоже не лень все это отсматривать. Сидим всем селом и ковыряем эту логику по отдельному реквесту.
Не буду расписывать, как я проверял каждый отдельный эндпоинт, ибо логику тестирования я описал чуть выше специально для вас.. покажу вам сразу итоговый результат, который получился у меня после пары часов исследований совместно с моим хорошим товарищем. Вот, что удалось выяснить в ходе тестирования в первые 15 минут. Заметки я специально оформлял так, чтобы новым в поисках этой уязвимости юзерам было понятно, что логика вполне себе применима.
Казалось бы, да. Куки проверяются, и без них ты упрешься в 401 Unauthorized, иди ка ты мол лесом, горе-хакер. Однако, многие эндпоинты изначально имеют Broken Access Control-отклонения. Нас не должно ни в коем разе пускать внутрь: иначе функционал был бы доступен на веб-форме, в которой почему-то видим только настройки и привязку паршивого бота. Но мы проходим внутрь и можем, используя наш session-токен, получать информацию в ответ от них. Также, мы изучили саму логику авторизации, и увидели, что одна из кук содержит И никнейм, И токен, а другая ТОЛЬКО токен. Та, что содержит ТОЛЬКО токен, оказалась необходимой как раз таки для этой механики авторизации. Изменений и Information Disclosure-паттернов в этом пронаблюдать не удалось, однако, просто учтем это в дальнейшем тестировании.
Согласно другому факту, полученному из этого незамысловатого тестирования, мы с вами установили следующее: сервер при "неправильном" формате запроса к эндпоинту не возвращает никаких бед реквестов и так далее. Он ведет себя следующим образом:
Все верно, сразу на тебе, 500 Internal Server Error в лицо. По опыту, советую одним из первых дел проверять паттерн users/{USER_ID}, мы с вами ранее уже видели. откуда можно достать юзерайди. Таким методом, помимо arjun, я и ходил из стороны в сторону вокруг эндпоинтов, пытаясь найти методы к ним обращения. arjun, кстати, это как раз таки потрясающий для этого софт - позволяет производить хороший в реализации логический брутфорс по словарику в том числе. Искал по дефолтным словарям с параметрами от ассетноут. admin/users/ стал первым эндпоинтом для моего тестирования, который откликнулся на этот USER_ID и перестал выдавать 500. Получается, если мы все делаем правильно, 500 не будет. Интересный паттерн, который следует запомнить.
Что нам говорит этот айдор:
Здесь наша гипотеза про разные роли у юзеров, коих куда больше, чем админ и неадмин, подтверждается). И это IDOR, позволяющий спереть все никнеймы на сервера для последующего брута по паролям, что точно подошли(ранее этот шаг мы описывали)). Потому что id у них выбирается не на рандом, как оказалось, а имеет лимиты. Имея айди своей брутнутой учетки, установил это. Шагнул сразу до следующей тысячи - 3000, увидел тот же internal server error. И так, методом подбора, нашел границу, последний юзерайди, не дающий 500. 2577 юзер стал последним, у нашей панельки 2577 юзеров.
Ситуация с /channels тоже ужасна, нам в лицо вылетает следующая штука:
Не совсем IDOR: мы не идем по его привычному для секьюрити специалистов паттерну. У нас нет никаких идентификаторов и прочей галиматьи. Зато есть прочие паттерны, тоже входящие в ряд CWE от группы Broken Access Control: ненадлежащая валидация. Прав-то вроде нет, но если ты авторизован хоть как-то, то вперед и в путь дорогу, дампь все трафферские ресурсы с этой панельки, как не в себя. Сохраняем этот дамп сразу. Кстати, если вы посмотрите на эти каналы внутри, вы увидите, что именно вынудило меня "работать по русскому ресурсу" - ребятки не стесняются не только лить скам-гемблу и дрейнеры, но еще и делать это по своей же стране.
С артиклзами(статьями) тоже все довольно интересно. У них есть свои идентификаторы, которые позволяют получать к ним доступ через уже другой эндпоинт, в котором нашел отклик гет-параметр по схожему паттерну: articles/{ARTICLE_ID}:
Посмотрим, че у них там за мануальчики.
Там же есть отдельный эндпоинт с имейджами, /articles-files. Туда влезать проблематично, но влезть тоже было можно:
Незамысловато, и оставлю подсказку, думаю, вы сами понимаете, какую именно, для тех, кто тоже захочет навестить сервис и потестить его). Шелл там более чем возможен. Загрузил статейку - загнал шеллку.
С помощью божьей помощи, простого перебора айдишников и линков, а так же ffuf закачиваем себе все, что тут есть:
Просто? Да. Сурово? Еще бы. Показывает ли это возможный импакт уязвимостей логики на таких сервисах? А как же. Бах, и вычислили всю траферскую сетку, увидев все траф.ресурсы, еще и юзернеймы все спарсили(спойлер, многие совпадают с никами в тг, твиттере и на других платформах).
Советую вам протестировать эту методологию, и куда больше обращать внимания на бизнес-логику. Многие паттерновые механизмы сканирования попросту не очень хорошо распознают такие мелкие нюансы(за исключением агентов MCP и изначально нейроночных штуковин, о них поговорим в следующих статьях серии), но у вас есть руки и глаза. Уязвимость, для теста которой нужно просто вести себя, как дурак, и совать все подряд во все подряд, способна нанести огромнейший урон организации, сдампить базы, получить юзера-админа и далее по списку. Не акцентируйтесь только на том, что видят сканеры
Надеюсь, что моя достаточно базовая методология будет для вас чем-то интересным, а живое тестирование "перед вами" покажет, что именно может быть осуществлено с помощью этой уязвимости, а также покажет вам новую, возможно, сторону для тестирования веб-приложений.
А в заключение вам парочка скриншотов по бритью людей на сигналах и сомнительных ресурсах и интересные материалы, которые определенно рекомендую к изучению:
Материалы:
1) OWASP - https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/
2) PortSwigger - https://portswigger.net/web-security/access-control/idor
3) https://vickieli.medium.com/how-to-find-more-idors-ae2db67c9489 - интересный материал для новичков в поиске этой вули =)
4) https://forum.duty-free[.]cc/threads/1519/ - интересный баг-репорт по крупному криптообменнику, где IDOR привел к дампу баз переводов и обменов, а также к дампу информации юзеров(считай, что скуля)
В ходе недавних своих размышлений мне четко и ясно захотелось выпустить своеобразную "многологию" из статей на разные темы веб-пентеста и пентеста Active Directory, которая бы содержала все основное и нужное для заинтересованных лиц. Без лишних деталей и ненужных словес, плетенных по древу. Лишь то, что, по моему опыту, действительно способно приводить к компрометации, а значит, и к профиту для пентестера N, который очень хочет, чтобы некая организация с ним поделилась.
Подробности я освещу в комментарии в этой теме, в первом комментарии после этой статьи.
P.S. - я не то, чтобы от избытка ума страдаю, потому, в случае неточностей или каких-то своих замечаний, в случае желания обсудить то, что я не успел осветить в статье, попрошу Вас, уважаемые читатели, сразу писать свои мысли в комментарии. Я всем постараюсь по мере сил и времени ответить. Больше таких вступлений у нас не будет. Также, я решил оставить тот же публицистический стиль, который был применен в возможно знакомой вам статье о RCE в реакте, но структуры статей я решил видоизменить, сделать более удобоваримыми и информативными. Потому, у нас будет некое содержание. Перейдем сразу к делу, и приятного вам прочтения.
Содержание:
1) Введение и матчасть.
2) Образцовые ситуации: Рассмотрим примеры уязвимости и ее импакта на PortSwigger.
3) Актуальные практики нахождения и эксплуатации уязвимости в дикой природе: инструментарий, методология.
4) Источники, интересные ресурсы.
Введение и матчасть
Современные тенденции разработки веб-приложений характеризуются поражающим ростом сложности бизнес-логики этих самых приложений, как и общей сложности видимой нами инфраструктуры.
Личные кабинеты, сбор всей возможной информации маркетологами, чтобы кормить вас новой таргетированной порцией в эдсах, сложнеющие год от году в своей структуре платежки(обработки заказов, остановки заказов, изменения в них на лету), и бедные разработчики, что поднимают все это действо, день ото дню отращивающее все новые и новые API-роуты.
И тут в игру вступает как раз таки человеческий фактор: "забыл про эндпоинт", "забыл поправить сурсы", "новый и не оттестированный по максимуму функционал".
В совокупности ровно такие ситуации и подпадают под отдельную классификацию девиантного поведения веб-прилки - в общий класс нарушений, названных Broken Access Control: когда веб-приложение дуркует очень своеобразным образом, неудовлетворительно проверяя возможность доступа у конкретного юзера к чужой информации/несанкционированным для него функциям. Пользак просто получает доступ к тому, к чему ему не можно.
Как раз такие "доступы" очень разные в зависимости от ситуации: когда мы можем втупую менять чужие аватарки, когда - вообще получать доступ к админовым и тестовым функциям бизнес-логики.
В зависимости от места, куда мы получили доступ в ходе эксплуатации, и рознится опасность уязвимости. Понятное дело, что просто смене аватарок у профилей других, не имеющих к тебе отношения, юзеров не присвоят "критикал импакт"; потенциальному черненькому душой парню тоже нет особого смысла с этим париться в каких-либо нуждах кроме дефейса и прочей галиматьи.
Но ситуация способна радикально измениться, когда в один момент мы получаем доступ к чему-то админскому, к логике создания и изменения прав аккаунтов, к логике помощи пользователям вроде "Забыл пароль?".
Не менее интересно бывает и изучать ту часть приложения, которая отвечает за платежные системы и заказы: такие штуки особенно опасны.
Не только потенциальным доступом к чужой инфе, но и, в редких случаях, созданием левых платежных заявок от имени других юзеров, их изменением или удалением.
Изучим эту совокупную группу разных уязвимостей, воспользовавшись ресурсом OWASP.
Но для начала, стоит поговорить об актуальности того, что мы сейчас рассматриваем.
Перейдем на OWASP Top-10:
Статистика умеет удивить, не правда ли?
Согласно тому, что мы видим в нынешней "горячей десятке", уязвимости нарушенного контроля уже на протяжении 4 лет держут свое заслуженное главенство в этой десятке.
Как и говорилось в начале, отдельным стимулом к тому выступает тенденция на всеобщее усложнение структуры таких приложений. Но однако, стоит также заметить, что начиная с эпохи "AI-бума" постепенно втерлась в обыденную жизнь разработчика и всевозможная автоматизация, зиждящаяся на нейронках всех применений. Проблемы, связанные как с привычкой "писать нейронкой", так и с привычкой использовать всевозможные автоматизационные фреймворки на их основе, включают в себя как раз таки эти "маленькие, но удаленькие" моменты, входящие в класс Broken Access Control. Этот огромный и "прожорливый" класс также забрал в себя прочие, ранее бывшие "отдельными", уязвы. Например, IDOR в 2017-ом, CSRF & SSRF ближе к нашим дням.
Рассмотрим стату Common Weakness Enumeration, связанную с этой группой.
Обширно, ничего не скажешь.. много самых разных возможных фейлов: тут тебе и опен-редиректы(возможность редиректить в стороны, что по дефолту прилке не положены, что открывает дорогу к грамотному чейну на фишинг и так далее), и приколы с кузницей запросов как на стороне клиентов(CSRF, принужденные выманить заветные запросы из браузера жертвы с нужными сведениями внутри), так и на стороне сервера(SSRF, когда мы можем отправлять запросы уже со стороны сервера произвольно, манипулируя изъянами его логики).
Наиболее "опасными" и простыми в реализации(без кучи шагов в чейне эксплуатации) вариантами будут нарушенные проверки авторизации, IDOR и SSRF: эти три CWE вполне себе желанны у черных душой парней и по наши дни. Отдельную роль в "сложных атаках" играют и Path Traversal: при правильном применении возможно выстроить далеко не слабую цепочку. Но сегодня, прежде чем подведем вывод о группе Broken Access Control, мы сфокусируем наше внимание именно на IDOR.
Из рассмотренных нами сведений становится ясно, что Broken Access Control - это группа типичных уязвимых паттернов, относящаяся к изъянам куда чаще не применимых технологий, а логики, выстроенной в приложении. Туда могут относиться разные уязвимости, но подавляющее большинство типичных уязвимых паттернов(инше говоря - антипаттернов) относятся к неправильной авторизации и неудовлетворительному качеству ее проверки.
Группа перешла в топ-1, который держит по сей день, уже в отчете OWASP Top-10 в 2021 году:
Рассмотрим отдельный паттерн неправильного и опасного поведения, в народе прозванный "IDOR". IDOR - Insecure Direct Object Reference - неправильное поведение приложения, характеризующееся возможностью у пользака обращаться к объектам, используя определенный идентификатор. Говоря иначе, приложение не проверяет авторизацию юзера Вани, не смотрит, кто он вообще такой и имеет ли Ваня доступ к ресурсу Пети, например, к информации о его профиле. Зато оно видит, допустим, уникальный id, присвоенный именно анкете юзера Пети, и сразу же дает ему туда доступ. Так можно описать классический случай IDOR, однако, сам по себе insecure direct object reference куда сложнее как паттерн поведения и подпадает сразу под несколько CWE, присвоенных группе Broken Access Control.
Короче говоря, че мы имеем на данный момент:
1) Имеешь авторизацию Вани на веб-аппке(допустим, кука), знаешь user_id Пети, и при этом швыряешь значит реквест в эндпоинт /api/v3/users с user_id=petya. Получаешь почему-то не Unauthorized и не инфу о своем профиле, а данные Пети. Его имейл, его сведения о профиле, все, Петю сдеанонили по сайтику. И это - первый, классический и самый узнаваемый случай: CWE-639, он же по-умному и по-англичански обзываемый секьюрити ресерчерами как Authorization Bypass Through User-Controlled Key. Ключиком нам выступит этот айдишник. Однако, нередки и случаи, когда сюда подпадает и CWE-285 - нарушается проверка, действительно ли сей объект принадлежит конкретному юзеру на сессии. Чаще всего в "иконичном айдоре" пересекаются как раз эти два викнесс-паттерна.
2) Можешь вообще не авторизуясь за Ваню играться с данными Пети? Критичность вули уже очень сильно возрастает(хотя тут я с ними и не согласен, создать акк под силу каждому пентестеру, и спарсят данные и там, и тут). Но тогда CWE-639 отступает, потому что из названия понятно, мы же должны байпасснуть авторизацию. Ну а у нас все перетекает в класс unauth-вуль.
Но в сухом итоге все эти паттерны будут узнаваться ресерчерами именно как IDOR.
Что же получается? Когда у нас есть какой-то объект, будь то файл или запись, мы зовем этот объект "объектом данных". Таким образом, можно сделать следующий вывод: IDOR - это уязвимый паттерн работы веб-приложения, подпадающий под CWE-639, CWE-285, либо под оба этих common-weakness паттерна, характеризуемый существованием объекта данных. В случае, если авторизация при доступе к ресурсу происходит ненадлежащим образом, паттерн CWE-285 становится доминирующим; в иных случаях(например, наличие определенного UUID и доступ к файлам только по нему, как в случае с CWE-639) в описании паттерна IDOR находят применение либо CWE-639, либо CWE-285 совместно с CWE-639. Когда мы каким-то образом можем получить доступ к этому объекту данных, минуя авторизацию или не нуждаясь в ней, это и будет считаться для нас IDOR; преимущественно IDOR в большинстве своих случаев ассоциирован именно с CWE-639. Посмотрим на картиночку, которая может показать это наглядно.
Тут все становится относительно понятно. Прямой доступ к чужим объектам без надлежащего контроля.
Уязвимость бесспорно коварна: получи доступ к информации о чужих профилях, и спарсишь весь сервис, просто перебирая юзерайдишники и прочие идентификаторы. Базу выгрузишь без SQLi и прочей магии, которую мы тоже позже в рамках этой серии статей рассмотрим. Получи доступ к логике чужих профилей и, допустим, корзин (как на всяких шоп-сайтах), и хоть подменяй адреса доставок, хоть вообще в нулину снимай все балансы пользаков. И именно этим она и интересна нам прежде всего.
Образцовые ситуации: Рассмотрим примеры уязвимости и ее импакта на PortSwigger.
Прежде чем перейти в кейсы из области "реального мира", а не "ой, братик, я опять застряла в стиралке", чем является большинство CTF на разных обучающих платформах, посмотрим на классические простейшие примеры этой уязвы. Поможет нам в этом не менее известная платформа для обучения, выпущенная нашими белыми коллегами из компании PortSwigger (берп, легенда, никогда не перейду на Caido полностью).
Идем в раздел веб-лаб под названием Authentication, смотрим на раздел Access Control Vulnerabilities. Здесь и будет то, что нам нужно: начинаем решать.
Лаба #1.
Заходим на первую лабу. Возьмем в качестве примера первую попавшуюся на глаза из раздела #access-control-vulnerabilities - user role can be modified in user profile, что нам и нужно. Уже по названию становится понятно, что внутри есть что-то на нашу сегодняшнюю тематику. Сразу включаем прокси Burp Suite: будем двигаться на пассивном краулинге, с нашими плутаниями по аппке нарастет и дерево в разделе Target.
Встречает нас обычный шоп из портсвиггеровых лабок:
Нам дают и дефолтные креды портсвиггера: сразу становится понятно, что в My account заглянуть все же стоит. В самом описании говорится про панельку на эндпоинте /admin, пробуем зайти в нее с дефолт кредов. Ожидаемо, нас не пускает. Логинимся в веб-панельку, посмотрим, есть ли нечто интересное внутри запроса.
Ненаход: в этот раз смотреть нам честно говоря не на что. Дефолтные перемсы "юзернейм" и "пассвуд", ничего интересного нет. Стоит посмотреть на внутрянку нашего юзерпрофиля, однако, виднеется только одна функция:
Окак, функция только одна. В целом, что нам терять? Терять нам нечего, клацаем. Введя наш имейл, разумеется. На веб-странице ничего интересного не произошло, может, нечто интересное есть в самом реквесте? Посмотрим.
Что ж, да, мы не разочарованы. Есть некий апи-ответ, джейсоновый, и есть как раз таки ключик roleid - некий идентификатор "роли" юзера на этом сервисе. В начале перед лабой говорится, что там надо поставить двойку, и будет пропуск в панельку. Ставим, смотрим.
Надо же, наход. Удаляем терпилу Карлоса к чертям.
Нереалистично? Да. Похоже на одно из лиц этой уязвимости? Да, х2. Мы знаем определенный объект - идентификатор нашей юзер-роли, и даже имея при этом свою обычную авторизацию, отправив этот идентификатор, получаем права. CWE-639.
Лаба #2.
Для большего понимания решим еще одну лабу, в этот раз с чутка другим видом того же поведения, что также воспринимается аналитиками как паттерн IDOR.
Дали нам дефолт креды Питера и опять тот же магазинчик.
Логинимся: тут судя по всему иначе никак. Смотрим на поведение веб-прилки при логине:
Опять порожняк, ничего толком нет, кроме классического Found, уведомляющего нас об успешной, вот же радость, авторизации. В этот раз видим мы в самой морде нашего личного кабинета апи-ключик, который на это поле с верифаем ну никак не влияет. Зато видим еще и нечто странное: новый GET-параметр, который висит сверху в урле и не дает покоя. id=wiener.
Подменим втупую на carlos, не выходя из браузера:
Выдаем наше решение, как видно, коробка уже все. Опять же, пример довольно нереалистичный, но право на жизнь определенное он все же имеет.
Эти коробки при всей своей вычурности способны научить главному навыку при поиске таких отклонений: смотреть на все подряд и кликать все подряд, авось что-то да и получится. Да и становится понятно, что импакт от таких вуль нельзя описать универсально для каждого кейса и он рознится от случая к случаю. То админка, то потенциальный ATO - Account Takeover, то и вовсе вуля становится помощником и одним из звеньев более "капитальной атаки", как, например, это работает с CTF на HackTheBox под названием Era - всем советую на досуге решить, кстати. Интересная, отчасти реалистичная машинка.
Рассмотрим более подробно логику поиска и эксплуатации в условиях реальных и подобающих.
Актуальные практики нахождения и эксплуатации уязвимости в дикой природе: инструментарий, методология
На примере решенных лабок стало понятно, что один из векторов поиска - просто шарахаться по веб-приложению в поисках потенциальных слабых мест, параллельно изучая все, на что может упасть взгляд. По-умному эта методика зовется "пассивный краулинг" - методика активной разведки, при которой мы ничего намеренно не краулим и не перебираем, как в случае условного фаззинга директорий, всем, однозначно, знакомого. Мы лишь "записываем" все реквесты и респонсы, пришедшие в результате "легитимного"(от рук самого пользователя) использования веб-приложения. В Burp это висит отдельной базовой возможностью, далеко не обязательно использовать Interceptor, чтобы перехватить какой-то из запросов - все те, что прошли через прокси бурпа, автоматически окажутся в истории.
Однако, стоит отметить общий набор мер, который может помочь в поиске подобного рода уязвимостей:
1) Просто пользуйтесь приложением, пристально все изучая. Особенно это касается опций в личных кабинетах, авторизации, регистрации, создания платежек - все те моменты, которые могут быть связаны с API-логикой.
2) Активный краулинг. Краулеры вроде katana и hakrawler могут очень помочь в поиске нужных роутов и эндпоинтов, а также неплохо справляются с "большими" объектами под тестирование, где этих "важных" эндпоинтов могут быть сотни.
3) Чтение сурсов. Это действительно важный источник сведений, который может много чего подсказать. Как минимум, необходимый набор GET/POST параметров для конкретного эндпоинта, чтобы понимать, как строить реквесты - далеко не все будет вам ясно из простого использования веб-аппа, где-то(например, админские или тестовые, "забытые" функции) вам быть не можно =)
Помимо понятных довольно мер, можно также выделить следующие "негласные правила": смотреть стоит прежде всего на эндпоинтах, либо принимающих какие-то уникальные идентификаторы(id, включая айди юзеров и так далее, все уникальные ключики), либо дающих доступ к какой-то функции на основе данных из запроса и авторизации(например, функции смены имейла на профиле юзера, где в формате POST следует отправить юзерайди и новый имейл). Допустим, что у вас есть путь .../api/v3/users/get-info. Если на нем существует какое-то аномальное поведение(например, выдача сведений при авторизационных хидерах, куки то или отдельный хидер, по id другого пользователя), стоит проверить также и остальные пути, включающие .../api/v3/users/... Вполне возможно, что нарушенные механизмы авторизации встретятся и у соседушек.
Порой встречаются инструменты документирования API, например, Swagger. Это тоже крайне полезная находка: Swagger может дать понимание, как использовать те или иные эндпоинты и как происходит информационный обмен с API-интерфейсом в веб-приложении.
Чтобы понять логику тестирования в случае, если ранее вы почему-то никогда не касались этой вули, возьму пример, недавно попавший в мою практику. Информационный ресурс достаточно вредоносного содержания, в комментариях к этой статье будут дальнейшие подробности. Уязвимости там могут быть достаточно "понятными" и "типовыми" для ознакомления с методологией "на живой цели". Описывать дальнейшую логику будем наглядно, производя полноценный "аудит" по уязвам этой группы.
Перейдем по ссылке и познакомимся с ресурсом.
Нас встречает вот такая мордашка, на которой происходят авторизация либо регистрация. Сделано довольно топорно, но в довольно прикольной неоновой теме, пусть нам это сейчас не сильно и важно. Первым делом стоит собрать ту информацию о нашей цели, которую мы можем собрать из открытых источников. Я сделал довольно просто и "на глаз", ведь наша сегодняшняя цель - рассмотреть только одну конкретную группу уязвимостей, а там главное копошиться именно в логике.
Перейдем к Wappalyzer и FOFA, чтобы понять, с чем имеем дело.
Стек незамысловатый, довольно даже обыденный, я бы сказал. У нас есть DDoS Guard, доступ обеспечивается как раз через его реверс-прокси, о чем нам радостно рапортует шодан. Однако, развертка здесь грамотностью не славится, и первый же запрос в FOFA выдает нам истинный IP-адрес сервера(Origin IP):
Адрес пингуется, дальше - больше: при проверке оказалось, что у нас есть прямой доступ(direct access) к веб-приложению по истинному адресу его сервера, о чем нам радостно рапортовал уже другой инструмент, httpx-toolkit:
Адрес для нас в данном случае - довольно ценная находка, и кратко объясню, почему именно. Теперь, если мы захотим пофаззить, мы будем делать это не через реверс-прокси DDoS Guard, что, очевидно, может принести некоторые затруднения и блокировки. Можно "не тихушничать" и делать куда более расточительные на веб-ресурсы конфиги фаззеров. Главное правило для нас сейчас - делать все так, чтобы ничего не упало, мы ведь - незаметная интервенция =)
В случае правил платформ для багхантеров все в целом почти такое же. Мы можем применять разные методики тестирования, но DoS/DDoS (даже нечаянно) во многих случаях непозволителен.
Увидев, что поле регистрации открыто, я сразу же включил девтулсы и подключил свой прокси, в этот раз Caido. Приступим к изучению и создадим учетку. Это поможет нам в нуждах тестирования.
Клацаем "зарегистрироваться", и получаем следующую картину:
Весьма интересно. Сразу видим API, по наитию и собственному опыту понимаю, что тестирование будет довольно приятным - хендлеры имеют довольно предсказуемые названия, без роскоши и фантазии). Куда неприятнее тот факт, что через куку какого-то черта передается IP-адрес клиента, посетившего ресурс, что уже само по себе сюр, но тут даже без малейших попыток "спрятать".
Сам эндпоинт auth выдавал 403(Forbidden), вероятно, закрыли его после первой попытки разведать, довольно успешной, но без подробного документирования). Что для нас в целом-то не проблема.
Увидев такой стек, как и увидев такие приятные API-роуты, первое, что пришло мне в голову, - попытаться запустить внутрь автоматизированного краулера. Соберем побольше информации о имеющихся веб-директориях, авось, увидим что-то интересное. Параллельно есть смысл постучать в gau и waybackurls - они тоже порой дают много полезностей, например, эндпоинты, в инструкции краулеров не попадающие, но имеющие в себе тем не менее много хорошего для нас материала. Таковыми нередко бывают тестовые эндпоинты, оставленные на проде случайно.
Gau показал себя не шибко полезным в этом конкретном кейсе, найдя кучу .svg-мусора и пару обфусцированных .js:
Куда большую пользу в этот раз нам принесла katana. Найдено некоторое количество довольно значимых уже на первый взгляд эндпоинтов и пара API-роутов, все это стоит сразу же сохранить в отдельный текстовый файл:
Пока отложим наши находки из katana. Все равно нам дается сешшн-токен(кука), и без него мы вряд ли уйдем куда-то далеко, с начала тестируем то, что можем протестировать, и так идем по нарастающей. Эта методика наиболее эффективна. Из доступных нам эндпоинтов у нас сейчас в полном доступе есть некий api/v3/auth, пойдем да постучимся, покрутим его то так, то эдак. С самого начала я решил попробовать авторизовать своего бобра, на что получил следующий результат:
Да, нам не ответили абсолютно. Это может свидетельствовать как об Internal Server Error, где до сих пор проблемы с отображением в Caido, так и о 403. Короче говоря, авторизовывать нашего бобра не хотят. Что ж, посмотрим на логин, поменяем креденшиалы на дефолтные встречаемые, посмотрим на реакцию. Ииииии, да. Сделано тут все крайне глупо и недальновидно, ничего не скажешь...
Да, все верно =)
Объясню, что это может означать. В случае, если у нас неверный "логин", который в базе не встречается(регу же они закрыли, судя по всему, новые учетки просто не поставляются), мы видим уведомление bad login. Если пароль, которого нет ни у одного из юзеров, результат аналогичен, только отличается вывод: bad password. Маленький Information Disclosure в ответе от API - мы видим то, чего видеть нам так то не можно. Но это же нам и поможет, мы знаем, что пароли и юзернеймы можно побрутить по отдельности, собрав только результаты, имеющиеся у них в авторизациях, а потом отсеять "гуды" и пробрутить уже перекрестно. С имеющимися в базе логинами и паролями. Процесс геморройный? Да, согласен, даже очень. Но делать нечего, проект отгремел свое и ушел далеко на вторые планы у его овнера, регу нам уже вряд ли откроют).
Я не буду в этой статье углубляться в подробности использования фаззеров, но сразу скажу, что использовал самопис. Для его использования учел факт direct access - прямого доступа к нашему серверу без реверс-прокси, чтобы сильно не драконить DDoS Guard. Зарядил 80 прокси, оставил это на вечер.. и увидел на утро заветные строчки с 200 OK:
Что ж, вот то, что мы можем с вами видеть:
Панелька крайне бедная, только 2 опции есть у нас на данный момент. Что у нас еще есть? Правильно, внимательные глаза заметят почему-то 2 запроса к auth-эндпоинту после креста, где логин намеренно неверный.
Первую мы уже могли видеть, это result: ok, уведомляющий нас об успешной авторизации, с чем мы его и поздравляем. Он выдает нам session-токен, куки-файл, который используется у нас в целом для любого авторизованного действия. Но второй выглядит куда более интересно:
Этот эндпоинт говорит нам о правах нашего юзера уже после авторизации, принимая к себе куку в качестве содержимого POST-запроса. Очевидно, это нужно для нашей фронтенд-логики, раз запрос произошел именно сейчас. Еще, мы видим, что мы - админ, но прав у нас маловато. Видимо, мы какой-то особый "админ", например, только по тг-менеджменту, или еще по какой гадости. Скорее всего, ролей у юзеров несколько - оставим в заметки в нашем Sublime сразу же этот факт, который потом стоит проверить.
А пока, провернем один фокус с "митм", подменив "пару строчек" в нашем ответе от сервера. Посмотрим, как отреагирует фронтенд у нас в браузере. И, вот, что у нас на это в ответ прилетело:
Что ж, теперь мы понимаем, насколько "причудливая" у нас архитектура. На самом деле, полнейший дебилизм, но оставлю свои замечания при себе). Лучше внимательно осмотрим кнопки и направления, куда они у нас ведут. И, что же мы видим, многие из кнопок ведут нас на эндпоинты, что уже находила катана, например:
Есть целая куча потенциальных точек отказа, куда нам определенно стоит постучать. Диалоги, месседжи, слишком много интересного, чтобы это игнорировать. Так как из веб-формы мы определенно ничего толкового не наделаем(я проверил это парочкой тестов), создаем новый файлик, в котором будем вести заметки. Я предпочитаю саблайм, он красивый, а так, хоть gedit бейте, хоть что. Но очень советую вам именно гуишные редакторы: это очень удобно.
Ровно с этого момента можно начинать движения в сторону нашей определенно организованной методики авторизованного тестирования. Суть такова: мы собираем все потенциальные точки для всевозможных Access Control-аномалий поведения. Места, где контроль за правами юзера уж очень нужен. Сама веб-прилка нам явно намекнула, что прав что-то смотреть у нас "нет", но почему бы не проверить?
Что получилось на первый же взгляд:
Вот так вот составил себе карту, чтобы понимать, в какую сторону копать и какие пути искать в дальнейшем. А теперь интересная закономерность, которую стоит проверять. Все дело в том, что отдельные юзерские эндпоинты, найденные катаной, у меня совпали в двух точках с роутами на API. Это видно по /articles, который виден как на пути /api/v3/, так и на обычной "морде". Попробовали поподставлять, и нашли "связь" "бекенда и фронтенда" - тут она не шибко сложна и все просто, одноименные панельки для юзера и одноименные роуты на API для получения данных к "морде".
Дополняем карту отдельными апи-хендлерами, все, что могли увидеть с наших этапов тестирования(в основном я юзал сведения с katana, считая их приоритетно полезными). Но что делать потом?
Все правильно, тыкать наобум. Намеренно пытаясь сломать самыми разными подвохами. Так, в сущности, и работают уязвимости бизнес-логики в немалой своей части. Мы то убираем куки(по одной), смотря, как откликается эндпоинт(401 Unauthorized или 200 OK), то начинаем подставлять чужие/рандомные значения, если есть какие-то идентификаторы в GET/POST запросах. Мы проверяем все, что может поломаться, а если точнее:
1) Как отреагирует эндпоинт, если к нему подойти совсем без авторизации? Если у вас есть кука, обозначающая вашу сессию/их несколько, или отдельный хидер, уберите его. Посмотрите на реакцию: будет ли ответ?
2) Как отреагирует эндпоинт, если, допустим, имея авторизацию одного юзера(хидер/кука) мы попытаемся подсунуть чужой/рандомный идентификатор?
3) Если эндпоинт выдает нам определенные данные, что, если добавлять их в свой запрос? Что, если их видоизменять?
Задавая эти вопросы самому себе, переносим все те эндпоинты, что нас наиболее сильно интересуют, в нашу карту аудита. Что получаем в итоге? Довольно хорошо структурированную систему, в которой мы будем тестить их по одиночке, делая свои заметки.
Открываем Caido, берем тот токен сессии, который был нам любезно выдан GET-формой эндпоинта api/v3/auth, едем в добрую путь-дорогу. Желательно еще друга подозвать, которому тоже не лень все это отсматривать. Сидим всем селом и ковыряем эту логику по отдельному реквесту.
Не буду расписывать, как я проверял каждый отдельный эндпоинт, ибо логику тестирования я описал чуть выше специально для вас.. покажу вам сразу итоговый результат, который получился у меня после пары часов исследований совместно с моим хорошим товарищем. Вот, что удалось выяснить в ходе тестирования в первые 15 минут. Заметки я специально оформлял так, чтобы новым в поисках этой уязвимости юзерам было понятно, что логика вполне себе применима.
Казалось бы, да. Куки проверяются, и без них ты упрешься в 401 Unauthorized, иди ка ты мол лесом, горе-хакер. Однако, многие эндпоинты изначально имеют Broken Access Control-отклонения. Нас не должно ни в коем разе пускать внутрь: иначе функционал был бы доступен на веб-форме, в которой почему-то видим только настройки и привязку паршивого бота. Но мы проходим внутрь и можем, используя наш session-токен, получать информацию в ответ от них. Также, мы изучили саму логику авторизации, и увидели, что одна из кук содержит И никнейм, И токен, а другая ТОЛЬКО токен. Та, что содержит ТОЛЬКО токен, оказалась необходимой как раз таки для этой механики авторизации. Изменений и Information Disclosure-паттернов в этом пронаблюдать не удалось, однако, просто учтем это в дальнейшем тестировании.
Согласно другому факту, полученному из этого незамысловатого тестирования, мы с вами установили следующее: сервер при "неправильном" формате запроса к эндпоинту не возвращает никаких бед реквестов и так далее. Он ведет себя следующим образом:
Все верно, сразу на тебе, 500 Internal Server Error в лицо. По опыту, советую одним из первых дел проверять паттерн users/{USER_ID}, мы с вами ранее уже видели. откуда можно достать юзерайди. Таким методом, помимо arjun, я и ходил из стороны в сторону вокруг эндпоинтов, пытаясь найти методы к ним обращения. arjun, кстати, это как раз таки потрясающий для этого софт - позволяет производить хороший в реализации логический брутфорс по словарику в том числе. Искал по дефолтным словарям с параметрами от ассетноут. admin/users/ стал первым эндпоинтом для моего тестирования, который откликнулся на этот USER_ID и перестал выдавать 500. Получается, если мы все делаем правильно, 500 не будет. Интересный паттерн, который следует запомнить.
Что нам говорит этот айдор:
Здесь наша гипотеза про разные роли у юзеров, коих куда больше, чем админ и неадмин, подтверждается). И это IDOR, позволяющий спереть все никнеймы на сервера для последующего брута по паролям, что точно подошли(ранее этот шаг мы описывали)). Потому что id у них выбирается не на рандом, как оказалось, а имеет лимиты. Имея айди своей брутнутой учетки, установил это. Шагнул сразу до следующей тысячи - 3000, увидел тот же internal server error. И так, методом подбора, нашел границу, последний юзерайди, не дающий 500. 2577 юзер стал последним, у нашей панельки 2577 юзеров.
Ситуация с /channels тоже ужасна, нам в лицо вылетает следующая штука:
Не совсем IDOR: мы не идем по его привычному для секьюрити специалистов паттерну. У нас нет никаких идентификаторов и прочей галиматьи. Зато есть прочие паттерны, тоже входящие в ряд CWE от группы Broken Access Control: ненадлежащая валидация. Прав-то вроде нет, но если ты авторизован хоть как-то, то вперед и в путь дорогу, дампь все трафферские ресурсы с этой панельки, как не в себя. Сохраняем этот дамп сразу. Кстати, если вы посмотрите на эти каналы внутри, вы увидите, что именно вынудило меня "работать по русскому ресурсу" - ребятки не стесняются не только лить скам-гемблу и дрейнеры, но еще и делать это по своей же стране.
С артиклзами(статьями) тоже все довольно интересно. У них есть свои идентификаторы, которые позволяют получать к ним доступ через уже другой эндпоинт, в котором нашел отклик гет-параметр по схожему паттерну: articles/{ARTICLE_ID}:
Посмотрим, че у них там за мануальчики.
Там же есть отдельный эндпоинт с имейджами, /articles-files. Туда влезать проблематично, но влезть тоже было можно:
Незамысловато, и оставлю подсказку, думаю, вы сами понимаете, какую именно, для тех, кто тоже захочет навестить сервис и потестить его). Шелл там более чем возможен. Загрузил статейку - загнал шеллку.
С помощью божьей помощи, простого перебора айдишников и линков, а так же ffuf закачиваем себе все, что тут есть:
Просто? Да. Сурово? Еще бы. Показывает ли это возможный импакт уязвимостей логики на таких сервисах? А как же. Бах, и вычислили всю траферскую сетку, увидев все траф.ресурсы, еще и юзернеймы все спарсили(спойлер, многие совпадают с никами в тг, твиттере и на других платформах).
Советую вам протестировать эту методологию, и куда больше обращать внимания на бизнес-логику. Многие паттерновые механизмы сканирования попросту не очень хорошо распознают такие мелкие нюансы(за исключением агентов MCP и изначально нейроночных штуковин, о них поговорим в следующих статьях серии), но у вас есть руки и глаза. Уязвимость, для теста которой нужно просто вести себя, как дурак, и совать все подряд во все подряд, способна нанести огромнейший урон организации, сдампить базы, получить юзера-админа и далее по списку. Не акцентируйтесь только на том, что видят сканеры
Надеюсь, что моя достаточно базовая методология будет для вас чем-то интересным, а живое тестирование "перед вами" покажет, что именно может быть осуществлено с помощью этой уязвимости, а также покажет вам новую, возможно, сторону для тестирования веб-приложений.
А в заключение вам парочка скриншотов по бритью людей на сигналах и сомнительных ресурсах и интересные материалы, которые определенно рекомендую к изучению:
Материалы:
1) OWASP - https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/
2) PortSwigger - https://portswigger.net/web-security/access-control/idor
3) https://vickieli.medium.com/how-to-find-more-idors-ae2db67c9489 - интересный материал для новичков в поиске этой вули =)
4) https://forum.duty-free[.]cc/threads/1519/ - интересный баг-репорт по крупному криптообменнику, где IDOR привел к дампу баз переводов и обменов, а также к дампу информации юзеров(считай, что скуля
)
Последнее редактирование:
