Перейти к содержимому

HTB GreenHorn прохождение: от уязвимости Pluck CMS до root через Depix

HTB GreenHorn прохождение: от уязвимости Pluck CMS до root через Depix
Время чтения: 12 мин.

EPSS (Exploit Prediction Scoring System — оценка от 0 до 1, показывающая вероятность эксплуатации уязвимости в ближайшие 30 дней) для CVE-2023-50564 в Pluck CMS — 0.29. Это Top 5% среди всех зарегистрированных уязвимостей. На машине GreenHorn из HackTheBox именно она становится входной точкой для полного захвата сервера. Три открытых порта, один переиспользованный пароль и PDF с «замазанным» текстом вместо удалённого — набор ошибок, который встречается далеко не только на CTF-площадках. В этом HTB GreenHorn writeup разберём каждый шаг от первого сканирования до root-флага, с пояснением, почему именно такое действие и что произойдёт в терминале.

Цепочка атаки и техники MITRE ATT&CK

MITRE ATT&CK — открытая база тактик и техник атак. T-коды вроде T1190 или T1505.003 — её идентификаторы, которые используют в отчётах и правилах детектирования по всему миру. Если ты видишь T-код в чьём-то writeup или в SIEM-правиле — это ссылка именно на эту базу. Каждый шаг CTF прохождения машины GreenHorn соответствует конкретной технике:

Этап Действие MITRE ATT&CK
Credential Access Хеш пароля в Gitea-репозитории T1552.001 — Credentials In Files
Initial Access CVE-2023-50564: загрузка PHP-шелла в Pluck CMS T1190 — Exploit Public-Facing Application
Execution Reverse shell через веб-шелл T1505.003 — Web Shell, T1059.004 — Unix Shell
Lateral Movement Переиспользование пароля: su junior T1078.003 — Local Accounts
Discovery PDF с пикселизованным паролем root T1083 — File and Directory Discovery
Privilege Escalation Depix + su root T1078.003 — Local Accounts

Бизнес-логика атаки: злоумышленник находит утечку конфигурации в Git, получает административный доступ к CMS, загружает вредоносный код и двигается по системе через слабые и переиспользованные пароли. По данным IBM X-Force Threat Intelligence Index 2025, рост атак с использованием действительных учётных данных составил +71% за год. GreenHorn показывает ровно этот сценарий в миниатюре.

Требования к окружению

Прежде чем стартовать, проверь готовность:

  • ОС: Kali Linux 2023.1+ или Parrot OS — все инструменты уже предустановлены.
  • RAM: минимум 4 ГБ для виртуальной машины, рекомендуется 8 ГБ.
  • Сеть: активное VPN-подключение к HTB (файл .ovpn из кабинета HackTheBox).
  • Дополнительно: Python 3.8+ с pip (для Depix), доступ к CrackStation (crackstation.net) или установленный hashcat с словарём rockyou.txt.
  • Depix: клонируется из github.com/beurtschipper/Depix (архивированный проект, последний коммит — 2020, но функционально рабочий). Единственная зависимость — библиотека pillow (рекомендуется версия ≥10.3.0 из-за известных уязвимостей в более ранних версиях, включая GHSA-3wvg-mj6g-m9cv).

Контекст применимости: внешний пентест, CTF-среда. Техники работают против legacy-систем с CMS без WAF (Web Application Firewall — межсетевой экран уровня приложений) и без EDR (Endpoint Detection and Response — агент на хосте, который отслеживает подозрительное поведение процессов и сетевых соединений).

Разведка: сканирование портов и обнаружение Pluck CMS

Что ищем и зачем

Первый шаг на любой машине HTB — понять, какие сервисы доступны снаружи. Для этого используем nmap — сетевой сканер, который отправляет пакеты на все порты хоста и анализирует ответы. Запускаем быстрое сканирование: nmap -p- --min-rate 10000 10.10.11.25. Флаг -p- означает «все 65535 TCP-портов», а --min-rate 10000 разгоняет процесс до 10 000 пакетов в секунду. В CTF-среде это нормально, на реальном внешнем пентесте такая скорость почти наверняка вызовет алерты IDS/IPS (систем обнаружения и предотвращения вторжений).

Затем детальное сканирование найденных портов: nmap -p 22,80,3000 -sCV 10.10.11.25 (флаг -sC — скрипты по умолчанию, -sV — определение версий).

PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 8.9p1 Ubuntu
80/tcp   open  http     nginx 1.18.0 (Ubuntu)
3000/tcp open  ppp?

