Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

Nginx

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Миттєве налаштування для оцінки вразливостей та тестування на проникнення. Виконуйте повний пентест з будь-якого місця за допомогою 20+ інструментів та функцій, які охоплюють рекон, звітність. Ми не замінюємо пентестерів - ми розробляємо власні інструменти, модулі виявлення та експлуатації, щоб дати їм можливість краще досліджувати, виконувати атаки та отримувати задоволення.

Відсутній кореневий каталог

Основи налаштування кореневого каталогу Nginx

При налаштуванні сервера Nginx директива root відіграє критичну роль, визначаючи базовий каталог, з якого постачаються файли. Розгляньте наступний приклад:

server {
root /etc/nginx;

location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}

У цій конфігурації /etc/nginx визначено як кореневий каталог. Це дозволяє доступ до файлів у вказаному кореневому каталозі, таких як /hello.txt. Проте важливо зауважити, що визначено лише конкретне місце (/hello.txt). Немає конфігурації для кореневого місця (location / {...}). Це упущення означає, що директива root застосовується глобально, дозволяючи запитам до кореневого шляху / отримувати доступ до файлів у /etc/nginx.

З цієї конфігурації виникає важливе питання безпеки. Простий запит GET, наприклад GET /nginx.conf, може розкрити чутливу інформацію, надаючи конфігураційний файл Nginx, розташований у /etc/nginx/nginx.conf. Встановлення кореня у менш чутливий каталог, наприклад /etc, може пом'якшити цей ризик, але все ще може дозволити ненавмисний доступ до інших критичних файлів, включаючи інші конфігураційні файли, журнали доступу та навіть зашифровані облікові дані, використовувані для базової аутентифікації HTTP.

Помилка конфігурації LFI через псевдонім

У конфігураційних файлах Nginx варто уважно перевірити директиви "location". Уразливість, відома як Локальне включення файлів (LFI), може бути ненавмисно введена через конфігурацію, яка нагадує наступне:

location /imgs {
alias /path/images/;
}

Ця конфігурація схильна до атак LFI через те, що сервер інтерпретує запити, такі як /imgs../flag.txt, як спробу доступу до файлів за межами призначеного каталогу, ефективно розгортаючи /path/images/../flag.txt. Цей недолік дозволяє зловмисникам отримувати файли з файлової системи сервера, до яких не повинен бути доступ через веб.

Для зменшення цієї вразливості конфігурацію слід налаштувати на:

location /imgs/ {
alias /path/images/;
}

Додаткова інформація: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Тести Accunetix:

alias../ => HTTP status code 403
alias.../ => HTTP status code 404
alias../../ => HTTP status code 403
alias../../../../../../../../../../../ => HTTP status code 400
alias../ => HTTP status code 403

Небезпечне обмеження шляху

Перевірте наступну сторінку, щоб дізнатися, як обійти директиви, такі як:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Використання небезпечних змінних / Розділення HTTP-запитів

Вразливі змінні $uri та $document_uri, їх можна виправити, замінивши їх на $request_uri.

Регулярний вираз також може бути вразливим, наприклад:

location ~ /docs/([^/])? { … $1 … } - Вразливий

location ~ /docs/([^/\s])? { … $1 … } - Не вразливий (перевірка пробілів)

location ~ /docs/(.*)? { … $1 … } - Не вразливий

Помилка в конфігурації Nginx демонструється наступним прикладом:

location / {
return 302 https://example.com$uri;
}

Символи \r (повернення каретки) та \n (перехід на новий рядок) позначають символи нового рядка в HTTP-запитах, а їх URL-кодовані форми представлені як %0d%0a. Включення цих символів у запит (наприклад, http://localhost/%0d%0aDetectify:%20clrf) до неправильно налаштованого сервера призводить до видання сервером нового заголовка під назвою Detectify. Це стається через те, що змінна $uri декодує URL-кодовані символи нового рядка, що призводить до неочікуваного заголовка у відповіді:

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://example.com/
Detectify: clrf

Дізнайтеся більше про ризики впровадження CRLF та розділення відповіді за посиланням https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Ця техніка також пояснюється в цьому виступі з деякими вразливими прикладами та механізмами виявлення. Наприклад, для виявлення цієї неправильної конфігурації з точки зору чорної скриньки ви можете використовувати такі запити:

  • https://example.com/%20X - Будь-який HTTP-код

  • https://example.com/%20H - 400 Поганий запит

Якщо вразливий, перший запит поверне "X", оскільки це будь-який метод HTTP, а другий викличе помилку, оскільки H не є дійсним методом. Таким чином, сервер отримає щось на зразок: GET / H HTTP/1.1, що викличе помилку.

Інші приклади виявлення:

  • http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Будь-який HTTP-код

  • http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Поганий запит

Деякі знайдені вразливі конфігурації, представлені в цьому виступі, були:

  • Зверніть увагу, як $uri встановлено таким, як є, у кінцевому URL

location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}

  • Зверніть увагу, як знову $uri знаходиться в URL (цього разу всередині параметра)

location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
proxy_pass http://$back;

  • Зараз у AWS S3

location /s3/ {
proxy_pass https://company-bucket.s3.amazonaws.com$uri;
}

Будь-яка змінна

Було виявлено, що дані, надані користувачем, можуть бути розглянуті як змінна Nginx в певних обставинах. Причина цього поведінки залишається дещо невловимою, але це не рідкість і не так просто перевірити. Ця аномалія була підкреслена в звіті про безпеку на HackerOne, який можна переглянути тут. Подальше дослідження повідомлення про помилку призвело до ідентифікації її виникнення в модулі фільтрації SSI кодової бази Nginx, вказавши Server Side Includes (SSI) як корінь проблеми.

Для виявлення цієї неправильної конфігурації можна виконати наступну команду, яка включає встановлення заголовка referer для перевірки друку змінної:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

Скани для цієї неправильної конфігурації по системах показали кілька випадків, де змінні Nginx можуть бути надруковані користувачем. Однак зменшення кількості вразливих випадків свідчить про те, що зусилля з усунення цієї проблеми були дещо успішними.

Читання відповіді віддаленого сервера в необробленому вигляді

Nginx пропонує функцію через proxy_pass, яка дозволяє перехоплювати помилки та HTTP-заголовки, що генеруються сервером, з метою приховування внутрішніх повідомлень про помилки та заголовків. Це досягається за допомогою Nginx, який обслуговує власні сторінки помилок у відповідь на помилки сервера. Однак виникають труднощі, коли Nginx стикається з недійсним запитом HTTP. Такий запит переадресовується на сервер, як отримано, і необроблена відповідь сервера потім надсилається клієнту без втручання Nginx.

Розгляньте приклад сценарію, що включає додаток uWSGI:

def application(environ, start_response):
start_response('500 Error', [('Content-Type', 'text/html'), ('Secret-Header', 'secret-info')])
return [b"Secret info, should not be visible!"]

Для управління цим використовуються конкретні директиви в конфігурації Nginx:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}

  • proxy_intercept_errors: Ця директива дозволяє Nginx обслуговувати власну відповідь для відповідей від сервера з кодом стану більше 300. Вона забезпечує те, що для нашої прикладної програми uWSGI відповідь 500 Error перехоплюється та обробляється Nginx.

  • proxy_hide_header: Як саме назва вказує, ця директива приховує вказані HTTP заголовки від клієнта, підвищуючи конфіденційність та безпеку.

Коли здійснюється дійсний запит GET, Nginx обробляє його нормально, повертаючи стандартну відповідь про помилку, не розкриваючи жодних секретних заголовків. Однак недійсний HTTP-запит обходить цей механізм, що призводить до розкриття сирої відповіді від сервера, включаючи секретні заголовки та повідомлення про помилки.

merge_slashes встановлено на off

За замовчуванням директива merge_slashes Nginx встановлена на on, що стискає кілька послідовних косих рисок в URL в одну риску. Ця функція, хоча й спрощує обробку URL, може ненавмисно приховати вразливості в програмах за Nginx, особливо тих, які схильні до атак на локальне включення файлів (LFI). Експерти з безпеки Danny Robinson та Rotem Bar підкреслили потенційні ризики, пов'язані з цією типовою поведінкою, особливо коли Nginx діє як зворотний проксі-сервер.

