Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +00:00

Translator 19f4e55921 Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/REA

2024-04-07 03:13:19 +00:00

18 KiB

Raw Blame History

Nginx

AWS hacklemeyi sıfırdan ileri seviyeye öğrenin htARTE (HackTricks AWS Red Team Expert) ile!

HackTricks'ı desteklemenin diğer yolları:

Şirketinizi HackTricks'te reklamını görmek istiyorsanız veya HackTricks'i PDF olarak indirmek istiyorsanız ABONELİK PLANLARI'na göz atın!
Resmi PEASS & HackTricks ürünlerini edinin
The PEASS Family'yi keşfedin, özel NFT'lerimiz koleksiyonumuzu
💬 Discord grubumuza katılın veya telegram grubumuza katılın veya bizi Twitter'da 🐦 @carlospolopm** takip edin.**
Hacking püf noktalarınızı paylaşarak PR'lar göndererek HackTricks ve HackTricks Cloud github depolarına katkıda bulunun.

Hemen kullanıma hazır zafiyet değerlendirme ve penetrasyon testi kurulumu. 20'den fazla araç ve özellikle tam bir pentest çalıştırın, keşiften raporlamaya kadar uzanan. Pentester'ları değiştirmiyoruz - özel araçlar, tespit ve istismar modülleri geliştiriyoruz, böylece daha derine inmek, kabukları patlatmak ve eğlenmek için zaman kazanıyorlar.

{% embed url="https://pentest-tools.com/" %}

Eksik kök konumu

Nginx Kök Dizini Yapılandırmanın Temelleri

Nginx sunucusunu yapılandırırken, root direktifi dosyaların sunulduğu temel dizini tanımlayarak kritik bir rol oynar. Aşağıdaki örneği göz önünde bulundurun:

server {
root /etc/nginx;

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

Bu yapılandırmada, /etc/nginx kök dizini olarak belirlenmiştir. Bu kurulum, belirtilen kök dizini içindeki dosyalara erişime izin verir, örneğin /hello.txt. Ancak, yalnızca belirli bir konum (/hello.txt) tanımlanmıştır. Kök konum (location / {...}) için herhangi bir yapılandırma bulunmamaktadır. Bu ihmal, kök yönergesinin genel olarak uygulanmasını sağlar ve /etc/nginx altındaki dosyalara erişim sağlar.

Bu yapılandırmadan kaynaklanan önemli bir güvenlik düşüncesi ortaya çıkar. Basit bir GET isteği, örneğin GET /nginx.conf, /etc/nginx/nginx.conf konumundaki Nginx yapılandırma dosyasını sunarak hassas bilgilerin ifşa edilmesine neden olabilir. Kökü daha az hassas bir dizine, örneğin /etc olarak ayarlamak, bu riski azaltabilir, ancak yine de diğer hassas dosyalara, diğer yapılandırma dosyalarına, erişim günlüklerine ve hatta HTTP temel kimlik doğrulaması için kullanılan şifrelenmiş kimlik bilgilerine istenmeyen erişime izin verebilir.

Alias LFI Yan Yapılandırması

Nginx'in yapılandırma dosyalarında, "location" yönergeleri için dikkatli bir inceleme gereklidir. Bir Local File Inclusion (LFI) olarak bilinen bir zafiyet, aşağıdakine benzer bir yapılandırma aracılığıyla yanlışlıkla tanıtılabilir:

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

Bu yapılandırma, sunucunun /imgs../flag.txt gibi istekleri yorumlayarak, dosyaların amaçlanan dizinin dışındaki dosyalara erişme girişimi olarak algılanmasına neden olan LFI saldırılarına duyarlıdır ve etkili bir şekilde /path/images/../flag.txt'ye çözülür. Bu zayıflık, saldırganların sunucunun dosya sisteminden web aracılığıyla erişilememesi gereken dosyaları almasına olanak tanır.

Bu zafiyeti hafifletmek için yapılandırma şu şekilde ayarlanmalıdır:

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

Daha fazla bilgi: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Accunetix testleri:

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

Güvensiz yol kısıtlaması

Aşağıdaki sayfayı kontrol edin:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Güvensiz değişken kullanımı / HTTP İsteği Bölme

{% hint style="danger" %} $uri ve $document_uri gibi güvenlik açıklı değişkenler bulunmaktadır ve bunlar $request_uri ile değiştirilerek düzeltilebilir.

Ayrıca regex de şu şekilde güvenlik açıklı olabilir:

location ~ /docs/([^/])? { … $1 … } - Güvenlik açıklı

location ~ /docs/([^/\s])? { … $1 … } - Güvenlik açıklı değil (boşlukları kontrol eder)

location ~ /docs/(.*)? { … $1 … } - Güvenlik açıklı değil {% endhint %}

Nginx yapılandırmasındaki bir güvenlik açığı aşağıdaki örnekle gösterilmektedir:

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

HTTP isteklerinde \r (Taşıma İşareti) ve \n (Satır Beslemesi) karakterleri yeni satır karakterlerini belirtir ve URL kodlanmış halleri %0d%0a olarak temsil edilir. Bu karakterleri bir istekte (örneğin, http://localhost/%0d%0aDetectify:%20clrf) içerdiğinde yanlış yapılandırılmış bir sunucu, Detectify adında yeni bir başlık çıkarır. Bu durum, $uri değişkeninin URL kodlanmış yeni satır karakterlerini çözmesi nedeniyle yanıtta beklenmeyen bir başlık oluşmasına yol açar:

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

Risks of CRLF injection and response splitting at https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/ hakkında daha fazla bilgi edinin.

Bu teknik ayrıca bu konuşmada bazı zayıf örnekler ve tespit mekanizmaları ile açıklanmıştır. Örneğin, Bu yanlış yapılandırmayı bir blackbox bakış açısından tespit etmek için şu istekleri yapabilirsiniz:

https://example.com/%20X - Herhangi bir HTTP kodu
https://example.com/%20H - 400 Bad Request

Eğer zayıfsa, ilk istek "X" herhangi bir HTTP yöntemi olarak dönecek ve ikincisi H geçerli bir yöntem olmadığı için bir hata dönecektir. Bu nedenle sunucu şuna benzer bir şey alacak: GET / H HTTP/1.1 ve bu hata oluşturacaktır.

Başka tespit örnekleri şunlar olabilir:

http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Herhangi bir HTTP kodu
http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request

O konuşmada bulunan bazı zayıf yapılandırmalar şunlardı:

$uri'nin nihai URL'de olduğu gibi ayarlandığına dikkat edin

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

Yine $uri URL'de (bu sefer bir parametre içinde) bulunmaktadır.

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

Şimdi AWS S3'te

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

Herhangi bir değişken

Belirli koşullar altında, kullanıcı tarafından sağlanan verilerin belirli durumlarda bir Nginx değişkeni olarak işleme tabi tutulabileceği keşfedildi. Bu davranışın nedeni oldukça belirsiz olsa da, nadir değil ve doğrulaması da kolay değil. Bu anormallik, HackerOne'da bir güvenlik raporunda vurgulandı ve buradan görülebilir. Hata mesajına yönelik daha fazla inceleme, bu durumun Nginx'in kod tabanındaki SSI filtre modülünde meydana geldiğinin belirlenmesine yol açtı ve Server Side Includes (SSI)'ı kök neden olarak işaret etti.

Bu yan yapılandırmayı tespit etmek için, aşağıdaki komut çalıştırılabilir, bu komut değişken yazdırma testi için bir referer başlığı ayarlamayı içerir:

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

Sistemler üzerinde bu yan yapılandırma için yapılan taramalar, Nginx değişkenlerinin bir kullanıcı tarafından yazdırılabileceği birden fazla örneği ortaya çıkardı. Ancak, savunmasız örneklerin sayısındaki azalma, bu sorunu düzeltme çabalarının bir dereceye kadar başarılı olduğunu göstermektedir.

Ham arka uç yanıtı okuma

Nginx, proxy_pass aracılığıyla sunucu hatalarını ve arka uç tarafından üretilen HTTP başlıklarını yakalamayı sağlayan bir özellik sunar, iç hata mesajlarını ve başlıkları gizlemeyi amaçlar. Bu, Nginx'in, arka uç hatalarına yanıt olarak özel hata sayfaları sunarak başarılı bir şekilde gerçekleştirilir. Bununla birlikte, Nginx'in geçersiz bir HTTP isteğiyle karşılaştığında zorluklar ortaya çıkar. Bu tür bir istek, alındığı gibi arka uca iletilir ve ardından arka uçun ham yanıtı doğrudan Nginx'in müdahalesi olmadan istemciye gönderilir.

Bir uWSGI uygulamasını içeren bir örnek senaryoyu düşünün:

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 yapılandırmasında belirli direktifler kullanılarak bunu yönetmek mümkündür:

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

proxy_intercept_errors: Bu yönerge, Nginx'in durum kodu 300'den büyük olan arka uç yanıtları için özel bir yanıt sunmasını sağlar. Örneğimizde uWSGI uygulaması için, bir 500 Hata yanıtının Nginx tarafından engellenip işlenmesini sağlar.
proxy_hide_header: Adından da anlaşılacağı gibi, bu yönerge belirli HTTP başlıklarını istemciden gizler, gizliliği ve güvenliği artırır.

Geçerli bir GET isteği yapıldığında, Nginx bunu normal şekilde işler, hiçbir gizli başlığı ortaya çıkarmadan standart bir hata yanıtı döndürür. Ancak geçersiz bir HTTP isteği bu mekanizmayı atlar ve gizli başlıkları ve hata mesajlarını da içeren ham arka uç yanıtlarının ortaya çıkmasına neden olur.

merge_slashes off olarak ayarlandı

Varsayılan olarak, Nginx'in merge_slashes yönergesi on olarak ayarlanmıştır, bu da bir URL'deki birden fazla ileri eğik çizgiyi tek bir eğik çizgiye sıkıştırır. Bu özellik, URL işleme sürecini basitleştirirken, Nginx'in arkasındaki uygulamalardaki zafiyetleri yanlışlıkla gizleyebilir, özellikle yerel dosya dahil etme (LFI) saldırılarına duyarlı olanlar. Güvenlik uzmanları Danny Robinson ve Rotem Bar, özellikle Nginx'in ters proxy olarak hareket ettiğinde bu varsayılan davranışla ilişkili potansiyel riskleri vurgulamışlardır.

Bu tür riskleri azaltmak için, bu zafiyetlere duyarlı uygulamalar için merge_slashes yönergesini kapatmanız önerilir. Bu, Nginx'in URL yapısını değiştirmeden istekleri uygulamaya ilettiğinden, altta yatan güvenlik sorunlarını gizlemeden işlem yapmasını sağlar.

Daha fazla bilgi için Danny Robinson ve Rotem Bar.

Harita Yönergesindeki Varsayılan Değer

Nginx yapılandırmasında, map yönergesi genellikle yetkilendirme kontrolünde rol oynar. Yaygın bir hata, varsayılan bir değer belirtmemektir, bu da yetkisiz erişime yol açabilir. Örneğin:

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 olmadan, bir kötü niyetli kullanıcı, /map-poc içinde tanımsız bir URI'ye erişerek güvenlik önlemlerini atlayabilir. Nginx kılavuzu, bu tür sorunları önlemek için bir varsayılan değer belirlemenizi önerir.

DNS Sahteciliği Zafiyeti

Belirli koşullar altında Nginx'e karşı DNS sahteciliği mümkündür. Bir saldırgan, Nginx'in kullandığı DNS sunucusunu bildiğinde ve DNS sorgularını onaylayabildiğinde DNS kayıtlarını sahtecilik yapabilir. Ancak, Nginx'in DNS çözümlemesi için localhost (127.0.0.1)'i kullanacak şekilde yapılandırıldıysa bu yöntem etkisiz olur. Nginx, bir DNS sunucusunu aşağıdaki gibi belirtmeye izin verir:

resolver 8.8.8.8;

`proxy_pass` ve `internal` Komutları

proxy_pass komutu, istekleri başka sunuculara yönlendirmek için kullanılır, ya içeriden ya da dışarıdan. internal komutu ise belirli konumlara sadece Nginx içinden erişilebilir olduğunu sağlar. Bu komutlar başlı başına güvenlik açıkları değillerdir, ancak yapılandırmaları güvenlik açıklarını önlemek için dikkatli bir şekilde incelenmelidir.

proxy_set_header Upgrade & Connection

Eğer nginx sunucusu Upgrade ve Connection başlıklarını geçmek için yapılandırılmışsa, bir h2c Smuggling saldırısı gerçekleştirilebilir ve korumalı/içsel uç noktalara erişilebilir.

{% hint style="danger" %} Bu güvenlik açığı, bir saldırganın proxy_pass uç noktasıyla doğrudan bir bağlantı kurmasına izin verecektir (http://backend:9999 bu durumda) ve bu içerik nginx tarafından kontrol edilmeyecektir. {% endhint %}

/flag'i çalmak için savunmasız yapılandırma örneği burada:

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;
}

{% hint style="warning" %} proxy_pass'in belirli bir yola işaret ettiği durumda bile, bağlantı http://backend:9999 ile kurulacaktır, bu nedenle iç uç noktadaki herhangi başka bir yola ulaşabilirsiniz. Dolayısıyla, proxy_pass URL'sinde bir yol belirtilmiş olması önemli değildir. {% endhint %}

Kendiniz Deneyin

Detectify, bu makalede tartışılan bazı yanlış yapılandırmalarla kendi zayıf Nginx test sunucusunu kurmanızı ve bunları kendiniz bulmanızı deneyebileceğiniz bir GitHub deposu oluşturdu!

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

Statik Analiz Araçları

GIXY

Gixy, Nginx yapılandırmasını analiz etmek için bir araçtır. Gixy'nin ana amacı güvenlik yanlı yapılandırmalarını önlemek ve hata tespitini otomatikleştirmektir.

Nginxpwner

Nginxpwner, yaygın Nginx yanlı yapılandırmalarını ve güvenlik açıklarını aramak için basit bir araçtır.

Referanslar

Zafiyet değerlendirmesi ve penetrasyon testi için anında kullanılabilir kurulum. 20'den fazla araç ve özellikle tam bir pentest çalıştırın, keşiften raporlamaya kadar uzanan özellikler. Pentester'ları değiştirmiyoruz - onlara daha derinlemesine kazma, kabukları patlatma ve eğlenme zamanı kazandırmak için özel araçlar, tespit ve istismar modülleri geliştiriyoruz.