Порт 22 — SSH-сервер, без учётных данных бесполезен. Порт 80 — веб-сервер nginx, который перенаправляет на http://greenhorn.htb/. Чтобы браузер знал этот адрес, добавляем запись: echo '10.10.11.25 greenhorn.htb' | sudo tee -a /etc/hosts. Порт 3000 — nmap не определил сервис (пометка ppp?), но в заголовках ответа видны cookie i_like_gitea. Это Gitea — self-hosted Git-платформа, аналог GitHub для своего сервера. По версии OpenSSH (8.9p1) определяем, что на сервере скорее всего Ubuntu 22.04 LTS.

Веб-сайт на порту 80

Открываем http://greenhorn.htb/ в браузере. Сайт — блог для начинающих веб-разработчиков. В подвале страницы — ссылка «admin» (ведёт на /login.php) и ссылка «pluck» на GitHub-вики. Страница /login.php сообщает версию CMS: Pluck 4.7.18. Pluck — лёгкая PHP-система управления контентом с открытым исходным кодом. Форма входа требует только пароль без имени пользователя — механизм аутентификации настолько упрощённый, что сразу наводит на мысль о слабых проверках.

В HTTP-заголовках ответа виден cookie PHPSESSID — подтверждение, что бэкенд на PHP. URL-паттерн /?file=welcome-to-greenhorn указывает на файловую маршрутизацию, характерную для Pluck.

Gitea на порту 3000

Переходим на http://greenhorn.htb:3000. Gitea позволяет просматривать публичные репозитории без аутентификации — нажимаем «Explore» и находим репозиторий GreenHorn. Это исходный код того самого Pluck CMS с порта 80.

Почему это критично: согласно документации Pluck CMS, хеш пароля администратора хранится в файле data/settings/pass.php. Открываем этот файл в репозитории Gitea:

<?php
$ww = 'd5443aef1b64544f3685bf112f6c405218c573c7279a831b1fe9612e3a4d770486743c5580556c0d838b51749de15530f87fb793afdcc689b6b39024d7790163';
?>

Переменная $ww содержит SHA-512 хеш пароля. В коде login.php видно, что Pluck вычисляет SHA-512 от введённого пароля и сравнивает с $ww — без salt (случайных данных, которые добавляются к паролю перед хешированием; без них одинаковые пароли всегда дают одинаковые хеши, и их можно искать по готовым таблицам). Это T1552.001 по MITRE ATT&CK — учётные данные в открытом доступе через внешний сервис.

Pluck CMS уязвимость RCE: от хеша до веб-шелла

Взлом хеша

SHA-512 хеш без salt проверяется через радужные таблицы (предвычисленные базы «хеш → пароль») за секунды. Вставляем хеш в CrackStation (crackstation.net) — результат: пароль iloveyou1.

Альтернатива — офлайн-брутфорс: hashcat -m 1700 hash.txt /usr/share/wordlists/rockyou.txt. Режим -m 1700 соответствует SHA-512, rockyou.txt — словарь из крупнейших утечек паролей. Пароль iloveyou1 входит в этот словарь, поэтому ломается мгновенно.

Работает если: хеш вычислен без salt и без итеративных алгоритмов (bcrypt, argon2). Если бы Pluck использовал bcrypt — CrackStation не помог бы, а перебор через hashcat потребовал бы часы или дни даже с GPU.

Эксплуатация CVE-2023-50564

Вводим iloveyou1 на странице /login.php — попадаем в админ-панель.

CVE-2023-50564 — уязвимость загрузки произвольных файлов (CWE-434 — Unrestricted Upload of File with Dangerous Type) в компоненте /inc/modules_install.php Pluck CMS v4.7.18. CVSS 8.8 (HIGH). Разберём вектор по компонентам: AV:N — атака по сети, AC:L — низкая сложность, PR:L — нужны привилегии уровня администратора CMS, UI:N — без участия пользователя, C:H/I:H/A:H — полная компрометация конфиденциальности, целостности и доступности.

Суть: Pluck позволяет загружать ZIP-архивы с модулями через админ-панель, но не проверяет содержимое. Можно упаковать PHP-файл с произвольным кодом — сервер распакует его в директорию модулей и исполнит при обращении по URL. Иногда эту уязвимость описывают как «инъекцию команд Pluck CMS», но технически это именно загрузка файлов без валидации — CWE-434.

