Upgrade Header Smuggling

Reading time: 6 minutes

H2C Smuggling

HTTP2 Over Cleartext (H2C)

H2C, veya http2 over cleartext, standart HTTP bağlantısını kalıcı birine yükselterek geçici HTTP bağlantılarının normundan sapar. Bu yükseltilmiş bağlantı, düz metin HTTP'nin tek isteklilik doğasına karşılık olarak, sürekli iletişim için http2 ikili protokolünü kullanır.

Kaçakçılık sorununu oluşturan temel nokta, ters proxy kullanımında ortaya çıkar. Genellikle, ters proxy HTTP isteklerini işler ve bunları arka uca ileterek, arka ucun yanıtını döner. Ancak, bir HTTP isteğinde Connection: Upgrade başlığı mevcut olduğ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ürerek, belirli protokollerin gerektirdiği sürekli değişimi kolaylaştırır. H2C bağlantıları için, RFC'ye uyum sağlamak üç belirli başlığın varlığını gerektirir:

Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings

Zafiyet, bir bağlantı yükseltildikten sonra, ters proxy'nin bireysel istekleri yönetmeyi bırakması ve bağlantı kurulduktan sonra yönlendirme işinin tamamlandığını varsayması durumunda ortaya çıkar. H2C Smuggling'in istismar edilmesi, H2C bağlantısının başarıyla başlatılması durumunda, istek işleme sırasında uygulanan ters proxy kurallarının (örneğin, yol tabanlı yönlendirme, kimlik doğrulama ve WAF işleme) aşılmasına olanak tanır.

Zayıf Proxiler

Zafiyet, ters proxy'nin Upgrade ve bazen Connection başlıklarını ele almasına bağlıdır. Aşağıdaki proxy'ler, proxy-pass sırasında bu başlıkları doğrudan ilettikleri için H2C smuggling'i doğrudan etkinleştirir:

• HAProxy
• Traefik
• Nuster

Buna karşılık, bu hizmetler proxy-pass sırasında her iki başlığı da doğrudan iletmez. Ancak, Upgrade ve Connection başlıklarının filtrelenmemiş bir şekilde iletilmesine izin verecek şekilde güvensiz bir şekilde yapılandırılabilirler:

• AWS ALB/CLB
• NGINX
• Apache
• Squid
• Varnish
• Kong
• Envoy
• Apache Traffic Server

İstismar

Tüm sunucuların, uyumlu bir H2C bağlantı yükseltmesi için gerekli başlıkları doğrudan iletmediğini belirtmek önemlidir. Bu nedenle, AWS ALB/CLB, NGINX ve Apache Traffic Server gibi sunucular doğal olarak H2C bağlantılarını engeller. Yine de, bazı arka uçların standartlara uymadığı durumlarda, Connection: Upgrade varyantı ile test etmek faydalı olabilir; bu varyant, Connection başlığından HTTP2-Settings değerini hariç tutar.

h2csmuggler by BishopFox ve h2csmuggler by assetnote araçları, H2C bağlantısı kurarak proxy tarafından uygulanan korumaları aşma girişimlerini kolaylaştırır ve böylece proxy tarafından korunan kaynaklara erişim sağlar.

Bu zafiyet hakkında, özellikle NGINX ile ilgili daha fazla bilgi için bu ayrıntılı kaynağa başvurun.

Websocket Smuggling

Websocket smuggling, bir proxy aracılığıyla erişilebilen bir uç noktaya HTTP2 tüneli oluşturmanın aksine, potansiyel proxy sınırlamalarını aşmak ve uç noktayla doğrudan iletişim sağlamak için bir Websocket tüneli kurar.

Senaryo 1

Bu senaryoda, kamuya açık bir WebSocket API'si sunan ve erişilemeyen bir iç REST API'si olan bir arka uç, iç REST API'sine erişim arayan kötü niyetli bir istemci tarafından hedef alınır. Saldırı birkaç adımda gerçekleşir:

1. İstemci, başlıkta yanlış bir Sec-WebSocket-Version protokol versiyonu ile ters proxy'ye bir Upgrade isteği gönderir. Proxy, Sec-WebSocket-Version başlığını doğrulamadığı için Upgrade isteğini geçerli kabul eder ve arka uca iletir.
2. Arka uç, Sec-WebSocket-Version başlığındaki yanlış protokol versiyonunu belirten 426 durum kodu ile yanıt verir. Ters proxy, arka ucun yanıt durumunu göz ardı ederek WebSocket iletişimine hazır olduğunu varsayar ve yanıtı istemciye iletir.
3. Sonuç olarak, ters proxy, istemci ile arka uç arasında bir WebSocket bağlantısının kurulduğunu düşünürken, gerçekte arka uç Upgrade isteğini reddetmiştir. Yine de, proxy, istemci ile arka uç arasında açık bir TCP veya TLS bağlantısını sürdürür ve bu bağlantı aracılığıyla istemcinin özel REST API'sine sınırsız erişim sağlar.

Etkilenen ters proxy'ler arasında sorunu ele almayı reddeden Varnish ve 1.8.0 veya daha eski Envoy proxy sürümü bulunmaktadır; daha yeni sürümler yükseltme mekanizmasını değiştirmiştir. Diğer proxy'ler de savunmasız olabilir.

Senaryo 2

Bu senaryo, hem kamuya açık bir WebSocket API'si hem de sağlık kontrolü için kamuya açık bir REST API'si olan ve erişilemeyen bir iç REST API'si bulunan bir arka ucu içerir. Saldırı daha karmaşık olup şu adımları içerir:

1. İstemci, sağlık kontrolü API'sini tetiklemek için bir POST isteği gönderir ve ek bir HTTP başlığı olan Upgrade: websocket ekler. NGINX, ters proxy olarak, bu isteği yalnızca Upgrade başlığına dayanarak standart bir Upgrade isteği olarak yorumlar ve isteğin diğer yönlerini göz ardı ederek arka uca iletir.
2. Arka uç, sağlık kontrolü API'sini çalıştırır ve saldırgan tarafından kontrol edilen bir dış kaynağa ulaşarak 101 durum kodu ile bir HTTP yanıtı döner. Bu yanıt, arka uç tarafından alındıktan sonra NGINX'e iletildiğinde, proxy'nin yalnızca durum kodunu doğrulaması nedeniyle bir WebSocket bağlantısının kurulduğunu düşünmesine neden olur.

Warning: Bu tekniğin karmaşıklığı, durum kodu 101 döndürebilen bir uç noktayla etkileşim kurma yeteneğini gerektirdiğinden artar.

Sonuç olarak, NGINX, istemci ile arka uç arasında bir WebSocket bağlantısının var olduğunu düşünür. Gerçekte, böyle bir bağlantı yoktur; hedef sağlık kontrolü REST API'siydi. Yine de, ters proxy bağlantıyı açık tutar ve istemcinin özel REST API'sine erişmesine olanak tanır.

Çoğu ters proxy bu senaryoya karşı savunmasızdır, ancak istismar, genellikle düşük şiddetli bir sorun olarak kabul edilen bir dış SSRF zafiyetinin varlığına bağlıdır.

Laboratuvarlar

Her iki senaryoyu test etmek için laboratuvarları kontrol edin https://github.com/0ang3el/websocket-smuggle.git

Referanslar

• https://blog.assetnote.io/2021/03/18/h2c-smuggling/
• https://bishopfox.com/blog/h2c-smuggling-request
• https://github.com/0ang3el/websocket-smuggle.git