Как найти веб сервер

Здравствуй, codeby!

Продолжаем пентест и сегодня научимся определять поставщика и версию веб-сервера, искать веб-приложения на сервере и взглянем на robots.txt.
Не пренебрегайте разведкой, ибо как вы увидите в некоторых примерах в статье – это очень важная часть тестирования. Результаты, полученные на этом этапе могут сильно повлиять на ход дальнейшего тестирования.

Определение веб-сервера.

Сегодня на рынке имеется множество разных производителей и версий веб-серверов, вот список некоторых:
Apache – свободный веб-сервер, наиболее часто используемый в UNIX-подобных операционных системах
nginx – свободный веб-сервер, разрабатываемый Игорем Сысоевым и на сегодняшний день соперничает по популярности с Apache
IIS от компании Microsoft, распространяемый с ОС семейства Windows
LiteSpeed Web Server — проприетарный веб-сервер, разрабатываемый с упором на быстродействие
Google Web Server — проприетарный веб-сервер комании Google, используемый в веб-инфраструктуре Google

Представленные выше серверы являются самыми популярными на 2019 год. Все остальные вместе взятые веб-серверы, названия которых исчисляются десятками, используются менее чем в 1% веб-приложений.
Актуальную статистику можно посмотреть

Ссылка скрыта от гостей

.

Определение веб-сервера, используемого в тестируемом приложении – это критически важная задача для тестера. Знание типа и версии веб-сервера позволит тестировщику определить, есть ли для этого сервера известные уязвимости и как их эксплуатировать, что в свою очередь может сильно изменить ход тестирования.

Эта информация может быть получена путем отправки определенных команд на веб-сервер и анализа ответов от него, поскольку разные версии серверов могут по-разному реагировать на эти команды. Обратите внимание, что для точной идентификации веб-сервера обычно требуется отправить несколько разных команд, поскольку разные версии могут одинаково реагировать на одну и ту же команду. Редко разные версии реагируют одинаково на все команды HTTP. Таким образом, отправляя несколько разных команд, тестер может строить более точные предположения.

Самая простая и основная форма идентификации веб-сервера – это посмотреть на заголовок «Server» в ответе сервера. Для теста будем использовать Netcat.

Рассмотрим следующий HTTP-запрос:

Как видим, в заголовке Server указан Apache.

Запрос-ответ на другой сервер:

На этот раз заголовок Server отдает больше информации. Видим, что версия Apache 2.4.12 и операционная система FreeBSD.

Microsoft IIS 7.5

nginx/1.12.2

LiteSpeed

Обратите внимание, что на сервер LiteSpeed кроме заголовка Server явно указывает заголовок X-Litespeed-Cache-Control.

Google Web Server (gws)

Netscape-Enterprise/6.0

Netscape-Enterprise/3.5-For-NetWare

Однако, данный способ помогает не всегда. У админа сервера есть возможность изменить значение заголовка Server, не показывать его вообще и другими способами скрыть версию веб-сервера. К примеру мы можем получить такой ответ:

Тут поставщика сервера по заголовку определить невозможно.

Более совершенные методы основаны на различных особенностях поведения веб-серверов. Например, каждому веб-серверу свойственно устанавливать свой порядок 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:

Посмотрите, как по разному реагирует один и тот же сервер на неправильный и правильный запросы:

Так отреагировал на неверный запрос наш неизвестный зверь Unknown-Webserver. От него приходят два ответа:

Изменим запрос – укажем несуществующий протокол JUNK, и теперь приходит один ответ:

Реакция LiteSpeed на несуществующую версию протокола HTTP/3.0):

На несуществующий протокол JUNK/1.0 LiteSpeed ответит иначе:

Анализируя полученную информацию, сравнивая ее с известными ответами различных серверов, пентестер строит и уточняет свои предположения.

Не обязательно использовать Netcat. Править HTTP-запросы и смотреть ответы сервера можно средствами браузера:

Сервер codeby.net спрятан за cloudflare.

