10-го декабря 2019 г. мы запустили четырнадцатую по счёту лабораторию. На девятый день в режиме нон-строп трем участникам удалось скомпрометировать узлы лаборатории, определив победителей этого сезона. Для всех остальных, кто пытался, пытается и будет пытаться пропентестить Test lab 14 мы решили опубликовать ее прохождение.

Лаборатория Test lab — бесплатная площадка для проверки и закрепления навыков тестирования на проникновение, представляющая собой корпоративную сеть виртуальной компании из уязвимых и неуязвимых компонентов (серверов, сетевого оборудования и рабочих станций).

Итак, пришло время разобрать все задания Test lab 14, чтобы дать возможность тем, у кого не получается, глубже погрузиться в мир информационной безопасности и узнать для себя что-то новое. Содержание получилось довольно объёмным, описание — лаконичным, но, надеемся, что интересным.

Вся информация представлена исключительно для ознакомления. Не применяйте полученные знания в противоправных или противозаконных целях.

Подключение к лаборатории

Для подключения к лаборатории используем логин/пароль, полученные в личном кабинете. Там же находится инструкция для настройки OpenVPN соединения для Linux и Windows платформ. На момент написания статьи на сайте Test lab было зарегистрировано более 30.000 участников.

После подключения становятся доступны шлюзы 192.168.101.14 и 192.168.101.15, за которыми расположены остальные узлы лаборатории.

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

Site

Начнем разведку сети со сканирования шлюза 192.168.101.14 с помощью Nmap. В ходе сканирования обнаруживаем открытые порты 80, 143, и 8080.

Пробуем подключиться к 192.168.101.14:80. При попытке обращения к веб-приложению получаем редирект на site.test.lab, но браузер не может его найти (ERR_NAME_NOT_RESOLVED). Получаем доступ к веб-ресурсу, добавив запись в /etc/hosts:

[code bash] 192.168.101.14 site.test.lab [/code]

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

Безрезультатно пытаемся использовать WPScan:

При попытке найти уязвимости получаем кастомную страницу, которая содержит еще один email, сохраняем и его. Вероятно, сайт защищён WAF. Вернёмся к нему позже.

Mail

На порту 8080 расположен Roundcube Webmail, на 143 — сервис IMAP. Воспользуемся списком сохранённых email’ов, пытаясь подобрать пароль:

[code bash] hydra -L email.txt -P /usr/share/john/password.lst imap://192.168.101.14 [/code]

Успешно подбираем пароль для почты support@test.lab: PASSWORD. Исследовав почтовый ящик пользователя, находим токен и несколько файлов: client.jar, certificate.zip и vpn.zip.

Java

Открываем jar-файл как архив и видим, что он состоит из одного класса Main. Открываем Main.class в IDE:

Рассмотрев декомпилированный код, обнаруживаем информацию для подключения к SSH и вывод результата выполнения команды:

[code bash] df -h | grep /dev/sda1 [/code]

При этом обращаем внимание, что пароль видоизменяется. Добавляем несколько строчек в класс, чтобы вывести IP-адрес сервера, логин и пароль, с которыми происходит подключение:

Компилируем изменённый класс и подменяем им оригинальный класс в jar-файле. Запускаем файл:

[code bash]java -jar client.jar[/code]

Выведенный на экран пароль является токеном.

VPN-2

С найденным конфигурационным файлом, логином и паролем подключаемся к VPN через шлюз 192.168.101.15:

В журнале подключения находим добавление нового маршрута на подсеть 172.16.0.0/16.

Просканировав найденную сеть, находим доступный хост 172.16.0.11 с открытым 80 портом:

Это стандартная страница сайта, в коде которой ничего интересного обнаружить не удалось. Поиск директорий с помощью DirBuster оказался безрезультатным. Поскольку сами задания предполагают поиск токенов, то попробуем использовать слово «token» в запросе. В результате скачивается файл, содержащий токен:

NS

При сканировании сети находим еще один хост с открытым 53 портом, на котором размещен DNS (BIND9):

Используя имя домена сайта, составим команду для AXFR:

[code bash] dig @172.16.0.10 test.lab axfr [/code]

Получаем записи зон DNS-сервера. Добавляем найденные А-записи в файл /etc/hosts. В одной из А-записей находим искомый токен:

AD

Теперь просканируем найденный в задании NS контроллер домена:

Пытаемся получить список пользователей AD:

[code bash] enum4linux -U 172.16.0.20 [/code]

Сохраняем вывод. Данные одного из пользователей содержат токен:

Terminal-2

