• IP-адрес машины Windows 10: 192.168.1.177
• IP-адрес машины Kali Linux: 192.168.27.139
• IP-адрес Backend-Server: 172.18.0.2
• IP-адрес Proxy-Server: 172.18.0.3
• Когда машина Windows 10 обращается к Apache HTTP Server, размещённому на машине Kali на порту 80, трафик перенаправляется на порт 80 Proxy-Server и далее передаётся на Backend-Server через порт 8080.

Требования к системе

• Атакующая машина:
  • Операционная система Windows 10
  • Установленные инструменты: Pycharm, BurpSuite, VScode
  • Использование браузера FireFox и расширения FoxyProxy для настройки прокси
• Машина жертвы:
  • Установленные инструменты и службы: Docker, Tcpdump
  • Настроенный Dockerfile (см. раздел приложения)

Цель эксплуатации: использовать уязвимость HTTP Request Smuggling для обхода ограничений прокси-сервера и доступа к скрытой функции на странице admin.php

Проведение эксперимента:

• Используем BurpSuite Community, настроенный как прокси, для перехвата и изменения запросов.
• В браузере устанавливаем расширение FoxyProxy и добавляем информацию о прокси:
• Включаем FoxyProxy на панели инструментов (в разделе расширений браузера), переключая с Turn Off на BurpSuite Commu:
• В BurpSuite включаем intercept (переключаем на on), чтобы перехватывать пакеты:
• На машине Kali с помощью команды cd переходим в папку лабораторной работы, где находится файл docker-composer.yml, и запускаем docker compose командой: docker-composer up --build

Проверка CRLF-инъекции:

• Сначала отправляем на систему запрос, содержащий управляющие символы (CRLF), например: HTTP/1.1\r\nFoo: baarr\r\r\n\n, и кодируем URL как: %20HTTP/1.1%0d%0aFoo:%20baarr => Можно заметить, что при вставке символов CRLF (%0d%0a) сервер обрабатывает наш запрос без каких-либо ошибок или ограничений, что показывает, что мы можем вставлять символы CRLF.

Проверка HTTP Request Smuggling:

• Далее у нас есть следующий URI: /categories/1 HTTP/1.1\r\nHost: Localhost\r\n\r\nGET /SMUGGLED. После URL-кодирования получаем: /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/SMUGGLED/
• После применения RewriteRule видно, что URL будет проанализирован, и наш запрос после прохождения через прокси преобразуется в следующий формат:
• Можно заметить, что на один отправленный нами запрос сервер получает и возвращает целых 2 ответа: один от GET /categories и один от GET /SMUGGLED

Эксплуатация HTTP Request Smuggling:

• Предположим, что в файле httpd.conf мы настроили Proxy-Server на блокировку доступа к странице /admin/
• Мы можем использовать HTTP Request Smuggling для обхода механизма проверки apache-proxy с помощью запроса:
  • Проверив логи, мы видим, что успешно обошли apache-proxy, отправили запрос на /admin, и backend также вернул статус-код 200 для GET /admin
  • Предположим, что в файле admin.php есть функция, выполняющая системную команду nslookup для запроса к любому домену, как показано ниже. Наша цель — обойти механизм прокси и получить доступ к этой скрытой функции для отправки DNS-запроса к любому домену; здесь мы запрашиваем нашу собственную машину Kali.
  • У нас есть код эксплойта (файл CVE-2023-25690.py) и файл pre.txt (содержащий smuggled-запрос, который мы хотим пропустить через Proxy-Server для отправки запроса в систему, здесь — /admin.php). Этот код создаёт smuggling-запрос с нашим запросом, находящимся в файле pre.txt, и отправляет его на сервер. Также сохраняет результаты запроса и ответа в два соответствующих файла: req.txt и res.txt
  • Одновременно на машине Kali используем TCPDUMP для перехвата DNS-пакетов на порту 53
