Рейтинг@Mail.ru

Наши друзья и партнеры

UnixForum
купить дешевый 
компьютер родом из Dhgate.com




Библиотека сайта rus-linux.net

Безопасная эксплуатация Apache, часть 7: атаки с использованием функций ОС сервера (продолжение)

Оригинал: Securing Apache, Part 7: Fool-proofing the Server OS
Автор: Arpit Bajpai
Дата публикации: 1 Марта 2011 г.
Перевод: А.Панин
Дата перевода: 31 Января 2013 г.

Начало этой части смотрите здесь.

Раскрытие исходного кода

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

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

Сценарий атаки

Предположим, что веб-сайт использует следующий PHP-код, позволяющий скачать файл с сервера:
<?php
if(isset($_GET[`file`]))
{
    $file = $_GET[`file`];
    readfile($file);
}
?>

Корректной строкой URL для данного сценария будет http://www.example.com/downloads.php?file=arpit.zip, но взломщик может сформировать вредоносную строку URL http://www.example.com/downloads.php?file=login.php, с помощью которой взломщику передается содержимое файла сценария login.php. Таким образом, взломщик узнает о фильтрах и проверках в сценарии login.php и даже о том, какие имена у других важных файлов исходного кода и конфигурации.

Для защиты от атак раскрытия исходного кода приложение должно использовать заданный список разрешенных типов файлов и отклонять любые запросы файлов других типов.

Утечка информации о списке файлов директории

Это часто встречающаяся уязвимость многих веб-серверов. Когда веб-сервер принимает запрос директории вместо определенного файла, он может ответить одним из трех способов, описанных ниже:
  1. Он может вернуть стандартный (заданный при настройке) ресурс, расположенный в данной директории, такой, как index.html, home.html, default.html, default.asp, default.aspx, index.php, и.т.д.
  2. Он может вернуть сообщение об ошибке с кодом статуса HTTP 403, сообщающее о том, что данный запрос не разрешен.
  3. Он может вернуть список файлов директории. Это происходит тогда, когда стандартные ресурсы не найдены.
В большинстве ситуаций списки файлов директорий не имеют отношения к безопасности приложений. Например, получение списка файлов директории для хранения изображений вообще не имеет отношения к безопасности приложения. На самом деле списки файлов директорий обычно умышленно разрешаются, так как они позволяют использовать встроенные возможности веб-сервера для навигации по сайтам, состоящим из статических страниц. Но все же некоторые файлы и директории обычно неумышленно размещаются в местах, доступных из корневой директории веб-сервера:
  • Файлы, генерируемые приложением: Приложения для разработки обычно генерируют файлы для указания области работы с сервером. Хорошим примером является популярный FTP-клиент WS_FTP, который помещает файл журнала событий в каждую директорию, которую он передает веб-серверу. Так как пользователи чаще всего передают множество директорий одновременно, файлы журнала событий также передаются вместе с ними и позволяют взломщикам раскрыть пути к файлам и получить их полный список. Другим примером является приложение CityDesk, которое помещает список всех файлов в корневую директорию сайта, в файл citydesk.xml.
  • Файлы управления конфигурацией: Инструменты управления конфигурацией создают множество файлов с метаданными. И снова эти файлы периодически отправляются на веб-сайт. Одна из популярных систем контроля версий CVS хранит свои файлы в директории с названием CVS. Эта директория создается в каждой созданной пользователем с помощью этой системы директории и, в свою очередь, содержит директории Entries, Repository и Root.
  • Файлы резервных копий: Текстовые редакторы обычно создают файлы резервных копий с такими расширениями, как ~, .bak, .old, .bkp и .swp. Когда изменения файлов производятся непосредственно на сервере, файлы резервных копий также остаются там. Даже в том случае, если изменения произведены на сервере или рабочей станции, предназначенных для разработки, благодаря особенности передачи директорий по протоколу FTP, они в конце концов окажутся на рабочем сервере.
  • Незащищенные файлы приложений: Приложения на основе сценариев обычно состоят из файлов, не предназначенных для прямого доступа, а вместо этого используемых в качестве библиотек или описаний дополнительных процедур. Раскрытие их содержимого происходит в том случае, если расширения этих файлов не классифицируются веб-сервером как расширения сценариев. Вместо исполнения сценария, веб-сервер отправляет его исходный код в ответ на запрос. Получив доступ к исходному коду, взломщик может начать поиск недоработок в области безопасности. Также эти файлы в некоторых случаях могут быть использованы для обхода ограничений логики работы приложения.
  • Важные данные веб-сервера: Обычно данная информация выводится в конце страницы со списком файлов и содержит имя сервера, номер версии и другие важные данные. Эти данные могут использоваться для применения определенных эксплоитов против веб-сервера.

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