При выполнении задания Java стал известен хост 172.16.20.2 и учётные данные одного из его пользователей. Подключившись к серверу по SSH в папке /opt, находим токен. Если продолжить поиски, можно обнаружить каталог .crt, а в нем файлы: dev.key и dev.crt. Сохраняем полученную информацию:

Просканировав сеть 172.16.0.0/24, находим еще один доступный сервер с открытым 80 портом:

WIKI

Пробросив порт с terminal-2, начинаем анализировать WIKI:

[code bash] ssh -L 80:172.16.0.12:80 dev@172.16.20.2 [/code]

На странице сайта имеется строка поиска, введя туда текст, убеждаемся, что он отображается на странице:

Для определения шаблонизатора попробуем ввести в строку поиска [code] {{7*7}} [/code], на странице отобразился введённый текст без изменений, следовательно, это не Jinga и не Twig. Далее для экономии времени воспользуемся инструментом Tplmap, но он не смог выяснить, какой шаблонизатор используется:

С помощью WhatWeb узнали, что сайт написан на Ruby-on-Rails:

Пробуем воспользоваться пейлоадом для популярного на Ruby-on-Rails шаблонизатором Haml:

[code bash] «<%=7*7%>» [/code]

На странице отобразилось 49, следовательно, шаблонизатор найден верно. Зная шаблонизатор, составляем запрос, позволяющий получить токен:

VPN-1

На основе файлов в каталоге .crt на terminal-2 редактируем найденный на почте конфигурационный файл VPN для подключения к VPN-1:

Ранее, при выполнении задания с DNS, мы видели, что часть А-записей находится в сетях 172.16.50.0/24 и 172.16.40.0/24. По аналогии с заданием VPN-2, просматриваем браузер по адресу 172.16.50.11/token:

Скачиваем файл, содержащий токен.

Site

Теперь переходим к сайту, который для нас был ранее недоступен. Сканируем его WPScan’ом, но теперь наш запрос не блокируется. Нашли интересный плагин:

Поискав информацию, обнаруживаем уязвимость в плагине. Воспользуемся найденным пейлоадом, на странице вывода отображается файл /etc/passwd, который содержит токен.

Это токен можно было получить раньше, но путем по-сложнее, обойдя WAF. После нескольких попыток получить доступ к LFI, адрес атакующего блокировался. Тем не менее, файл с токеном можно было получить, например, так:

[code]http://site.test.lab/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/etc/subuid[/code]

News

Просканировав IP-адрес 172.16.50.21, находим открытый 80 порт, на котором доступен сайт News. На странице авторизации воспользуемся ранее найденной учётной записью dev:

Фаззинг поля поиска не увенчался успехом. Dirbuster тоже ничего не обнаружил. Анализируем структуру файлов в ручном режиме и находим файл lenta.php.save, содержимое которого позволяет развить атаку:

Используя полученные данные, составляем запрос для выполнения команды на сервере. Через RCE получаем доступ к файлу с токеном:

[code bash] http://news.test.lab/lenta.php?debug=dawdawgoiagi2re0&cmd=cat /opt/token [/code]

DB

Помимо найденного в /opt токена, в директории сайта находим файл DB.php. Исходя из его содержимого, понимаем, с какими реквизитами происходит подключение к базе данных сервера 172.16.40.5. Подключившись, находим таблицу, содержащую токен, и выводим её содержимое при помощи команды:

[code bash] http://news.test.lab/lenta.php?debug=dawdawgoiagi2re0&cmd=mysql%20-h%20172.16.40.5%20-u%20php-site%20php%20-pfqafG32rGpwvbcsof%20-e%20%22select%20*%20from%20other%22 [/code]

Router

У нас остался хост 172.16.50.50, но TCP-сканирование не дало результатов. Просканируем UDP. Нашли открытый SNMP порт (161 UDP). При помощи инструмента Onesixtyone получаем community-строки:

[code bash] onesixtyone -c /usr/share/john/password.lst 172.16.50.50 [/code]

Далее при помощи инструмента Snmpwalk попробуем получить информацию о сервере:

Анализируем вывод команды, замечаем странное имя системы, вероятно, это токен. Также находим упоминание о сети 172.16.60.0/24, предположив, что она доступна через этот сервер:

User

Прописываем у себя найденные маршруты. Открывается доступ к сети 172.16.60.0/24. В ней мы находим несколько систем (172.16.60.2-172.16.60.5), на которых открыт 22 порт:

Найденные ранее учётные данные не подошли, поэтому осуществим атаку методом перебора на логины пользователей. Нашли учётные записи sidorov, petrov:

