Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
В этой статье мы на примере средней по сложности машины TheNotebook с Hack The Box поработаем с технологией JSON Web Token, проэксплуатируем уязвимость при загрузке файлов на сервер и посмотрим, как работает одна из техник Docker Breakout — побега из контейнера Docker.
warning
Подключаться к машинам с HTB рекомендуется только через VPN. Не делай этого с компьютеров, где есть важные для тебя данные, так как ты окажешься в общей сети с другими участниками.
Адрес машины сразу же кидаем в /etc/hosts
, чтобы дальше набирать только название.
10.10.10.230 thenotebook.htb
И, как и любая другая атака, работа над виртуалкой начинается со сканирования портов. Привожу свой традиционный скрипт, который делает это в два прохода при помощи Nmap.
#!/bin/bashports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr 'n' ',' | sed s/,$//)nmap -p$ports -A $1
Результат работы скрипта
По результатам сканирования имеем два открытых порта: 22 (служба SSH) и 80 (веб‑сервер nginx 1.14.0). Для начала внимательно осмотримся на сайте и соберем информацию.
Сайт предоставляет возможность регистрации и дальнейшей авторизации. Стоит сразу выполнить эти действия, так как очень высока вероятность тем самым увеличить поверхность атаки.
Главная страница сайта
После авторизации нам открываются функции создания, хранения и чтения заметок. А это потенциальная точка входа.
Страница работы с заметками
В данном случае стоит просмотреть все запросы к серверу и его ответы. Не исключено, что таким образом обнаружатся логические ошибки в приложении. Для отлова всех запросов и ответов проксируем их через Burp. Настроив его, проходим полный цикл работы с заметкой: создаем ее и просматриваем.
Страница создания и заполнения заметки
Страница просмотра заметок
А теперь смотрим историю запросов в Burp.
История запросов Burp
При просмотре запросов сразу обратим внимание на используемые cookie. По формату авторизационная печенька уж очень похожа на JWT.
Cookie, передаваемые веб‑серверу
JSON Web Token состоит из трех частей: заголовка (header), полезной нагрузки (payload) и подписи. Заголовок и полезная нагрузка представляют собой объекты JSON, а нагрузка может быть любой — это именно те критические данные, которые передаются приложению.
Заголовок содержит поля:
alg
— алгоритм, используемый для подписи/шифрования. Это обязательный ключ;typ
— тип токена. Должно иметь значение JWT
;cty
— тип содержимого.Третий элемент вычисляется на основании первых и зависит от выбранного алгоритма. Токены могут быть перекодированы в компактное представление: к заголовку и полезной нагрузке применяется алгоритм кодирования Base64-URL, после чего добавляется подпись и все три элемента разделяются точками (как на скриншоте выше).
Попробуем разобрать данные. Для этого нам понадобится либо приложение jwt_tool, либо онлайновый сервис jwt.io. Я выбрал jwt.io, чтобы ничего не устанавливать, и дальше буду использовать его.
В нашем варианте в заголовке присутствует ключ kid
, указывающий на приватный ключ, а в качестве подписанных данных значатся используемые при регистрации данные — имя пользователя и адрес электронной почты. Но в данных присутствует еще один ключ admin_cap
, скорее всего обозначающий наличие привилегий.
Разбор JWT с помощью jwt.io
Что делать дальше, понятно — нужно изменить ключ, отвечающий за наличие привилегий администратора, подписать новые данные, сгенерировать новый JWT и заменить старый на сервисе заметок. Наличие привилегий администратора может дать ряд своих преимуществ — от чтения приватной информации до установки на сервис разных дополнений (что, скорее всего, приведет нас к удаленному выполнению кода).
С изменением ключа admin_cap
все ясно, просто выставим единичку. Но что сделать с подписью? В заголовке указан адрес приватного ключа, что наталкивает на идею: сгенерировать свою пару ключей для подписи токена, разместить их на своем веб‑сервере и затем в заголовке указать адрес ключа на этом сервере. Сначала сгенерируем пару ключей, а потом переведем в формат PEM.
ssh-keygen -t rsa -b 4096 -m PEM -f privKey.key
openssl rsa -in privKey.key -pubout -outform PEM -out pubKey.key.pub
Генерирование пары ключей
Теперь запустим в той же директории простой веб‑сервер на основе Python 3.
python3 -m http.server
Пора генерировать новый токен. Изменяем значения по ключам admin_cap
и kid
, во втором случае указываем URL сгенерированного ключа. Также вставляем сгенерированные публичный и приватный ключи в поля Verify Signature. Если ты все сделал правильно, то ниже токена увидишь надпись Signature Verified.
Создание нового токена
Вставляем новый токен в cookie, например с помощью расширения для браузера Cookie Editor, и обновляем страницу. В окне запущенного веб‑сервера увидим обращение к файлу ключа, а в браузере, если обновить страницу, появится ссылка на админскую панель.
Логи веб‑сервера
Разделы сайты
Нам стали доступны для просмотра заметки администратора — можно поискать в них что‑нибудь интересное. Но помимо этого, открылась форма для загрузки файлов. Среди админских заметок видим упоминание исполнения файлов PHP, а это потенциальный вектор атаки.
Заметка об исправлении конфигураций
Источник: xakep.ru