Само собой, что для получения тех же самых результатов существуют автоматизированные инструменты.
Например whatweb, который по умолчанию предустановлен в Kali:

Если вы по какой-то причине не хотите напрямую связываться с целевым сервером, можете использовать онлайн-сервисы, к примеру

Ссылка скрыта от гостей

:

Бывает, что ни один из рассмотренных способов не принес нужного результата. В таком случае вам могут помочь страницы об ошибках в веб-приложении, которые в себе могут раскрывать информацию о сервере.

Они могут быть такими (Tengine/2.0.0):

такими (nginx/1.12.2):

и даже такими (Apache/2.4.18):

На последнем скрине видим, что раскрывается не только информация о версии сервера, но так же мы узнали версию используемого фреймворка и путь до корня веб-сервера.

robots.txt

Файл robots.txt используется для того, что бы поисковые роботы и сканеры знали, какие веб-страницы можно индексировать, а какие нет.
Для примера файл robots.txt Google.com:

Такой файл имеется в большинстве веб-приложений и иногда может содержать в себе важную для тестера информацию, например, пути к административным интерфейсам. Кроме того, иногда в robots.txt указаны расширения файлов, которые нельзя (или можно) индексировать, что указывает на возможность наличия таких файлов на сервере.

Определение веб-приложений на сервере.

На следующем шаге нам необходимо выяснить, какие конкретно приложения размещены на веб-сервере. Многие веб-приложения имеют уязвимости, которые давно стали достоянием общественности, и которые можно использовать для получения удаленного доступа к серверу и другим приложениям, размещенным на том же сервере. Кроме того, некоторые приложения, которые предназначены для «внутреннего использования», часто плохо сконфигурированы и редко обновляются.

Например, имеется коммерческий сайт, на первый взгляд вполне «ухожен», да еще и IT-направленности. На домене аж четвертого уровня находим веб-приложение, написанное на языке Perl, расположенное на том же самом сервере, что и целевой сайт. Похоже, что админ чувствовал себя в безопасности, располагая на данном веб-сервере такое приложение, так как оно не планировалось для использования широким кругом лиц.
Хочется предупредить таких админов — это ложное чуство безопасности, по-другому называемое Security through obscurity.

Найденное приложение оказалось уязвимым к Ditectory Traversal и Local File Include. На скриншоте видно подключение файла /etc/passwd и вывод его содержимого в браузер:

В прилжении были найдены и другие уязвимости. Например можно просматривать некоторые директории и файлы этого приложения через браузер:

Обратите внимание на файл “password”:

C этим паролем заходим в админку, а в админке есть возможность заливать произвольные файлы на сервер (в том числе исполняемые):

Есть уязвимости в логике – средствами приложения можно просматривать список файлов в произвольных директориях, загрузить и удалить файл в любой директории, например в /etc. Такой эффект достигался путем манипулярования значением параметра DIR в запросе (смотрите в адресную строку):

Оцените важность этапа разведки в тестировании на этом примере.

Как искать веб-приложения на сервере?
Для начала рассмотрим точки, где они могут находиться.

1. Неочевидные URL.
Очевидной точкой входа для веб-приложения является

Ссылка скрыта от гостей

. Но хотя это самая распространенная ситуация, ничто не заставляет приложение запускаться именно со слэша «/».
Например, одно и то же доменное имя может быть связано с тремя веб-приложениями, такими как:

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

.

2. Нестандартные порты.
Хотя веб-приложения обычно работают на портах 80 (http) и 443 (https), это вовсе не обязательно. Фактически, веб-приложения могут работать на любых TCP-портах и на них можно ссылаться, указав номер порта следующим образом:

Ссылка скрыта от гостей

3. Виртуальные хосты.
DNS позволяет связать один ip-адрес с несколькими доменными именами.
Например, IP-адрес 192.168.1.100 может быть связан с именами

Ссылка скрыта от гостей

, helpdesk.example.com, webmail.example.com. Не обязательно, чтобы все имена принадлежали одному домену example.com. Такой подход используется в виртуальном хостинге, который позволяет множеству сайтов располагаться на одном веб-сервере.