• Можно заметить, что отправленный нами запрос прошёл через прокси: прокси считает его допустимым запросом. Но на backend-server запрос анализируется с учётом управляющих символов, поэтому из одного запроса backend-server выделил 3 запроса: первый — GET /categories.php?id=1, второй — GET /admin.php?secret=192.168.1.194 и, наконец, GET /abc
• Таким образом, мы успешно отправили запрос на /admin.php — туда, куда прокси не разрешает отправлять запросы. => Проверив TCPDUMP, мы видим, что TCPDUMP перехватил DNS-пакеты, отправленные на наш адрес, — значит, скрытая функция в /admin.php была успешно выполнена.

Приложение

Конфигурация файла Dockerfile в папке Backend

• Этот файл конфигурации указывает, что Backend-Server использует образ PHP 7.4-apache — образ, содержащий PHP 7.4 вместе с веб-сервером Apache.
• Вторая команда копирует всё содержимое из папки src/ в папку /var/www/html — это папка по умолчанию, которую Apache использует для построения веб-содержимого; также эту папку называют веб-корнем (web root).
• Третья команда использует sed для замены всех вхождений 80 на 8080. Это позволяет изменить порт Apache по умолчанию внутри Backend-Server с 80 на 8080.
• Четвёртая команда используется для обновления пакетов и установки пакета dnsutils — информацию об этом пакете можно посмотреть здесь: https://github.com/iagox86/dnsutils/blob/master/README.md
• Последняя команда выполняется при запуске контейнера — это команда, использующая apache для запуска веб-сервера Apache.

Конфигурация файла Dockerfile в папке Frontend

• Этот файл копирует файл httpd.conf из папки Frontend в файл /tmp/httd.conf и, наконец, помещает содержимое этого файла httpd.conf в файл /usr/local/apache2/conf/httpd.conf
• Файл httpd.conf — это основной файл конфигурации Apache HTTP Server; этот файл определяет параметры конфигурации или действия на сервере — здесь это Proxy-Server.
• Файл httpd.conf обычно устанавливается по пути /usr/local/apache2/conf/httpd.conf, поэтому мы должны поместить содержимое по пути /usr/local/apache2/conf/httpd.conf, а создание файла httpd.conf в папке Frontend позволяет более гибко настраивать Apache (не нужно переходить по указанному пути, чтобы переписывать файл httpd.conf).

Конфигурация файла docker-compose.yml:

• Здесь определяются сервисы, сети и т.д., необходимые для запуска приложения.
• Здесь мы объявляем два основных сервиса: apache-proxy и backend-server:
  • Apache-Proxy: построен на основе файла ./frontend/Dockerfile, сеть — backend-network (bridge). Кроме того, есть конфигурация depends_on: backend-server, указывающая, что Apache-Proxy может быть запущен только после завершения запуска Backend-Server. Наконец, ports: "80:80" задаёт проброс портов: весь трафик, поступающий на порт 80 хост-машины, будет перенаправляться на порт 80 контейнера.
  • Backend-Server: построен на основе файла ./backend/Dockerfile, сеть backend-network вместе с Proxy, чтобы они могли взаимодействовать друг с другом. Конфигурация expose открывает порт 8080, чтобы Apache-Proxy перенаправлял трафик на Backend-Server через этот порт. Наконец, добавлены некоторые функции безопасности, такие как запрет пользователю создавать новые права (добавлять, изменять, удалять файлы, добавлять права на процессы или сеть и т.д.) и фильтрация системных вызовов, выполняемых программой.

Конфигурация файла httpd.conf

• Сначала настраивается хранение логов по двум путям: /use/local/apache2/logs/error.log и /use/local/apache2/logs/access.log
• Затем загружаются необходимые модули для применения Rewrite Rule (правила перезаписи).
• Далее указывается DocumentRoot — параметр в файле конфигурации Apache, который определяет, где находятся файлы данных сервера.
• Затем применяется правило перезаписи для путей к /categories/ и /admin/.
• И, наконец, блокируется отправка запросов на /admin/ — это делается для того, чтобы мы могли провести лабораторную работу по обходу прокси и доступу к этой странице.