Сегодня мы будем решать задачу «Lazy», предлагаемую в рамках CTF-конкурса, которая представляет собой лабораторную работу, разработанную на базе платформы Hack the Box
Автор: Raj Chandel
Привет друзья! Сегодня мы будем решать задачу «Lazy», предлагаемую в рамках CTF-конкурса, которая представляет собой лабораторную работу, разработанную на базе платформы Hack the Box. В рамках этой онлайн-платформы есть множество задач, как для начинающих, так и для продвинутых специалистов, решая которые вы можете прокачать свои навыки пентестера. Лабораторная работа Lazy относится к категории изъятых из использования (Retired Lab).
Уровень: Средний
Задача: Найти файлы user.txt и root.txt, используя уязвимости в лабораторной работе.
Начнем.
Поскольку эти лабораторные работы доступны только онлайн, за каждой закреплен статический IP-адрес. За лабораторной работой Lazy закреплен IP-адрес 10.10.10.18.
Как обычно, начинаем со сканирования портов.
nmap -A 10.10.10.18
По результатам сканирования выясняется, что на компьютере жертвы работают две службы: ssh и HTTP, которые привязаны к портам 22 и 80 соответственно.
Рисунок 1: Результаты сканирования портов
Поскольку 80-й порт открыт, попробуем ввести IP в адресной строке браузера. В результате появилась простейшая страница со ссылками на регистрацию и авторизацию. При клике на ссылку Register открывается форма.
Рисунок 2: Результат ввода IP в адресной строке браузера
Затем я решил зарегистрироваться. В качестве логина во время регистрации я использовал admin, в качестве пароля – 123.
Рисунок 3: Регистрационная форма
Но в ответ я получил следующее: «Duplicate entry ‘admin’ for key PRIMARY» и «Can’t create user: user exists», что свидетельствовало о том, что имя пользователя «admin» уже существует. Мы могли бы заняться подбором пароля, но эта задача достаточно трудоемкая.
Рисунок 4: Результаты регистрации имени пользователя «admin»
Затем я решил воспользоваться утилитой Burp suite для анализа запросов браузера и зарегистрировался под именем пользователя aadmin и паролем 123.
Рисунок 5: Форма авторизации
В перехваченном запросе я обнаружил аутентификационный cookie. Затем я отправил перехваченный запрос в Burp Repeater для анализа и получил подсказку «invalid padding», из чего был сделан предварительный вывод, что мы вероятно имеем дело с уязвимостью padding oracle. Для более подробного ознакомления с этим типом уязвимостей, рекомендую ознакомиться с другой нашей статьей. Поскольку я уже сталкивался с подобными ситуациями, мне было понятно, что делать дальше.
Рисунок 6: Перехваченный запрос
Далее открываем терминал и запускаем команду, показанную на рисунке ниже, которая содержит целевой URL и cookie, полученный при перехвате запроса.
Рисунок 7: Запуск скрипта padbuster
По результатам анализа cookie выяснилось, что необходим #ID второго типа.
Кроме того, на скриншоте ниже видно, что было перехвачено три расшифрованных значения в формате base64, HEX и ASCII. Аутентификационный cookie представляет собой комбинацию имени пользователя и пароля. В итоге выясняется, что закодированное значение является именем пользователя aadmin.
Рисунок 8: Результат анализа cookie
Теперь нам нужно еще раз закодировать аутентификационный cookie с именем пользователя admin при помощи padbuster.
Рисунок 9: Кодирование cookie с именем пользователя admin
И опять требуется ID с типом 2. На рисунке ниже выделено зашифрованное значение с использованием имени пользователя admin.
Рисунок 10: Результат кодирования аутенификационного cookie
Копируем полученное значение «BAit——–AAAA» и заменяем аутентификационный cookie в перехваченном запросе.
Рисунок 11: Запрос с обновленным аутентификационным cookie
При отсылке обновленного запроса происходит авторизация под административной учетной записью, после чего у нас появляется доступ к административной странице. В разделе My key указано имя пользователя mitsos и ssh-ключ.
Рисунок 12: Административная раздел
Сохраняем ssh-ключ в текстовом файле. Также можно заметить, что в URL указано имя пользователя mitsos.
Рисунок 13: Секретный ssh-ключ
Загружаем ключ и назначаем соответствующие права при помощи chmod. Теперь, когда у нас есть имя пользователя и ssh-ключ, можно подключиться к серверу.
ssh -i key mitsos@10.10.10.18
После успешного подключения к PTY-шеллу на компьютере жертвы, вводим команду ls и видим в списке файлов user.txt. Первая часть задачи решена.
Рисунок 14: Содержимое файла user.txt
Приступаем ко второй части задачи.
Как видно из рисунка выше, помимо файла user.txt в той же папке есть директория peda и backup, однако, изучив эти папки, мы не смогли найти что-то полезное. Во время запуска исполняемого файла backup, на экране появилось содержимое файла shadow с хешами пользователей. Мы запустили команду strings и внутри файла backup обнаружили команду «cat /etc/shadow».
Рисунок 15: Результат исследования строк файла backup
Теперь нам нужно создать персональный исполняемый файл cat, как показано на рисунке ниже. В новой версии при запуске cat мы получим доступ к шеллу.
cd /tmp
echo "/bin/sh" > cat
chmod 777 cat
export PATH=/tmp:$PATH
cd
ls
./backup
Теперь попробуем запустить файл backup и посмотрим появится ли шелл.
Рисунок 16: Запуск обновленной версии backup
После получения шелла с правами суперпользователя нам остается зайти в директорию root и посмотреть содержимое файла root.txt. Однако не следует забывать, что переменная $PATH была изменена, и при запуске cat нужно указывать соответствующий путь.
Рисунок 17: Содержимое файла root.txt
Таким образом, мы решили вторую часть задачи.