Insecure Indexing Vulnerability (IIV) - это уязвимость, реализация которой
состоит в использовании внутренних поисковых систем веб-сайтов для нахождения и
извлечения информации из скрытых или недоступных для публичного просмотра
веб-документов. В этой статье будут рассмотрены основные методы реализации
данного вида атак.
Intro
На самом деле IIV эксплуатируется хакерами уже давно, но попала в разряд
уязвимостей около года назад. Впервые она была подробно описана специалистом по
безопасности веб-приложений Эмитом Клейном (в доке "The Insecure Indexing
Vulnerability - Attacks Against Local Search Engines").
Многие интернет-проекты, контент которых постоянно обновляется, например, сайты
новостных агентств, часто заранее выкладывают различную информацию на сервер и
лишь через некоторое время, порой весьма значительное, делают ссылку на эту
информацию, делая ее, таким образом, доступной посетителям сайта. Но пока этого
не произошло, этот документ недоступен для пользователей сети, при этом он может
быть доступен поисковому механизму сайта. С его помощью хакер зачастую может
извлечь эту инфу. Рассмотрим, как это происходит.
Суть IIV
Индексация веб-документов внутренним поисковым движком может осуществляться
двумя способами:
1) crawling style indexing - поисковой механизм индексирует сначала файл
index.htm (расширение может быть иным), затем переходит по имеющимся ссылкам
(ведущим на страницы этого же сайта), индексируя их, и т.д., пока не будут
проиндексированы все страницы сайта. Таким образом, проиндексированы будут
только те страницы, на которые имеются ссылки с других страниц. По-хорошему,
подобная индексация сайта должна проводиться через внешний прокси, симулируя,
таким образом, удаленного клиента, что позволяет избежать индексации информации,
которая должна быть доступна только локальному пользователю или администратору
ресурса.
Подобным же образом действуют внешние поисковые системы, такие как Google или
Яndex. Ограничивать их поле зрения призван файл robots.txt, неграмотное
заполнение которого администратором может привлечь к сайту тысячу "посетителей"
без всяких там баннерных реклам. Правда, последствия наплыва гугл-хакеров на
сайт могут стать для админа весьма плачевными.
2) file-level search - поисковой механизм индексирует сначала файлы, находящиеся
в корневом каталоге сайта, затем переходит в каталоги находящиеся в нем, и т.д.
пока, опять же, не будут проиндексированы все файлы. Понятное дело,
индексировать абсолютно все файлы сайта совершенно не нужно, поэтому file-level
search-движки настраиваются на индексацию файлов с определенными расширениями и
в определенных директориях. Именно в поисковых системах с прямым доступом к
файлам может присутствовать IIV.
Допустим, на сайт выложили материал, планируя через некоторое время открыть его
для всеобщего обозрения. Так как на него нет ссылки, то он будет невидимым как
для посетителей сайта, так и для поисковых систем типа crawling. В то же время,
он будет проиндексирован поисковой системой имеющей прямой доступ к файлам. Если
хакер найдет такой материал, то он сможет ознакомиться с ним, перейдя на него по
ссылке, созданной поисковым движком.
Но это был простой вариант развития событий. Если администратор все же не хочет,
чтобы невидимый ресурс стал общедоступным, он может сделать его недоступным для
внешних пользователей, создав соответствующую запись в файле .htaccess. В этом
случае для хакера ситуация разворачивается следующим образом: поисковая система
находит скрытый файл, но при переходе по ссылке, ведущей к нему, сервер
возвращает HTTP 403/401 response. Несмотря на такое положение дел, хакер все же
имеет возможность восстановить полностью или частично информацию, хранящуюся на
недоступном ему ресурсе. О техниках восстановления информации из недоступных
ресурсов будет написано далее, прежде хочу описать способы обнаружении IIV и
скрытых ресурсов сайта.
Обнаружение
Простой способ нахождения большого количества потенциально уязвимых IIV сайтов -
поиск поисковых движков, поддерживающих file-level search. Таких насчитывается
огромное множество, большой популярностью пользуются
Perlfect,
Swish-e,
WebGlimpse и множество
других. Отыскивать движки можно с помощью CGI-сканера, или, что гораздо проще, с
помощью Гугла: "Powered by <название движка>". Правда, практической пользы от
этого часто нет никакой, кроме как возможности потренироваться. Обычно нас
интересует информация с определенных сайтов, поэтому стоит потратить время на
изучение именно их поисковых механизмов.
Чтобы обнаружить невидимый ресурс, неплохо бы знать, что в нем может
содержаться. К примеру, существует сайт, на котором появляются каждые несколько
дней новые статьи. Каждая выложенная на сайт статья содержит в себе дату,
записанную в определенном формате, например: dd-mm-yyyy. Тогда можно попробовать
поискать даты, имеющие более позднее значение, чем те, что стоят в последних
опубликованных на сайте статьях. Способов здесь можно придумать кучу, поэтому
придется задействовать всю свою фантазию для нахождения скрытого ресурса.
Еще один способ состоит в составлении двух списков файлов сайта, первого -
методом crawling'а, второго - с помощью file-level-поисковика. Затем нужно
сравнить результаты, и если во втором списке содержатся файлы, которых нет в
первом, то весьма вероятно, что это и есть скрытые ресурсы. Для составления
первого списка удобно использовать spider или crawler - программы, создающие
списки ссылок, имеющихся на сайте (еще удобнее использовать онлайновый сервис
SiteMap Creator - читай о нем на врезке). В поисковик можно ввести слово,
которое наверняка есть в каждом тексте - какой-нибудь предлог или артикль для
англоязычного текста.
Если материалы, имеющиеся на сайте носят имена типа "00032.txt" или
"advisory043.txt" и т.п., то можно попробовать поискать скрытые файлы, меняя
цифры в именах файлов и пытаться открыть их в браузере. Еще лучше вводить эти
имена в поисковик сайта, так как с помощью браузера ты не обнаружишь скрытые
ресурсы недоступные для внешних пользователей.
Обход .htaccess'а
Итак, что же делать когда мы находим скрытый ресурс, но веб-сервер не позволяет
нам открыть его в браузере? Если этот недоступный ресурс содержит текст, то мы
можем воссоздать этот текст, ведь поисковой движок имеет к нему доступ, а мы
имеем доступ к поисковому движку ;).
Ты когда-нибудь пробовал читать книгу, находящуюся в запертой комнате, через
замочную скважину? Пора попробовать... Большинство поисковых систем в
результатах поиска выводит на экран запрашиваемое слово (или фразу) с небольшим
фрагментом текста, окружающего его. Таким образом, мы уже видим кусочек
недоступного нам текста. Копируем этот кусочек и вставляем снова в строку поиска
- в результате наш кусочек текста становится еще больше. Затем можно брать
словосочетания, расположенные по краям этого куска текста, и, вставляя их в
строку поиска, перемещаться таким образом вверх-вниз по тексту.
Но что если поисковой движок не выводит никаких фрагментов текста, а только
выдает ссылку на недоступный ресурс? Тогда все гораздо хуже. Придется
восстанавливать текст вслепую. Если синтаксис движка достаточно развитый и
позволяет использовать операторы и маски для поиска, то имеет смысл
задействовать их. В принципе, возможно, хотя бы частично, автоматизировать это
дело, написав скрипт, например, на перле.
Защита
Теперь о том, как можно защитить свой сайт от IIV. Наипростейшим решением,
похоже, является отказ от использования поисковых систем с прямым доступом к
файлам в пользу crawling-поисковиков (кстати, многие движки поддерживают оба
способа индексации ресурсов). Если все же решил использовать file-level
поисковую систему, то позаботься об ее грамотной настройке. Запрети индексацию
файлов с расширениями .php, .php3, .pl, .cgi, .asp, .java, .vb, .jsp, .aspx, и
т.д. Запрети так же доступ к каталогам типа /cgi-bin, /scripts, и им подобным.
Имеет смысл запускать поисковой движок сайта с более низкими привилегиями, чем
веб-сервер. Так можно будет контролировать индексируемость отдельных файлов,
настраивая права доступа к ним.
Помни, что если кто-то обнаружит на твоем сайте скрытый ресурс, то он может
сделать его общедоступным, просто выложив где-нибудь в сети ссылку на него -
рано или поздно она будет проиндексирована уже внешними поисковыми системами.
Outro
Конечно, об Insecure Indexing Vulnerability нельзя сказать, что это серьезная и
глобальная уязвимость вроде XSS или SQL-Injection. Но бывают случаи, что
использование IIV может принести хакеру весьма ощутимую пользу: можно обнаружить
код приватного эксплойта за несколько дней до того, как он станет публичным;
описанные в статье методики могут пригодиться при взломе сайта, если имеет место
некорректно произведенная настройка поискового движка. В общем, о возможности
эксплуатирования IIV следует помнить как хакерам, так и администраторам
веб-сайтов.
P.S.
Существуют онлайновые сервисы, способные создавать карту сайтов, т.е. заменяющие
тебе программу-спайдер. Пользоваться ими гораздо удобнее - сэкономишь и время, и
траффик. Найти такой сервис ты сможешь по адресу
http://tools.webmasters.sk/sitemap-creator.php. SiteMap Creator умеет
создавать карту сайта, покажет тебе все внутренние и внешние ссылки, а так же
ссылки на файлы, расположенные на исследуемом сайте. Помимо, собственно, SiteMap
Creator'а на сайте tools.webmasters.sk находятся еще более десяти веб-сервисов,
предназначенных для использования веб-девелоперами, и все это - совершенно
бесплатно.