После этого возникает вопрос о том, как взломщики могут получить доступ к списку содержимого директорий. Я не буду описывать способ подбора имен директорий с важными данными с помощью манипуляций с URI. Для этой цели взломщики могут просто использовать операторы расширенного поиска Google (очевидно, что этот метод может применяться при условии знания операторов расширенного поиска Google, таких, как site:, inurl:, intext:, intitle:, и.т.д.).

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

Поиск списков содержимого директорий в Google

Поиск с использованием выражения intitle:index.of site:example.com вернет вам список содержимого директории сайта example.com в том случае, если вывод списков содержимого директорий включен на сервере - а в большинстве случаев это именно так. Результат может содержать важные файлы из категорий, описанных выше. Аналогично, поиск с использованием выражения intitle:index.of ws_ftp.log или intitle: index.of 'parent directory' 'ws_ftp.ini' вернет списки содержимого директорий, содержащие файлы ws_ftp.log или ws_ftp.ini. Подобным образом взломщики могут искать файлы с расширениями .bak, .bkp, .swp, а также с другими расширениями.

Другим популярным среди взломщиков запросом является site:example.com AND intitle: 'index.of' 'backup', который возвращает список файлов в директории резервных копий (в случае, если данная директория присутствует на домене example.com). Аналогичный запрос site:example.com AND ext:log выведет все файлы журналов событий на данном домене.

Примечание: Логический оператор AND объединяет два условия или большее их количество в рамках одного запроса.

Другим поисковым запросом является "robots.txt" + "Disallow:" ext:txt site:example.com. Этот запрос выводит содержимое файла robots.txt для домена example.com, из которого взломщик может узнать пути и директории, которые по усмотрению администратора веб-сайта не должны быть индексированы ботом Google.

Более опасный запрос "phpMyAdmin" "running on" inurl:"main.php" выводит взломщиков прямо на страницу phpMyAdmin на сервере - это один из ночных кошмаров администратора сайта. Если вы попробуете выполнить этот запрос, пожалуйста, не переходите по каким-либо ссылкам из множества доступных!

Другие полезные запросы, о назначении которых вы можете догадаться:
  • intitle:index.of.password
  • intitle:"Index of" _vti_inf.html
  • allinurl:auth_user_file.txt
  • allinurl:admin mdb
  • site:edu filetype:xls +bank account
  • filetype:bak inurl:"htaccess|passwd|shadow|htusers"

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

Мероприятия по повышению безопасности

Раскрытие информации через получение списков содержимого директорий и поисковую систему Google является большой проблемой, при этом процесс получения данной информации не требует опыта; таким образом, эта уязвимость может быть включена в категорию особо опасных. Вы можете следовать инструкциям для того, чтобы защититься от нее:
  1. Добавление в директории файлов index.html без содержания является простейшим способом предотвращения показа пользователям списка их содержимого. Также можете добавить в эти файлы текст: "Ваша попытка доступа к данным сайта была зафиксирована в журнале событий" в случае, если вы хотите ввести в заблуждение начинающих взломщиков.
  2. Для отключения вывода списков содержимого директории в Apache следует открыть файл .htaccess и найти строку Option Indexes для выбранной директории, после чего заменить ее на строку Option -Indexes. Сделайте то же самое с файлом httpd.conf и перезапустите сервер Apache. После этого вывод списка содержимого директорий должен быть отключен.
  3. Если вы хотите оставить включенным вывод списка содержимого директорий, не размещайте ссылки на любые файлы с важной для взломщиков информацией.
  4. Распространенным заблуждением является предположение о том, что можно полагаться на функцию Disallow файла robots.txt, так как некоторые поисковые машины также индексируют страницы на сервере, запрещенные для индексации с помощью этого файла.

Инструменты

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

Раскрытие информации

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

Комментарии в коде HTML

Разработчики веб-сайтов обычно оставляют комментарии в исходном коде HTML. Эти комментарии чаще всего используются самими разработчиками, а реже - сторонними разработчиками. Однако, обычно данные комментарии помогают взломщикам лучше понять принцип работы целевого приложения. Например, посмотрите на HTML-код ниже:
<TABLE border="0" cellPadding="0" cellSpacing="0" height="59" width="591">
<TBODY>
<TR>
<!--If the image files are missing, restart ZBEAST -->
<TD bgColor="#ffffff" colSpan="5" height="17" width="587"> </TD>

Здесь мы видим комментарий, оставленный разработчиком и говорящий о том, что нужно делать в том случае, если файлы изображений не отображаются. Ключевой информацией в данном случае является имя приложения, которое точно описано в коде, ZBEAST.

Код JavaScript

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

Комментарии и метаданные в инструментах разработки

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

WebDAV

