SELinux на практике: DVWA-тест

После публикации предыдущей статьи про SELinux ^[1] поступило много предложений «на практике доказать полезность» этой подсистемы безопасности. Мы решили произвести тестирование. Для этого мы создали три уязвимых стенда с типовыми конфигурациями (Damn Vulnerable Web Application на CentOS 5.8). Отличия между ними были лишь в настройках SELinux: на первой виртуальной машине он был отключен, на двух других были применены политики «из коробки» — targeted и strict.

В таком составе стенд виртуальных машин подвергся тестированию на проникновение. Взглянем на результаты?

Впрочем, давайте для начала обратимся к настройкам узлов. Для создания шаблонов была использована операционная система CentOS 5.8 с развернутой на ней «лампочкой» (LAMP ^[2]). В процессе настройки я старался допускать все возможные в данном случае типичные ошибки: подключение к БД с правами суперпользователя, настройку всего что только можно «по умолчанию». Таким образом мы старались воссоздать три линии развития событий с единой отправной точкой.

Исходный сервер представляет собой Апач в объятиях Красной Шапочки, который получил все возможные обновки — при помощи стандартной утилиты yum. Конечно же, в этой сказке не обошлось без своей Бабушки: на узлах установлена база данных MySQL. Эту прекрасную компанию дополняет крайне уязвимый Волк — Damn Vulnerable Web Application ^[3], через которого можно добраться практически до всех прочих персонажей. Однако на двух серверах из трех хакеров ждет Охотник с ружьем — SELinux, который собирается отстрелить Волку все лишние конечности при сомнительной активности.

На незащищенном сервере SELinux находится в режиме «Disabled». Это классическое решение из инструкций с Сайта-Который-Нельзя-Называть ^[4]. Все лежит на своих местах, httpd и mysqld имеют конфигурацию по умолчанию. Никакой дополнительной защиты, таким образом, на узле нет, и все зависит от устойчивости непосредственно самих служб.

В качестве одного из вариантов защиты веб-сервера я использовал SELinux с политикой targeted. Изменений в нее никаких не вносил: решение «из коробки» именно в том виде, в каком его предлагает вендор. Сервисы запускаются в подготовленных доменах и действуют в рамках «стандартного функционирования» — с точки зрения инженеров Red Hat.

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

Я попросил своего коллегу из Positive Technologies (на Хабре он известен как ki11obyte ^[5]) провести тест на проникновение. Дальше рассказывать будет он.

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

Дана форма загрузки изображений на сервер, которая проверяет только поле Content-Type в запросе. Заливаем веб-шелл на PHP, подменив Content-Type (в данном случае с помощью BurpSuite) на image/jpeg.

Шелл проходит проверку и загружается на сервер.

Настроенный SELinux также не смог в данном случае защитить систему.

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

Файл подключился успешно на каждой из машин. SELinux, таким образом, не защитит нас от ошибок в веб-приложениях.

Теперь можем спокойно выполнять команды через загруженный веб-шелл.

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

Теперь очередь машины со включенным SELinux. Снова получаем веб-шелл — и немного разочаровываемся: не хватает прав на создание сокетов и даже на выполнение ls.

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

Листинг, кстати, удалось осуществить средствами PHP.

Кроме того, удалось создать файл, сделать его исполняемым и исполнить.

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

Запрос SELECT LOAD_FILE(‘/etc/passwd’) позволяет читать файлы. Также нам легко удается записать файл во временный каталог: SELECT 1 INTO OUTFILE '/tmp/ololo'. Что оказалось действительно странным, так это довольно необычные права на созданный файл.

На машине со включенным и сконфигурированным SELinux отличий обнаружено не было, что несколько разочаровало.
—

В результате эксперимента мы пришли к следующим выводам. Во-первых, я ошибся с выбором уязвимого приложения: DVWA — плохой пример для SELinux. Основная масса «уязвимостей» направлена на то, к чему и так есть доступ в домене httpd_t. В итоге совсем непонятно — как помочь несчастной Красной Шапочке и безотказному, на все согласному Апачу. Единственным подохдящим решением стало ограничение доступа к большинству двоичных файлов — с запретом обратного соединения. Во всех остальный случаях действия злоумышленника просто не попадали в сферу компетенции подсистемы безопасности при штатных настройках.

Во-вторых, стало окончательно ясно, что настройка SELinux для веб-проекта — весьма трудоемкое дело, которое требует уверенных знаний и значительных усилий. Замечу: не просто «для защиты веб-сервера», а именно для серьезной защиты проекта в целом. Возможно составить собственную политику взаимодействия контекстов, но целесообразность этого вызывает сомнения. Мое личное мнение: от грамотной настройки php и httpd и регулярных обновлений зависит гораздо больше.

Итак, SELinux способен как минимум запротоколировать нездоровую активность в системе. А если внимательно выполнить настройку — даже и запретить несанкционированные действия. К сожалению, однако, он никак не сможет защитить ваш веб-проект от ошибок в коде или неверной настройки приложений.

Автор: isox