Планирование анализа безопасности веб-ресурсов


Введение.

Эта заметка является в некотором роде продолжением моей публикации "Сбор критических данных без вторжения"(1), вышедшей в 2003-м на bugtraq.ru, а затем в белорусском журнале "Сетевые решения".

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

Порядок действий и ведения записей выбран автором на основе личных предпочтений (и во многом, под впечатлением от руководств OWASP(2) и т.д.), любой практик может (и, скорее всего, захочет) использовать собственный набор техник и способа ведения "бортового журнала". Так, многие из упомянутых онлайн-инструментов не уникальны, кто-то может создать свои аналоги или предпочесть готовые.

Немного о руководстве OWASP Testing Guide: в настоящее время на официальном сайте предлагается версия 3 (349 страниц); в то время как раньше успел там скачать некий OWASP_Testing_Guide_v3.full.pdf (374 страницы). К минусам руководства можно отнести его некоторую избыточность, часть описанных сценариев представляются маловероятными, либо чрезвычайно редко встречающимися.

Тем не менее, советы по организации испытаний и система классификации рисков определенно полезны. Из других материалов можно упомянуть Common Criteria for Information Technology Security Evaluation и OSSTMM (Open Source Security Testing Methodology Manual).

В демонстрационных целях выбраны ресурсы некого сервис-центра, портящего технику клиентов вместо ремонта.


Порядок анализа.

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

______________________________________________
[RDNS] | Reverse DNS | x | данные Reverse DNS
----------------------------------------------

Одним из первых шагов является определение основных идентификаторов ресурса (IP, хостинг, веб-сервер). Для этого мне представляется удобным комбинированный сервис Domain Dossier(3). Также помогает в идентификации серверного ПО аддон для Firefox - Server Spy(4).

simservice.ru    = 213.189.197.165 (axx165.distributed.zenon.net)
samsungremont.ru = 89.111.176.12   (fe16.hc.ru)

Оба сайта расположены на shared-хостингах "Зенон" и "Хостинг-Центр", используются веб-сервер nginx и движок магазина OSCommerce. У simservice.ru выявлена версия PHP/5.2.17. Используется виджет обратной связи с livetex.ru

Для упомянутого Reverse DNS использую онлайн сервисы Robtex(5) и BGP Looking Glass(6), тем самым определяю - выделенный ли это сервер, или совместный хостинг. (В данном случае получены данные о других ресурсах на shared-хостинге).

Затем уже посещаю исследуемый ресурс, используя HTTP/HTTPS-сниффер, реализованный в виде аддона для Firefox - Foxmeter(7), что в целом дает представление о структуре сайта, кроссдоменных скриптах/виджетах и т.д. Получаю список доступных команд HTTP запросом OPTIONS (аддон Poster(8) либо curl). В данном случае оба сервера не дали ответа на OPTIONS. Также можно поинтересоваться деталями SSL-сертификата, при наличии такового. Онлайн-инструмент, среди прочих, имеется на serversniff.net (10) В некоторых случаях, поисковый запрос вида "victim.com" site:victim.com приносит неожиданные результаты: файлы с неверно заданными правами, сервисные страницы и т.д. samsungremont.ru отреагировал на обращение к .htaccess ошибкой 403 от имени Apache/1.3.42 (маскировка).

На этой стадии уже можно получить представление о сервере и CMS. Дополнительые сведения можно посмотреть в стандартных файлах robots.txt и sitemap.xml (sitemap.xml.gz). В случае нехватки sitemap.xml можно восполнить пробел с помощью онлайн-генератора(9), а то и клиентского приложения. Изучаемые ресурсы выдали стандартный robots.txt от OSCommerce, sitemap.xml пришлось генерировать. В некоторых случаях может оказаться ценной информация о дизайнере (компании или отдельном специалисте) - многие используют типичные решения, например некие дизайн-студии решительно не признают .htaccess, в результате чего вся продукция имеет типовую уязвимость - листинг директорий (OWASP-AZ-001). В нашем случае Дизайн выполнен дизайн-бюро pella.ru, без особых ошибок (если учитывать безобразное фоновое изображение )

Для получения представления о хостинге, и не в последнюю очередь о применяемых СЗИ, рекомендуется изучить официальный сайт хостера. Чтобы не повторять этот шаг лишний раз, данные заносятся в отдельную таблицу по хостерам (аппаратура, ОС, диапазоны адресов, специфические клиентские домены). В рассматриваемом случае интерес вызвала информация о модемном пуле "Зенона": тестовый доступ: demo:demo

745-7171 - Cisco Systems Access Server 5300
251-1030 - USRobotics MP16

После идентификации CMS желательно получить её копию для анализа. В подавляющем большинстве случаев даже крупные компании используют бесплатные движки вроде Wordpress/Drupal/Joomla!. Почти все платные движки также можно скачать в виде пробной версии, позволяющей изучить структуру и возможные проблемы с безопасностью. Распространенные движки нередко страдают от ошибок, вроде листинга Wordpress или принудительной регистрации в Joomla!, позволяющей использовать ряд служебных функций.

При изучении структуры веб-ресурса особое внимание уделяю расположению данных и административным интерфейсам. Доступный административный вход имеет классификацию риска OWASP-CM-007. В нашем случае административный вход находится в /admin

Любые сообщения сервера об ошибках также могут нести полезную информацию, вроде физических путей к файлам и служебных логинов. В отдельных случаях стоит присмотреться к cookies: там также может раскрываться информация о сервере. У изучаемых сайтов - стандартные cookies OSCommerce и livetex. Наличие внутреннего поисковика также добавляет сведений, да и любая формочка - потециальный вектор атаки. Обнаружен поисковик.

Подводя итог, перечислю основные виды данных, получаемых в ходе вышеописанных действий: IP-адрес, записи DNS, тип сервера и CMS, копию CMS, структуру сайта, доступные команды HTTP, служебные файлы вроде robots.txt и sitemap.xml, информацию о хостинге и дизайнере, расположение данных и административного интерфейса. Приблизительный вид сводной таблицы по данным:

_______________________________________________________________________________________________
CENTRALOPS   | + |
REVERSE DNS  | + | shared
HTTP SNIFF   | + | CMS
HTTP OPTIONS | + | -
SERVER       | + | nginx 1.4.1
ISP          | + | 213.189.197.165 (axx165.distributed.zenon.net) / 89.111.176.12 (fe16.hc.ru)
SHARED       | + | +
CMS          | + | OSCommerce
SOURCE COPY  | + | +
HTML CHECK   | + | +
ADMIN        | + | /admin
SEARCH       | + | http://samsungremont.ru/advanced_search.php
ERRORS       | + | +
ROBOTS       | + | +
SITEMAP      | + | generic
HTACCESS     | + | 403
COOKIES      | + | +

Ссылки:


______________________________
ALiEN Assault
2013

Inception E-Zine