Перечисление приложений на веб-сервере

Резюме

Ключевым шагом в тестировании уязвимостей веб-приложений является выявление всех приложений, размещенных на веб-сервере. Многие приложения имеют известные уязвимости и стратегии атак, которые могут быть использованы для удаленного управления или эксплуатации данных. Кроме того, многие приложения часто настроены неправильно или не обновлены, поскольку они воспринимаются как используемые "только внутри", и, следовательно, не представляют угрозы. С ростом числа виртуальных веб-серверов традиционное соотношение 1:1 между IP-адресом и веб-сервером теряет своё значение. Нередко несколько веб-сайтов или приложений имеют одинаковый IP-адрес. Эта ситуация не ограничивается хостинговыми средами, но также применима и к корпоративным сетям.

Иногда специалистам по безопасности предоставляют набор IP-адресов для тестирования. Это ближе к пентесту, но в любом случае ожидается, что тестировщик будет проверять все веб-приложения, доступные по этим адресам. Проблема возникает, если IP-адрес обслуживает HTTP-сервис на порту 80, но при обращении по IP-адресу выводится сообщение вроде "Нет веб-сервера, настроенного на этом адресе". Однако на этом сервере могут находиться различные веб-приложения, привязанные к разным символьным (DNS) именам. Очевидно, что результат анализа сильно зависит от того, тестирует ли специалист все приложения или только те, о которых ему известно.

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

Другие вопросы, влияющие на объем оценки, связаны с веб-приложениями, опубликованными по неочевидным URL (например, http://www.example.com/some-strange-URL), которые не имеют явных ссылок. Это может произойти из-за ошибок конфигурации или намеренно (например, скрытые административные интерфейсы).

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

Цели тестирования
Перечислить приложения, входящие в область тестирования, которые существуют на веб-сервере.

Как тестировать
Обнаружение веб-приложений — это процесс, направленный на выявление приложений, размещенных на инфраструктуре. Обычно такая инфраструктура представлена как набор IP-адресов (возможно, блок подсетей), но может также включать символические DNS-имена или их комбинацию. Эти данные предоставляются перед началом тестирования, будь то классический пентест или оценка приложений. В обоих случаях, если в правилах тестирования не указано иное (например, проверять только приложение по адресу http://www.example.com/), оценка должна стремиться быть максимально полной, то есть она должна выявлять все приложения, доступные через данный целевой адрес. Ниже приведены примеры некоторых техник, которые можно использовать для достижения этой цели.

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

Три ключевых фактора
Три ключевых фактора влияют на то, сколько приложений связано с данным DNS-именем (или IP-адресом):

1. Разные базовые URL

   Очевидной точкой входа для веб-приложения является www.example.com, то есть с помощью этой сокращенной нотации подразумевается, что приложение начинается на http://www.example.com/ (то же самое справедливо для HTTPS). Однако, несмотря на то, что это наиболее распространённая ситуация, ничто не заставляет приложение начинаться с /.

   Например, одно и то же символическое имя может быть связано с тремя веб-приложениями, такими как:

   • http://www.example.com/url1
   • http://www.example.com/url2
   • http://www.example.com/url3

   В этом случае URL http://www.example.com/ не будет связан с содержательной страницей, и три приложения будут скрыты, если тестировщик не знает, как их найти, то есть не знает о url1, url2 или url3. Обычно нет необходимости публиковать приложения таким образом, если владелец не хочет, чтобы они были доступны стандартным способом, и готов сообщить пользователям их точное местоположение. Это не означает, что эти приложения секретны, просто их существование и местоположение не рекламируется.

2. Нетипичные порты

   Веб-приложения обычно работают на портах 80 (HTTP) и 443 (HTTPS), но нет ничего магического в этих номерах портов. Фактически, веб-приложения могут быть привязаны к любым TCP-портам и могут быть доступны через URL с указанием порта, например: http[s]://www.example.com:port/. Например, http://www.example.com:20000/.

3. Виртуальные хосты

   DNS позволяет одному IP-адресу быть связанным с несколькими символьными именами. Например, IP-адрес 192.168.1.100 может быть связан с DNS-именами www.example.com, helpdesk.example.com, webmail.example.com. Не обязательно, чтобы все имена принадлежали одному и тому же DNS-домену. Это отношение 1

   может быть использовано для обслуживания различного контента с помощью виртуальных хостов. Информация о том, к какому виртуальному хосту относится запрос, передается в заголовке Host HTTP 1.1.

   Вы не узнаете о существовании других приложений, кроме очевидного www.example.com, если не знаете о helpdesk.example.com и webmail.example.com.

   Подходы к решению проблемы 1 - Необычные URL

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

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

Во-вторых, эти приложения могут быть упомянуты на других веб-страницах, и есть вероятность, что они были проиндексированы поисковыми системами. Если тестировщики подозревают существование таких скрытых приложений на www.example.com, они могут выполнить поиск с использованием оператора site и проанализировать результат запроса site:www.example.com. Среди возвращённых URL может оказаться ссылка на такое неочевидное приложение.

Ещё один вариант — это пробовать проверять URL, которые могут быть кандидатами на непубличные приложения. Например, фронтэнд для веб-почты может быть доступен по таким адресам, как:

• https://www.example.com/webmail
• https://webmail.example.com/
• https://mail.example.com/

То же самое касается административных интерфейсов, которые могут быть опубликованы по скрытым URL (например, административный интерфейс Tomcat), но при этом нигде не упомянуты. Немного "умного угадывания" или поиск по словарю могут принести результаты. В этом могут помочь сканеры уязвимостей.

Подходы к решению проблемы 2 - Нестандартные порты

Проверка наличия веб-приложений на нестандартных портах довольно проста. Порт-сканер, такой как nmap, способен выполнять распознавание сервисов с помощью опции -sV и может идентифицировать HTTP[S] сервисы на произвольных портах. Для этого требуется полный скан всего адресного пространства TCP портов (64k).

Например, следующая команда выполнит TCP-соединение для сканирования всех открытых портов на IP 192.168.1.100 и попытается определить, какие сервисы привязаны к ним (показаны только основные ключи — у nmap есть множество опций, обсуждение которых выходит за рамки данной темы):

nmap –Pn –sT –sV –p0-65535 192.168.1.100

Достаточно просмотреть вывод и найти http или указание на SSL-защищённые сервисы (их нужно проверить, чтобы убедиться, что это https). Например, вывод предыдущей команды может выглядеть так:

Интересные порты на 192.168.1.100:
(65527 портов были проверены, но не показаны ниже, так как они закрыты)
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 3.5p1 (protocol 1.99)
80/tcp    open  http        Apache httpd 2.0.40 ((Red Hat Linux))
443/tcp   open  ssl         OpenSSL
901/tcp   open  http        Samba SWAT administration server
1241/tcp  open  ssl         Nessus security scanner
3690/tcp  open  unknown
8000/tcp  open  http-alt?
8080/tcp  open  http        Apache Tomcat/Coyote JSP engine 1.1

Из этого примера можно сделать следующие выводы:

• На порту 80 запущен сервер Apache HTTP.
• На порту 443, вероятно, работает HTTPS-сервер (это нужно подтвердить, например, зайдя по адресу https://192.168.1.100 в браузере).
• На порту 901 находится веб-интерфейс Samba SWAT.
• Сервис на порту 1241 — это не HTTPS, а SSL-защищённый демон Nessus.
• Порт 3690 предлагает неназванный сервис (nmap возвращает его отпечаток и инструкции по отправке в базу данных отпечатков nmap, если вы знаете, что это за сервис).
• На порту 8000 также работает неизвестный сервис; вероятно, это HTTP, так как часто встречаются HTTP-серверы на этом порту.

Рассмотрим это на примере:

$ telnet 192.168.10.100 8000
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
GET / HTTP/1.0

Ответ сервера:

HTTP/1.0 200 OK
pragma: no-cache
Content-Type: text/html
Server: MX4J-HTTPD/1.0
expires: now
Cache-Control: no-cache

<html>
...

Это подтверждает, что на порту 8000 действительно запущен HTTP-сервер. В качестве альтернативы тестировщики могли бы посетить этот URL в веб-браузере или использовать команды GET или HEAD в Perl, которые имитируют HTTP-взаимодействие, подобное приведённому выше (однако не все серверы поддерживают запросы HEAD).

Apache Tomcat работает на порту 8080.
Эту задачу могут также выполнять сканеры уязвимостей, но сначала нужно убедиться, что выбранный сканер способен идентифицировать HTTP[S] сервисы, работающие на нестандартных портах. Например, Nessus может идентифицировать такие сервисы на произвольных портах (если ему указать сканировать все порты), и в дополнение к nmap Nessus проведёт несколько тестов на известные уязвимости веб-серверов, а также проверит конфигурацию SSL на HTTPS сервисах. Как упоминалось ранее, Nessus также может обнаружить популярные приложения или веб-интерфейсы, которые могут остаться незамеченными (например, административный интерфейс Tomcat).

Подходы к решению проблемы 3 - Виртуальные хосты

Существует несколько техник, которые можно использовать для определения DNS-имен, связанных с данным IP-адресом x.y.z.t.

Передача зон DNS

Эта техника в настоящее время имеет ограниченное применение, поскольку передачи зон в значительной степени не поддерживаются DNS-серверами. Тем не менее, стоит попробовать. Прежде всего, тестировщики должны определить, какие серверы имен обслуживают x.y.z.t. Если для x.y.z.t известно символическое имя (например, www.example.com), его серверы имен можно определить с помощью таких инструментов, как nslookup, host или dig, запрашивая DNS NS записи.

Если для x.y.z.t не известны символические имена, но в определении цели содержится хотя бы одно символическое имя, тестировщики могут попробовать применить тот же процесс и запросить сервер имен этого имени (надеясь, что x.y.z.t также обслуживается этим сервером имен). Например, если цель состоит из IP-адреса x.y.z.t и имени mail.example.com, определите серверы имен для домена example.com.

Пример показывает, как определить серверы имен для www.owasp.org с помощью команды host:

$ host -t ns www.owasp.org
www.owasp.org is an alias for owasp.org.
owasp.org name server ns1.secure.net.
owasp.org name server ns2.secure.net.

Теперь можно запросить передачу зоны у серверов имен для домена example.com. Если тестировщик удачлив, он получит список DNS-записей для этого домена. Это будут очевидные www.example.com и неочевидные helpdesk.example.com и webmail.example.com (и, возможно, другие). Проверьте все имена, возвращённые при передаче зоны, и учитывайте все из них, которые связаны с оцениваемой целью.

Попробуем запросить передачу зоны для owasp.org с одного из его серверов имен:

$ host -l www.owasp.org ns1.secure.net
Using domain server:
Name: ns1.secure.net
Address: 192.220.124.10#53
Aliases:

Host www.owasp.org not found: 5(REFUSED)
; Transfer failed.
.

Обратные запросы DNS

Этот процесс аналогичен предыдущему, но основывается на обратных (PTR) DNS-записях. Вместо запроса передачи зоны попробуйте установить тип записи на PTR и выполните запрос по указанному IP-адресу. Если тестировщики будут удачливы, они могут получить запись с DNS-именем. Эта техника основывается на существовании сопоставлений IP-адресов и символических имен, что не гарантируется.

Веб-поиск DNS

Этот вид поиска схож с передачей зоны DNS, но использует веб-сервисы, которые позволяют выполнять поиск по именам в DNS. Одним из таких сервисов является служба поиска DNS от Netcraft. Тестировщик может запросить список имен, принадлежащих выбранному вами домену, например, example.com. Затем он проверяет, являются ли полученные имена актуальными для цели, которую он исследует.

Сервисы обратного IP

Сервисы обратного IP похожи на обратные запросы DNS, но отличаются тем, что тестировщики запрашивают веб-приложение вместо сервера имен. Существует множество таких сервисов. Поскольку они склонны возвращать частичные (и часто различные) результаты, лучше использовать несколько сервисов для получения более всестороннего анализа.

• Domain Tools Reverse IP (требуется бесплатная регистрация)
• Bing, синтаксис: ip:x.x.x.x
• Webhosting Info, синтаксис: http://whois.webhosting.info/x.x.x.x
• DNSstuff (доступно множество сервисов)
• Net Square (несколько запросов по доменам и IP-адресам, требует установки)

Следующий пример показывает результат запроса к одному из вышеперечисленных сервисов обратного IP для 216.48.3.18, IP-адреса www.owasp.org. Обнаружены три дополнительных неочевидных символических имени, соответствующих тому же адресу.

Поиск в Google

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

Например, учитывая предыдущий пример с www.owasp.org, тестировщик может выполнить поиск в Google и других поисковых системах, чтобы найти информацию (и, следовательно, DNS-имена), связанную с недавно обнаруженными доменами, такими как webgoat.org, webscarab.com и webscarab.net.

Техники поиска в Google объясняются в разделе "Тестирование: пауки, роботы и краулеры".

Инструменты

• Инструменты для проверки DNS, такие как nslookup, dig и подобные.
• Поисковые системы (Google, Bing и другие крупные поисковые системы).
• Специализированные веб-сервисы для поиска, связанного с DNS (см. текст).
• Nmap
• Сканер уязвимостей Nessus
• Nikto