LIMB
Приветствую все любопытные умы, что кликнули на мою статейку.
Сложно не заметить следующую тенденцию: во многих сегментах как относительно black-деятельности, так и bughunting-пространства в последнее время наступает печальная тенденция - люди "уперлись" в несколько тяжелых для таргетов, несомненно, уязвимостей вроде RCE и SQLi с готовыми эксплойтами/легкой эксплуатацией в целом, ленясь изучать таргеты вне этих "рамок". Несомненно, в массовой работе и сборе больших количеств профитных таргетов этот подход располагает огромными плюсами, но тем не менее, на многих таргетах люди в силу своего подхода(а он прост, проверили сканерами вроде окуня/отчекали по готовым нукли темплейтам) теряют, возможно, достаточно большой профит(и особенно критично это именно для багхантеров :D).
Речь пойдет как раз о таких вулях, на поиск которых многим нередко выделить немножко времени попросту лень: Insecure Direct Object Reference, Broken Access Control, семейка всевозможных, но вполне очевидных при должной сноровке вуль API.
Разберем на практическом примере мы с вами именно первые две вули - IDOR и BAC.
Предисловие: кого мы ловим?
Начнем с небольшой справочки по обоим вулям.
IDOR - вуля в наш век довольно нередкая(кто понял шуточку про гпт-кодерков, тот понял :D). И при своей относительной распространенности она куда опаснее многих столь же распространенных вуль(например, всевозможные XSSки, которые тож можно часто встретить). А суть вули может быть описана при этом довольно просто: глупая железка aka приложение какого-то черта использует вводимые нами, людишками, данные как прямую ссылку на какой-то объект данных(привет, всякие user_id=1337 и вся семейка хаев и критов в репортах хакервана). Но при этом всем должно быть одно особенное условие: приложение не должно проверять, а имеет ли вообще юзер на это полномочия или просит чужое/неправильное, на должном уровне. И в этом же условии кроется, кстать, полное для понимания описание BAC. Аномальное поведение, связанное с недостаточным/нарушенным контролем(валидацией).
То есть, допустим, вместо того, чтобы выдавать юзеру определенный объект(допустим, данные по учетке) по проверке тех же кук, апишка ожидает определенный id этого юзера, но никак это не проверяет - юзер с айдишкой 1337 просто кидает запрос, в котором подменяет свой идентификатор на идентификатор юзера с айдишкой 228 и видит его данные.
Это как если бы в школе у Васи и Пети были два шкафчика без замков, но с написанными именами. Или если бы были одинаковые ключи.. Вася просто откроет шкафчик Пети и тихо "найдет", что ему нужно.
Хорошая картинка, дающая достаточное понимание природы такой вули.
При этом всем, вуля достаточно сложна к обнаружению со стороны сокеров: сложно выявить в полотне логов аномальное поведение юзеров, которые юзают такую "фичу".
Методика поиска, эксплуатация
Понимаю, что вы здесь собрались совсем не за объяснениями, которых тонны на всех уважающих себя платформах. Так что перейдем к методике их поиска. Опишу я по большей части в этой статье именно ручной способ поиска таких дырищ, потому что именно полапав все руками можно понять, как это автоматизировать, понять саму природу вули. А автоматизация - вопрос грамотных рук =)
Ищем, как я сказал уже, вручную. Таргет для примера возьму чуть необычный - это Telegram-бот с имеющейся мини-аппкой. Этого не стоит бояться, скажу заранее тем кто опыта работы с такой штукой не имел - это тот же сайт в браузере, оставленном нам дядюшкой Дуровым внутри нашей излюбленной телеги.
Понадобится нам HTTP Debugger, 1 штука, Burp Suite, тоже 1 штука, и удобное рабочее место. Я предпочитаю работать с HTTP Debugger внутри виртуалки, чтобы не сломать свой XRay, который к их "decrypt ssl" очень чувствителен, но вы можете юзать и что-то другое. Допустим, мне удобно просто работать с браузером с парой экстеншенов: дефолтная лиса тоже неплохо справляется со своими задачками.
Без лишних слов открываем мини-аппку обменника, что я выбрал для демонстрации серьезности таких мисконфигураций, и идем в открытый заранее HTTP Debugger.
Клацаем все, что видим: методом ручного краулинга мы постепенно собираем наш surface для последующего исследования.
Не ленимся клацать, обновлять страницы, изучать доступный нам функционал: HTTP Debugger все снифает для нас, собирая Surface.
По факту, нам бы с легкостью хватило одного только домена, и HTTP Debugger можно закрывать: любители веб-пентеста сами потрясающе справляются, обладая потрясающими тулами вроде katana, gau и ffuf для любителей носить с собой пачку словариков.
Я же иду тоже довольно обыденным для веб-пентестера путем: регаюсь и изучаю весь функционал, клацаю кнопки, собираю информацию.
Спустя 5 минут активного изучения функционала нашего веб-приложения мы имеем на руках достаточно внушительный surface, с кучей разных урлок. Коли сижу в HTTP дебаггере, тут же и поищу то, что с наибольшей вероятностью меня заинтересует, загнав в search-поле всем знакомый /api/:
Потенциально интересные для нас пути, отфильтрованные в выводе дебаггера.
Любители автоматизации на этом этапе бы сказали, "хм, а что, если написать условный темплейтик под gf, и с помощью простого пайплайна собирать все потенциальные точки на дальнейшее изучение?". И были бы они вполне себе правы: к примеру, я использую такой же пайплайн на многодоменных системах, если есть настроение побагхантить. Или если имеется огромное количество URL.. все глазами не отсмотреть, и тут ручной краулинг уже не слишком подходит. Как пример, представим такой лайн:
echo "domain.xyz" | gau | uro | gf idor | httpx-toolkit -mc 200 -o idorpoints.txt
А потом(минутка лайфхаков) открыть, допустим, берп, и через его проксю прогнать это все действо =)
cat idorpoints.txt | while read url; do curl -x http://127.0.0.1:8080 -s "$url"; done
Подобная работа с ванлайнерами перенесет все потенциальные точки отсортированно и после дедупликации в наш Burp, а там изучим в target-разделе или в хттп хистори).
Читатели, полагаю, понимают, что этот мануал - вводная часть, а значит и уязва здесь будет на виду довольно тривиальная. Но не будем спойлерить: просмотрим эти реквесты.
И, вот же сюрприз, есть несколько потенциальных точек, которые... весьма интересны для нас, как для пентестеров =)
Интересный запрос.. просмотрев raw-вид, куки и возможные защитные хидеры, видим, что ничего не валидируется. Запрос может прийти при любых условиях.
Не увидев никаких хидеров в запросе, никаких куки, подтверждающих, что мы - это мы, мы видим конкретный параметр - user_id. Это обменник в телеграм-боте: очевидно, мы имеем дело с юзерайди нашего пользователя в телеграме. Перейдем в группу этого проекта, видим множество админов. Они и станут нашими испытуемыми. Ресерчерам и пентестерам же этот паттерн должен до боли напоминать любой книжный IDOR, в идеальных так сказать условиях.
Немножко быдло-OSINT: изучаем группу, смотрим юзерайди админов через любой из доступных тулов. Очевидно, админы могут юзать свой продукт на постоянной основе.
Цепляем один из любопытных айдишников иииииии... получаем вывод.
Книжный, иконичный IDOR. Отработал идеально. Все факторы - нарушенная/отсутствующая валидация и прямая ссыль на какой-то объект(данные) были соблюдены, мы молодцы и раскачали его сейчас на Information Disclosure - думаю, не каждый день обменник разливает платежные данные своих пользователей))0).
Понятное дело, что такая вулька откроет нам двери к какому-то подобию Credential Stuffing-атак - парсим тгшечку(их чат), собираем юзерайди и хоть через интрудер берпа начинаем рассыпать их внутрь, после чего полная бдшка будет собрана.
Изучим еще немного их апи-логики. И находим интересный эндпоинт, отвечающий за апдейт информации о пользователе - мыло, номер мобильника, никнейм. И снова третье сентября.. снова нет никаких малейших признаков валидации, от кого, куда и зачем этот реквест идет.
Копируем запрос как при легитимном использовании этого эндпоинта, и пробуем кому-то что-то поменять. Иииииии. Да.
Успех. В этот раз мы видим яркую демонстрацию явления Broken Access Control - валидация нарушена, и, пусть мы не обладаем полномочиями смотреть на данные напрямую, мы можем что-то изменять от лица других юзеров, что является крайне опасной ситуацией: например, подмени пароль через "Forgot Password", где на практике тоже часто встречаются подобные вещи, и учетка юзера твоя с корнями.
Часто встречаемые уязвимости в логике, особенно в эпоху ленивых разрабов и нейрослопа, выдаваемого за продукт, способный стоять на проде - это болезнь, которая может сделать вам немалый кеш. Помогайте компаниям улучшать их безопасность, не проходите мимо такого - может, вам тоже перепадет приятное вознаграждение =)
Сложно не заметить следующую тенденцию: во многих сегментах как относительно black-деятельности, так и bughunting-пространства в последнее время наступает печальная тенденция - люди "уперлись" в несколько тяжелых для таргетов, несомненно, уязвимостей вроде RCE и SQLi с готовыми эксплойтами/легкой эксплуатацией в целом, ленясь изучать таргеты вне этих "рамок". Несомненно, в массовой работе и сборе больших количеств профитных таргетов этот подход располагает огромными плюсами, но тем не менее, на многих таргетах люди в силу своего подхода(а он прост, проверили сканерами вроде окуня/отчекали по готовым нукли темплейтам) теряют, возможно, достаточно большой профит(и особенно критично это именно для багхантеров :D).
Речь пойдет как раз о таких вулях, на поиск которых многим нередко выделить немножко времени попросту лень: Insecure Direct Object Reference, Broken Access Control, семейка всевозможных, но вполне очевидных при должной сноровке вуль API.
Разберем на практическом примере мы с вами именно первые две вули - IDOR и BAC.
Предисловие: кого мы ловим?
Начнем с небольшой справочки по обоим вулям.
IDOR - вуля в наш век довольно нередкая(кто понял шуточку про гпт-кодерков, тот понял :D). И при своей относительной распространенности она куда опаснее многих столь же распространенных вуль(например, всевозможные XSSки, которые тож можно часто встретить). А суть вули может быть описана при этом довольно просто: глупая железка aka приложение какого-то черта использует вводимые нами, людишками, данные как прямую ссылку на какой-то объект данных(привет, всякие user_id=1337 и вся семейка хаев и критов в репортах хакервана). Но при этом всем должно быть одно особенное условие: приложение не должно проверять, а имеет ли вообще юзер на это полномочия или просит чужое/неправильное, на должном уровне. И в этом же условии кроется, кстать, полное для понимания описание BAC. Аномальное поведение, связанное с недостаточным/нарушенным контролем(валидацией).
То есть, допустим, вместо того, чтобы выдавать юзеру определенный объект(допустим, данные по учетке) по проверке тех же кук, апишка ожидает определенный id этого юзера, но никак это не проверяет - юзер с айдишкой 1337 просто кидает запрос, в котором подменяет свой идентификатор на идентификатор юзера с айдишкой 228 и видит его данные.
Это как если бы в школе у Васи и Пети были два шкафчика без замков, но с написанными именами. Или если бы были одинаковые ключи.. Вася просто откроет шкафчик Пети и тихо "найдет", что ему нужно.
Не удалось прогрузить медиа
Хорошая картинка, дающая достаточное понимание природы такой вули.
При этом всем, вуля достаточно сложна к обнаружению со стороны сокеров: сложно выявить в полотне логов аномальное поведение юзеров, которые юзают такую "фичу".
Методика поиска, эксплуатация
Понимаю, что вы здесь собрались совсем не за объяснениями, которых тонны на всех уважающих себя платформах. Так что перейдем к методике их поиска. Опишу я по большей части в этой статье именно ручной способ поиска таких дырищ, потому что именно полапав все руками можно понять, как это автоматизировать, понять саму природу вули. А автоматизация - вопрос грамотных рук =)
Ищем, как я сказал уже, вручную. Таргет для примера возьму чуть необычный - это Telegram-бот с имеющейся мини-аппкой. Этого не стоит бояться, скажу заранее тем кто опыта работы с такой штукой не имел - это тот же сайт в браузере, оставленном нам дядюшкой Дуровым внутри нашей излюбленной телеги.
Понадобится нам HTTP Debugger, 1 штука, Burp Suite, тоже 1 штука, и удобное рабочее место. Я предпочитаю работать с HTTP Debugger внутри виртуалки, чтобы не сломать свой XRay, который к их "decrypt ssl" очень чувствителен, но вы можете юзать и что-то другое. Допустим, мне удобно просто работать с браузером с парой экстеншенов: дефолтная лиса тоже неплохо справляется со своими задачками.
Без лишних слов открываем мини-аппку обменника, что я выбрал для демонстрации серьезности таких мисконфигураций, и идем в открытый заранее HTTP Debugger.
Клацаем все, что видим: методом ручного краулинга мы постепенно собираем наш surface для последующего исследования.
Не удалось прогрузить медиа
Не ленимся клацать, обновлять страницы, изучать доступный нам функционал: HTTP Debugger все снифает для нас, собирая Surface.
По факту, нам бы с легкостью хватило одного только домена, и HTTP Debugger можно закрывать: любители веб-пентеста сами потрясающе справляются, обладая потрясающими тулами вроде katana, gau и ffuf для любителей носить с собой пачку словариков.
Я же иду тоже довольно обыденным для веб-пентестера путем: регаюсь и изучаю весь функционал, клацаю кнопки, собираю информацию.
Спустя 5 минут активного изучения функционала нашего веб-приложения мы имеем на руках достаточно внушительный surface, с кучей разных урлок. Коли сижу в HTTP дебаггере, тут же и поищу то, что с наибольшей вероятностью меня заинтересует, загнав в search-поле всем знакомый /api/:
Не удалось прогрузить медиа
Потенциально интересные для нас пути, отфильтрованные в выводе дебаггера.
Любители автоматизации на этом этапе бы сказали, "хм, а что, если написать условный темплейтик под gf, и с помощью простого пайплайна собирать все потенциальные точки на дальнейшее изучение?". И были бы они вполне себе правы: к примеру, я использую такой же пайплайн на многодоменных системах, если есть настроение побагхантить. Или если имеется огромное количество URL.. все глазами не отсмотреть, и тут ручной краулинг уже не слишком подходит. Как пример, представим такой лайн:
echo "domain.xyz" | gau | uro | gf idor | httpx-toolkit -mc 200 -o idorpoints.txt
А потом(минутка лайфхаков) открыть, допустим, берп, и через его проксю прогнать это все действо =)
cat idorpoints.txt | while read url; do curl -x http://127.0.0.1:8080 -s "$url"; done
Подобная работа с ванлайнерами перенесет все потенциальные точки отсортированно и после дедупликации в наш Burp, а там изучим в target-разделе или в хттп хистори).
Читатели, полагаю, понимают, что этот мануал - вводная часть, а значит и уязва здесь будет на виду довольно тривиальная. Но не будем спойлерить: просмотрим эти реквесты.
И, вот же сюрприз, есть несколько потенциальных точек, которые... весьма интересны для нас, как для пентестеров =)
Не удалось прогрузить медиа
Интересный запрос.. просмотрев raw-вид, куки и возможные защитные хидеры, видим, что ничего не валидируется. Запрос может прийти при любых условиях.
Не увидев никаких хидеров в запросе, никаких куки, подтверждающих, что мы - это мы, мы видим конкретный параметр - user_id. Это обменник в телеграм-боте: очевидно, мы имеем дело с юзерайди нашего пользователя в телеграме. Перейдем в группу этого проекта, видим множество админов. Они и станут нашими испытуемыми. Ресерчерам и пентестерам же этот паттерн должен до боли напоминать любой книжный IDOR, в идеальных так сказать условиях.
Не удалось прогрузить медиа
Немножко быдло-OSINT: изучаем группу, смотрим юзерайди админов через любой из доступных тулов. Очевидно, админы могут юзать свой продукт на постоянной основе.
Цепляем один из любопытных айдишников иииииии... получаем вывод.
Не удалось прогрузить медиа
Книжный, иконичный IDOR. Отработал идеально. Все факторы - нарушенная/отсутствующая валидация и прямая ссыль на какой-то объект(данные) были соблюдены, мы молодцы и раскачали его сейчас на Information Disclosure - думаю, не каждый день обменник разливает платежные данные своих пользователей))0).
Понятное дело, что такая вулька откроет нам двери к какому-то подобию Credential Stuffing-атак - парсим тгшечку(их чат), собираем юзерайди и хоть через интрудер берпа начинаем рассыпать их внутрь, после чего полная бдшка будет собрана.
Изучим еще немного их апи-логики. И находим интересный эндпоинт, отвечающий за апдейт информации о пользователе - мыло, номер мобильника, никнейм. И снова третье сентября.. снова нет никаких малейших признаков валидации, от кого, куда и зачем этот реквест идет.
Копируем запрос как при легитимном использовании этого эндпоинта, и пробуем кому-то что-то поменять. Иииииии. Да.
Успех. В этот раз мы видим яркую демонстрацию явления Broken Access Control - валидация нарушена, и, пусть мы не обладаем полномочиями смотреть на данные напрямую, мы можем что-то изменять от лица других юзеров, что является крайне опасной ситуацией: например, подмени пароль через "Forgot Password", где на практике тоже часто встречаются подобные вещи, и учетка юзера твоя с корнями.
Часто встречаемые уязвимости в логике, особенно в эпоху ленивых разрабов и нейрослопа, выдаваемого за продукт, способный стоять на проде - это болезнь, которая может сделать вам немалый кеш. Помогайте компаниям улучшать их безопасность, не проходите мимо такого - может, вам тоже перепадет приятное вознаграждение =)
👍69
🔥11
🤔18
😢17
💯9