WebDAV (Web Distributed Authoring and Versioning) является расширением протокола HTTP. Оно добавляет несколько новых методов запросов к описанным в спецификации HTTP для реализации таких функций, как редактирование и управление файлами, хранящимися на веб-серверах, даже с удаленных систем. В том случае, если это расширение используется по умолчанию веб-сайтом, оно позволит любому пользователю получить список файлов сайта даже при наличии всех индексных файлов в директориях и отключенной функции вывода содержимого директорий.

PROPFIND (метод HTTP, используемый WebDAV) применяется для получения свойств (в формате XML) ресурса, а также позволяет получить структуру коллекции (этим термином обозначается иерархия директорий) удаленной системы. Этот запрос может применяться взломщиками с помощью метода, показанного ниже и предусматривающего использование telnet для соединения с www.example.com:
$ telnet example.com 8080
Trying 217.160.182.153...
Connected to example.com.
Escape character is '^]'.
PROPFIND / HTTP/1.1
Depth: 1

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

Подробные сообщения об ошибках

Эти сообщения в большинстве случаев являются ответами на некорректные запросы. Наиболее типичным примером является сообщение об ошибке, относящееся к SQL-запросу. Атаки на основе SQL-инъекций обычно требуют от взломщика предварительного изучения структуры или формата, используемого для осуществления SQL-запросов на сайте. Данные, раскрытые с помощью подробного сообщения об ошибке, могут содержать важную для взломщика информацию о том, как формируются корректные SQL-запросы к базе данных. (Для подробного описания атак на основе SQL-инъекций обратитесь к части 1 данной серии статей.) Данное сообщение об ошибке было получено после помещения апострофа в поле идентификатора пользователя на странице входа в систему:

В первой части сообщается о синтаксической ошибке. Сообщение об ошибке раскрывает параметры, использованные в SQL-запросе: username и password. Эта раскрытая информация является недостающим звеном, позволяющим взломщику начать реализацию атаки на основе SQL-инъекции против сайта.

Стандартной ошибкой, которую мы можем увидеть, является ошибка "HTTP 404 Not Found". Часто это сообщение об ошибке сообщает полезные подробности о сервере и других программных компонентах. Например:

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

Другие методы включают в себя догадку о файлах без наличия прямой ссылки на них. Лучшим примером этого подхода может быть догадка о строке URL для интерфейса администрирования веб-приложения - например, достаточно просто предположить корректность строки URL www.example.com/wp-admin/ для любого веб-сайта на основе WordPress.

Мероприятия по повышению безопасности

  1. Отключите расширение WebDAV в Apache если вы не используете его. Для этого найдите следующие строки в файле httpd.conf и замените On на Off.
    <IfDefine DAV>
    DAV On
    </IfDefine>
    
    По умолчанию директива IfDefine DAV используется только для директории /usr/local/httpd/htdocs. Для всех других директорий, использующих данную директиву, также должно быть произведено отключение WebDAV. После этого следует перезапустить Apache.
  2. При рассмотрении раскрытия информации при помощи тэгов комментариев HTML можно сделать вывод, что не следует отклонять запрос веб-страницы из-за тэгов комментариев. Для их обработки в Apache 2.0 существует замечательная функция с названием "фильтры" (обратитесь к официальной документации Apache). В основе работы фильтров лежит возможность чтения данных из стандартного ввода и запись данных в стандартный вывод. Эта функция становится привлекательной с точки зрения безопасности при рассмотрении данного типа раскрытия информации.
  3. Приложение никогда не должно предоставлять подробных сообщений об ошибках или отладочной информации браузеру пользователя. В случае возникновения неожиданного события (такого, как ошибка в запросе к базе данных, ошибка при чтении файла с диска или исключение при внешнем запросе API), приложение должно возвращать одно и то же сообщение об ошибке в общей форме для уведомления пользователя о ней.
  4. В Apache специальные страницы для вывода сообщений об ошибках задаются с помощью директивы ErrorDocument в файле httpd.conf. Например: ErrorDocument 500 /generalerror.html. С помощью этой директивы пользователи будут перенаправлены на страницу generalerror.html, которая может быть вашей модифицированной страницей ошибки.
  5. Отключите или ограничьте вывод подробностей при обработке ошибок. В частности, не показывайте пользователям отладочную информацию, трассировку стека или информацию о путях к файлам. Более того, переопределение стандартного обработчика ошибок для того, чтобы в любом случае возвращался статус '200' (OK) с сообщением снижает вероятность успешного использования автоматизированных инструментов для выявления серьезных ошибок.
  6. Наконец, разработчики должны быть более осмотрительными и не допускать непреднамеренного раскрытия любой важной информации.

Мы поговорим о других опасных атаках на веб-приложения и Apache в следующей статье.

Всегда помните: нужно знать все о взломе, но не заниматься им.

Дополнительные ресурсы

Продолжение серии: "Безопасная эксплуатация Apache, часть 8: атаки DoS и DDoS"

Если вам понравилась статья, поделитесь ею с друзьями: