Web Application Firewall(WAF)’ları Bypasslamak -6
Evet arkadaşlar serinin son yazısı ile karşınızdayım. Dediğim gibi bu işlerin en sonunda yani bu yazıda gerçek hayatta bu bypass işlemleri ile örnekler verip sonlandıracağım. Hemen devam edelim.
Wafları Güvenli Hale Getirme ve Sonuç İşlemleri
DOM tabanlı XSS, yaygın olarak kullanılan başka bir XSS türüdür ve bunu serinin 4. yazısında işlemedim. DOM veya Belge Nesne Modeli, bir tarayıcıdaki belgeleri temsil etmek için kullanılan yapısal biçimdir. DOM, JavaScript gibi dinamik komut dosyalarının, bir form alanı veya oturum tanımlama bilgisi gibi belgenin bileşenlerine başvurmasını sağlar ve aynı zamanda, farklı alanlardaki komut dosyalarının diğer alanlar için tanımlama bilgileri almasını sınırlayan bir güvenlik özelliğidir. Şimdi, buna dayalı XSS saldırıları, enjekte ettiğimiz yükün, kurbanın tarayıcısındaki DOM ortamını değiştirerek kodun beklenmedik bir şekilde çalışması sonucunda yürütüldüğü zamandır. Bununla, diğer iki saldırının aksine, burada kurbanın gördüğü sayfanın değişmediğini, ancak daha önce söylediğimiz gibi DOM ortamında yapılan değişiklikler nedeniyle enjekte edilen kodun farklı şekilde yürütüldüğünü kastediyoruz. Diğer XSS saldırılarında, DOM tabanlı XSS güvenlik açıkları, sunucu gerçekte neyin yürütüldüğünü belirleyemeden birçok durumda yürütülebilir. Bu, incelediğimiz WAF’ler gibi genel XSS filtreleme ve algılama tekniklerinin çoğunu bu tür saldırılara karşı etkisiz hale getirebilir ve bu nedenle bu saldırı bizim için önemlidir. Birçok para birimini destekleyen online alışveriş sitesinde aşağıdaki kodu inceleyelim:
document.write (“<SEÇENEK değer = 1>” + document.location.href.substring (document.location.href.indexOf (“default =”) + 8) + ”</OPTION>”);> ”); document.write (“<OPTION değer = 2> Dolar </OPTION>”);
Bu web sitesindeki para birimini değiştirmeye çalıştığımızda, sayfa aşağıdaki gibi bir URL ile çağrılır:
http://www.onlineawm.com/page.html?cur=Euro
Bu URL’de DOM tabanlı bir XSS saldırısı gerçekleştirmek için kurbana aşağıdaki bağlantıyı gönderebiliriz:
http://www.onlineawm.com/page.html?cur= <script> alert (document.cookie) </script>
Kurban bu bağlantıya tıkladığında, tarayıcı farklı bir para birimi isteyecek, ancak bir para birimi değeri sağlamak yerine aşağıdakileri verecektir:
Sunucu, sayfaya bu Javascript kodunu içinde sağlayarak yanıt verecektir. Ardından, tarayıcı bu sayfa için document.location nesnesinin aşağıdakileri içereceği bir DOM nesnesi oluşturacaktır:
http://www.onlineawm.com/page.html?cur=<script>alert(document.cookie)</script
Sayfadaki Javascript kodu, parametrenin HTML kodu içermesini beklemez ve bu nedenle, çalışma zamanında sayfaya (DOM) yansıtır. Sayfa daha sonra sayfayı oluşturur ve daha önce sağladığımız komut dosyasını komut dosyası etiketlerinde yürütür.
Buna rağmen, bu saldırıda yük, sunucu tarafından HTTP yanıtına gömülmemiş, isteğin bir parçası olarak sunucuya ulaşmıştır,yüklü bir WAF veya sunucu tarafı kontrolleri tarafından tespit edilmesi mümkündür. WAF’ı atlamak ve betiği sunucuya göndermekten kaçınmak için, URI’de # işaretinden sonraki kısmın tarayıcı tarafından sunucuya gönderilmediğini unutmamalıyız. Bununla, daha önce kullandığımız document.cookie gibi başvurduğu herhangi bir kod, fragman kullanan bir saldırıya karşı savunmasız olabilir ve bu tür bir senaryoda komut dosyası sunucuya gönderilmez. Önceki saldırıda kullandığımız URL şuna dönüştürülebilir:
http://www.onlineawm.com/page.html#cur= <script> alert (document.cookie) </script>
aynı komut dosyasını çalıştırır, ancak betiğin sunucuya gönderilmemesine ek olarak, bu nedenle herhangi bir tür sunucu tarafı kontrolünün bir WAF’sini başarıyla atladık. Bu saldırıda sunucu, page.html noktasına gelene kadar yalnızca URL’yi görecektir.
Bir başka ilginç örnek, tarayıcıya bir PDF dosyası sunulduğunda ve Adobe Acrobat eklentisi dosyayı işlerse, bunun sonucunda parçanın bir kısmını JavaScript olarak yürütebilir. JavaScript mevcut sitenin bağlamında (DOM) yürütüldüğünden, XSS koşulunun karşılanması için web sitesinin içinde bir PDF bağlantısı bularak ondan yararlanmak gerçekten çok kolaydır. Ardından aşağıdaki gibi bir bağlantı oluşturuyoruz:
http://www.website.com/pdffile.pdf#parameter=javascript:script-goes-here
Şimdi, saldırının aşağı yukarı aynı olduğunu görebilirsiniz, ancak istemci tarafının farklı bir yönünü kullanıyoruz ve bu durumda, kurban güncel olmayan bir Acrobat Reader yüklüyse, komut dosyası gitmeden yürütülecektir. sunucu. Anlayabildiğimiz gibi, DOM tabanlı XSS gerçekten tehlikelidir ve doğası gereği hiçbir WAF onu filtreleyemez. Son olarak, daha fazla XSS saldırısı ve bunları istismar etmenin daha fazla yolu var, ancak bu seride bu konuya girmeye gerek yok.
BlackList’i JS Kodu ile Bypasslamak
Bu serinin ilk yazılarında, WAF’lerin pozitif ve negatif olmak üzere iki temel modeli takip ettiğini öğrendik. Kodlama süresinden tasarruf etmek için, WAF’lerin çoğu negatif modele güvenir, bu nedenle WAF’ın engellemeye çalıştığı modelleri arayan genel olarak REG-EX biçiminde tüm imzaları içeren bir veritabanına sahiptirler. Bununla ilgili sorun, JavaScript’in doğası ve esnekliği nedeniyle kolayca atlanabilmesidir. Bu tür bir korumayı atlamak için JavaScript oluşturmanın sayısız yolu vardır, ancak şimdi kara listeleri atlamak için kullanabileceğimiz üç farklı yaklaşımdan bahsedelim. Bunlar;
Brute Force: Bu yöntemle birçok olasılık deniyoruz ve bunlardan bazılarının çalışmasını bekliyoruz. Bu, bahsettiğimiz ve bahsedeceğimiz araçların çoğunun kullandığı yöntemdir ve bazı tür filtreler için iyi bir yöntem olabilir, ancak birçok kez söylediğimiz gibi, bu yöntemler başarısız olduğu için otomatik araçlar anlayamaz. bağlam ve her saldırının bağlamı her durumda değişir.
Tarayıcı Hataları: Adobe Acrobat XSS örneğinde söylediğimiz gibi, hedefin tarayıcısındaki bir hatayı kullanarak WAF’ı atlamanın bazı yolları vardır. Bu, birilerinin kullanacağı son yaklaşımdır, çünkü güvenlik sorunları olan eski tarayıcıları, güvenlik sorunları olan eklentileri ve hatta sıfır günü aramamız gerekir, bunlardan yararlanabilmek ve WAF’ın eklediği sınırlamaları atlatmak zorundayız.
REG-EX Reverse: Kara listeyi atlamada en iyi yaklaşım reg-ex reverse yöntemidir.. Daha önce de söylediğimiz gibi, WAF’ler gönderdiğimiz değerleri veritabanında sakladıkları imzalarla eşleştirmeye dayanır ve bu imzalar karmaşık normal ifadeler biçimindedir. Yük bu imzalardan herhangi biriyle eşleşirse (reg-ex), WAF tetiklenir ve sizin de anlayabileceğiniz gibi, hiçbir imza bizim yükümüzle eşleşmezse WAF tetiklenmez. Bu yöntemde, bu WAF imzalarını tersine çevirmeye çalışırız ve WAF’ın kara listesini öğrendikten sonra, tüm filtreleri atlayabilen ve WAF’ı tetiklemeyen komut dosyaları ve saldırılar üretebiliriz.
Şimdi pratik örneklerle bruteforcing ve reg-ex reversing hakkında konuşarak devam edelim. Öncelikle, WAF tarafından engellenip engellenmediklerini ve HTTP yanıtında bundan nasıl oluşturulduğunu görmek için <p>, <h1> veya <b> gibi zararsız etiketleri denemeli ve eklemeliyiz. Aşağıdakileri kontrol ediyoruz:
Evet arkadaşlar serinin son yazısı ile karşınızdayım. Dediğim gibi bu işlerin en sonunda yani bu yazıda gerçek hayatta bu bypass işlemleri ile örnekler verip sonlandıracağım. Hemen devam edelim.
Wafları Güvenli Hale Getirme ve Sonuç İşlemleri
DOM tabanlı XSS, yaygın olarak kullanılan başka bir XSS türüdür ve bunu serinin 4. yazısında işlemedim. DOM veya Belge Nesne Modeli, bir tarayıcıdaki belgeleri temsil etmek için kullanılan yapısal biçimdir. DOM, JavaScript gibi dinamik komut dosyalarının, bir form alanı veya oturum tanımlama bilgisi gibi belgenin bileşenlerine başvurmasını sağlar ve aynı zamanda, farklı alanlardaki komut dosyalarının diğer alanlar için tanımlama bilgileri almasını sınırlayan bir güvenlik özelliğidir. Şimdi, buna dayalı XSS saldırıları, enjekte ettiğimiz yükün, kurbanın tarayıcısındaki DOM ortamını değiştirerek kodun beklenmedik bir şekilde çalışması sonucunda yürütüldüğü zamandır. Bununla, diğer iki saldırının aksine, burada kurbanın gördüğü sayfanın değişmediğini, ancak daha önce söylediğimiz gibi DOM ortamında yapılan değişiklikler nedeniyle enjekte edilen kodun farklı şekilde yürütüldüğünü kastediyoruz. Diğer XSS saldırılarında, DOM tabanlı XSS güvenlik açıkları, sunucu gerçekte neyin yürütüldüğünü belirleyemeden birçok durumda yürütülebilir. Bu, incelediğimiz WAF’ler gibi genel XSS filtreleme ve algılama tekniklerinin çoğunu bu tür saldırılara karşı etkisiz hale getirebilir ve bu nedenle bu saldırı bizim için önemlidir. Birçok para birimini destekleyen online alışveriş sitesinde aşağıdaki kodu inceleyelim:
document.write (“<SEÇENEK değer = 1>” + document.location.href.substring (document.location.href.indexOf (“default =”) + 8) + ”</OPTION>”);> ”); document.write (“<OPTION değer = 2> Dolar </OPTION>”);
Bu web sitesindeki para birimini değiştirmeye çalıştığımızda, sayfa aşağıdaki gibi bir URL ile çağrılır:
http://www.onlineawm.com/page.html?cur=Euro
Bu URL’de DOM tabanlı bir XSS saldırısı gerçekleştirmek için kurbana aşağıdaki bağlantıyı gönderebiliriz:
http://www.onlineawm.com/page.html?cur= <script> alert (document.cookie) </script>
Kurban bu bağlantıya tıkladığında, tarayıcı farklı bir para birimi isteyecek, ancak bir para birimi değeri sağlamak yerine aşağıdakileri verecektir:
Sunucu, sayfaya bu Javascript kodunu içinde sağlayarak yanıt verecektir. Ardından, tarayıcı bu sayfa için document.location nesnesinin aşağıdakileri içereceği bir DOM nesnesi oluşturacaktır:
http://www.onlineawm.com/page.html?cur=<script>alert(document.cookie)</script
Sayfadaki Javascript kodu, parametrenin HTML kodu içermesini beklemez ve bu nedenle, çalışma zamanında sayfaya (DOM) yansıtır. Sayfa daha sonra sayfayı oluşturur ve daha önce sağladığımız komut dosyasını komut dosyası etiketlerinde yürütür.
Buna rağmen, bu saldırıda yük, sunucu tarafından HTTP yanıtına gömülmemiş, isteğin bir parçası olarak sunucuya ulaşmıştır,yüklü bir WAF veya sunucu tarafı kontrolleri tarafından tespit edilmesi mümkündür. WAF’ı atlamak ve betiği sunucuya göndermekten kaçınmak için, URI’de # işaretinden sonraki kısmın tarayıcı tarafından sunucuya gönderilmediğini unutmamalıyız. Bununla, daha önce kullandığımız document.cookie gibi başvurduğu herhangi bir kod, fragman kullanan bir saldırıya karşı savunmasız olabilir ve bu tür bir senaryoda komut dosyası sunucuya gönderilmez. Önceki saldırıda kullandığımız URL şuna dönüştürülebilir:
http://www.onlineawm.com/page.html#cur= <script> alert (document.cookie) </script>
aynı komut dosyasını çalıştırır, ancak betiğin sunucuya gönderilmemesine ek olarak, bu nedenle herhangi bir tür sunucu tarafı kontrolünün bir WAF’sini başarıyla atladık. Bu saldırıda sunucu, page.html noktasına gelene kadar yalnızca URL’yi görecektir.
Bir başka ilginç örnek, tarayıcıya bir PDF dosyası sunulduğunda ve Adobe Acrobat eklentisi dosyayı işlerse, bunun sonucunda parçanın bir kısmını JavaScript olarak yürütebilir. JavaScript mevcut sitenin bağlamında (DOM) yürütüldüğünden, XSS koşulunun karşılanması için web sitesinin içinde bir PDF bağlantısı bularak ondan yararlanmak gerçekten çok kolaydır. Ardından aşağıdaki gibi bir bağlantı oluşturuyoruz:
http://www.website.com/pdffile.pdf#parameter=javascript:script-goes-here
Şimdi, saldırının aşağı yukarı aynı olduğunu görebilirsiniz, ancak istemci tarafının farklı bir yönünü kullanıyoruz ve bu durumda, kurban güncel olmayan bir Acrobat Reader yüklüyse, komut dosyası gitmeden yürütülecektir. sunucu. Anlayabildiğimiz gibi, DOM tabanlı XSS gerçekten tehlikelidir ve doğası gereği hiçbir WAF onu filtreleyemez. Son olarak, daha fazla XSS saldırısı ve bunları istismar etmenin daha fazla yolu var, ancak bu seride bu konuya girmeye gerek yok.
BlackList’i JS Kodu ile Bypasslamak
Bu serinin ilk yazılarında, WAF’lerin pozitif ve negatif olmak üzere iki temel modeli takip ettiğini öğrendik. Kodlama süresinden tasarruf etmek için, WAF’lerin çoğu negatif modele güvenir, bu nedenle WAF’ın engellemeye çalıştığı modelleri arayan genel olarak REG-EX biçiminde tüm imzaları içeren bir veritabanına sahiptirler. Bununla ilgili sorun, JavaScript’in doğası ve esnekliği nedeniyle kolayca atlanabilmesidir. Bu tür bir korumayı atlamak için JavaScript oluşturmanın sayısız yolu vardır, ancak şimdi kara listeleri atlamak için kullanabileceğimiz üç farklı yaklaşımdan bahsedelim. Bunlar;
Brute Force: Bu yöntemle birçok olasılık deniyoruz ve bunlardan bazılarının çalışmasını bekliyoruz. Bu, bahsettiğimiz ve bahsedeceğimiz araçların çoğunun kullandığı yöntemdir ve bazı tür filtreler için iyi bir yöntem olabilir, ancak birçok kez söylediğimiz gibi, bu yöntemler başarısız olduğu için otomatik araçlar anlayamaz. bağlam ve her saldırının bağlamı her durumda değişir.
Tarayıcı Hataları: Adobe Acrobat XSS örneğinde söylediğimiz gibi, hedefin tarayıcısındaki bir hatayı kullanarak WAF’ı atlamanın bazı yolları vardır. Bu, birilerinin kullanacağı son yaklaşımdır, çünkü güvenlik sorunları olan eski tarayıcıları, güvenlik sorunları olan eklentileri ve hatta sıfır günü aramamız gerekir, bunlardan yararlanabilmek ve WAF’ın eklediği sınırlamaları atlatmak zorundayız.
REG-EX Reverse: Kara listeyi atlamada en iyi yaklaşım reg-ex reverse yöntemidir.. Daha önce de söylediğimiz gibi, WAF’ler gönderdiğimiz değerleri veritabanında sakladıkları imzalarla eşleştirmeye dayanır ve bu imzalar karmaşık normal ifadeler biçimindedir. Yük bu imzalardan herhangi biriyle eşleşirse (reg-ex), WAF tetiklenir ve sizin de anlayabileceğiniz gibi, hiçbir imza bizim yükümüzle eşleşmezse WAF tetiklenmez. Bu yöntemde, bu WAF imzalarını tersine çevirmeye çalışırız ve WAF’ın kara listesini öğrendikten sonra, tüm filtreleri atlayabilen ve WAF’ı tetiklemeyen komut dosyaları ve saldırılar üretebiliriz.
Şimdi pratik örneklerle bruteforcing ve reg-ex reversing hakkında konuşarak devam edelim. Öncelikle, WAF tarafından engellenip engellenmediklerini ve HTTP yanıtında bundan nasıl oluşturulduğunu görmek için <p>, <h1> veya <b> gibi zararsız etiketleri denemeli ve eklemeliyiz. Aşağıdakileri kontrol ediyoruz:
- Uygulanan kodlama türü
Bu olaylardan herhangi birinin meydana gelip gelmediğini not alıyoruz ve filtre etiketleri çıkarırsa, kapanış karakteri olmadan açık bir etiket eklemeye çalışıyoruz, örneğin <p, <h1 veya <b ve WAF’ın HTTP yanıtını inceliyoruz . Bu aşamada uygulama, uygulanan etiketi doğru şekilde oluşturduysa, bu, reg-ex’in hem açılış hem de kapanış parantezlerini aradığı ve açılış etiketini filtrelemediği anlamına gelir.
Bu olasılıklardan devam etmek için, WAF’lerin çoğunun filtrelediği en yaygın XSS komut dosyalarından bazılarını deniyoruz. Bunlar şunlar olabilir:
komut dosyaları, 403 yasak sayfa HTTP yanıtını veya 500 Dahili hatayı tetikleyebilir ve yanıttan veya bir kısmından tamamen çıkarabilir. WAF’ın yalnızca açılış ve kapanış komut dosyası etiketini filtrelediği ve diğer tüm içeriği el değmeden bıraktığı durumlar vardır. Ayrıca, daha önce gördüğümüz gibi, WAF yalnızca açma ve kapama parantezlerini filtreleyebilir ve diğerlerini olduğu gibi bırakabilir. Bir sonraki adıma geçmek için, kodlamanın temellerini kullanıyoruz ve etiketteki komut dosyası kelimesinin harflerinin büyük / küçük harflerini değiştirerek komut dosyası etiketini maskelemeye çalışıyoruz. Örneğin:
WAF büyük / küçük harfe duyarlıysa (ki bu çok nadir değildir), devam eder ve yalnızca bir kontrol yapan bir WAF’ın komut dosyası etiketini filtreleyeceği, ancak bunun filtrelemesiyle yeni bir kod etiketini oluşturulur ve komut dosyası başarılı olur. Yani, bu örnek için şuna benzer bir şey sağlıyoruz:
<scr <script> ipt> alert (document.cookie) </ scr <script> ipt>
Tüm bu kontrollerden sonra bir <a href=””> etiketini verelim ve cevabını inceleyelim, eğer WAF ilk gördüğümüz adımda olduğu gibi aynı kontrolleri yapıyorsa, yapmıyorsa bir Href etiketi içindeki JavaScript ifadesi.
Şimdi bu değişikliğin yanıtını kontrol etmeliyiz ve WAF, <a> etiketindeki JavaScript ifadesini filtrelemişse veya yalnızca JavaScript’i kaldırmışsa ve evet ise, bu filtreyi, büyük / küçük harf durumu ile oynayarak atlamaya çalışıyoruz. daha önce yaptığımız gibi mektuplar. Yalnızca JavaScript anahtar kelimesi filtrelenmişse, bu filtreyi kodlayarak atlamanın pek çok yolu vardır.
Z3DX
Bu olasılıklardan devam etmek için, WAF’lerin çoğunun filtrelediği en yaygın XSS komut dosyalarından bazılarını deniyoruz. Bunlar şunlar olabilir:
komut dosyaları, 403 yasak sayfa HTTP yanıtını veya 500 Dahili hatayı tetikleyebilir ve yanıttan veya bir kısmından tamamen çıkarabilir. WAF’ın yalnızca açılış ve kapanış komut dosyası etiketini filtrelediği ve diğer tüm içeriği el değmeden bıraktığı durumlar vardır. Ayrıca, daha önce gördüğümüz gibi, WAF yalnızca açma ve kapama parantezlerini filtreleyebilir ve diğerlerini olduğu gibi bırakabilir. Bir sonraki adıma geçmek için, kodlamanın temellerini kullanıyoruz ve etiketteki komut dosyası kelimesinin harflerinin büyük / küçük harflerini değiştirerek komut dosyası etiketini maskelemeye çalışıyoruz. Örneğin:
WAF büyük / küçük harfe duyarlıysa (ki bu çok nadir değildir), devam eder ve yalnızca bir kontrol yapan bir WAF’ın komut dosyası etiketini filtreleyeceği, ancak bunun filtrelemesiyle yeni bir kod etiketini oluşturulur ve komut dosyası başarılı olur. Yani, bu örnek için şuna benzer bir şey sağlıyoruz:
<scr <script> ipt> alert (document.cookie) </ scr <script> ipt>
Tüm bu kontrollerden sonra bir <a href=””> etiketini verelim ve cevabını inceleyelim, eğer WAF ilk gördüğümüz adımda olduğu gibi aynı kontrolleri yapıyorsa, yapmıyorsa bir Href etiketi içindeki JavaScript ifadesi.
Şimdi bu değişikliğin yanıtını kontrol etmeliyiz ve WAF, <a> etiketindeki JavaScript ifadesini filtrelemişse veya yalnızca JavaScript’i kaldırmışsa ve evet ise, bu filtreyi, büyük / küçük harf durumu ile oynayarak atlamaya çalışıyoruz. daha önce yaptığımız gibi mektuplar. Yalnızca JavaScript anahtar kelimesi filtrelenmişse, bu filtreyi kodlayarak atlamanın pek çok yolu vardır.
Z3DX
Bu içeriği görmek için giriş yapın.
