Привет, codeby!
В данной статье будет рассмотрена тема забытых файлов на сервере, устаревших файлов, бэкапов, временых файлов и тех, которые в принципе не должны быть доступны обычным пользователям из браузера. Рассмотрим угрозы, которые таят эти файлы и способы поиска таких файлов. Так же затронем тему поиска административных интерфейсов и подбора к ним учетных данных.
Хотя большинство файлов на веб-сервере обрабатываются им и нужны для работы приложения, зачастую на сервере можно обнаружить забытые, временные, неиспользуемые файлы, бэкапы, в которых может содержаться чувствительная информация.
Кроме того, что в результате раскрытия исходников серверного кода злоумышленник получает информацию о структуре сервера, настройках и логике приложения, не редки сценарии, когда прямо в коде содержатся имена пользователей и пароли в открытом виде.
Иногда, осуществляя поиск забытых и старых файлов, на сервере можно обнаружить бэкдоры и альтернативные административные интерфейсы.
Одним из источников уязвимостей являются файлы, которые создаются автоматически в результате редактирования файлов приложения. Для того, что бы убедиться в этом, создайте у себя на компьютере новый файл test и откройте его для редактирования в любом текстовом редакторе, например в vim:
В другом окне терминала введите команду ls -a:
в директории test, кроме созданного нами файла появился другой файл - .test.swp.
После того, как мы закроем редактор, файл test.swp автоматически будет удален, но по разным причинам удаление происходит не всегда. Из этого следует, что редактировать файлы веб-приложения прямо на сервере — это плохая идея.
В примере ниже мы хотя и не имеем возможности прочитать файл с расширением .swp, все равно получаем некоторую информацию о файловой системе сервера:
Временные файлы, как правило, являются скрытыми. Поэтому на данном ftp-сервере (скрин ниже) среди прочих файлов найти файл с расширением .swp не удалось:
Но имея названия файлов мы можем предположить, как будут называться соответствующие им временные файлы. Раз существует файл i_Investigation.txt, то есть вероятность, что он редактировался на сервере и в результате был создан временный файл, который скрыт от нас и браузера. Попробуем обратиться к файлу с именем .i_Investigation.txt.swp напрямую через адресную строку:
Как видим, такой файл действительно существует и мы можем его скачать.
Иногда копии файлов на сервере создаются вручную. Например при внесении изменений в файл settings.php разработчик захотел сохранить старую версию файла на случай, если захочет быстро вернуться к старым настройкам. Для этого перед внесением изменений он создал копию файла settings.php и назвал ее settings.php.old. Веб-сервер обрабатывает файл settings.php как приложение и не предоставляет доступ к его исходному коду:
А файл settings.php.old, так как имеет другое расширение, интерпретируется сервером как простой текст, в результате чего раскрывается исходный код файла:
Другой причиной возникновения уязвимостей, связанных со скрытыми файлами в директориях веб-приложения, являются особенности архитектуры или конфигурции приложений. Часто в директориях приложений находятся файлы настроек, логи, файлы с данными, хотя видимых причин на то, что бы хранить их там — нет.
Какие угрозы несут в себе такие файлы.
1. Файлы бэкапов, временные файлы и т.д. могут раскрывать конфиденциальную информацию, которая может способствовать атаке на веб-приложение. Например файлы, которые содержат учетные данные для доступа к СУБД, файлы конфигурации, содержащие ссылки на другое скрытое содержимое, абсолютные пути к файлам и т. д.
2. Скрытые веб-страницы могут содержать мощные функциональные возможности, которые можно использовать для атаки на приложение. Например, страница администрирования, которая не связана напрямую с веб-приложением, но может быть доступна любому пользователю, который знает, где ее найти.
В примере ниже в исходном коде мы обнаружили ссылку на админку:
Но при попытке доступа к админке потерпели неудачу:
Что ж, выполним поиск файлов в директории /admin1:
Найдена какая-то совсем старая версия html-страницы, имеющая административные функции. Весьма вероятно, что она содержит уязвимости:
3. Старые версии файлов приложения, которые могут содержать уязвимости, исправленные в поздних версиях. Например файл viewdoc.old.jsp содержит уязвимость, которая была исправлена в новой версии файла viewdoc.jsp. Но если файл viewdoc.old.jsp все еще доступен из сети и может быть найден посторонними, то и уязвимость в нем все еще может быть проэксплуатирована.
4. Резервные копии файлов могут раскрывать исходный код, предназначенный для выполнения на сервере. Например файл viewdoc.bak может вернуть исходный код файла viewdoc.jsp. Проанализировав исходный код можно выявить уязвимости, которые трудно выявить при выполнении слепых запросов к исполняемому файлу.
5. Иногда резервные копии приложения помещаются в архив. Если архив будет доступен для скачивания напрямую через браузер, то к злоумышленникам могут попасть все файлы веб приложения. В результате ему будет легко определить структуру приложения, изучить исходные коды, файлы конфигурации.
6. Часто при создании копии файла изменяется не расширение файла, а его имя. Например к имени settings.php может добавиться префикс copy_ и получится copy_settings.php. Так как в этом случае расширение остается неизменным, исходный код файла раскрыт не будет. Но старая копия файла может иметь устаревшую или неправильную логику. Выполнение такого файла может вызвать ошибку в приложении, в результате которой будет раскрыта ценная информация.
7. Log-файлы могут содержать информацию о действиях пользователей приложения, о посещаемых ими url-адресах (в том числе скрытых), cookie и другие идентификаторы, ip-адреса пользователей, конфиденциальные данные пользователей, если они передаются в url, информацию об ошибках приложения и т.д.
8. Вышесказанное относится и к снимкам файловой системы, которые могут создаваться автоматически. Например файл /.snapshot/view.php может содержать уязвимость, которая исправлена в более поздней версии /view.php, и может быть проэксплуатирована любым, кто обнаружит снимки.
Как искать.
Поиск файлов без ссылок можно выполнять как вручную, так и автоматизированными инструментами. Рассмотрим некоторые способы.
Для начала, обратите внимание на то, как именуются фалы и директории в приложении и на основе этого сделайте выводы. Например, если вы обнаружили директорию /app /user/, то имеет смыл поискать директории с именами /app /admin/, /app /manager/. Если в приложении существует файл viewuser.asp, то нужно поискать файлы с названиями edituser.asp, adduser.asp, deleteuser.asp.
Ссылки на скрытый контент можно обнаружить в файле robots.txt и в исходном коде веб-страниц и js-файлов, как в одном из примеров выше:
Другой способ - слепое угадывание имен файлов и каталогов. Предполагаем существование какого-либо каталога или файла, отправляем запрос на сервер в попытке получить доступ к этому каталогу, и если от сервера пришел ответ с кодом 200, то чаще всего это означает, что запрошенный ресурс существует (за исключением случаев, когда приложение возвращает кастомную страницу 404, но в ответе сервера все равно возвращается код 200). Так же имейте ввиду, что коды 301 (Moved), 302(Found), 401 (Unauthorized), 403(Forbidden) и 500(Internal error) могут указывать на существование запрашиваемого ресурса.
Для автоматизации тестирования можно использовать утилиту dirb, которая была рассмотрена в предыдущих статьях, или OWASP Zap, который имеет встроенный фазер с широкими возможностями.
Для уточнения поиска используйте имена уже найденных файлов. Добавляйте к ним префикс, например copy_index.php или _index.php. Добавляейте расширения — index.php.bak. Меняйте расширения местами — index.bak.php. Используйте другое расширение вместо фактического — index.old.
Один из способов найти скрытые файлы — это найти директории в приложении, которые позволяют листинг:
Данной уязвимости подвержено множество веб-приложений и веб-серверов.
Например CVE-2000-0869 (
CVE-2005-3293 (
CVE-2008-1606 (
CVE-2018-12524 (
Так же поиск скрытых файлов, на которые нет ссылок в целевом веб-приложении, можно выполнить в поисковых системах. Если администратор удалил на сайте все ссылки на старую версию файла index1.php, но сам файл остался на сервере, то можно отыскать этот файл в индексе или кэше поисковых систем.
Ко всему вышесказанному хотел бы чуть больше добавить о поиске административных интерфейсов.
Уже на всех предыдущих этапах пентеста, в том числе на этапе поиска файлов, которые должны быть скрыты от обычных пользователей, мы часто можем обнаружить административные интерфейсы. Ранее мы выполняли поиск скрытых директорий с помощью dirb, использовали сканер уязвимостей Nikto, сканировали открытые порты, искали информацию в поисковиках — все это должно было дать существенный результат.
Ко всему, что уже было проделано, не помешает изучить документацию к серверному ПО и к веб-приложению (если она имеется), если это возможно, то изучить в открытых источниках структуру приложения, что бы узнать пути к админкам по умолчанию. Например стандартными путями к административным интерфейсам CMS WordPress являются /wp-login или /wp-admin:
Так же на предыдущих шагах вы сканировали веб-сервер на наличие открытых портов и определяли запущенные на этих портах службы. Возможно, что на альтернативных портах будут располагаться альтернативные админки:
Если найденные административные интерфейсы требуют логин и пароль, на следующем шаге мы можем попытаться их подобрать.
Для начала, составьте список имен (логинов), которые наиболее вероятны в контексте целевого веб-приложения. Это могут быть имена и ники админов сайта, модераторов, владельцев, службы поддержки и других причастных пользователей. Включите в этот список стандартные логины, такие как admin, administrator, root, test, user. Используя этот список и словарь вероятных паролей можно приступать к брутфорсу.
Для брута подойдут такие инструменты, как:
THC Hydra (Брутфорс веб-сайтов с Hydra (часть вторая инструкции по Hydra)) — подходит для онлайн-брута почти всего. Можно подбирать пароли к ssh, telnet, smtp, rdp и десяткам других протоколов. Так же есть возможность брутить веб-формы.
Burp Suite ([2] Burp Suite: Атаки с помощью Intruder) - очень удобный инструмент для пентеста, в том числе и для брута веб-форм. Но в версии free брут идет слишком медленно.
WPScan (
Metasploit — некоторые его модули позволяют выполнять брутфорс разных интерфейсов.
Я вам покажу, как можно брутить веб-формы с OWASP Zap. В качестве подопытного возьмем уязвимое веб-приложение OWASP Mutillidae II. Вот его форма логина:
Попробуем ввести какие-нибудь произвольные учетные данные, например root:root :
Веб-приложение ответило нам, что такого аккаунта не существует. Попробуем другие данные — admin:root :
Теперь приложение говорит, что введен неверный пароль. Делаем вывод, что пользователь admin существует.
Далее будем использовать перехватывающий прокси OWASP Zap.
Отправим последний запрос из браузера еще раз и рассмотрим его в ZAP:
В теле POST-запроса отправляется три параметра со значениями. Два из них (username и login-php-submit-button) будут всегда оставаться неизменными, а значение параметра password мы будем менять перед каждым отправлением запроса на сервер.
Мы это сделаем с помощью инструмента Fuzz, встроенного в ZAP. Выделяем значение параметра password и вызываем контекстное меню. В меню выбираем Fuzz:
Открылось окно настроек фазера. Значение root параметра password уже выделено цветом. В ту область в запросе, которая выделена цветом, фазером будут подставляться другие значение. Эту настройку можно менять, можно добавить одновременно несколько таких точек для подстановки значений, но сейчас это ни к чему. Нам нужно только указать словарь, которым будем брутить.
Жмем payloads:
Жмем add:
В новом окне в выпадающем списке (сверху) выбираем File и в поле File указываем путь до нашего словаря с паролями. Жмем Add и Ok.
Теперь нажимаем кнопку Start Fuzzer и ждем результата:
Смотрим на скриншот выше.
Во-первых, ответ на запрос, в котором в качестве пароля отправлялось значение «admin», пришел с кодом ответа 302, в то время как все остальные ответы приходили с кодом 200. Во-вторых, начиная с запроса с паролем «admin», размер возвращаемой страницы изменился. Из этого можем сделать вывод, что мы залогинились в системе с учетными данными admin:admin.
Проверьте на возможность подбора паролей все найденые админ. интерфейсы. Это могут быть:
- вход в административную панель веб-приложения
- входы в панели управления веб-сервером, базами данных которые могут быть запущены на альтернативных портах(например phpMyAdmin)
- вход в веб-почту
- вход в другие веб-приложения, которые косвенно или прямо связаны с целевым веб-приложением
- вход в другие сервисы, работающие на сервере, такие как telnet, ssh, ftp, smtp, rdp и так далее
В ходе брутфорса могут возникнуть сложности, связанные с тем, что WAF или другая система защиты на сервере блокирует попытки подбора паролей. В таком случае можно попытаться обойти WAF, часто меняя свои IP-адреса, уменьшая количество потоков, увеличивая время между запросами.
В целом брутфорс паролей все еще может давать хорошие результаты, так как админы порой просто забывают, что у них в системе остался юзер с именем test и паролем test, и к тому же люди как были, так и остаются слишком ленивыми для того, что бы придумывать сложные пароли.
На сегодня у меня все, всем пока! )
В данной статье будет рассмотрена тема забытых файлов на сервере, устаревших файлов, бэкапов, временых файлов и тех, которые в принципе не должны быть доступны обычным пользователям из браузера. Рассмотрим угрозы, которые таят эти файлы и способы поиска таких файлов. Так же затронем тему поиска административных интерфейсов и подбора к ним учетных данных.
Как стать хакером и Как взломать сайт: беглое знакомство с OWASP Testing Guide.
Введение в пентест веб-приложений: Поиск утечек информации с помощью поисковых систем.
Пентест веб-приложений: Определение веб-сервера. Robots.txt. Определение приложений на веб-сервере.
Пентест веб-приложений: Исследование исходного кода веб-страниц. Определение точек входа. Карта приложения.
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.
Пентест веб-приложений: Тестирование конфигурации инфраструктуры приложения. Расширения файлов.
Введение в пентест веб-приложений: Поиск утечек информации с помощью поисковых систем.
Пентест веб-приложений: Определение веб-сервера. Robots.txt. Определение приложений на веб-сервере.
Пентест веб-приложений: Исследование исходного кода веб-страниц. Определение точек входа. Карта приложения.
Пентест веб-приложений: Определение фреймворка и веб-приложения. Карта архитектуры приложения.
Пентест веб-приложений: Тестирование конфигурации инфраструктуры приложения. Расширения файлов.
Хотя большинство файлов на веб-сервере обрабатываются им и нужны для работы приложения, зачастую на сервере можно обнаружить забытые, временные, неиспользуемые файлы, бэкапы, в которых может содержаться чувствительная информация.
Кроме того, что в результате раскрытия исходников серверного кода злоумышленник получает информацию о структуре сервера, настройках и логике приложения, не редки сценарии, когда прямо в коде содержатся имена пользователей и пароли в открытом виде.
Иногда, осуществляя поиск забытых и старых файлов, на сервере можно обнаружить бэкдоры и альтернативные административные интерфейсы.
Одним из источников уязвимостей являются файлы, которые создаются автоматически в результате редактирования файлов приложения. Для того, что бы убедиться в этом, создайте у себя на компьютере новый файл test и откройте его для редактирования в любом текстовом редакторе, например в vim:
В другом окне терминала введите команду ls -a:
в директории test, кроме созданного нами файла появился другой файл - .test.swp.
После того, как мы закроем редактор, файл test.swp автоматически будет удален, но по разным причинам удаление происходит не всегда. Из этого следует, что редактировать файлы веб-приложения прямо на сервере — это плохая идея.
В примере ниже мы хотя и не имеем возможности прочитать файл с расширением .swp, все равно получаем некоторую информацию о файловой системе сервера:
Временные файлы, как правило, являются скрытыми. Поэтому на данном ftp-сервере (скрин ниже) среди прочих файлов найти файл с расширением .swp не удалось:
Но имея названия файлов мы можем предположить, как будут называться соответствующие им временные файлы. Раз существует файл i_Investigation.txt, то есть вероятность, что он редактировался на сервере и в результате был создан временный файл, который скрыт от нас и браузера. Попробуем обратиться к файлу с именем .i_Investigation.txt.swp напрямую через адресную строку:
Как видим, такой файл действительно существует и мы можем его скачать.
Иногда копии файлов на сервере создаются вручную. Например при внесении изменений в файл settings.php разработчик захотел сохранить старую версию файла на случай, если захочет быстро вернуться к старым настройкам. Для этого перед внесением изменений он создал копию файла settings.php и назвал ее settings.php.old. Веб-сервер обрабатывает файл settings.php как приложение и не предоставляет доступ к его исходному коду:
А файл settings.php.old, так как имеет другое расширение, интерпретируется сервером как простой текст, в результате чего раскрывается исходный код файла:
Другой причиной возникновения уязвимостей, связанных со скрытыми файлами в директориях веб-приложения, являются особенности архитектуры или конфигурции приложений. Часто в директориях приложений находятся файлы настроек, логи, файлы с данными, хотя видимых причин на то, что бы хранить их там — нет.
Какие угрозы несут в себе такие файлы.
1. Файлы бэкапов, временные файлы и т.д. могут раскрывать конфиденциальную информацию, которая может способствовать атаке на веб-приложение. Например файлы, которые содержат учетные данные для доступа к СУБД, файлы конфигурации, содержащие ссылки на другое скрытое содержимое, абсолютные пути к файлам и т. д.
2. Скрытые веб-страницы могут содержать мощные функциональные возможности, которые можно использовать для атаки на приложение. Например, страница администрирования, которая не связана напрямую с веб-приложением, но может быть доступна любому пользователю, который знает, где ее найти.
В примере ниже в исходном коде мы обнаружили ссылку на админку:
Но при попытке доступа к админке потерпели неудачу:
Что ж, выполним поиск файлов в директории /admin1:
Найдена какая-то совсем старая версия html-страницы, имеющая административные функции. Весьма вероятно, что она содержит уязвимости:
3. Старые версии файлов приложения, которые могут содержать уязвимости, исправленные в поздних версиях. Например файл viewdoc.old.jsp содержит уязвимость, которая была исправлена в новой версии файла viewdoc.jsp. Но если файл viewdoc.old.jsp все еще доступен из сети и может быть найден посторонними, то и уязвимость в нем все еще может быть проэксплуатирована.
4. Резервные копии файлов могут раскрывать исходный код, предназначенный для выполнения на сервере. Например файл viewdoc.bak может вернуть исходный код файла viewdoc.jsp. Проанализировав исходный код можно выявить уязвимости, которые трудно выявить при выполнении слепых запросов к исполняемому файлу.
5. Иногда резервные копии приложения помещаются в архив. Если архив будет доступен для скачивания напрямую через браузер, то к злоумышленникам могут попасть все файлы веб приложения. В результате ему будет легко определить структуру приложения, изучить исходные коды, файлы конфигурации.
6. Часто при создании копии файла изменяется не расширение файла, а его имя. Например к имени settings.php может добавиться префикс copy_ и получится copy_settings.php. Так как в этом случае расширение остается неизменным, исходный код файла раскрыт не будет. Но старая копия файла может иметь устаревшую или неправильную логику. Выполнение такого файла может вызвать ошибку в приложении, в результате которой будет раскрыта ценная информация.
7. Log-файлы могут содержать информацию о действиях пользователей приложения, о посещаемых ими url-адресах (в том числе скрытых), cookie и другие идентификаторы, ip-адреса пользователей, конфиденциальные данные пользователей, если они передаются в url, информацию об ошибках приложения и т.д.
8. Вышесказанное относится и к снимкам файловой системы, которые могут создаваться автоматически. Например файл /.snapshot/view.php может содержать уязвимость, которая исправлена в более поздней версии /view.php, и может быть проэксплуатирована любым, кто обнаружит снимки.
Как искать.
Поиск файлов без ссылок можно выполнять как вручную, так и автоматизированными инструментами. Рассмотрим некоторые способы.
Для начала, обратите внимание на то, как именуются фалы и директории в приложении и на основе этого сделайте выводы. Например, если вы обнаружили директорию /app /user/, то имеет смыл поискать директории с именами /app /admin/, /app /manager/. Если в приложении существует файл viewuser.asp, то нужно поискать файлы с названиями edituser.asp, adduser.asp, deleteuser.asp.
Ссылки на скрытый контент можно обнаружить в файле robots.txt и в исходном коде веб-страниц и js-файлов, как в одном из примеров выше:
Другой способ - слепое угадывание имен файлов и каталогов. Предполагаем существование какого-либо каталога или файла, отправляем запрос на сервер в попытке получить доступ к этому каталогу, и если от сервера пришел ответ с кодом 200, то чаще всего это означает, что запрошенный ресурс существует (за исключением случаев, когда приложение возвращает кастомную страницу 404, но в ответе сервера все равно возвращается код 200). Так же имейте ввиду, что коды 301 (Moved), 302(Found), 401 (Unauthorized), 403(Forbidden) и 500(Internal error) могут указывать на существование запрашиваемого ресурса.
Для автоматизации тестирования можно использовать утилиту dirb, которая была рассмотрена в предыдущих статьях, или OWASP Zap, который имеет встроенный фазер с широкими возможностями.
Для уточнения поиска используйте имена уже найденных файлов. Добавляйте к ним префикс, например copy_index.php или _index.php. Добавляейте расширения — index.php.bak. Меняйте расширения местами — index.bak.php. Используйте другое расширение вместо фактического — index.old.
Один из способов найти скрытые файлы — это найти директории в приложении, которые позволяют листинг:
Данной уязвимости подвержено множество веб-приложений и веб-серверов.
Например CVE-2000-0869 (
Ссылка скрыта от гостей
) — веб-сервер Apache 1.3.12, по умолчанию предустановленный в SuSE Linux 6.4, включает в себя WebDAV, который позволяет злумышленнику получать названия каталогов с помощью HTTP-метода PROPFIND.CVE-2005-3293 (
Ссылка скрыта от гостей
) — веб-сервер Xerver 4.17 позволяет получить исходный код выполняемых скриптов с помощью запроса, который завершается символом «.» (точка) и получить список содержимого каталога, завершив запрос символом «%00».CVE-2008-1606 (
Ссылка скрыта от гостей
) — множественные уязвимости в Elastic Path 4.1 и 4.1.1 (ecommerce-система) повзоляют злоумышленнику загружать произвольные файлы на сервер, скачивать файлы с сервера, просматривать содержимое каталогов и файлов на сервере.CVE-2018-12524 (
Ссылка скрыта от гостей
) и еще несколько аналогичных уязвимостей в MadDash (Monitoring and Debugging Dashboard) позволяют с помощью прямого запроса к каталогам получать список их содержимого.Так же поиск скрытых файлов, на которые нет ссылок в целевом веб-приложении, можно выполнить в поисковых системах. Если администратор удалил на сайте все ссылки на старую версию файла index1.php, но сам файл остался на сервере, то можно отыскать этот файл в индексе или кэше поисковых систем.
Ко всему вышесказанному хотел бы чуть больше добавить о поиске административных интерфейсов.
Уже на всех предыдущих этапах пентеста, в том числе на этапе поиска файлов, которые должны быть скрыты от обычных пользователей, мы часто можем обнаружить административные интерфейсы. Ранее мы выполняли поиск скрытых директорий с помощью dirb, использовали сканер уязвимостей Nikto, сканировали открытые порты, искали информацию в поисковиках — все это должно было дать существенный результат.
Ко всему, что уже было проделано, не помешает изучить документацию к серверному ПО и к веб-приложению (если она имеется), если это возможно, то изучить в открытых источниках структуру приложения, что бы узнать пути к админкам по умолчанию. Например стандартными путями к административным интерфейсам CMS WordPress являются /wp-login или /wp-admin:
Так же на предыдущих шагах вы сканировали веб-сервер на наличие открытых портов и определяли запущенные на этих портах службы. Возможно, что на альтернативных портах будут располагаться альтернативные админки:
Если найденные административные интерфейсы требуют логин и пароль, на следующем шаге мы можем попытаться их подобрать.
Для начала, составьте список имен (логинов), которые наиболее вероятны в контексте целевого веб-приложения. Это могут быть имена и ники админов сайта, модераторов, владельцев, службы поддержки и других причастных пользователей. Включите в этот список стандартные логины, такие как admin, administrator, root, test, user. Используя этот список и словарь вероятных паролей можно приступать к брутфорсу.
Для брута подойдут такие инструменты, как:
THC Hydra (Брутфорс веб-сайтов с Hydra (часть вторая инструкции по Hydra)) — подходит для онлайн-брута почти всего. Можно подбирать пароли к ssh, telnet, smtp, rdp и десяткам других протоколов. Так же есть возможность брутить веб-формы.
Burp Suite ([2] Burp Suite: Атаки с помощью Intruder) - очень удобный инструмент для пентеста, в том числе и для брута веб-форм. Но в версии free брут идет слишком медленно.
WPScan (
Ссылка скрыта от гостей
Ссылка скрыта от гостей
- если тестируемое приложение создано на основе CMS WordPress, брут админки можно выполнить с помощью этой утилиты. Для этой же цели можно использовать WPSeku (WPSeku-простой сканер тестирования Wordpress).Metasploit — некоторые его модули позволяют выполнять брутфорс разных интерфейсов.
Я вам покажу, как можно брутить веб-формы с OWASP Zap. В качестве подопытного возьмем уязвимое веб-приложение OWASP Mutillidae II. Вот его форма логина:
Попробуем ввести какие-нибудь произвольные учетные данные, например root:root :
Веб-приложение ответило нам, что такого аккаунта не существует. Попробуем другие данные — admin:root :
Теперь приложение говорит, что введен неверный пароль. Делаем вывод, что пользователь admin существует.
Далее будем использовать перехватывающий прокси OWASP Zap.
Нам нужно сделать так, что бы все общение браузера и сервера происходило через перехватывающий прокси, в данном случае это ZAP.
После того, как вы запустили ZAP, нужно пройти в настройки браузера и изменить настройки прокси. Для браузера Firefox должно быть, как на скриншоте:
После того, как вы запустили ZAP, нужно пройти в настройки браузера и изменить настройки прокси. Для браузера Firefox должно быть, как на скриншоте:
Отправим последний запрос из браузера еще раз и рассмотрим его в ZAP:
В теле POST-запроса отправляется три параметра со значениями. Два из них (username и login-php-submit-button) будут всегда оставаться неизменными, а значение параметра password мы будем менять перед каждым отправлением запроса на сервер.
Мы это сделаем с помощью инструмента Fuzz, встроенного в ZAP. Выделяем значение параметра password и вызываем контекстное меню. В меню выбираем Fuzz:
Открылось окно настроек фазера. Значение root параметра password уже выделено цветом. В ту область в запросе, которая выделена цветом, фазером будут подставляться другие значение. Эту настройку можно менять, можно добавить одновременно несколько таких точек для подстановки значений, но сейчас это ни к чему. Нам нужно только указать словарь, которым будем брутить.
Жмем payloads:
Жмем add:
В новом окне в выпадающем списке (сверху) выбираем File и в поле File указываем путь до нашего словаря с паролями. Жмем Add и Ok.
Теперь нажимаем кнопку Start Fuzzer и ждем результата:
Смотрим на скриншот выше.
Во-первых, ответ на запрос, в котором в качестве пароля отправлялось значение «admin», пришел с кодом ответа 302, в то время как все остальные ответы приходили с кодом 200. Во-вторых, начиная с запроса с паролем «admin», размер возвращаемой страницы изменился. Из этого можем сделать вывод, что мы залогинились в системе с учетными данными admin:admin.
Проверьте на возможность подбора паролей все найденые админ. интерфейсы. Это могут быть:
- вход в административную панель веб-приложения
- входы в панели управления веб-сервером, базами данных которые могут быть запущены на альтернативных портах(например phpMyAdmin)
- вход в веб-почту
- вход в другие веб-приложения, которые косвенно или прямо связаны с целевым веб-приложением
- вход в другие сервисы, работающие на сервере, такие как telnet, ssh, ftp, smtp, rdp и так далее
В ходе брутфорса могут возникнуть сложности, связанные с тем, что WAF или другая система защиты на сервере блокирует попытки подбора паролей. В таком случае можно попытаться обойти WAF, часто меняя свои IP-адреса, уменьшая количество потоков, увеличивая время между запросами.
В целом брутфорс паролей все еще может давать хорошие результаты, так как админы порой просто забывают, что у них в системе остался юзер с именем test и паролем test, и к тому же люди как были, так и остаются слишком ленивыми для того, что бы придумывать сложные пароли.
На сегодня у меня все, всем пока! )
Последнее редактирование:
