9.2 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 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
- PEASS Ailesi'ni keşfedin, özel NFT'lerimiz koleksiyonumuz
- **💬 Discord grubumuza katılın veya telegram grubumuza katılın veya bizi Twitter 🐦 @carlospolopm'da takip edin.
- Hacking püf noktalarınızı paylaşarak PR'ler 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, standart bir HTTP bağlantısını sürekli bir bağlantıya yükselterek geçici HTTP bağlantılarının normundan sapar. Bu yükseltilmiş bağlantı, düz metin HTTP'nin tek istek doğasına karşı devam eden 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. Genellikle, 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 sürekli bir bağlantıyı 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, bu başlıkları varsayılan olarak iletir ve dolayısıyla H2C smuggling'i varsayılan olarak etkinleştirir:
- HAProxy
- Traefik
- Nuster
Öte yandan, aşağıdaki hizmetler, bu başlıkları varsayılan olarak iletmez. Bununla birlikte, güvensiz bir şekilde yapılandırılmış olabilirler ve Upgrade ve Connection başlıklarının filtresiz iletilmesine izin verebilirler:
- AWS ALB/CLB
- NGINX
- Apache
- Squid
- Varnish
- Kong
- Envoy
- Apache Traffic Server
Sömürü
Uyumlu bir H2C bağlantısı yükseltmek için gereken başlıkları varsayılan 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 faydalı olabilir.
{% hint style="danger" %}
proxy_pass URL'sinde belirtilen belirli yol (örneğin, http://backend:9999/socket.io) bağlantıyı varsayılan olarak http://backend:9999 olarak ayarlar. Bu, bu tekniği kullanarak dahili uç noktadaki herhangi bir yolla etkileşime izin verir. 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ı, bir H2C bağlantısı kurarak ters vekil tarafından uygulanan korumaları atlamaya yönelik girişimleri kolaylaştırır.
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 oluşturarak potansiyel vekil kısıtlamalarını atlamayı ve uca doğrudan iletişimi kolaylaştırmayı amaçlar.
Senaryo 1
Bu senaryoda, bir iç REST API'sine erişilemeyen bir arka uç, bir kamu WebSocket API'sı sunar ve kötü niyetli bir istemcinin iç REST API'ye erişim aradığı hedeflenir. 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 iletir. - 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ğlar.
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ümlerin yükseltme mekanizmasını değiştirmiş olmasıyla birlikte diğer vekiller de hassas olabilir.
Senaryo 2
Bu senaryo, bir iç REST API'sine erişilemeyen bir arka uçta, hem bir kamu WebSocket API'si hem de sağlık kontrolü için bir kamu REST API'si bulunan bir arka uç hedeflenir. 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ığı
Upgrade: websocketiçerir. Ters vekil olarak hizmet veren NGINX, yalnızcaUpgradebaşlığına dayanarak bu isteği standart bir Upgrade isteği olarak yorumlar 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 bir HTTP yanıtı ile
101durum kodunu içeren bir yanıt alı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ıkla ö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 labları kontrol edin: https://github.com/0ang3el/websocket-smuggle.git