Теперь рассмотрим способы поиска приложений.

На самом деле не существует способа точно определить все веб-приложения на сервере. Например url1 в адресе

Ссылка скрыта от гостей

может быть непредсказуемым и вы никогда о нем не узнаете. Однако существует ряд методов, которые можно использовать для получения допольнительной информации.
К примеру, если веб-сервер неправильно сконфигурирован и позволяет листинг директорий прямо в браузере, как в примере ниже:

в этом примере каждая директория является входом в самостоятельное веб-приложение.

Так же могут помочь поисковые системы. Укажите в поисковом запросе поиск по сайту:

Можно выполнить поиск вручную или по словарю с помощью сканеров по вероятным адресам для почты, административной панели, старой версии сайта и т.д. Пример для поиска почтового сервиса:
https://www.example.com/webmail, https://webmail.example.com/ или https://mail.example.com/

Учтите обратную систуацию — веб-приложения с одним доменом, но разными поддоменами, могут располагаться на разных серверах.

Для поиска приложений на нестандартных портах воспользуйтесь сканером nmap:

Тут на портах 8000 и 8080 распологаются http-службы.
При переходе по адресу в браузере на порту 8000 сервер запрашивает http-get-авторизацию, а на порту 8080 какой-то сайт.

Желательно сканировать весь диапозон портов.

Другие примеры. На порту 20000 расположилась веб-почта, а на порту 8080 phpMyAdmin:

Следующий способ поиска приложений основан на DNS zone transfers.
Передача зоны DNS (DNS zone transfers) – является одним из механизмов репликации баз DNS между серверами. Имела очень широкое распространение, но в настоящее время вытесняется другими механизмами репликации, в связи с чем имеет ограниченое применение при тестировании. Однако стоит попробовать.
Прежде всего, тестеры должны определить серверы имен, обслуживающие целевой ip-адрес, пусть это будет адрес «1.1.1.1». Если доменное имя известно для 1.1.1.1 (пусть это будет

Ссылка скрыта от гостей

), его серверы имен можно определить с помощью таких инструментов, как nslookup, host или dig.

В следующем примере показано, как идентифицировать серверы имен для yandex.ru с помощью команды host:

Теперь мы попробуем запросить записи для yandex.ru на одном из его серверов DNS, и если нам повезет, сервер нам вернет этот список записей:

нам не повезло )

Можно попробовать выполнить обратный DNS-запрос. Отправляем IP, получаем имя:

Тоже самое в nslookup:

Тоже самое в dig:

Вы можете воспользоваться онлайн сервисами, такими, как

Ссылка скрыта от гостей

или

Ссылка скрыта от гостей

. Часто подобные службы возвращают частично разные или неполные данные, поэтому лучше использовать несколько таких сервисов.

Как только вы определили все веб-приложения, не спешите их взламывать. Создайте список найденных приложений, вы к нему еще вернетесь. Определите, какие приложения принадлежат одному владельцу, а какие разным; Используются те же технологии, что и на целевом сайте, или другие; Находятся ли приложения с одинаковым доменом на одном и том же сервере, или на разных.

Что касается веб-сервера – определив его версию, установите сервер той же версии на свой компьютер и изучите его структуру и особенности. Выполните поиск по базам уязвимостей (Metasploit Exploitation Framework и searchsploit — как искать и как использовать эксплойты или

Ссылка скрыта от гостей

). Изучите конфиги и значения по умолчанию, а затем проверьте их на тестируемом сервере, вдруг админ забыл что-то поменять. Некоторые демонстрационные и тестовые веб-приложения, поставляемые с веб-серверами, тоже имеют известные уязвимости, поэтому стоит их изучить и попытаться найти на тестируемом сервере.

После того, как вы собрали максимально полную информацию о веб-сервере, можно приступать к дальнейшим действиям:
поиск утечек информации в исходном коде веб-страниц, определение точек входа и составление карты веб-приложения, чем и займемся в следующей статье.

А на сегодня всё, спасибо за внимание!