Перейти к содержанию

Проверка старых резервных копий и неиспользуемых файлов на наличие конфиденциальной информации

Резюме
На веб-серверах часто можно встретить неиспользуемые или забытые файлы, которые могут предоставить важную информацию об инфраструктуре или учетных данных. Это могут быть старые версии изменённых файлов, включаемые файлы, которые загружаются в виде исходного кода, или резервные копии в виде сжатых архивов. Резервные копии могут создаваться автоматически файловой системой, на которой размещено приложение, это называется «снапшотами».

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

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

Эти забытые файлы могут представлять серьёзную угрозу безопасности. Это происходит потому, что резервные копии могут иметь расширения файлов, отличающиеся от исходных. Например, архивы с расширением .tar, .zip или .gz, созданные вручную, или автоматические копии, создаваемые редакторами (например, редактор Emacs генерирует файл с именем file~, когда редактируется файл file). При копировании вручную создается похожая ситуация (например, копирование файла с именем file в файл file.old). Система хранения может создавать снимки файлов приложения без вашего ведома, и они могут быть доступны через веб, создавая аналогичные угрозы.

Эти файлы обрабатываются веб-сервером иначе, чем исходные файлы. Например, копия файла login.asp с именем login.asp.old может позволить пользователю скачать исходный код файла login.asp, потому что файл с расширением .old будет отображён как обычный текст. Это представляет серьёзный риск безопасности, так как чувствительная информация может быть раскрыта.

Основные риски:

  1. Выявление серверного кода, что может раскрыть бизнес-логику или конфиденциальные данные (имена путей, структуры данных и т.д.).
  2. Нередко в коде содержатся открытые учетные данные, что является крайне опасной практикой.
  3. Файлы конфигураций, логов или данных, которые не должны быть доступны через веб-сервер, но могут оказаться в директориях, доступных пользователям, также представляют угрозу.

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

Угрозы

Старые, резервные и неиспользуемые файлы представляют различные угрозы безопасности веб-приложения:

  1. Раскрытие конфиденциальной информации: Неиспользуемые файлы могут раскрыть чувствительную информацию, способствующую целенаправленным атакам на приложение. К примеру, это могут быть включаемые файлы с учетными данными к базе данных, конфигурационные файлы с ссылками на скрытый контент, абсолютные пути к файлам и т.д.

  2. Доступ к мощным функциональным возможностям: Неиспользуемые страницы могут содержать функционал, который может быть использован для атаки на приложение. Например, это может быть страница администрирования, доступная любому пользователю, который знает, где ее найти, но не ссылается на неё в опубликованном контенте.

  3. Уязвимости в старых и резервных файлах: Старые и резервные файлы могут содержать уязвимости, которые были устранены в более новых версиях. Например, файл viewdoc.old.jsp может содержать уязвимость обхода каталога, исправленную в viewdoc.jsp, но все еще подвержен эксплуатации теми, кто находит старую версию.

  4. Раскрытие исходного кода: Резервные файлы могут раскрыть исходный код страниц, предназначенных для выполнения на сервере. Например, запрос к viewdoc.bak может вернуть исходный код для viewdoc.jsp, который можно проанализировать на наличие уязвимостей, труднодоступных через слепые запросы к исполняемой странице. Эта угроза касается не только скриптовых языков, таких как Perl, PHP, ASP, JSP и др., но и других файлов.

  5. Архивы резервных копий: Резервные архивы могут содержать копии всех файлов внутри (или даже вне) веб-корня. Это позволяет злоумышленнику быстро проанализировать все приложение, включая неиспользуемые страницы, исходный код и включаемые файлы. Например, если забыть файл myservlets.jar.old, содержащий (резервную копию) классов реализации сервлетов, это открывает доступ к большой чувствительной информации, подверженной декомпиляции и обратной разработке.

  6. Изменение имен файлов: В некоторых случаях копирование или редактирование файла не изменяет расширение файла, но изменяет имя файла. Это происходит, например, в Windows-средах, где операции копирования создают файлы с префиксом "Копия " или локализованными версиями этой строки. Поскольку расширение файла остается неизменным, это не случай, когда исполняемый файл возвращается как обычный текст веб-сервером, и, следовательно, это не случай раскрытия исходного кода. Однако такие файлы тоже опасны, так как могут содержать устаревшую и некорректную логику, которая, будучи вызванной, может привести к ошибкам приложения, предоставляя ценную информацию злоумышленнику, если включен вывод диагностических сообщений.

  7. Лог-файлы: Лог-файлы могут содержать конфиденциальную информацию о действиях пользователей приложения, например, чувствительные данные, передаваемые в параметрах URL, идентификаторы сессий, посещенные URL (что может раскрыть дополнительный неиспользуемый контент) и т.д. Другие лог-файлы (например, FTP-логи) могут содержать чувствительную информацию о техническом обслуживании приложения со стороны системных администраторов.

  8. Снимки файловой системы: Снимки файловой системы могут содержать копии кода с уязвимостями, которые были исправлены в более новых версиях. Например, файл /.snapshot/monthly.1/view.php может содержать уязвимость обхода каталога, исправленную в /view.php, но всё ещё подверженную эксплуатации теми, кто находит старую версию.