Для зменшення таких ризиків рекомендується вимкнути директиву merge_slashes для програм, які вразливі до цих загроз. Це забезпечує, що Nginx пересилає запити до програми без зміни структури URL, тим самим не маскуючи жодних потенційних проблем безпеки.

Для отримання додаткової інформації перегляньте статтю Danny Robinson та Rotem Bar.

Значення за замовчуванням в директиві Map

У конфігурації Nginx директива map часто відіграє роль у контролі авторизації. Частою помилкою є не вказання значення за замовчуванням, що може призвести до несанкціонованого доступу. Наприклад:

http {
map $uri $mappocallow {
/map-poc/private 0;
/map-poc/secret 0;
/map-poc/public 1;
}
}
server {
location /map-poc {
if ($mappocallow = 0) {return 403;}
return 200 "Hello. It is private area: $mappocallow";
}
}

Без default зловмисний користувач може обійти безпеку, отримавши доступ до невизначеного URI всередині /map-poc. Довідка Nginx рекомендує встановити значення за замовчуванням, щоб уникнути таких проблем.

Уразливість DNS-підробки

DNS-підробка проти Nginx можлива за певних умов. Якщо зловмисник знає DNS-сервер, який використовується Nginx, і може перехоплювати його DNS-запити, він може підробити DNS-записи. Однак цей метод не ефективний, якщо Nginx налаштований використовувати localhost (127.0.0.1) для розгортання DNS. Nginx дозволяє вказати DNS-сервер наступним чином:

resolver 8.8.8.8;

Директиви proxy_pass та internal

Директива proxy_pass використовується для перенаправлення запитів на інші сервери, як внутрішньо, так і зовнішньо. Директива internal забезпечує доступ лише до певних ресурсів всередині Nginx. Хоча ці директиви не є вразливостями самі по собі, їх конфігурація вимагає ретельного аналізу для запобігання порушень безпеки.

proxy_set_header Upgrade & Connection

Якщо сервер nginx налаштований на передачу заголовків Upgrade та Connection, можлива атака зі зміною протоколу h2c для доступу до захищених/внутрішніх кінцевих точок.

Ця вразливість дозволить зловмиснику встановити пряме з'єднання з кінцевою точкою proxy_pass (http://backend:9999 у цьому випадку), контент якої не буде перевірений nginx.

Приклад вразливої конфігурації для викрадення /flag можна знайти тут:

server {
listen       443 ssl;
server_name  localhost;

ssl_certificate       /usr/local/nginx/conf/cert.pem;
ssl_certificate_key   /usr/local/nginx/conf/privkey.pem;

location / {
proxy_pass http://backend:9999;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
}

location /flag {
deny all;
}

Зверніть увагу, що навіть якщо proxy_pass вказує на конкретний шлях, такий як http://backend:9999/socket.io, з'єднання буде встановлено з http://backend:9999, тому ви можете звертатися до будь-якого іншого шляху всередині цільової внутрішньої точки. Тому не має значення, чи вказаний шлях в URL proxy_pass.

Спробуйте самі

Detectify створив репозиторій GitHub, де ви можете використовувати Docker, щоб налаштувати свій власний вразливий тестовий сервер Nginx з деякими неправильними налаштуваннями, що обговорюються в цій статті, і спробувати знайти їх самостійно!

https://github.com/detectify/vulnerable-nginx

Інструменти статичного аналізу

GIXY

Gixy - це інструмент для аналізу конфігурації Nginx. Основна мета Gixy - запобігання неправильним налаштуванням безпеки та автоматизація виявлення дефектів.

Nginxpwner

Nginxpwner - це простий інструмент для пошуку загальних неправильних налаштувань та вразливостей Nginx.

Посилання

Миттєве налаштування для оцінки вразливостей та тестування на проникнення. Виконайте повний тест на проникнення з будь-якого місця за допомогою 20+ інструментів та функцій, які охоплюють реконструкцію, звітність. Ми не замінюємо тестувальників на проникнення - ми розробляємо власні інструменти, модулі виявлення та експлуатації, щоб дати їм можливість краще досліджувати, виконувати атаки та насолоджуватися цим.

Вивчіть хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

PreviousMoodleNextPHP Tricks

Last updated