Подключаемся к хостам с найденными учётными записями и исследуем их. На сервере 172.16.60.4 находим дамп в папке /opt и копируем его к себе для последующего разбора. На 172.16.60.3 находим папку .ssh, содержащую файл id_rsa, сохраняем его. На сервере 172.16.60.5 в папке /opt находим файл с токеном.

Dump

Исследуем найденный дамп при помощи инструмента Tcpdump:

[code bash] tcpdump -r /root/dump -A | grep token [/code]

В выводе команды находим токен и учётную запись leonov для сервера 172.16.0.21 (Git).

Добавим найденные учётные записи к имеющимся у нас.

GIT

Проходим авторизацию через веб-интерфейс:

Просматриваем комиты и находим среди них токен.

Certificate

Находим репозиторий certificate:

Клонируем проект и запускаем его. При запуске получаем приглашение ввести пароль. Видим, что проект ведёт себя также, как и certificate.so, полученный в задании Mail. Исследовав certificate.py, обнаруживаем, что он запрашивает пароль и использует его, предположительно, для расшифровки сертификата. Модифицируя исходный код, добавим в него вывод эталонного пароля и сертификата при вводе любой строки, кроме правильного пароля:

Сохраняем файл и запускаем программу. Снова запрашивается пароль, но, благодаря внесённым правкам, получаем токен и приватный ключ.

Задание можно было выполнить раньше, проведя декомпиляцию файла certificate.so.

Terminal-1

Просканировав сеть 172.16.40.0/24, находим открытый 22 порт на 172.16.40.2. Попробуем подключиться с известными учётными данными. Ни с одной учетной записью не удалось войти, но ранее мы обнаружили приватный ключ у пользователя sidorov, поэтому попробуем подключиться, используя его:

[code bash] ssh -i /root/id_rsa sidorov@172.16.40.2 [/code]

В /opt находим скрытый файл с токеном:

FPM

Далее с терминала открывается доступ к новым серверам в этой подсети. На 172.16.40.3 находим открытые 80 и 9000 порты. Подключившись по 80 порту, видим, что на сайте ведутся технические работы.

Далее начинаем фаззить сервис на 9000 порту (FPM). При помощи скрипта на Python получаем доступ FPM к серверу:

[code bash] python fpm.py 172.16.40.3 /var/www/admin.test.lab/index.php -c «<?php system('cat /opt/token'); ?>» [/code]

В выводе обнаружили токен.

Passwd_verify

Обнаруживаем хост 172.16.40.6, на котором доступен 22 порт. Проходим авторизацию, используя учётную запись пользователя sidorov, требуется ПИН:

Чтобы не тратить время на перебор, приступим к другим задачам. К сожалению, другие хосты из этой сети с терминала недоступны. Предполагаем, что доступ к ним можно получить только через машину с GH. Но даже несмотря на наличие проверки ПИН-кода, выполнить проброс портов можно:

[code bash] ssh -L 2222:172.16.40.4:22 sidorov@172.16.40.6 -i /tmp/id_rsa [/code]

При подключении к серверу не подошла ни одна учётная запись, даже sidorov с приватным ключом. Пробуем воспользоваться полученным из задания «Certificate»:

[code bash] ssh -p 2222 ivanov@127.0.0.1 -i /tmp/id_rsa_cert [/code]

На сервере 172.16.40.4 в папке /opt находим файл «revers», загружаем на локальный ПК и запускаем. При запуске получаем приглашение ввести пароль. Пробуем декомпилировать файл, выясняя в процессе, что введённый пароль сравнивается со строкой:

Предполагая, что это хеш пароля, попробуем его подобрать, но чтобы не тратить много времени, воспользуемся онлайн-сервисами:

Вводим пароль при запуске программы и получаем токен.

Elasticsearch

Это задание на анализ больших данных. Итак, пробрасываем порт:

[code]ssh -L 2222:172.16.40.6:22 sidorov@172.16.40.2 -i id_rsa
ssh -p2222 -L 9200:172.16.40.7:9200 sidorov@127.0.0.1 -i id_rsa [/code]

Открываем через браузер и проходим аутентификацию с учётными данными petrov:P@ssw0rd, найденными в 172.16.60.0/24:

Проанализировав во всех сообщениях содержимое поля text, обнаружили, что символ «|» встречается только дважды. Строка между ними и является токеном. На этом прохождение Test lab 14 завершено, спасибо, что дочитали до конца.

P.S.

Если все это показалось слишком сложным и хотите на практике разобраться, как это работает — пройдите обучение по программам Zero Security: A (базовая подготовка) или Корпоративные лаборатории Pentestit (расширенная подготовка) в области практической информационной безопасности.

До встречи в новой лаборатории!