Перейти к основному содержанию
 

CTF — HTTP - IP restriction bypass

CTF

Продолжаем решать задачки по информационной безопасности web-серверов. Сегодня задачка с портала root-me.org, называется "HTTP - IP restriction bypass". За решение задачки дают 10 баллов, начальный уровень.

ctf

Читаем задание. Имеется примечание:

Только локальные пользователи смогут получить доступ к странице.

Ещё есть сообщение:

Дорогие коллеги,

Теперь мы управляем подключениями к интрасети с использованием приватных IP-адресов, поэтому больше нет необходимости входить в систему с именем пользователя /пароля, если вы уже подключены к внутренней сети компании.

С уважением,

Администратор сети

Ссылки

https://www.root-me.org

Решение

Переходим на страницу задания:

http://challenge01.root-me.org/web-serveur/ch68/

ctf

Мы видим форму логина и сообщение: "Your IP ::ffff:46.39.246.23 dot not belong to the LAN." Ну, всё понятно. Нас пустят на страницу сайта, если у нас будет IP адрес из локальной сети.

А как веб сервер определяет IP адрес клиента? Скорее всего из серверной переменной REMOTE_ADDR. В этой переменной хранится реальный IP адрес хоста, который соединился с веб сервером. Изменить это значение клиент не может. Вернее может, если войдёт через какой-нибудь VPN. Однако, в нашем случае это ничего не даст, так как сервер выполняет проверку на локальный IP, а у VPN такого IP адреса всё равно не будет.

Размышляем дальше. А что если веб сервер проверяет не только REMOTE_ADDR? Ведь пользователь на работе может сидеть за прокси-сервером, тогда аутентифицировать его на веб сайте не получится. На такой случай есть множество других серверных переменных:

  • HTTP_X_FORWARDED_FOR
  • HTTP_CLIENT_IP
  • HTTP_X_REAL_IP
  • HTTP_VIA

Всё что начинается с "HTTP_" пользователь может переопределить. Например, чтобы переопределить переменную HTTP_X_FORWARDED_FOR, нужно в запросе отправить заголовок X-FORWARDED-FOR. Давайте так и сделаем.

X-FORWARDED-FOR — нестандартный заголовок, по факту используемый непрозрачными прокси-серверами и балансировщиками нагрузки для передачи реального IP клиента.

Через дополнение ModHeader добавляю заголовок X-FORWARDED-FOR и указываю там для пробы адрес 127.0.0.1.

ctf

Обновляю страницу.

ctf

На сайт нас не пустило, мы снова видим форму логина. Однако, сообщение теперь другое: "Your IP 127.0.0.1 dot not belong to the LAN.". Значит, веб сервер действительно проверяет заголовок X-FORWARDED-FOR при его наличие. Вот только указанный нами IP адрес ему не нравится. Сменим его на локальный адрес сети.

Частные диапазоны IP-адресов:

  • 10.0.0.0 — 10.255.255.255 (маска подсети 255.0.0.0 или /8)
  • 100.64.0.0 — 100.127.255.255 (маска подсети 255.192.0.0 или /10)
  • 172.16.0.0 — 172.31.255.255 (маска подсети: 255.240.0.0 или /12)
  • 192.168.0.0 — 192.168.255.255 (маска подсети: 255.255.0.0 или /16)

Предполагаю, что используется подсеть 192.168.0.0. Прописываю в заголовке X-FORWARDED-FOR адрес 192.168.0.5.

ctf

Обновляю страницу.

ctf

Нас пустило на сайт. И здесь же флаг:

Флаг: Ip_$po0Fing

Валидируем.

ctf

Безопасность

При определении IP адреса нельзя доверять серверным переменным, которые начинаются с "HTTP_". Все они могут быть подменены пользователем. Даже REMOTE_ADDR может быть изменён с помощью VPN, туннелей, турбо-ускорителей в браузерах или бесплатного Wi-Fi в метро.

Я, будучи веб-разработчиком, использовал X-FORWARDED-FOR для определения точного IP балансировщика за прокси сервером, но никак не для аутентификации клиентов.

Альтернативное решение

Решим задачку с помощью curl.

Формируем запрос curl, добавляя в него заголовок X-FORWARDED-FOR со значением 192.168.0.5:

curl -X POST -H "X-FORWARDED-FOR:192.168.0.5" \
http://challenge01.root-me.org/web-serveur/ch68/

Делаем запрос через командную строку или shell:

ctf

Флаг получен.

Теги