Получение reverse shell (обратного шелла — соединения, которое инициирует сервер-жертва к машине атакующего, а не наоборот):

Шаг 1. Берём стандартный PHP reverse shell из /usr/share/webshells/php/php-reverse-shell.php (предустановлен в Kali). Открываем файл, меняем IP на свой (адрес интерфейса tun0, виден через ip addr show tun0) и порт на 4444. Упаковываем: zip shell.zip shell.php.

Шаг 2. На своей машине запускаем слушатель: nc -lnvp 4444. Флаг -l — слушать, -n — без DNS, -v — подробный вывод, -p 4444 — порт. В терминале появится надпись «Listening on 0.0.0.0 4444» — слушатель активен.

Шаг 3. В админ-панели Pluck переходим в «Manage modules» и загружаем shell.zip через форму. После загрузки обращаемся к http://greenhorn.htb/data/modules/shell/shell.php — в терминале с netcat появляется сессия от www-data@greenhorn. Это пользователь, под которым работает веб-сервер.

Когда CVE-2023-50564 не работает

  • Без аутентификации в админ-панели эксплуатация невозможна — уязвимость требует PR:L.
  • WAF (ModSecurity с CRS, Cloudflare WAF) блокирует загрузку ZIP с PHP по сигнатурам содержимого.
  • AppArmor или SELinux на сервере могут запретить исполнение PHP из директории модулей.
  • CISA SSVC Decision для этой CVE — Track (мониторить): exploitation: none, automatable: no — массовой эксплуатации в реальных атаках не зафиксировано, несмотря на высокий EPSS.
  • Pluck CMS версий, отличных от 4.7.18, может содержать исправление или иную логику загрузки модулей.

Повышение привилегий Linux CTF: Depix и восстановление пикселизованного пароля

Переход на пользователя junior

От www-data нужно подняться выше. Команда cat /etc/passwd | grep bash покажет учётные записи с интерактивным shell — на GreenHorn это junior и root.

Пробуем переиспользование паролей: su junior с паролем iloveyou1 — и он подходит. Промпт сменится на junior@greenhorn. Читаем первый флаг: cat /home/junior/user.txt.

Это T1078.003 (Local Accounts) — использование валидных учётных данных одного сервиса для доступа к учётной записи ОС. На внутренних пентестах переиспользование паролей — одна из самых частых находок. Один пароль на CMS, SSH и почту — классика, которую я вижу раз за разом.

PDF с «замазанным» паролем root

В домашней директории junior лежит PDF-файл. Внутри — скриншот с текстом, где пароль root «замазан» мозаичным фильтром (пикселизацией). Обнаружение этого файла — T1083 (File and Directory Discovery): после получения доступа к системе атакующий ищет документы с чувствительными данными.

Автор машины этим показывает простую вещь: пикселизация — не способ удаления информации. Она создаёт иллюзию безопасности, не более.

Depix: восстановление пикселизованного пароля

Depix — Python-инструмент для деобфускации пикселизованного текста. Принцип работы: Depix берёт эталонное изображение De Bruijn sequence (набор всех возможных пиксельных комбинаций для конкретного шрифта) и сопоставляет блоки мозаики с блоками эталона. Если мозаика линейная (каждый блок — среднее значение исходных пикселей), процесс детерминирован: одни входные данные всегда дают один результат. Depix просто находит соответствие.

Шаг 1. Извлекаем изображение из PDF утилитой pdfimages (пакет poppler-utils, предустановлен в Kali): pdfimages -png file.pdf output. На выходе — один или несколько PNG-файлов; нужен тот, что содержит пикселизованный текст.

Шаг 2. Клонируем Depix и устанавливаем зависимость: git clone https://github.com/beurtschipper/Depix.git && cd Depix && pip install "pillow>=10.3.0".

Шаг 3. Запускаем восстановление:

python3 depix.py \
  -p images/pixelized_password.png \
  -s images/searchimages/debruijn.png \
  -o output.png

Флаг -p — путь к пикселизованному изображению, -s — эталонная De Bruijn sequence (поставляется в репозитории Depix), -o — результат. Процесс занимает от нескольких секунд до пары минут.

В output.png будет восстановленный текст пароля. Качество зависит от размера блоков пикселизации (мелкие блоки до 5 пикселей дают лучший результат) и совпадения шрифта с эталоном.

Шаг 4. Используем восстановленный пароль: su root, вводим пароль из output.png. Промпт изменится на root@greenhorn — читаем cat /root/root.txt. Второй флаг. Машина пройдена.

