Furkan Öztürk tarafından yazılmıştır.
Merhaba değerli okurlar, bu yazımızda HTTP Request Smuggling‘den Türkçesiyle HTTP İstek Kaçakçılığı’ndan bahsedecek ve laboratuvar ortamında örnek bir senaryo ile saldırıyı gerçekleştireceğiz. Buyrun konumuza geçelim,
HTTP Request Smuggling Türkçesiyle HTTP İstek Kaçakçılığı, bir web sitesinin herhangi bir kaynaktan aldığı HTTP isteklerinin işlenme biçimini hedef alarak bu biçimin manipüle edilmesini dolayısıyla web sitesindeki güvenlik denetimlerinin atlatılmasını, hassas verilere yetkisiz erişilmesini sağlayan saldırı tekniğidir. Tekniğin daha anlaşılır olması için HTTP Request Smuggling‘in çalışma mekanizmasını inceleyelim.
HTTP Request Smuggling temelde, web uygulamasına normal şartlarda gönderildiği takdirde WAF gibi güvenlik denetleyicilerine takılan istekleri, iyi niyetli diğer isteklere gizleyerek kaçak yollarla uygulamaya sokmayı hedefler. Bunu da aynı ağ bağlantısı üzerinden sunucuya art arda istek göndererek gerçekleştirir. Böylece sunucu, art arda gelen istekler arasındaki sınırı belirleyemeyecek ve bütün istekleri tek bir istekmiş gibi algılayıp web uygulamasına gönderecektir. Bu sayede iyi niyetli datanın içerisinde gizlenerek gelen zararlı istek, uygulamaya geldiğinde ayrıştırılarak işleme konacak ve saldırgan hedefine ulaşacaktır.
saldırının çalışma mantığı
Saldırıyı gerçekleştirebilmek için istek gövdesinde “Transfer Encoding” ve “Content-Length” olmak üzere iki farklı HTTP başlığı kullanılır.
Content-Length: Gönderilen isteğin boyutunu bayt belirtir.
Transfer-Encoding: Satırlarla ayrılmış parçalı istekler için türü “Chunked” olarak belirtir. Böylece yığın kodlama açılmış olur ve bu da gelen isteğin birden fazla veri parçası içerdiği anlamına gelir.
Her şeyden önce bu saldırı tekniğinin çalışması için saldırı yapılacak web uygulaması bazı gereklilikleri sağlamalıdır. Bahsettiğimiz gereklilik aslında sunucuların HTTP isteklerini yorumlama biçiminin suistimal edilmesinden kaynaklı bir nevi zafiyetin oluşma sebebi. Peki nedir bu zafiyetimsi şeyin oluşmasına neden olan?
Bu saldırı türünde front-end sunucu, content-length başlığına bakar. Bu başlıkta belirtilen boyut kadar datayı, güvenlik denetleyicilerine takılmadan back-end sunucuya gönderir. Back-end sunucu gelen istekleri ayırır ve transfer-encoding başlığına bakarak bu istekleri çalıştırır.
Bu saldırı türünde ise, front-end sunucu Transfer-Encoding, Back-end sunucu ise content-length başlığını destekler. Front-End sunucu, Transfer-Encoding başlığına bakarak gelen isteğin tamamını back-end sunucuya gönderir. Back-end sunucu kendisine gelen isteği Content-length başlığına göre çalıştırır.
Bu saldırı türünde, her iki sunucu da Transfer-Encoding başlığını destekler. front-end ve back-end sunucular, Transfer-Encoding başlığına farklı biçimde yaklaşabilir. Saldırganın amacı çeşitli Transfer-Encoding varyasyonlarıyla bunu tespit etmektir. Örneğin sonsuz Transfer-Encoding varyasyonu sonucunda sunuculardan biri bu başlığı işler ve diğer sunucu bu başlığa karartma uygular. Bunun üzerine başlığı işleyen sunucu tespit edilir ve bu tespite göre saldırının devamında hangi saldırı türünün (CL.TE, TE.CL) işleve konulacağı belirlenir.
Bu başlıkta HTTP Request Smuggling‘i TE.CL saldırı türüyle uygulamalı olarak gerçekleştireceğiz. Diğer saldırı türlerine ait lablara makalenin son başlığından erişebilirsiniz.
Örnek senaryomuzu PortSwigger‘daki Lab üzerinde Burp Suite yazılımını kullanarak gerçekleştireceğiz. (https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl)
BurpSuite‘i çalıştıralım. Ardından Proxy > Intercept > Open Browser diyerek tarayıcımızı açalım
burp suite
Portswigger‘ın bize verdiği site adresini tarayıcıya yapıştıralım ve adrese bağlandıktan sonra burp‘e dönelim
lab ortamı
Burp‘e döndükten sonra üstteki panelden “HTTP History” sekmesine gelelim. Burada adreslere ait dökümleri görüyoruz. Az önce istek yaptığımız adresin üzerine gelip sağ tık yaparak “Send To Repeater” diyelim
send to repeater
Hemen ardından panelden “Repeater” kısmına gelelim. Burası birazdan web uygulamasına yapacağımız istekleri ve cevaplarını izleyeceğimiz kısım. Fakat burada istek göndermeye başlamadan önce panelin en üstünde bulunan diğer “Repeater” sekmesinden “Update Content-Length” seçeneğini aşağıdaki gibi deaktif hale getirelim.
repeater sekmesi
Şimdi “Request” tablosuna isteğimizi yazmaya başlayabiliriz
request
Yukarıdaki resimde görünen istek gövdesinin tamamını siliyorum ve ilk olarak aşağıdaki gibi “Content-Length” ve “Transfer-Encoding” başlığını kullanarak yeni bir POST isteği yazıyorum
POST / HTTP/1.1
Host: ac0d1fbc1f6dd50580cf431200c400c9.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Connection: keep-alive
Content-Type: application/x-www-from-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
devamında bir satır aşağıya inerek üstteki post isteğine gizleyeceğimiz yeni HTTP isteğini yazıyoruz
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-from-urlencoded
Content-Length: 15
x=1
0
İstek gövdemiz bir bütün halinde aşağıdaki gibi olacaktır.
POST / HTTP/1.1
Host: ac0d1fbc1f6dd50580cf431200c400c9.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Connection: keep-alive
Content-Type: application/x-www-from-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
Buradaki “5c” ve “0” ifadelerinin kafa karışıklığına yol açacağını düşünerek küçük bir parantez açalım. İkinci isteğimizin başına yazdığımız “5c” gönderdiğimiz isteğin hex formatındaki uzunluğudur. Sunucu bu ifadeyi okuduğunda “5c” yani 92 decimal uzunluğundaki sıradaki isteği işler. Yine burada ileti parçasının sonundaki “0”a gelindiğinde isteğin sonlandırıldığı düşünülür. Ve “0”ın ardına yazılan istekler, bir sonraki isteğin başlangıcı olarak kabul edilir.
İsteği “Send” butonuna tıklayarak gönderdiğimizde “TE-CL Saldırı Türü” başlığında bahsettiğimiz işlemler gerçekleşecektir. Ve sonucunda response kısmında aşağıdaki gibi dönüt almış olacağız. Burada sunucunun her iki isteği de sorunsuz işlediğini görüyoruz.
response
HTTP Request Smuggling saldırısını gerçekleştirdik. Peki bu işin savunması nasıl olacak? Bu başlığımızda bu soruyu cevaplandıralım.
Yukarıdaki yöntemlerin çoğu aslında isteklerin sınırları arasındaki belirsizliği gidermek üzerine uygulanmaktadır.
Yukarıda çözümünü yaptığımız senaryoya ek olarak farklı senaryolardaki diğer lablara aşağıdan ulaşabilirsiniz,
Burada yazımızın sonuna gelmiş bulunmaktayız. Diğer yazılarda görüşmek dileğiyle sevgiyle kalın…
[TR] HTTP Request Smuggling Saldırısı ve Yöntemi
Merhaba değerli okurlar, bu yazımızda HTTP Request Smuggling‘den Türkçesiyle HTTP İstek Kaçakçılığı’ndan bahsedecek ve laboratuvar ortamında örnek bir senaryo ile saldırıyı gerçekleştireceğiz. Buyrun konumuza geçelim,
HTTP REQUEST SMUGGLING NEDİR ?
HTTP Request Smuggling Türkçesiyle HTTP İstek Kaçakçılığı, bir web sitesinin herhangi bir kaynaktan aldığı HTTP isteklerinin işlenme biçimini hedef alarak bu biçimin manipüle edilmesini dolayısıyla web sitesindeki güvenlik denetimlerinin atlatılmasını, hassas verilere yetkisiz erişilmesini sağlayan saldırı tekniğidir. Tekniğin daha anlaşılır olması için HTTP Request Smuggling‘in çalışma mekanizmasını inceleyelim.
HTTP REQUEST SMUGGLING ÇALIŞMA MEKANİZMASI
HTTP Request Smuggling temelde, web uygulamasına normal şartlarda gönderildiği takdirde WAF gibi güvenlik denetleyicilerine takılan istekleri, iyi niyetli diğer isteklere gizleyerek kaçak yollarla uygulamaya sokmayı hedefler. Bunu da aynı ağ bağlantısı üzerinden sunucuya art arda istek göndererek gerçekleştirir. Böylece sunucu, art arda gelen istekler arasındaki sınırı belirleyemeyecek ve bütün istekleri tek bir istekmiş gibi algılayıp web uygulamasına gönderecektir. Bu sayede iyi niyetli datanın içerisinde gizlenerek gelen zararlı istek, uygulamaya geldiğinde ayrıştırılarak işleme konacak ve saldırgan hedefine ulaşacaktır.
saldırının çalışma mantığı
HTTP REQUEST SMUGGLING SALDIRISI NASIL GERÇEKLEŞİR ?
- Saldırı yapılacak web uygulamasına bir POST isteği yapılmasına peşinen saldırıda kullanılmak üzere yeni bir HTTP isteği gönderilir.
- Sunucular, her iki istek de aynı ağ bağlantısı üzerinden art arda gönderildiği için bu iki istek arasındaki sınırı belirleyemez ve gönderilen ikinci isteği POST datası içerisindeymiş gibi algılar. Dolayısıyla karşı uygulamada bulunan güvenlik denetleyicileri tarafından dikkat çekmez.
- Ardından POST data, içerisinde gelen zararlı ikinci istek ile birlikte web uygulamasına gider.
- Web uygulamasına bir bütünmüş gibi görünerek gelen bu data, burada POST isteği ve ikinci HTTP isteği olarak birbirinden ayrıştırılır ve ayrı ayrı işleme konur. Bu sayede sistemde zararlı HTTP isteği kaçak yollarla çalışmış olur.
Saldırıyı gerçekleştirebilmek için istek gövdesinde “Transfer Encoding” ve “Content-Length” olmak üzere iki farklı HTTP başlığı kullanılır.
Content-Length: Gönderilen isteğin boyutunu bayt belirtir.
Transfer-Encoding: Satırlarla ayrılmış parçalı istekler için türü “Chunked” olarak belirtir. Böylece yığın kodlama açılmış olur ve bu da gelen isteğin birden fazla veri parçası içerdiği anlamına gelir.
Her şeyden önce bu saldırı tekniğinin çalışması için saldırı yapılacak web uygulaması bazı gereklilikleri sağlamalıdır. Bahsettiğimiz gereklilik aslında sunucuların HTTP isteklerini yorumlama biçiminin suistimal edilmesinden kaynaklı bir nevi zafiyetin oluşma sebebi. Peki nedir bu zafiyetimsi şeyin oluşmasına neden olan?
- Back-end sunucuya aynı ağ bağlantısı üzerinden arka arkaya birden fazla istek gönderiliyor olması. (Bu sebeple arka arkaya gönderilen isteklere ait sınırlar belirlenemeyecektir.)
- Front-end ve back-end sunucular için aynı servislerin kullanılmıyor olması. (Sunucuların, gelen HTTP istekleri içerisinde yer alan “Transfer-Encoding” başlığına birbirinden farklı davranma ihtimalleri olduğu için burada yine bir belirsizlik oluşacaktır.)
HTTP REQUEST SMUGGLING SALDIRI TÜRLERİ
1- CL.TE SALDIRI TÜRÜ
Bu saldırı türünde front-end sunucu, content-length başlığına bakar. Bu başlıkta belirtilen boyut kadar datayı, güvenlik denetleyicilerine takılmadan back-end sunucuya gönderir. Back-end sunucu gelen istekleri ayırır ve transfer-encoding başlığına bakarak bu istekleri çalıştırır.
2- TE.CL SALDIRI TÜRÜ
Bu saldırı türünde ise, front-end sunucu Transfer-Encoding, Back-end sunucu ise content-length başlığını destekler. Front-End sunucu, Transfer-Encoding başlığına bakarak gelen isteğin tamamını back-end sunucuya gönderir. Back-end sunucu kendisine gelen isteği Content-length başlığına göre çalıştırır.
3- TE.TE SALDIRI TÜRÜ
Bu saldırı türünde, her iki sunucu da Transfer-Encoding başlığını destekler. front-end ve back-end sunucular, Transfer-Encoding başlığına farklı biçimde yaklaşabilir. Saldırganın amacı çeşitli Transfer-Encoding varyasyonlarıyla bunu tespit etmektir. Örneğin sonsuz Transfer-Encoding varyasyonu sonucunda sunuculardan biri bu başlığı işler ve diğer sunucu bu başlığa karartma uygular. Bunun üzerine başlığı işleyen sunucu tespit edilir ve bu tespite göre saldırının devamında hangi saldırı türünün (CL.TE, TE.CL) işleve konulacağı belirlenir.
SALDIRININ LAB ORTAMINDA GERÇEKLEŞTİRİLMESİ
Bu başlıkta HTTP Request Smuggling‘i TE.CL saldırı türüyle uygulamalı olarak gerçekleştireceğiz. Diğer saldırı türlerine ait lablara makalenin son başlığından erişebilirsiniz.
Örnek senaryomuzu PortSwigger‘daki Lab üzerinde Burp Suite yazılımını kullanarak gerçekleştireceğiz. (https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl)
BurpSuite‘i çalıştıralım. Ardından Proxy > Intercept > Open Browser diyerek tarayıcımızı açalım
burp suite
Portswigger‘ın bize verdiği site adresini tarayıcıya yapıştıralım ve adrese bağlandıktan sonra burp‘e dönelim
lab ortamı
Burp‘e döndükten sonra üstteki panelden “HTTP History” sekmesine gelelim. Burada adreslere ait dökümleri görüyoruz. Az önce istek yaptığımız adresin üzerine gelip sağ tık yaparak “Send To Repeater” diyelim
send to repeater
Hemen ardından panelden “Repeater” kısmına gelelim. Burası birazdan web uygulamasına yapacağımız istekleri ve cevaplarını izleyeceğimiz kısım. Fakat burada istek göndermeye başlamadan önce panelin en üstünde bulunan diğer “Repeater” sekmesinden “Update Content-Length” seçeneğini aşağıdaki gibi deaktif hale getirelim.
repeater sekmesi
Şimdi “Request” tablosuna isteğimizi yazmaya başlayabiliriz
request
Yukarıdaki resimde görünen istek gövdesinin tamamını siliyorum ve ilk olarak aşağıdaki gibi “Content-Length” ve “Transfer-Encoding” başlığını kullanarak yeni bir POST isteği yazıyorum
POST / HTTP/1.1
Host: ac0d1fbc1f6dd50580cf431200c400c9.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Connection: keep-alive
Content-Type: application/x-www-from-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
devamında bir satır aşağıya inerek üstteki post isteğine gizleyeceğimiz yeni HTTP isteğini yazıyoruz
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-from-urlencoded
Content-Length: 15
x=1
0
İstek gövdemiz bir bütün halinde aşağıdaki gibi olacaktır.
POST / HTTP/1.1
Host: ac0d1fbc1f6dd50580cf431200c400c9.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Connection: keep-alive
Content-Type: application/x-www-from-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
Buradaki “5c” ve “0” ifadelerinin kafa karışıklığına yol açacağını düşünerek küçük bir parantez açalım. İkinci isteğimizin başına yazdığımız “5c” gönderdiğimiz isteğin hex formatındaki uzunluğudur. Sunucu bu ifadeyi okuduğunda “5c” yani 92 decimal uzunluğundaki sıradaki isteği işler. Yine burada ileti parçasının sonundaki “0”a gelindiğinde isteğin sonlandırıldığı düşünülür. Ve “0”ın ardına yazılan istekler, bir sonraki isteğin başlangıcı olarak kabul edilir.
İsteği “Send” butonuna tıklayarak gönderdiğimizde “TE-CL Saldırı Türü” başlığında bahsettiğimiz işlemler gerçekleşecektir. Ve sonucunda response kısmında aşağıdaki gibi dönüt almış olacağız. Burada sunucunun her iki isteği de sorunsuz işlediğini görüyoruz.
response
HTTP REQUEST SMUGGLING ÖNLEME YÖNTEMLERİ
HTTP Request Smuggling saldırısını gerçekleştirdik. Peki bu işin savunması nasıl olacak? Bu başlığımızda bu soruyu cevaplandıralım.
- Back-end isteklerinin ayrı ağ bağlantıları üzerinden gelmesini sağlamak için isteklerin yeniden kullanılmasını devre dışı bırakmak
- İstekler arasındaki sınırın bilinmesi için Front-end ve back-end sunucuları aynı web sunucusu yazılımından temin etmek
- Anormal istekleri algılamak için doğru WAF‘i kullanmak
- Back-end sunucunun belirsiz istekleri reddetmesini ya da bu isteklere karşı ağ bağlantısını kapatmasını sağlamak
Yukarıdaki yöntemlerin çoğu aslında isteklerin sınırları arasındaki belirsizliği gidermek üzerine uygulanmaktadır.
ALTERNATİF SALDIRI SENARYOLARI
Yukarıda çözümünü yaptığımız senaryoya ek olarak farklı senaryolardaki diğer lablara aşağıdan ulaşabilirsiniz,
- https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te
- https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl
- https://portswigger.net/web-security/request-smuggling/lab-obfuscating-te-header
Burada yazımızın sonuna gelmiş bulunmaktayız. Diğer yazılarda görüşmek dileğiyle sevgiyle kalın…
Moderatör tarafında düzenlendi: