04.09.2018

Решение задачи Lazy на базе платформы Hack the Box

image

Сегодня мы будем решать задачу «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

Таким образом, мы решили вторую часть задачи.