Дверь открыли либо он был открыт?
Эта статья посвящена случаям, которые произошли и публично доступны. Я поставил все ссылки с которых случаи взяты. Я не нарушаю закон, поскольку все это является публичным! Эта статья предназначена исключительно для образовательных целей. Пример, который будет приведен, относится не к странам СНГ.
- Паутина
- Дневник белой шляпы [Часть 1]: не DDoS
- Дневник белой шляпы [Часть 2]: Интервью [GraphQL]
- Дневник белой шляпы [Часть 3]: Cтажировкa [File Inclusion (Remote / Local)]
- Дневник белой шляпы [Часть 5]: Удачная догадка [RCE - Проверка простейших CVE, найденных в PHP-приложениях]
- Дневник белой шляпы [Часть 6]: Сообщение [Websockets + Tool]
- Дневник белой шляпы [Часть 7]: Ничего [JWT]
- Дневник белой шляпы [Часть 9]: Сертификат [eWPT]
- ОС
- Дневник белой шляпы [Часть 4]: Знания [PrivEsc - Linux Capabilities] [Повышение привилегий - Возможности Linux]
- OSINT
- Дневник белой шляпы [Часть 8]: Презентации [OSINT или Разведка ?]
Содержание
- Что такое нарушенный контроль доступа?
- Лаборатории
- Забудьте всё написанное выше
Что такое нарушенный контроль доступа?
Нарушенный контроль доступа - это уязвимость, при которой непривилегированный пользователь может выполнять привилегированные действия. Непривилегированным пользователем может быть кто угодно: незарегистрированные пользователи, зарегистрированные пользователи, модераторы, администраторы, у которых нет полных привилегий, и т.д. Привилегированными пользователями также могут быть все, кто имеет доступ к определенной части системы, к которой у других нет доступа. Это может быть конкретная страница, функция или что-то еще. Уязвимости с нарушенным контролем доступа в основном оцениваются в зависимости от важности информации и системы, в которой она была обнаружена.
Если мы взглянем на OWASP, то эта уязвимость окажется на первом месте. Это потому, что большинство разработчиков на самом деле забывают проверить эту уязвимость. Эта уязвимость связана не только с информацией, которую вы можете получить, но и с параметрами, которые вы действительно можете протестировать. Если пользователь по умолчанию может выполнить 10 действий на веб-сайте, то привилегированный пользователь, очевидно, может сделать намного больше. Чем больше действий, тем больше параметров, тем больше уязвимостей. Разве не забавно, когда разработчики пишут дополнительный код для исправления уязвимости, а дополнительный код содержит еще 2 уязвимости?
Передача конфиденциальной информации неавторизованному субъекту - это уязвимость, которую вы можете понять из самого названия. Эта уязвимость может возникнуть по разным причинам, начиная с неправильно сконфигурированного robots.txt файл и заканчивая параметрами, которые не проверяют привилегии пользователя.
Есть и другие уязвимости, связанные с этой, очевидно, что все они относятся к уязвимостям контроля доступа. Я дам краткое описание, чтобы вы могли понять. Вставка конфиденциальной информации в отправленные данные - это когда данные, запрошенные пользователем, содержат конфиденциальную информацию, которая не должна быть доступна этому пользователю. Хранение файла с конфиденциальными данными в Web Root - это уязвимость, с которой вы знакомы лучше, чем я) Это связано с тем, что данная уязвимость связана со страницами "index /", которые содержат конфиденциальные файлы без проверки контроля доступа. Принудительный просмотр - это уязвимость, при которой пользователь может получить доступ к конфиденциальным данным, просто введя URL-адрес. Помните о последней уязвимости, мы будем на нем фокусироваться!
Лаборатории
Лаборатория №1
Ссылка:[URL]https://portswigger.net/web-security/access-control/lab-unprotected-admin-functionality[/URL]Цель этой лабораторной работы - найти способ получить доступ к панели администратора. Ну, если бы это был настоящий веб-сайт, мы бы использовали другие методы. Если вы новичок, у вас на примете directory bruteforce, сениоры будут смеяться, я скажу, что directory bruteforce доказал свою эффективность в поиске PII. Личная идентифицирующая информация (PII) - это любой тип данных, которые могут быть использованы для идентификации кого-либо. В этой лаборатории все, что нам нужно сделать, это открыть robots.txt и получите доступ к админ-панели из указанного каталога.
![Изображение [1]: robots.txt](../../_assets/img/file_10c42de.jpg "Изображение [1]: robots.txt")
Изображение [1]: robots.txt
![Изображение [2]: Лаборатория решена](../../_assets/img/file_10c42bf.jpg "Изображение [2]: Лаборатория решена")
Изображение [2]: Лаборатория решена
Это всего лишь лаборатория, и даже ребенок может это сделать, верно? Это легко, не так ли? Если вы так думаете, то совершаете очень большую ошибку. Такого рода уязвимости существуют в реальных системах. Я покажу вам это в 3-eй части статьи.
Лаборатория №2
Ссылка: [URL]https://portswigger.net/web-security/access-control/lab-user-role-controlled-by-request-parameter[/URL]Цель этой лабораторной работы - получить доступ к панели администратора путем редактирования cookie. Cookie - это один из способов. Выглядит просто, не так ли? Опять же, дождитесь третьей части статьи)
![Изображение [3]: Проверка cookie](../../_assets/img/file_10c42a0.jpg "Изображение [3]: Проверка cookie")
Изображение [3]: Проверка cookie
![Изображение [4]: Редактирование cookie](../../_assets/img/file_10c4281.jpg "Изображение [4]: Редактирование cookie")
Изображение [4]: Редактирование cookie
![Изображение [5]: Лаборатория решена](../../_assets/img/file_10c4262.jpg "Изображение [5]: Лаборатория решена")
Изображение [5]: Лаборатория решена
Лаборатория №3
Ссылка:[URL]https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-data-leakage-in-redirect[/URL]Эта лабораторная работа посвящена уязвимости, из-за которой произошла утечка данных при перенаправлении 302. Обычно редиректы не содержат никакого текста. В этой лаборатории мы должны получить доступ к API-ключу пользователя carlos.
![Изображение [6]: Bход](../../_assets/img/file_10c4243.jpg "Изображение [6]: Bход")
Изображение [6]: Bход
![Изображение [7]: Лаборатория решена](../../_assets/img/file_10c3f99.jpg "Изображение [7]: Лаборатория решена")
Изображение [7]: Лаборатория решена
Лаборатория №4
Ссылка:[URL]https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-password-disclosure[/URL]Цель этой лабораторной работы - проанализировать исходный код открывая профиль администратора.
![Изображение [8]: Bход](../../_assets/img/file_10c3f7a.jpg "Изображение [8]: Bход")
Изображение [8]: Bход
![Изображение [9]: Лаборатория решена](../../_assets/img/file_10c3f5b.jpg "Изображение [9]: Лаборатория решена")
Изображение [9]: Лаборатория решена
Забудьте всё написанное выше
Все лаборатории, которые я привел в качестве примера, очевидно, взяты из реальных случаев, но у вас также должно быть "видение", чтобы понять, что и где может произойти. Я приведу примеры из реальной жизни и объясню их так, как я вижу, вы можете добавить то, что вы думаете, в комментариях.Забудьте все, что я написал выше, за исключением уязвимостей лабораторий. Первая лабораторная работа посвящена доступу к каталогу, в котором отсутствует правильная проверка контроля доступа. Но как нам найти этот каталог? Действительно может robots.txt помочь нам? Очевидно, что это возможно, но не в большинстве случаев, поэтому хорошо иметь контрольный список того, что мы должны сделать. Итак, что же мы на самом деле можем и должны делать? Хорошо, давайте предположим, что мы хотим внести свой вклад в безопасность систем, участвуя в программах VDP. В этом случае, если мы сосредоточимся на уязвимостях контроля доступа, как это в основном делаю я, мы сначала должны понять нашу область применения (scope). Давайте представим, что наша программа VDP позволяет нам протестировать все поддомены домена. Итак, во-первых, мы должны использовать amass. Мне все равно, какие мифы вы слышали от ultra pro extra хакерах, когда дело касается Access Control хакер это я, у вас должен быть сервер и вы должны настроить amass там, так как он может работать даже 3 дня, если масштаб большой, также вы должны понимать, что amass - это инструмент, который даст вам больше результата, чем что-либо другое. Затем вам нужно найти системы, которые не дадут вам выполнять действия без входа в систему, поскольку это те системы, которые наверняка будут уязвимы для уязвимостей контроля доступа, если вы знаете, где искать. В-третьих, что вам нужно сделать, так это найти каталоги, которые не видны обычным посетителям, открывающим веб-сайт.
Важность и реальность
Давайте проанализируем репорты хакеров, которым удалось обнаружить уязвимости в системе контроля доступа и получить доступ к конфиденциальной информации.Отчет № 1:
https://hackerone.com/reports/1938693Дата: 7 Aпреля 2023 года
Итак, парень просто ввел admin/admin и вошел в систему. Реальный вопрос, стоящий за этой атакой, заключается в том, как он нашел систему, с помощью которой он может это протестировать. Как ему удалось найти именно этот уязвимый домен? И эта уязвимость была обнаружена в Министерстве обороны США.
Отчет № 2:
https://hackerone.com/reports/1690548Дата: 3 Cентября 2022 года
MegaKrutoyXacker сказал(а):
Этот парень в основном перехватывал ответы на свои запросы и редактировал код статус код. Если вы правильно прочитали мою статью, то это случай из лаборатории № 2, но вместо cookie этот парень отредактировал статус код. Кстати, этот метод очень популярен. Вопрос тот же самый. Как ему удалось найти именно этот уязвимый домен? Эта уязвимость была обнаружена в Военно-воздушных силах США.
Отчет № 3:
https://hackerone.com/reports/1394910Дата: 8 ноября 2021 года
В этом случае парень просто проверил исходный код запроса с статус кодом 302 и обнаружил конфиденциальную информацию. На самом деле это из нашей лаборатории № 4. Вопрос остается открытым. Как ему удалось найти именно этот уязвимый домен? Эта уязвимость была обнаружена в Министерстве обороны США.
Большинство из вас увидят даты и скажут, что это редкая проблема, нет, это не так, проблема в том, что большинство отчетов недоступны для общественности, и я могу поспорить, что большинство из них касаются контроля доступа. Для каждого опытного человека поиск этих уязвимых доменов - это просто работа, которую они уже автоматизировали. Для этого существуют различные способы, и я объясню один из них.
Подготовка лаборатории
Вы должны установить amass, httpx и waybackurls.Установка amass:
Bash:
wget https://github.com/owasp-amass/amass/releases/download/v4.2.0/amass_Linux_amd64.zip
unzip amass_Linux_amd64.zip
sudo cp amass_Linux_amd64/amass /usr/bin/amassУстановка httpx:
Bash:
wget https://github.com/projectdiscovery/httpx/releases/download/v1.3.4/httpx_1.3.4_linux_amd64.zip
unzip httpx_1.3.4_linux_amd64.zip
sudo cp httpx /usr/bin/httpxУстановка waybackurls:
Bash:
wget https://github.com/tomnomnom/waybackurls/releases/download/v0.1.0/waybackurls-linux-amd64-0.1.0.tgz
tar xvf waybackurls-linux-amd64-0.1.0.tgz
sudo cp waybackurls /usr/bin/waybackurlsКак я уже говорил ранее, поиск этих доменов - это просто используемый метод, вы также могли бы использовать aquatone вместо httpx, но, я думаю, этот способ проще. Сначала мы должны найти все поддомены определенного домена. Я предпочитаю использовать для этого простую команду amass:
Bash:
amass enum -d xss.proПолучив список поддоменов, мы должны найти те, которые являются живыми, и сделать скриншот доменов life. На самом деле наша цель здесь - найти панели входа в систему / администратора. Мы можем делать это различными способами, от создания скриншотов до автоматизации процесса путем анализа исходных кодов. Подобно тому, как мы можем выполнять поиск по определенным ключевым словам, значениям или проверять используемые методы, для входа в систему следует использовать метод POST. Но проверка исходного кода не всегда может сработать, так как не во всех случаях вы найдете эти данные, поэтому я предпочитаю проверять скриншоты.
После получения страниц входа в систему мы также можем использовать различные методы, но я очень предпочитаю waybackurls. Waybackurls будет собирать URL-адреса с wayback machine, это позволит нам видеть определенные каталоги, которые не видны обычным пользователям, и эти каталоги могут содержать конфиденциальную информацию. Это не сказка, это реальность.
Метод первый: получение поддоменов, проверка того, живы ли они, снятие скриншотов и использование wayback machine
Метод второй: получение поддоменов, проверка, активны ли они, сохранение статус кодов и использование wayback machine - в этом случае мы можем получать перенаправления, содержащие конфиденциальную информацию, или даже сможем обойти 403, если он отображается непосредственно на главной странице.
Использование httpx:
https://github.com/projectdiscovery/httpxИспользование amass: либо
https://medium.com/@BrownBearSec/how-to-actually-use-amass-more-effectively-bug-bounty-59e83900de02 либо
Bash:
amass enum -d xss.pro
Bash:
waybackurls xss.pro > xss.txtЕсли не верите тому чта я отписал, прошу ваш метод в комментах ультра мега про хацкеры)
Теперь вы лучше понимаете, откуда *на самом деле* берутся эти уязвимые домены, и вы можете делать то же самое, участвовать в VDP и поддерживать компании / организации. Повсюду нарушенный контроль доступа и вход это миф. Я и тут находил эту уязвимость:
https://xss.pro/threads/97211/. Вы скажете ну и что, это не министерство обороны, да вы правы, этот сайт более безопасен.С уважением grozdniyandy
Специально для xss.pro
Последнее редактирование:
