Здравствуй, 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-запросы и смотреть ответы сервера можно средствами браузера:
Сервер yg140.servegame.com спрятан за cloudflare.
Само собой, что для получения тех же самых результатов существуют автоматизированные инструменты.
Например whatweb, который по умолчанию предустановлен в Kali:
Если вы по какой-то причине не хотите напрямую связываться с целевым сервером, можете использовать онлайн-сервисы, к примеру 2ip.ru:
Бывает, что ни один из рассмотренных способов не принес нужного результата. В таком случае вам могут помочь страницы об ошибках в веб-приложении, которые в себе могут раскрывать информацию о сервере.
Они могут быть такими (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.
Очевидной точкой входа для веб-приложения является 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 может быть непредсказуемым и вы никогда о нем не узнаете. Однако существует ряд методов, которые можно использовать для получения допольнительной информации.
К примеру, если веб-сервер неправильно сконфигурирован и позволяет листинг директорий прямо в браузере, как в примере ниже:
в этом примере каждая директория является входом в самостоятельное веб-приложение.
Так же могут помочь поисковые системы. Укажите в поисковом запросе поиск по сайту:
Можно выполнить поиск вручную или по словарю с помощью сканеров по вероятным адресам для почты, административной панели, старой версии сайта и т.д. Пример для поиска почтового сервиса:
Учтите обратную систуацию — веб-приложения с одним доменом, но разными поддоменами, могут располагаться на разных серверах.
Для поиска приложений на нестандартных портах воспользуйтесь сканером 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 (пусть это будет www.example.com), его серверы имен можно определить с помощью таких инструментов, как nslookup, host или dig.
В следующем примере показано, как идентифицировать серверы имен для yandex.ru с помощью команды host:
Теперь мы попробуем запросить записи для yandex.ru на одном из его серверов DNS, и если нам повезет, сервер нам вернет этот список записей:
нам не повезло )
Можно попробовать выполнить обратный DNS-запрос. Отправляем IP, получаем имя:
Тоже самое в nslookup:
Тоже самое в dig:
Вы можете воспользоваться онлайн сервисами, такими, как 2ip.ru или ipinfo.io. Часто подобные службы возвращают частично разные или неполные данные, поэтому лучше использовать несколько таких сервисов.
Как только вы определили все веб-приложения, не спешите их взламывать. Создайте список найденных приложений, вы к нему еще вернетесь. Определите, какие приложения принадлежат одному владельцу, а какие разным; Используются те же технологии, что и на целевом сайте, или другие; Находятся ли приложения с одинаковым доменом на одном и том же сервере, или на разных.
Что касается веб-сервера - определив его версию, установите сервер той же версии на свой компьютер и изучите его структуру и особенности. Выполните поиск по базам уязвимостей (Metasploit Exploitation Framework и searchsploit — как искать и как использовать эксплойты или exploit-db). Изучите конфиги и значения по умолчанию, а затем проверьте их на тестируемом сервере, вдруг админ забыл что-то поменять. Некоторые демонстрационные и тестовые веб-приложения, поставляемые с веб-серверами, тоже имеют известные уязвимости, поэтому стоит их изучить и попытаться найти на тестируемом сервере.
После того, как вы собрали максимально полную информацию о веб-сервере, можно приступать к дальнейшим действиям:
поиск утечек информации в исходном коде веб-страниц, определение точек входа и составление карты веб-приложения, чем и займемся в следующей статье.
А на сегодня всё, спасибо за внимание!
Продолжаем пентест и сегодня научимся определять поставщика и версию веб-сервера, искать веб-приложения на сервере и взглянем на 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-запросы и смотреть ответы сервера можно средствами браузера:
Сервер yg140.servegame.com спрятан за cloudflare.
Само собой, что для получения тех же самых результатов существуют автоматизированные инструменты.
Например whatweb, который по умолчанию предустановлен в Kali:
Если вы по какой-то причине не хотите напрямую связываться с целевым сервером, можете использовать онлайн-сервисы, к примеру 2ip.ru:
Бывает, что ни один из рассмотренных способов не принес нужного результата. В таком случае вам могут помочь страницы об ошибках в веб-приложении, которые в себе могут раскрывать информацию о сервере.
Они могут быть такими (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.
Очевидной точкой входа для веб-приложения является 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://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 (пусть это будет www.example.com), его серверы имен можно определить с помощью таких инструментов, как nslookup, host или dig.
В следующем примере показано, как идентифицировать серверы имен для yandex.ru с помощью команды host:
Теперь мы попробуем запросить записи для yandex.ru на одном из его серверов DNS, и если нам повезет, сервер нам вернет этот список записей:
нам не повезло )
Можно попробовать выполнить обратный DNS-запрос. Отправляем IP, получаем имя:
Тоже самое в nslookup:
Тоже самое в dig:
Вы можете воспользоваться онлайн сервисами, такими, как 2ip.ru или ipinfo.io. Часто подобные службы возвращают частично разные или неполные данные, поэтому лучше использовать несколько таких сервисов.
Как только вы определили все веб-приложения, не спешите их взламывать. Создайте список найденных приложений, вы к нему еще вернетесь. Определите, какие приложения принадлежат одному владельцу, а какие разным; Используются те же технологии, что и на целевом сайте, или другие; Находятся ли приложения с одинаковым доменом на одном и том же сервере, или на разных.
Что касается веб-сервера - определив его версию, установите сервер той же версии на свой компьютер и изучите его структуру и особенности. Выполните поиск по базам уязвимостей (Metasploit Exploitation Framework и searchsploit — как искать и как использовать эксплойты или exploit-db). Изучите конфиги и значения по умолчанию, а затем проверьте их на тестируемом сервере, вдруг админ забыл что-то поменять. Некоторые демонстрационные и тестовые веб-приложения, поставляемые с веб-серверами, тоже имеют известные уязвимости, поэтому стоит их изучить и попытаться найти на тестируемом сервере.
После того, как вы собрали максимально полную информацию о веб-сервере, можно приступать к дальнейшим действиям:
поиск утечек информации в исходном коде веб-страниц, определение точек входа и составление карты веб-приложения, чем и займемся в следующей статье.
А на сегодня всё, спасибо за внимание!
Вложения
Последнее редактирование:
