Nginx уже давно используется в дикой природе. Мы все где-то видели имя NGINX при кодировании/взломе. NGINX всегда был мишенью для хакеров/охотников за ошибками из-за большого количества неверных конфигураций в нем, и нас, исследователей безопасности/охотников за ошибками, взлом веб-сервера всегда очаровывает. Сегодня мы увидим, как НА САМОМ ДЕЛЕ мы можем взломать NGINX, если он уязвим, и попытаемся получить от него немного денег.
Что ж, если вы новичок в этой теме и каким-то образом не знаете, как работает NGINX в качестве сервера, вот описание из Интернета: « Nginx создан для обеспечения низкого использования памяти и высокой степени параллелизма. Вместо того, чтобы создавать новые процессы для каждого веб-запроса, Nginx использует асинхронный, управляемый событиями подход, при котором запросы обрабатываются в одном потоке. В Nginx один главный процесс может управлять несколькими рабочими процессами. Мастер поддерживает рабочие процессы, в то время как рабочие выполняют фактическую обработку. Поскольку Nginx является асинхронным, каждый запрос может выполняться рабочим потоком одновременно, не блокируя другие запросы . «Очевидно, что с помощью NGINX можно многое сделать:
- Обратный прокси с кэшированием
- IPv6
- Балансировки нагрузки
- Поддержка FastCGI с кэшированием
- Веб-сокеты
- Обработка статических файлов, индексных файлов и автоиндексация
Поскольку NGINX является наиболее распространенным веб-сервером, который используется в наши дни, также существует множество проблем с безопасностью. Мы говорим о них сегодня: -
- Отсутствует корневая локация
- Псевдоним LFI неправильной конфигурации
- Чтение необработанного ответа бэкэнда
- Небезопасное использование переменных
- Отсутствует корневое местоположение:
Код:
server {
root /etc/nginx;
location /hack.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:1212/;
}
}В NGINX директива root указывает корневую папку. В этом примере корневой файл определен как /etc/nginx, это означает, что мы можем продолжить поиск nginx и файлов внутри него. Итак, здесь, если вы отправите простой запрос, такой как GET /nginx.conf, он раскроет некоторую конфиденциальную информацию, такую как конфигурация nginx и другие вещи. Поскольку «/» может обрабатывать любой запрос, мы можем отправить через него конфиденциальную конечную точку. В некоторых случаях можно получить доступ к другим файлам конфигурации и журналам доступа.
2. Неправильная конфигурация псевдонима LFI:
Всегда рекомендуется проверять операторы «местоположения» в конфигурации NGINX. Если вы найдете что-то вроде:
Код:
location /imgs {
alias /path/images/
}Вы можете продолжить и выполнить LFI здесь. Как? Разверните его до /imgs../secret.txt, и он превратится в /path/images/../secret.txt.
3. Чтение необработанного ответа бэкэнда:
С Nginx proxy_pass, есть возможность перехватывать ошибки и заголовки HTTP, созданные серверной частью. Это очень полезно, если вы хотите скрыть внутренние сообщения об ошибках и заголовки, чтобы они обрабатывались Nginx. Nginx автоматически отобразит пользовательскую страницу ошибки, если бэкэнд ответит ей.
Представьте, что есть такое приложение:
Код:
def application(environ, start_response):
start_response(‘500 Error’, [(‘Content-Type’, ‘text/html’, (‘Secret-Header’,’secret’)])
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;
}Итак, если мы отправим простой запрос GET, наш ответ будет примерно таким:
Код:
HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3
Content-Type: text/html
Content-Length: 15
Connection: closeНо что, если мы попытаемся отправить неверный запрос и проверим, что будет дальше? Что-то вроде этого:
Код:
GET /? XTTP/1.1
Host: 127.0.0.1
Connection: closeЕсли он уязвим, мы должны получить ответ с секретной информацией:
Код:
XTTP/1.1 500 Error
Content-Type: text/html
Secret-Header: secret
here we should get our secret info4. Небезопасное использование переменных:
Уязвимая конфигурация NGINX будет выглядеть так:
Код:
location / {
return 302 https://abcd.com$uri;
}Новые символы строки для HTTP-запросов: \r (возврат каретки) и \n (перевод строки). URL-кодирование символов новой строки приводит к следующему представлению символов %0d%0a. Когда эти символы включены в запрос, например http://localhost/ Hacker: testк серверу с неправильной конфигурацией, сервер ответит новым заголовком с именем HACKER, поскольку переменная $uri содержит символы новой строки, декодированные URL-адресом.
Код:
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 200
Connection: keep-alive
Location: https://abcd.com/
Hacker: test- proxy_pass и внутренние директивы: -
Это были некоторые распространенные сценарии атак, которые возникают в NGINX. Очевидно, что в этом продукте сообщается о большом количестве переполнений буфера, и всегда рекомендуется проверять все, что вы можете сделать на конкретном сервере. Поскольку NGINX также используется в качестве балансировщика нагрузки, там также возможен DOS. Однако чем больше они обновляют продукт, тем исчезают старые уязвимости. Поскольку он часто используется, есть вероятность, что возникнут новые уязвимости.
Я надеюсь, что вы получили что-то из этого блога. Старики знают, что многое из того, что упоминается в этом блоге, уже доступно в этом блоге, так что для этих парней немного. Но если вы новичок, вы наверняка получите от этого хорошие знания. Я надеюсь, что это поможет вам узнать пару вещей.
Перевел эту статью