mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
93 lines
8.0 KiB
Markdown
93 lines
8.0 KiB
Markdown
# Upgrade Header Smuggling
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
### H2C Smuggling <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
||
|
||
#### HTTP2 Over Cleartext (H2C) <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
||
|
||
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ı, sürekli iletişim için http2 ikili protokolünü kullanır; bu, düz metin HTTP'nin tek isteklilik doğasına karşıdı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ını sağlar.
|
||
|
||
#### Zayıf Proxiler <a href="#exploitation" id="exploitation"></a>
|
||
|
||
Zafiyet, ters proxy'nin `Upgrade` ve bazen `Connection` başlıklarını nasıl yönettiğine 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 <a href="#exploitation" id="exploitation"></a>
|
||
|
||
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.
|
||
|
||
> [!CAUTION]
|
||
> `proxy_pass` URL'sinde belirtilen belirli **yol** (örneğin, `http://backend:9999/socket.io`) ne olursa olsun, kurulan bağlantı varsayılan olarak `http://backend:9999`'dir. Bu, bu teknikten yararlanarak o iç uçtaki herhangi bir yol ile etkileşimde bulunmayı sağlar. Dolayısıyla, `proxy_pass` URL'sinde bir yol belirtmek erişimi kısıtlamaz.
|
||
|
||
[**h2csmuggler by BishopFox**](https://github.com/BishopFox/h2csmuggler) ve [**h2csmuggler by assetnote**](https://github.com/assetnote/h2csmuggler) 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**](../network-services-pentesting/pentesting-web/nginx.md#proxy_set_header-upgrade-and-connection) 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 sağlamak isteyen 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üşünmeye yönlendirilir, oysa 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ı 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 etkilenebilir.
|
||
|
||
|
||
|
||
### 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, bunu yalnızca `Upgrade` başlığına dayalı 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şır; bu kaynak, `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 yol açar.
|
||
|
||
|
||
|
||
> **Warning:** Bu tekniğin karmaşıklığı, 101 durum kodu 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üşünmeye yönlendirilir. 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](https://github.com/0ang3el/websocket-smuggle.git)
|
||
|
||
### Referanslar
|
||
|
||
- [https://blog.assetnote.io/2021/03/18/h2c-smuggling/](https://blog.assetnote.io/2021/03/18/h2c-smuggling/)
|
||
- [https://bishopfox.com/blog/h2c-smuggling-request](https://bishopfox.com/blog/h2c-smuggling-request)
|
||
- [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|