Почему пикселизация — не защита

Пикселизация заменяет блок пикселей их средним значением. Процесс детерминированный — при известном шрифте и размере символов пространство перебора конечно. Это фундаментально отличается от реального удаления:

Метод маскировки Обратимо Причина
Пикселизация / размытие Да Depix сопоставляет блоки с эталоном
Чёрный прямоугольник в PDF-редакторе Да Текст остаётся в слое под прямоугольником
Удаление текста из PDF с пересохранением Нет Текст удалён из объектов файла
Замена символов на случайные Нет Оригинал не восстановим

На реальных пентестах PDF с «замазанными» паролями, ключами API и персональными данными — не экзотика. Особенно в документации, которую передают подрядчикам или публикуют во внутренних wiki. Техника деобфускации пикселизованного текста применима везде, где используется мозаичный фильтр стандартного шрифта.

Ограничения и детектирование

Предусловия каждого этапа

Цепочка GreenHorn работает при совпадении конкретных условий. Разрыв любого звена останавливает атаку:

  • Gitea без аутентификации. Если Gitea требует логин для просмотра репозиториев (штатная опция в настройках) — хеш не утекает, атака останавливается на разведке. На практике: всегда проверяйте настройки видимости репозиториев при деплое Gitea.
  • SHA-512 без salt. Bcrypt или argon2 с солью делают радужные таблицы бесполезными. Hashcat потребует на порядки больше ресурсов.
  • CVE-2023-50564 — только Pluck CMS v4.7.18. Другие версии могут не содержать эту уязвимость.
  • Переиспользование пароля. Уникальный пароль у junior потребует альтернативных векторов: SSH-ключи в /home, sudo -l, cron-задачи, SUID-бинарники.
  • Depix. Крупные блоки мозаики (более 15 пикселей) или нестандартный шрифт приводят к частичному или нулевому восстановлению. Depix заточен под линейную пикселизацию моноширинных шрифтов.

Что видит защитная сторона

На реальном сервере с мониторингом каждый шаг оставляет артефакты:

  • Загрузка ZIP через Pluck. POST на /inc/modules_install.php + последующий GET к новому PHP-файлу фиксируются в nginx access log. ModSecurity с CRS (Core Rule Set) блокирует PHP внутри архивов. Cloudflare WAF детектирует паттерны reverse shell в теле запроса.
  • Reverse shell. Исходящее TCP-соединение от процесса www-data на нестандартный порт. CrowdStrike Falcon обнаруживает это через behavioral analysis: веб-серверный процесс не должен устанавливать исходящих TCP на произвольные порты. Elastic Defend 8.x+ ловит аналогичное через правила обнаружения аномального parent-child process lineage (веб-сервер → shell). SentinelOne обнаруживает аномальную сетевую активность из контекста веб-серверного процесса.
  • su от www-data. Запись в /var/log/auth.log. SIEM-правило: su от www-data к любому пользователю — аномалия, которая при штатной работе не встречается никогда.

GreenHorn намеренно не содержит EDR, WAF и SIEM — это учебная среда. На боевой инфраструктуре Ubuntu 22.04 с Canonical STIG compliance и EDR-агентом эта цепочка была бы заблокирована или обнаружена на нескольких этапах.

Три вещи, которые остаются после GreenHorn. Привычка проверять Git-инстансы: разработчики коммитят секреты постоянно, и по данным Mandiant M-Trends 2025, эксплоиты (38%) — самый распространённый вектор initial access. Понимание, что CMS с загрузкой модулей без валидации — это практически гарантированный RCE. И осознание, что визуальная маскировка не равна удалению — Depix восстановление пикселизованного пароля занимает минуты.

Главная ценность Easy-машин — не сложность техник, а формирование цепочечного мышления. Новички часто знают инструменты по отдельности — nmap, hashcat, netcat — но не видят, как результат одного шага становится входом для следующего. Сканирование даёт Gitea, Gitea даёт хеш, хеш открывает CMS, CMS даёт шелл, шелл даёт PDF, PDF даёт root. Разорви любое звено — цепочка рассыпается. Если хочешь выстроить такое мышление системно, а не тыкаться наугад от машины к машине — на IB Basics в Codeby Academy показывают, как связывать техники в цепочки и понимать логику каждого шага.

Эту тему и смежные навыки разбирают на практике в курсе «Тестирование веб-приложений на проникновение (WAPT)» Codeby Academy.