9.4 KiB
Yükseltme Başlığı Kaçakçılığı
AWS hackleme konusunda sıfırdan kahramana kadar öğrenin htARTE (HackTricks AWS Kırmızı Takım Uzmanı)!
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 (https://github.com/sponsors/carlospolop)!
- Resmi PEASS & HackTricks ürünlerini edinin
- PEASS Ailesi'ni keşfedin, özel NFT'lerimiz koleksiyonumuz
- 💬 Discord grubuna veya telegram grubuna katılın veya bizi Twitter 🐦 @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.
Try Hard Güvenlik Grubu
{% embed url="https://discord.gg/tryhardsecurity" %}
H2C Kaçakçılığı
Açık Metin Üzerinden HTTP2 (H2C)
H2C veya açık metin üzerinden http2, geçici HTTP bağlantılarının normundan saparak standart bir HTTP bağlantısını kalıcı bir bağlantıya yükseltir. Bu yükseltilmiş bağlantı, düz metin HTTP'nin tek istek doğasına karşı, sürekli iletişim için http2 ikili protokolünü kullanır.
Kaçakçılık sorununun özü, bir ters proxy'nin kullanımıyla ortaya çıkar. Normalde, ters proxy HTTP isteklerini işler ve arka uca ileterek, ardından arka uç yanıtını döndürür. Ancak, bir HTTP isteğinde Connection: Upgrade başlığı bulunduğunda (genellikle websocket bağlantılarıyla görülür), ters proxy istemci ve sunucu arasında kalıcı bir bağlantı sürdürür, belirli protokoller tarafından gereken sürekli değişimi kolaylaştırır. H2C bağlantıları için, RFC'ye uyum, üç belirli başlığın varlığını gerektirir:
Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings
H2C Smuggling
Zafiyet, bir bağlantıyı yükselttikten sonra ters vekilin, yönlendirme işleminin bağlantı kurulduktan sonra tamamlandığını varsayarak bireysel istekleri yönetmeyi durdurması durumunda ortaya çıkar. H2C Smuggling'in sömürülmesi, başarılı bir H2C bağlantısı başlatıldığında, istek işleme sırasında uygulanan ters vekil kurallarını atlamayı sağlar; bu kurallar arasında yol tabanlı yönlendirme, kimlik doğrulama ve WAF işleme bulunmaktadır.
Zafiyetli Vekiller
Zafiyet, ters vekilin Upgrade ve bazen Connection başlıklarını nasıl işlediğine bağlıdır. Aşağıdaki vekiller, proxy geçişi sırasında bu başlıkları doğal olarak ileten ve böylece H2C smuggling'i doğal olarak etkinleştiren vekillerdir:
- HAProxy
- Traefik
- Nuster
Öte yandan, aşağıdaki hizmetler, proxy geçişi sırasında her iki başlığı da doğal olarak iletmemektedir. Bununla birlikte, Upgrade ve Connection başlıklarının filtresiz iletilmesine izin veren güvensiz şekilde yapılandırılmış olabilirler:
- AWS ALB/CLB
- NGINX
- Apache
- Squid
- Varnish
- Kong
- Envoy
- Apache Traffic Server
Sömürü
Uyumlu bir H2C bağlantı yükseltmesi için gereken başlıkları doğal olarak ileten tüm sunucuların olmadığını belirtmek önemlidir. Bu nedenle, AWS ALB/CLB, NGINX ve Apache Traffic Server gibi sunucular, H2C bağlantılarını doğal olarak engeller. Bununla birlikte, bazı arka uçların standartlara uymayabileceği için, uyumsuz Connection: Upgrade varyantı ile test etmek yararlı olabilir.
{% hint style="danger" %}
proxy_pass URL'sinde belirtilen belirli yol (örneğin, http://backend:9999/socket.io) bağlantının varsayılan olarak http://backend:9999 olmasına neden olur. Bu, bu tekniği kullanarak dahili uç noktadaki herhangi bir yola etkileşim sağlar. Dolayısıyla, proxy_pass URL'sinde bir yol belirtmek erişimi kısıtlamaz.
{% endhint %}
BishopFox tarafından h2csmuggler ve assetnote tarafından h2csmuggler araçları, H2C bağlantısı kurarak proxy tarafından uygulanan korumaları atlamaya yönelik girişimleri kolaylaştırır ve bu sayede proxy tarafından korunan kaynaklara erişim sağlar.
Bu zafiyetle ilgili daha fazla bilgi için özellikle NGINX hakkında bu detaylı kaynağa başvurun.
Websocket Smuggling
Websocket smuggling, bir HTTP2 tüneli oluşturmanın aksine, bir Websocket tüneli kurarak potansiyel proxy kısıtlamalarını atlamayı ve uca doğrudan iletişim sağlamayı amaçlar.
Senaryo 1
Bu senaryoda, bir iç REST API'ye erişilemeyen bir arka uç, bir halka açık WebSocket API sunmaktadır ve kötü niyetli bir istemcinin iç REST API'ye erişim arayışında hedef alınmaktadır. Saldırı şu adımlarda gerçekleşir:
- İstemci, başlıkta yanlış bir
Sec-WebSocket-Versionprotokol sürümü ile bir Upgrade isteği göndererek ters vekile başlar. Ters vekil,Sec-WebSocket-Versionbaşlığını doğrulayamadığı için Upgrade isteğini geçerli olarak kabul eder ve arka uca iletilmesini sağlar. - Arka uç,
Sec-WebSocket-Versionbaşlığındaki yanlış protokol sürümünü belirten426durum kodu ile yanıt verir. Ters vekil, arka ucun yanıt durumunu göz ardı ederek WebSocket iletişimi için hazır olduğunu varsayar ve yanıtı istemciye iletir. - Sonuç olarak, ters vekil, istemci ile arka uç arasında bir WebSocket bağlantısı kurulmuş gibi yanıltılırken, aslında arka uç, Upgrade isteğini reddetmiştir. Bununla birlikte, vekil, istemci ile arka uç arasında açık bir TCP veya TLS bağlantısını sürdürür ve istemcinin bu bağlantı aracılığıyla özel REST API'ye kısıtlamasız erişim sağlamasına olanak tanır.
Etkilenen ters vekiller arasında, sorunu ele almaktan kaçınan Varnish ve Envoy proxy sürümü 1.8.0 veya daha eski olanlar, daha sonraki sürümlerde yükseltme mekanizmasını değiştirmiş olmalarına rağmen, bulunmaktadır. Diğer vekiller de savunmasız olabilir.
Senaryo 2
Bu senaryo, hem halka açık bir WebSocket API hem de bir sağlık kontrolü için halka açık bir REST API'ye sahip bir arka uçu içerir ve bir iç REST API'ye erişilemeyen bir arka uç hedef alınır. Daha karmaşık olan saldırı, aşağıdaki adımları içerir:
- İstemci, sağlık kontrol API'sini tetiklemek için bir POST isteği gönderirken, ek bir HTTP başlık olan
Upgrade: websocketi içerir. Ters vekil olarak hizmet veren NGINX, yalnızcaUpgradebaşlığına dayanarak bu isteği standart bir Upgrade isteği olarak yorumlar ve isteğin diğer yönlerini göz ardı eder ve arka uca iletir. - Arka uç, sağlık kontrol API'sini yürütürken, saldırgan tarafından kontrol edilen bir harici kaynağa ulaşır ve
101durum kodu ile bir HTTP yanıtı döndürür. Bu yanıt, arka uca ulaştığında ve NGINX'e iletilirken, yalnızca durum kodunu doğruladığı için vekili, bir WebSocket bağlantısının kurulduğuna inandırır.
Uyarı: Bu tekniğin karmaşıklığı, genellikle düşük önem derecesi olarak kabul edilen bir dış SSRF zafiyetinin varlığını gerektirmesi nedeniyle artar.
Sonuç olarak, NGINX, istemci ile arka uç arasında bir WebSocket bağlantısı olduğuna inanır. Aslında böyle bir bağlantı yoktur; sağlık kontrol REST API'si hedef alınmıştır. Bununla birlikte, ters vekil bağlantıyı açık tutar ve istemcinin bu aracılığıyla özel REST API'ye erişmesine olanak tanır.
Çoğu ters vekil bu senaryoya karşı savunmasız olabilir, ancak sömürü, genellikle düşük önem derecesi olarak kabul edilen bir dış SSRF zafiyetinin varlığına bağlıdır.
Lablar
Her iki senaryoyu test etmek için lablara https://github.com/0ang3el/websocket-smuggle.git adresinden erişebilirsiniz.