Компания
300,19
рейтинг
12 мая 2012 в 14:28

Разработка → SELinux на практике: DVWA-тест

После публикации предыдущей статьи про 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 способен как минимум запротоколировать нездоровую активность в системе. А если внимательно выполнить настройку — даже и запретить несанкционированные действия. К сожалению, однако, он никак не сможет защитить ваш веб-проект от ошибок в коде или неверной настройки приложений.
Автор: @isox
Positive Technologies
рейтинг 300,19

Похожие публикации

Комментарии (24)

  • +2
    Печально. Я ждал, так сказать, «немного» большего от SELinux, даже с «коробочными» настройками.
    • +3
      Я искренне надеялся на более «положительный» результат.
      Но интерес был именно в таком «чистом» тесте. ПОсмотреть объективные результаты.
      • +1
        Интересно увидеть аналогичный тест с AppArmor.
        • 0
          Кстати действительно интересно. Самое главное что он гораздо менее геморный чем selinux, и его реально настроить для проекта. А вот насколько слабее пути чем контексты, это отдельный вопрос.
  • +1
    Установленный из коробки доставляет гемор с настройкой софта, а получается и пользы от него немного…
    • +1
      Как я и написал, скорее я выбрал не самый удачный пример.
      Польза есть. Но, к сожалению, в других местах.
  • 0
    Для защиты от ошибок в коде следует применять Web Application Firewall
    • +1
      Вы абсолютно правы.
      • 0
        mod_security например.
  • +1
    Не знаю, при чем тут котэ, но он зачетный!
    • 0
      RedHat же
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Котэ шикарен! :)
  • 0
    Я тут ждал…
    А Вашей статьей Вы только подтвердили, что selinux по дефолту надо выключать, ибо он несет много проблем при настройке ПО, а толку без настройки 0.
    Кому надо, пусть настраивают.
    • +1
      Ну, не 0.
      Но довольно мало с точки зрения уязвимостей уровня DVWA.
      К сожалению, осветить ситуацию целиком не вышло, ввиду отсутствия критических уязвимостей в системе, которые можно было бы использовать.
      • 0
        Как насчёт mempodipper?
        • +1
          Я надеюсь на более быстрый ответ от моего коллеги ki11obyte, если он помнит подробности пентеста.
          Я не готов сказать сейчас, есть ли данная уязвимость на тех системах.
          Прошу простить, но я уже дома и тестовые машины мне не доступны.
          Мне доступна кружка с пивом и чипсы.
        • +1
          На тестовых машинах было ядро 2.6.18 (подтверждение есть на скриншотах). mempodipper там не подходит.
        • 0
          На сколько я вижу, то не должен сработать этот сплойт, потому что нельзя создавать сокет из под домена httpd_t. Да и su не должен пропустить. Ответ теоритический.
          • 0
            теорЕтический*
  • 0
    Для данного типа проникновения лучше запрещать исполнение скриптов из каталогов в которые можно загружать файлы. Это более простой и быстрый способ. SELinux хорош при обслуживании больших проектов, для глобального контроля безопасности. Настраивать каждый раз на маленьких проектах не всегда удобно (хотя желательно это делать).
  • 0
    Поимел много проблем с незапускаемостью, когда ставил Redmine под CentOS. Поэтому странно, что во всех вариантах шел запустился.
    Покажите пожалуйста вывод ls -laZ hackable и ls -laZ hackable/uploads в вариантах с включенным SELinux.
    На папке hackable/uploads должно быть httpd_user_script_rw_t — читать и писать файлы из скриптов. Скрипт шелла из такой папки запускаться не должен.

    • +1
      На strict-политике я ограничивал контекстом запуск скриптов из uploads.
      Проблема, как я ее понимаю, именно в том, что веб-шелл подгружается через другой скрипт (инклюд), выполнение которого вполне легитимно.
      • 0
        Да, от инклюдов похоже не спасает.

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

Самое читаемое Разработка