|
Здравствуй, античат !
Продолжаем пентест и сегодня научимся определять поставщика и версию веб-сервера, искать веб-приложения на сервере и взглянем на robots.txt. Не пренебрегайте разведкой, ибо как вы увидите в некоторых примерах в статье - это очень важная часть тестирования. Результаты, полученные на этом этапе могут сильно повлиять на ход дальнейшего тестирования. Определение веб-сервера. Сегодня на рынке имеется множество разных производителей и версий веб-серверов, вот список некоторых: Apache - свободный веб-сервер, наиболее часто используемый в UNIX-подобных операционных системах nginx- свободный веб-сервер, разрабатываемый Игорем Сысоевым и на сегодняшний день соперничает по популярности с Apache IIS от компании Microsoft, распространяемый с ОС семейства Windows LiteSpeed Web Server —проприетарный веб-сервер, разрабатываемый с упором на быстродействие Google Web Server — проприетарный веб-сервер комании Google, используемый в веб-инфраструктуре Google Представленные выше серверы являются самыми популярными на 2019 год. Все остальные вместе взятые веб-серверы, названия которых исчисляются десятками, используются менее чем в 1% веб-приложений. Актуальную статистику можно посмотреть тут. Определение веб-сервера, используемого в тестируемом приложении - это критически важная задача для тестера. Знание типа и версии веб-сервера позволит тестировщику определить, есть ли для этого сервера известные уязвимости и как их эксплуатировать, что в свою очередь может сильно изменить ход тестирования. Эта информация может быть получена путем отправки определенных команд на веб-сервер и анализа ответов от него, поскольку разные версии серверов могут по-разному реагировать на эти команды. Обратите внимание, что для точной идентификации веб-сервера обычно требуется отправить несколько разных команд, поскольку разные версии могут одинаково реагировать на одну и ту же команду. Редко разные версии реагируют одинаково на все команды HTTP. Таким образом, отправляя несколько разных команд, тестер может строить более точные предположения. Самая простая и основная форма идентификации веб-сервера - это посмотреть на заголовок «Server» в ответе сервера. Для теста будем использовать Netcat. Рассмотрим следующий HTTP-запрос: https://forum.antichat.xyz/attachments/4847322/2.png Как видим, в заголовке Server указан Apache. Запрос-ответ на другой сервер: https://forum.antichat.xyz/attachments/4847322/3.png На этот раз заголовок Server отдает больше информации. Видим, что версия Apache 2.4.12 и операционная система FreeBSD. Microsoft IIS 7.5 https://forum.antichat.xyz/attachments/4847322/3.png nginx/1.12.2 https://forum.antichat.xyz/attachments/4847322/4.png LiteSpeed https://forum.antichat.xyz/attachments/4847322/5.png Обратите внимание, что на сервер LiteSpeed кроме заголовка Server явно указывает заголовок X-Litespeed-Cache-Control. Google Web Server (gws) https://forum.antichat.xyz/attachments/4847322/6.png Netscape-Enterprise/6.0 https://forum.antichat.xyz/attachments/4847322/7.png Netscape-Enterprise/3.5-For-NetWare https://forum.antichat.xyz/attachments/4847322/7.png Однако, данный способ помогает не всегда. У админа сервера есть возможность изменить значение заголовка Server, не показывать его вообще и другими способами скрыть версию веб-сервера. К примеру мы можем получить такой ответ: https://forum.antichat.xyz/attachments/4847322/8.png Тут поставщика сервера по заголовку определить невозможно. Более совершенные методы основаны на различных особенностях поведения веб-серверов. Например, каждому веб-серверу свойственно устанавливать свой порядок HTTP-заголовков в ответе. Еще раз посмотрите на все примеры, приведенные выше. В примере с nginx заголовок Server является первым, и расположен перед заголовком Date. В примере c Apache заголовок Server располагается вторым по порядку, после заголовка Date, точно так, как в примере, где сервер мы не смогли определить. И точно так, как в примере с Netscape-Enterprise/6.0. Пример Netscape-Enterprise/3.5-For-NetWare по порядку заголовков похож на nginx/1.12.2. Как видим, не все так однозначно, поэтому переходим к следующему способу, основанному на отправке некорректных запросов. В запросе изменим версию протокола на несуществующую - HTTP/3.0. Так реагирует Apache: https://forum.antichat.xyz/attachments/4847322/9.png Посмотрите, как по разному реагирует один и тот же сервер на неправильный и правильный запросы: https://forum.antichat.xyz/attachments/4847322/10.png Так отреагировал на неверный запрос наш неизвестный зверь Unknown-Webserver. От него приходят два ответа: https://forum.antichat.xyz/attachments/4847322/11.png Изменим запрос - укажем несуществующий протокол JUNK, и теперь приходит один ответ: https://forum.antichat.xyz/attachments/4847322/11.png Реакция LiteSpeed на несуществующую версию протокола HTTP/3.0): https://forum.antichat.xyz/attachments/4847322/12.png На несуществующий протокол JUNK/1.0 LiteSpeed ответит иначе: https://forum.antichat.xyz/attachments/4847322/12.png Анализируя полученную информацию, сравнивая ее с известными ответами различных серверов, пентестер строит и уточняет свои предположения. Не обязательно использовать Netcat. Править HTTP-запросы и смотреть ответы сервера можно средствами браузера: https://forum.antichat.xyz/attachments/4847322/13.png Сервер античат спрятан за cloudflare. Само собой, что для получения тех же самых результатов существуют автоматизированные инструменты. Например whatweb, который по умолчанию предустановлен в Kali: https://forum.antichat.xyz/attachments/4847322/15.png Если вы по какой-то причине не хотите напрямую связываться с целевым сервером, можете использовать онлайн-сервисы, к примеру 2ip.ru: https://forum.antichat.xyz/attachments/4847322/14.png Бывает, что ни один из рассмотренных способов не принес нужного результата. В таком случае вам могут помочь страницы об ошибках в веб-приложении, которые в себе могут раскрывать информацию о сервере. Они могут быть такими (Tengine/2.0.0): https://forum.antichat.xyz/attachments/4847322/16.png такими (nginx/1.12.2): https://forum.antichat.xyz/attachments/4847322/17.png и даже такими (Apache/2.4.18): https://forum.antichat.xyz/attachments/4847322/18.png На последнем скрине видим, что раскрывается не только информация о версии сервера, но так же мы узнали версию используемого фреймворка и путь до корня веб-сервера. robots.txt Файл robots.txt используется для того, что бы поисковые роботы и сканеры знали, какие веб-страницы можно индексировать, а какие нет. Для примера файл robots.txt Google.com: https://forum.antichat.xyz/attachments/4847322/18.png Такой файл имеется в большинстве веб-приложений и иногда может содержать в себе важную для тестера информацию, например, пути к административным интерфейсам. Кроме того, иногда в robots.txt указаны расширения файлов, которые нельзя (или можно) индексировать, что указывает на возможность наличия таких файлов на сервере. Определение веб-приложений на сервере. На следующем шаге нам необходимо выяснить, какие конкретно приложения размещены на веб-сервере. Многие веб-приложения имеют уязвимости, которые давно стали достоянием общественности, и которые можно использовать для получения удаленного доступа к серверу и другим приложениям, размещенным на том же сервере. Кроме того, некоторые приложения, которые предназначены для «внутреннего использования», часто плохо сконфигурированы и редко обновляются. Например, имеется коммерческий сайт, на первый взгляд вполне «ухожен», да еще и IT-направленности. На домене аж четвертого уровня находим веб-приложение, написанное на языке Perl, расположенное на том же самом сервере, что и целевой сайт. Похоже, что админ чувствовал себя в безопасности, располагая на данном веб-сервере такое приложение, так как оно не планировалось для использования широким кругом лиц. Хочется предупредить таких админов — это ложное чуство безопасности, по-другому называемое Security through obscurity. Найденное приложение оказалось уязвимым к Ditectory Traversal и Local File Include. На скриншоте видно подключение файла /etc/passwd и вывод его содержимого в браузер: https://forum.antichat.xyz/attachments/4847322/30.png В прилжении были найдены и другие уязвимости. Например можно просматривать некоторые директории и файлы этого приложения через браузер: https://forum.antichat.xyz/attachments/4847322/32.png Обратите внимание на файл "password": https://forum.antichat.xyz/attachments/4847322/31.png C этим паролем заходим в админку, а в админке есть возможность заливать произвольные файлы на сервер (в том числе исполняемые): https://forum.antichat.xyz/attachments/4847322/34.png Есть уязвимости в логике - средствами приложения можно просматривать список файлов в произвольных директориях, загрузить и удалить файл в любой директории, например в /etc. Такой эффект достигался путем манипулярования значением параметра DIR в запросе (смотрите в адресную строку): https://forum.antichat.xyz/attachments/4847322/36.png Оцените важность этапа разведки в тестировании на этом примере. Как искать веб-приложения на сервере? Для начала рассмотрим точки, где они могут находиться. 1. Неочевидные URL. Очевидной точкой входа для веб-приложения является Example Domain. Но хотя это самая распространенная ситуация, ничто не заставляет приложение запускаться именно со слэша «/». Например, одно и то же доменное имя может быть связано с тремя веб-приложениями, такими как: http://www.example.com/url1, http://www.example.com/url2, http://www.example.com/url3. 2. Нестандартные порты. Хотя веб-приложения обычно работают на портах 80 (http) и 443 (https), это вовсе не обязательно. Фактически, веб-приложения могут работать на любых TCP-портах и на них можно ссылаться, указав номер порта следующим образом: http://www.example.com:20000/ 3. Виртуальные хосты. DNS позволяет связать один ip-адрес с несколькими доменными именами. Например, IP-адрес 192.168.1.100 может быть связан с именами www.example.com, helpdesk.example.com, webmail.example.com. Не обязательно, чтобы все имена принадлежали одному домену example.com. Такой подход используется в виртуальном хостинге, который позволяет множеству сайтов располагаться на одном веб-сервере. Теперь рассмотрим способы поиска приложений. На самом деле не существует способа точно определить все веб-приложения на сервере. Например url1 в адресе http://www.example.com/url1 может быть непредсказуемым и вы никогда о нем не узнаете. Однако существует ряд методов, которые можно использовать для получения допольнительной информации. К примеру, если веб-сервер неправильно сконфигурирован и позволяет листинг директорий прямо в браузере, как в примере ниже: https://forum.antichat.xyz/attachments/4847322/18.png в этом примере каждая директория является входом в самостоятельное веб-приложение. Так же могут помочь поисковые системы. Укажите в поисковом запросе поиск по сайту: https://forum.antichat.xyz/attachments/4847322/18.png Можно выполнить поиск вручную или по словарю с помощью сканеров по вероятным адресам для почты, административной панели, старой версии сайта и т.д. Пример для поиска почтового сервиса: Код:
https://www.example.com/webmail, https://webmail.example.com/ или https://mail.example.com/Для поиска приложений на нестандартных портах воспользуйтесь сканером nmap: https://forum.antichat.xyz/attachments/4847322/18.png Тут на портах 8000 и 8080 распологаются http-службы. При переходе по адресу в браузере на порту 8000 сервер запрашивает http-get-авторизацию, а на порту 8080 какой-то сайт. https://forum.antichat.xyz/attachments/4847322/18.png Желательно сканировать весь диапозон портов. Другие примеры. На порту 20000 расположилась веб-почта, а на порту 8080 phpMyAdmin: https://forum.antichat.xyz/attachments/4847322/18.png https://forum.antichat.xyz/attachments/4847322/18.png Следующий способ поиска приложений основан на DNS zone transfers. Передача зоны DNS (DNS zone transfers) - является одним из механизмов репликации баз DNS между серверами. Имела очень широкое распространение, но в настоящее время вытесняется другими механизмами репликации, в связи с чем имеет ограниченое применение при тестировании. Однако стоит попробовать. Прежде всего, тестеры должны определить серверы имен, обслуживающие целевой ip-адрес, пусть это будет адрес «1.1.1.1». Если доменное имя известно для 1.1.1.1 (пусть это будет www.example.com), его серверы имен можно определить с помощью таких инструментов, как nslookup, host или dig. В следующем примере показано, как идентифицировать серверы имен для yandex.ru с помощью команды host: https://forum.antichat.xyz/attachments/4847322/18.png Теперь мы попробуем запросить записи для yandex.ru на одном из его серверов DNS, и если нам повезет, сервер нам вернет этот список записей: https://forum.antichat.xyz/attachments/4847322/18.png нам не повезло ) Можно попробовать выполнить обратный DNS-запрос. Отправляем IP, получаем имя: https://forum.antichat.xyz/attachments/4847322/18.png Тоже самое в nslookup: https://forum.antichat.xyz/attachments/4847322/18.png Тоже самое в dig: https://forum.antichat.xyz/attachments/4847322/18.png Вы можете воспользоваться онлайн сервисами, такими, как 2ip.ru или ipinfo.io. Часто подобные службы возвращают частично разные или неполные данные, поэтому лучше использовать несколько таких сервисов. https://forum.antichat.xyz/attachments/4847322/18.png Как только вы определили все веб-приложения, не спешите их взламывать. Создайте список найденных приложений, вы к нему еще вернетесь. Определите, какие приложения принадлежат одному владельцу, а какие разным; Используются те же технологии, что и на целевом сайте, или другие; Находятся ли приложения с одинаковым доменом на одном и том же сервере, или на разных. Что касается веб-сервера - определив его версию, установите сервер той же версии на свой компьютер и изучите его структуру и особенности. Выполните поиск по базам уязвимостей (Metasploit Exploitation Framework и searchsploit — как искать и как использовать эксплойты или exploit-db). Изучите конфиги и значения по умолчанию, а затем проверьте их на тестируемом сервере, вдруг админ забыл что-то поменять. Некоторые демонстрационные и тестовые веб-приложения, поставляемые с веб-серверами, тоже имеют известные уязвимости, поэтому стоит их изучить и попытаться найти на тестируемом сервере. После того, как вы собрали максимально полную информацию о веб-сервере, можно приступать к дальнейшим действиям: поиск утечек информации в исходном коде веб-страниц, определение точек входа и составление карты веб-приложения, чем и займемся в следующей статье. А на сегодня всё, спасибо за внимание! |
Позновательно, так держать!
|
Wappalyzer не проще установить? не? )) да, скажите, руками определять это кульно) 21 век, с помощью простых плагинов и дополнений, уже можно пентест делать, от сайта конечноже зависит, но все же)
ПС запятые ставил 5 минут , наверное правильно..?) |
Цитата:
|
я ждал такого ответа)) твой вариант мне в копилку залетел!
|
Здравы будьте, инфоопасные братья и сестры! Немного о robots.txt. Общеизвестны расширения htm, html, php, и т.д, а есть wbp, которое связано с CMS, и подсвечивает нам mediacache, разработанный фирмой Adobe и используемый в документообороте во всем мире. Иногда, используя выражение вида site: name mediacache, можно просматривать внутренние документы, аналогично обычным запросам в гугле с добавлением pdf, ppt xls, doc, docs, etc. Спасибо за внимание и понимание.
|
Цитата:
здесь примеры последних "дорков" но никто не мешает их переделать под нужный нам сайт) https://forum.antichat.xyz/attachmen...91e064203b.png |
Пентест веб приложений: определение веб-сервера, изучение robots.txt, определение приложений на веб-сервере.
Сегодня научимся определять поставщика и версию веб-сервера, искать веб-приложения на сервере и взглянем на robots.txt. codeby.net Вот это дополнение не помешает прикрепить в основную тему. |
Огромное!!! Огромнейшее Вам спасибо за Ваш неоценимый труд!!!!!!!
|
| Время: 11:54 |