Цели тестирования

Найти и проанализировать неиспользуемые файлы, которые могут содержать чувствительную информацию.

Методы тестирования

Чёрный ящик
Тестирование на наличие неиспользуемых файлов использует как автоматизированные, так и ручные методы, и обычно включает комбинацию следующих техник:

Вывод на основе схемы именования опубликованного контента
Перечислите все страницы и функциональные возможности приложения. Это можно сделать вручную, используя браузер, или с помощью инструмента для паутинного сканирования. Большинство приложений используют узнаваемую схему именования и организуют ресурсы на страницах и в каталогах, используя слова, которые описывают их функции. Из схемы именования опубликованного контента часто можно сделать вывод о названии и местоположении неиспользуемых страниц. Например, если найдена страница viewuser.asp, стоит также проверить edituser.asp, adduser.asp и deleteuser.asp. Если обнаружен каталог /app/user, стоит также искать /app/admin и /app/manager.

Другие подсказки в опубликованном контенте
Многие веб-приложения оставляют подсказки в опубликованном контенте, которые могут привести к обнаружению скрытых страниц и функциональности. Эти подсказки часто появляются в исходном коде HTML и JavaScript файлов. Исходный код всего опубликованного контента следует вручную просмотреть для выявления подсказок о других страницах и функциональности. Например:

Комментарии программистов и закомментированные секции исходного кода могут ссылаться на скрытый контент:

<!-- <A HREF="uploadfile.jsp">Upload a document to the server</A> --> <!-- Link removed while bugs in uploadfile.jsp are fixed -->

JavaScript может содержать ссылки на страницы, которые отображаются в графическом интерфейсе пользователя только в определённых обстоятельствах:

var adminUser=false;
if (adminUser) menu.add(new menuItem("Maintain users", "/admin/useradmin.jsp"));

HTML-страницы могут содержать формы, которые были скрыты, отключив элемент SUBMIT:

<form action="forgotPassword.jsp" method="post"> <input type="hidden" name="userID" value="123"> <!-- <input type="submit" value="Forgot Password"> --> </form>

Другим источником подсказок о неиспользуемых директориях является файл /robots.txt, который используется для предоставления инструкций веб-роботам:

User-agent: *
Disallow: /Admin
Disallow: /uploads
Disallow: /backup
Disallow: /~jbloggs
Disallow: /include

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

#!/bin/bash

server=example.org
port=80

while read url
do
    echo -ne "$url\t"
    echo -e "GET /$url HTTP/1.0\nHost: $server\n" | netcat $server $port | head -1
done | tee outputfile

  1. В зависимости от сервера, GET может быть заменен на HEAD для более быстрых результатов. Файл вывода можно просмотреть с помощью grep на наличие «интересных» кодов ответа. Код ответа 200 (ОК) обычно указывает на то, что действительный ресурс найден (при условии, что сервер не выдает пользовательскую страницу «не найдено» с использованием кода 200). Но также стоит обратить внимание на 301 (Перемещено), 302 (Найдено), 401 (Не авторизован), 403 (Запрещено) и 500 (Внутренняя ошибка), которые также могут указывать на ресурсы или директории, достойные дальнейшего исследования.

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

    • Определите используемые расширения файлов в известных областях приложения (например, jsp, aspx, html) и используйте базовый словарь, дополненный каждым из этих расширений (или используйте более длинный список общих расширений, если позволяют ресурсы).
    • Для каждого файла, идентифицированного через другие методы перечисления, создайте пользовательский словарь, полученный из этого имени файла. Получите список общих расширений файлов (включая ~, bak, txt, src, dev, old, inc, orig, copy, tmp, swp и т.д.) и используйте каждое расширение до, после и вместо расширения фактического имени файла.

Примечание: Операции копирования файлов в Windows создают файлы с префиксом «Копия « или локализованными версиями этой строки, поэтому они не меняют расширение файла. Хотя «Копия» файлы обычно не раскрывают исходный код при доступе, они могут предоставить ценную информацию в случае возникновения ошибок при их вызове.

Информация, полученная через уязвимости и неправильную конфигурацию сервера

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

Множество уязвимостей было обнаружено в отдельных веб-серверах, которые позволяют злоумышленнику перечислять неиспользуемый контент, например:

  • Уязвимость просмотра каталога Apache ?M=D.
  • Различные уязвимости раскрытия исходного кода скриптов IIS.
  • Уязвимости просмотра каталогов WebDAV в IIS.

