Планирование анализа безопасности веб-ресурсовВведение.Эта заметка является в некотором роде продолжением моей публикации "Сбор критических данных без вторжения"(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 | + | + Ссылки:
|