14.05.2012

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

image

Оценка эффективности защиты SELinux на примере DWVA от Кирилла Ермакова, исследовательский центр Positive Research

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

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

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

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

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

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

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

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

 Начнем с машины, на которой 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 способен как минимум запротоколировать нездоровую активность в системе. А если внимательно выполнить настройку — даже и запретить несанкционированные действия. К сожалению, однако, он никак не сможет защитить ваш веб-проект от ошибок в коде или неверной настройки приложений.

или введите имя

CAPTCHA
:-)
15-05-2012 02:31:38
selinux не нужен.
0 |
бу
15-05-2012 10:04:57
посоветуйте книгу по SELinux'y, желательно с введением в него
0 |
redo
17-05-2012 09:27:35
Для начала можно почитать тут: http://docs.fedoraproject.org/ru-RU/Fedora/13/html/Security-Enhanced_Linux/index.html
0 |
RU_LIDS
16-05-2012 14:28:30
От дефейса не спасает, но от выхода из домена httpd_t спасает. Если конечно нет сплоита в ядро с отключением самого SELinux.
0 |