Использование общедоступной информации

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

  • Страницы, которые раньше имели ссылки, могут все еще появляться в архивах интернет-поисковиков. Например, 1998results.asp может больше не ссылаться с сайта компании, но может оставаться на сервере и в базах данных поисковых систем. Этот старый скрипт может содержать уязвимости, которые могут быть использованы для компрометации всего сайта. Оператор поиска site: Google можно использовать для выполнения запроса только по выбранному домену, например: site:www.example.com. Использование поисковых систем таким образом привело к широкому спектру техник, которые вы можете найти полезными и которые описаны в разделе «Google Hacking» этого руководства. Проверьте его, чтобы отточить свои навыки тестирования с помощью Google. Резервные файлы, скорее всего, не будут ссылаться на другие файлы и, следовательно, могут не индексироваться Google, но если они находятся в просматриваемых каталогах, поисковая система может знать о них.
  • Кроме того, Google и Yahoo хранят кэшированные версии страниц, найденных их роботами. Даже если 1998results.asp был удален с целевого сервера, версия его вывода может по-прежнему храниться в этих поисковых системах. Кэшированная версия может содержать ссылки на или подсказки о дополнительном скрытом контенте, который все еще остается на сервере.
  • Контент, который не ссылается из целевого приложения, может быть связан с помощью сторонних веб-сайтов. Например, приложение, которое обрабатывает онлайн-платежи от третьих лиц, может содержать различные индивидуальные функции, которые (обычно) можно найти только, следуя ссылкам на веб-сайтах его клиентов.

Обход фильтров имен файлов

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

Пример: Расширение имен файлов Windows 8.3 c:\program files становится C:\PROGRA\~1

  1. Удалите несовместимые символы.
  2. Преобразуйте пробелы в символы подчеркивания.
  3. Возьмите первые шесть символов базового имени.
  4. Добавьте ~<цифра>, который используется для различия файлов с именами, использующими одни и те же первые шесть символов. Эта конвенция изменяется после первых трех совпадений имен.
  5. Укоротите расширение файла до трех символов.
  6. Преобразуйте все символы в верхний регистр.

Эти техники могут помочь выявить скрытые файлы и ресурсы на сервере, которые иначе были бы недоступны.

Тестирование серым ящиком (Gray-Box Testing)

Проведение тестирования серой зоны (gray box testing) по отношению к старым и резервным файлам требует анализа файлов, содержащихся в каталогах, принадлежащих набору веб-каталогов, обслуживаемых веб-серверами инфраструктуры веб-приложений. Теоретически это обследование должно проводиться вручную для более тщательной проверки. Однако в большинстве случаев копии файлов или резервные файлы, как правило, создаются с использованием одних и тех же соглашений об именах, поэтому поиск можно легко автоматизировать. Например, редакторы оставляют резервные копии, называя их с распознаваемым расширением или окончанием, а люди склонны оставлять файлы с расширением .old или аналогичными предсказуемыми расширениями. Хорошая стратегия — это периодическая планировка фоновой задачи, проверяющей файлы с расширениями, которые могут указывать на то, что они являются копиями или резервными файлами, а также проведение ручных проверок на более длительных интервалах.

Исправление уязвимостей

Чтобы гарантировать эффективную стратегию защиты, тестирование должно сочетаться с политикой безопасности, которая четко запрещает опасные практики, такие как:

  • Редактирование файлов на месте на файловых системах веб-сервера или сервера приложений. Это особенно плохая привычка, так как это может привести к созданию резервных или временных файлов редакторами. Удивительно, как часто это происходит, даже в крупных организациях. Если вам абсолютно необходимо редактировать файлы в рабочей системе, убедитесь, что вы не оставляете ничего, что не предназначено явно, и учитывайте, что вы делаете это на свой страх и риск.

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

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

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

  • Снимки файловой системы не должны быть доступны через веб, если корень документа находится на файловой системе, использующей эту технологию. Настройте ваш веб-сервер, чтобы отказать в доступе к таким каталогам, например, в Apache следует использовать директиву location следующего вида:

<Location ~ ".snapshot">
    Order deny,allow
    Deny from all
</Location>

Инструменты

Инструменты оценки уязвимостей, как правило, включают проверки для обнаружения веб-каталогов с обычными именами (такими как "admin", "test", "backup" и т. д.) и сообщают о любых веб-каталогах, которые допускают индексирование. Если вы не можете получить список каталогов, следует проверить наличие вероятных резервных расширений. Проверьте, например:

  • Nessus
  • Nikto2
  • Инструменты веб-пауков:
    • wget
    • Wget для Windows
    • Sam Spade
    • Spike Proxy включает функцию краулера веб-сайтов
    • Xenu
    • curl

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