Neler yeni

Web Application Firewall(WAF)’ları Bypasslamak -6 (1 Viewer)

Z3DX 

Forum Efsanesi
onursal
pentester
Mesajlar
381
Credits
40
Web Application Firewall(WAF)’ları Bypasslamak -6

1612172740884.png


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​
 

Ekli dosyalar

  • 1612172792456.png
    1612172792456.png
    201.5 KB · Görüntüleme: 10
  • 1612172824080.png
    1612172824080.png
    145.9 KB · Görüntüleme: 9

Z3DX 

Forum Efsanesi
onursal
pentester
Mesajlar
381
Credits
40
Devam etmek için, modül 3'te gördüğümüz gibi JavaScript’i çalıştıracak bir olay işleyiciyi denemeliyiz:

Ve bir kez daha, olayın soyulup kaldırılmadığını veya “açık” dan sonraki “fareyle üzerine gelme” kısmının yalnızca soyulup kaldırılmadığını kontrol ediyoruz ve WAF’ın tüm verileri filtrelemeye çalışıp çalışmadığını kontrol etmek için geçersiz bir olay işleyicisi olası olaylar veya yalnızca bazıları. Bunu yapmak için şöyle bir şey veriyoruz:

Şimdi bu olayı enjekte edebiliyorsak, bu, WAF’ın yalnızca bir dizi olayı filtrelediği, hepsini değil anlamına gelir. HTML5 ile, JavaScript’i birlikte kullanabileceğimiz 150'den fazla olay işleyicimiz var ve bunların tümünü WAF tarafından filtrelememede büyük bir değişiklik var. Daha az sıklıkla filtrelenen olay işleyicilerinden biri “onhashchange” dir ve şu şekilde kullanılabilir:

Bu, birinin bir WAF’ı atlamak için izleyebileceği yaklaşımlardan biriydi, ancak tek yaklaşım değil. Pentesterin beğenisine ve deneyimine ve ele aldığı durumlara bağlı olarak test etmenin daha fazla yolu var.

Bu bölümü bitirmek için, daha önce yaptığımız gibi JavaScript’i enjekte etmek için kullanabileceğimiz yaygın olarak kullanılan diğer bazı etiketleri kullandığımız bazı durumları inceleyelim. Src niteliğini içeren bazı etiketlerle başlayalım. Bu niteliği kullanan birçok etiket vardır ve bunları aşağıdaki şekilde test edebiliriz:

Burada görebileceğiniz gibi, src özniteliklerini kullanan etiketlere olay işleyicileri ekleyebiliriz ve etiketi src’den a / ile ayırarak kullanabiliriz. Bu şekilde WAF’ı birçok kez kandırabilir ve atlayabiliriz. Src özniteliğini kullanan diğer iki ilginç etiket, iframe ve gömülüdür ve bir WAF’yi denemek ve atlamak için bunları aşağıdaki gibi kullanabiliriz:

<embed / src = // goo.gl/wrDiR

Bir JavaScript’i düşünebileceğimizden çok daha fazla şekilde uygulayabileceğimizi görebilirsiniz. İlkinde, iframe ve src arasındaki boşluğu kaldırıyoruz, böylece WAF bunları anahtar kelime olarak tanımlayamaz. İkincisinde, ayırma için tekrar / kullandığımızı ve ardından olay işleyicisini kodlamak için base64 kullandığımızı görüyoruz. Kodu çözülürse , <body onmouseover = alert (document.cookie)> üretir . Kullanabileceğimiz bazı etiketlerin diğer özellikleri, bir WAF’ı kötü amaçlı olarak engelleme eğiliminde olmadıkları için birçok kez bir WAF’ı atlamak için kullanılabilen poster ve verilerdir. Örneğin:

Bunları daha önceki komut dosyalarıyla aşağı yukarı aynı şekilde kullandığımızı görebilirsiniz, bu da bize bir WAF’ı denemek ve atlamak için birçok alternatif yolumuz olabileceğini söyler. Şimdi, pek çok WAF tarafından filtrelenmediği kanıtlanmış bir özellik, nadir kullanımı nedeniyle formaction özelliğidir. Bunu şu şekilde kullanabiliriz:

Anlayacağınız gibi, bir WAF geliştirme ekibinin bir WAF’ı atlamak için üretilebilecek tüm olası varyasyonları toplaması imkansızdır. Burada sadece bu iş için kullanılabilecek bir dizi öznitelik ve etiket gördük, ancak liste, referans için daha fazla örnekle devam ediyor:

* Arka Plan Özniteliği (tablo etiketi)

* Veri Özelliği (nesne etiketi)

* Kod Özniteliği (uygulama, yerleştirme etiketi vb.)

* Eylem Özelliği (form etiketi vb.)

Şimdiye kadar WAF parmak izi bağlamında Nmap ve WafW00f gibi bazı araçlar gördük, ancak sadece parmak izimizi değil, aynı zamanda hedef WAF’ı atlamamıza da yardımcı olabilecek çok çeşitli araçlar var. Otomasyon gerçekten önemlidir, çünkü farklı bir görüş elde etmek için sonuçlarımızı otomatik bir aracın sonuçlarıyla karşılaştırmalıyız.

WAFNinja, WAF’ı otomatik olarak atlamak için en iyi araçlardan biri olan Python ile yazılmış bir komut dosyasıdır. WAFNinja, araçla birlikte gelen yerel bir veritabanı dosyasında depolanan çeşitli yükler ve fuzzing dizeleri ile birlikte gelir. Ayrıca, kolayca genişletilebilmesi ve kullanımı basit olması için bu şekilde oluşturulmuştur. Ayrıca, hem GET hem de POST istekleriyle HTTP bağlantılarını ve yetkilendirme gerektiren sayfalara erişmek için çerez kullanımını destekler. Son olarak, kesen bir proxy kurma seçeneğimiz var, ancak bunu bu bölümde incelemeyeceğiz. Aşağıdakileri uygulayarak WAFNinja’yı Linux makinemize kolayca indirip çalıştırabiliriz:

git clone https://github.com/khalilbijjou/WAFNinja

Ve bundan sonra, WAFNinja klasörünün içinde, python wafninja.py dosyasını çalıştırarak çalıştırabiliriz. WAFNinja uygulamasının mantığı şu şekildedir:

wafninja.py [-h] [-v] {fuzz, bypass, insert-fuzz, insert-bypass, set-db}…

Ve aşağıdaki işlevleri kullanabiliriz:

* fuzz — WAF tarafından hangi sembollere ve anahtar kelimelere izin verildiğini kontrol edin.

* bypass veri tabanından hedefe yükleri gönderir.

* insert-fuzz bir dize ekleyin.

* insert-baypas baypas listesine bir yük ekleyin.

* set-db başka bir veritabanı dosyası kullanın. Aynı veritabanını başkalarıyla paylaşmak için kullanışlıdır.

Şimdi fuzz işlevi, daha önce bahsettiğimizin aynısını yapıyor. Farklı semboller ve anahtar kelimeler göndererek WAF kural kümesini tersine çevirir ve her isteğin yanıtlarını analiz eder. Aşağıdakileri gerçekleştirerek böyle bir saldırı oluşturabiliriz:

python wafninja.py fuzz -u “http://www.website.com/index.php?id=FUZZ" -c “phpsessid = cookie” -t xss -o output.html

Burada aşağıdaki seçenekleri kullandık:

* -c kullanmak istediğimiz çerez için

* -t saldırı türü için (sql veya xss)

* -o .html biçiminde kaydedilen çıktı dosyası için

Bu, bir fuzzing saldırısı gerçekleştirmenin bir yoludur ve bunu fuzz işlevini vererek yaptık. Fuzz dizgilerini daha fazla genişletmek için, bir fuzzing stringi ekleyebileceğimiz insert-fuzz’ı ekleyebiliriz. Ve son olarak, diğer gerçekten önemli işlev, yükleri numaralandırarak ve bunları hedefe göndererek WAF’ı zorlayan bypassondur. Her talebin cevabını analiz eder ve aşağıdaki şekilde kullanabiliriz:

python wafninja.py bypass -u “http://www.website.com/index.php" -p “Name=PAYLOAD&amp;Submit=Submit” -c “phpsessid=cookie” -t xss -o output.html

Burada tek farklı parametre, POST parametresi aracılığıyla yükleri göndermek için kullanılan -p’dir. Ayrıca insert-bypass fonksiyonunun eklenmesiyle yükleri genişletebiliriz. Daha fazla parametre ve kullanım örneği için, yardım sayfasını görmek için python wafninja.py -h yazın.

Modül 2'de gördüğümüz gibi, SQL enjeksiyonu WAF’ın gerçekten önemli bir bölümüdür ve birçok yönden onu atlayabiliriz. Ancak, elbette, onu atlamak için otomatik bir yola ihtiyacımız var. Bu nedenle modül 2'nin bir videosunda gördüğümüz SQLMap’i kullanacağız, ancak onu farklı bir şekilde kullanacağız. Öncelikle, SQLMap genel olarak, SQL enjeksiyon kusurlarını tespit etme ve kullanma ve veritabanı sunucularını devralma sürecini otomatikleştiren açık kaynaklı bir sızma test aracıdır. Bu bölümde, WAF’leri ve IDS’leri atlamak için SQLmap’i nasıl kullanabileceğimizi göreceğiz.

Bunu yapmak için, sunucuya otomatik olarak gönderilen yükleri değiştiren kurcalama betikleri kullanacağız. Bazı durumlarda, WAF’ı kandırmak için birkaç kurcalama komut dosyasını bir araya getirmemiz gerekebilir ve bunların tam listesini burada bulabiliriz

https://svn.sqlmap.org/sqlmap/trunk/sqlmap/tamper/

MySQL veritabanlarını hedef alacak iki komut dosyasını inceleyelim. Bu komut dosyaları, tüm boşlukları rastgele metin içeren yorumları engellemek için dönüştürür. Kali Linux’ta SQLmap’i başlatmak için, bir terminal penceresinde sadece sqlmap’i çalıştırıyoruz ve kurcalama betikleri için -tamper seçeneğini kullanıyoruz.

Örneğin:
sqlmap -u ‘http://192.168.85.128/dvwa/vulnerabilities/sqli/?id=1' — cookie=’cookiehere’ — dbms “MySQL” — technique U -p id — tamper “space2morehash.py”

Burada kullandığımız space2hash.py kurcalama betiğinin genişletilmiş sürümü olan space2morehash.py de açıklamaları belirli işlev adları ile parantez arasına ekleyecektir. Ayrıca kullandığımız seçenekler şunlardır:

-u Saldırmak istediğimiz URL

- cookie = HTTP Çerez başlık değerini nereye ekleriz

-dbms Sunucunun kullandığı dbms’yi zorlayan seçenek

- teknik Hangi SQL enjeksiyon tipinin test edileceğini belirtin. (U birleşim sorgusu tabanlıdır)

-p Test edilebilir parametreyi belirtin

Elbette bunun yanında, kurcalama betiklerini kullanmak için -tamper seçeneğini ve ardından betik adını kullanmalıyız.

Ekli dosyayı görüntüle 1747

Artık SQLmap’i çalıştırdığımıza göre, kurcalama betiği boşlukları% 23randomText% 0A ile değiştirdi, görebildiğimiz gibi URL kodlu. Modül 2'de incelediğimiz CHAR (), USER () ve CONCAT () fonksiyonları FUNCTION% 23randomText% 0A () olarak değiştirildi, çünkü bizim örneğimizde WAF tarafından engellendikleri tespit edildi. Neden bununla değiştirildiği bu ders kapsamında değildir.

Devam etmek için, kullanabileceğimiz ve kodlama işlemlerini otomatikleştirmeye yardımcı olabileceğimiz diğer iki program charencode.py ve chardoubleencode.py’dir

Bunlar, WAF anahtar kelimeleri filtrelediğinde baypas için gerçekten yararlı komut dosyalarıdır. En iyi çıkış yolunu bulabilirler ve -tamper seçeneğiyle bunları tekrar kullanabiliriz. Örnek bir saldırı şu şekilde olabilir:

sqlmap.py -u “http://localhost/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" — cookie=”security=low; PHPSESSID=bb61j7e8jrsfd87s9037fsdgf3" -D dvwa -tables -tamper “chardoubleencode.py”

Uygulama istekle URL’yi çözerse, ikinci komut dosyası olan chardoublebleencode.py’yi kullanırız. Basit charencode.py, kodlamada bize yardımcı olan basittir. Ek olarak, uygulama ASP / ASP.NET’te programlanmışsa, charunicodeencode.py ve percent.py betikleri gerçek yükü gizlemek için kullanılabilir. ASP’nin ilginç bir özelliği, karakterler arasına istediğimiz kadar yüzde işareti ekleme yeteneğidir, bu nedenle aşağıdaki resim 3'te görebileceğimiz AND 1 = %%%%%%%% 1 , tamamen geçerlidir.

Ekli dosyayı görüntüle 1748

SQLmap’te kendi kullanımlarına sahip birçok kurcalama komut dosyası vardır, bu nedenle neyin var olduğunu görmeniz ve her durumda uygun komut dosyasını kullanmanız gerekir. Kolaylıkla ve iyi sonuçlarla kullanılabilen gerçekten kullanışlı bir özelliktir.

 

Z3DX 

Forum Efsanesi
onursal
pentester
Mesajlar
381
Credits
40
WAF Örneklerini Atlama

Şimdiye kadar, teori hakkında daha fazla konuştuk (bu kötü değil), ancak WAF’larda yalnızca az miktarda gerçek saldırı gördük, bu yüzden şimdi yaygın olarak kullanılan ve gerçek güvenlik açıklarına dayanan WAF’lara yönelik bazı gerçek saldırıları inceleyelim üzerlerinde bulundu.

Bu güvenlik açıklarının yamalandığını ve yalnızca eski WAF’larda çalışacağını unutmayın, sahibini bilgilendirmeden gerçek bir WAF’ı atlamanın yollarını sağlayamayız.

Incapsula WAF, web sitelerini SQL Enjeksiyonlarına, siteler arası komut dizisine, yasadışı kaynak erişimine, OWASP ilk on tehdidine ve yorum spam’i, sahte kayıtlar, site kazıma ve kötü niyetli botlar dahil olmak üzere web 2.0 tehditlerine karşı korumak için çözümler sunar. Incapsula üzerinden web sitesi trafiğini yönlendirmek için bir web sitesinin Alan Adı Sistemini (DNS) değiştirerek çalışır. Incapsula daha sonra botlardan ve web sitesi kazıyıcılarından gelen kötü niyetli saldırıları filtreler.

Modül 1'de söylediğimiz gibi, WAF’leri atlamanın en çok kullanılan yollarından biri, HTTP parametre kirliliği ve HTTP parametre parçalanmasıdır. Şimdi Incapsula tarafından korunan aşağıdaki örnek web sitesini ele alalım:

http://www.website.com/page.asp?a=first&a=second

Parametre aynı olduğundan, web sitesi a parametresini “birinci, ikinci” olarak görecektir. Buna bildiklerimizden saldırmak için, bunu şu şekilde değiştirelim:

http://www.website.com/page.asp?a=nothing'/*&a=*/or/*&a=*/1=1/*&a=*/--+

Artık sayfa bir parametreyi “‘/ *, * / veya / *, * / 1 = 1 / *, * / — + -” olarak görüyor. Anlayacağınız gibi, bu bir WAF tarafından kolayca filtrelenebilir ve Incapsula, bu saldırıları, daha sonraki aşamalara geçirmeden önce, ASP’nin yaptığı gibi aynı isimle tüm parametreleri birleştirerek yönetir. Bu güvenlik önleminde, parametrelerin normalleştirme aşamasının ASP’den farklı son sonuçlar oluşturmasına izin veren bir güvenlik açığı bulunmuştur. Yani, daha önce sağladığımız saldırı bağlantısının Incapsula tarafından engellenebileceğini söylersek, aşağıdakiler onu atlayabilir:

http://www.website.com/page.asp?a=nothing'/*&a%00=*/or/*&a=*/1=1/*&a%00=*/--+

Gördüğünüz gibi, parametre adından sonra boş bir bayt var. Incapsula, parametreleri aynı karaktere sahip başka bir parametreden farklı bir boş baytı izleyen parametreleri ele alır. Yani Incapsula için a ve% 00 farklı bir parametredir. Sonuç olarak, parametre aynı isimle birleştirildiğinde, kötü amaçlı bir dizge görmeyecek ve onu filtrelemeyecektir.

Şimdi, aynı WAF içinde bazı XSS saldırılarına devam edelim. Bu WAF, <script> uyarı (document.cookie) </script> gibi herhangi bir kodlama olmadan kullandığımız yaygın XSS dizelerini doğru bir şekilde filtreliyor. Ayrıca, basit bir HTML etiketinde bir olay işleyicisi uygulamaya çalışmanın da faydasız olduğu kanıtlanmıştır, çünkü o da filtrelenmiştir. Dolayısıyla, <a href=”javascript:alert(‘test’)”> gibi bir şey filtrelenecek, ancak bizi şaşırtacak şekilde, <img src = x onerror = ”input”> gibi bir şey tespit edilmedi. Dolayısıyla, engellenen özellik, yalnızca olay işleyicisi değil, olay işleyicisinin içindeki JavaScript kodudur.

Bu önlemi atlatmanın ilk yolu, HTML, çift URL ve Unicode kodlamasının bir karışımını kullanmaktır. Yani, bu WAF’de bir baypas bulmak ve birçok test yapmak için derine inmemiz gerektiğini görebilirsiniz, ancak sonunda her zaman bir yol vardır. Şimdi şunları sağlayalım:

% 3Cimg% 2Fsrc% 3D% 22x% 22% 2Fonerror% 3D% 22prom% 5Cu0070t% 2526% 2523x28% 3B% 2526% 2523x27% 3B% 2526% 2523x58% 3B% 2526% 2523x53% 3B% 2526% 2523x53% 3B% 2526 % 2523x27% 3B% 2526% 2523x29% 3B% 22% 3E

Şimdi, bu önceki yük <img src = x onerror = ”input”> ama bazı değişikliklerle. Ayrıca, bu yük önce HTML ve ardından çift URL kodlamasıyla kodlandı. Çift URL kodlaması, istemcinin girişini birden çok kez URL olarak çözen belirli sunucularda çalışır.

Herkese açık olan ikinci XSS baypası, yalnızca 7 karakter içeren JavaScript’ler oluşturmak için tanıtılan bir teknik olan JS-F ** K’ye dayanmaktadır. Yani aşağıdaki gibi bir şey işi yapacak:

Bu yük ile, WAF eylemlerimizi engellemeden web sitesinde istediğimiz her şeyi yapabiliriz, ancak tek engel uzunluktur, çünkü çoğu sunucu GET isteği URL uzunluğunu kısıtlar. Bununla birlikte, yük gerçekten iyi bir çözümdür ve Imperva Incapsula WAF’ı başarıyla atlayabilir.

WebKnight WAF, IIS ve diğer web sunucuları için Açık Kaynak WAF’dir ve yaygın olarak kullanılmaktadır. Bu gerçekten iyi bir çözüm, ancak elbette onu atlamak için buradayız ve tüm WAF’ların en savunmasız filtre kurallarından birine sahip, ancak daha iyi olmaya çalışıyor. Artık OWASP tarafından sunulan ve bir WebKnight WAF’ı kolayca atlayabilen iki SQL Payload’ı şunlardır:

0 union(select 1,@@hostname,@@datadir) 0 union(select 1,username,password from(users))

Gördüğünüz gibi, ikisi de kullanıcı adı ve şifre dahil ciddi kişisel bilgileri ifşa ediyor ve yük hiç kodlanmamış. Ayrıca, bu WAF bir JavaScript olay işleyicisine, kullanıcı <details> öğesini açıp kapattığında meydana gelen geçişe karşı savunmasızdır ve tüm tarayıcılarda desteklenir. Örneğin:

Son olarak, bir <menu> öğesi bir bağlam menüsü olarak gösterildiğinde tetiklenen ve yalnızca Firefox web tarayıcısında çalışan başka bir olay işleyicimiz var. Bir kullanıcı sağ tıkladığında, komut dosyası WebKnight XSS filtre algılamasını atlayarak çalıştırılır ve aşağıdaki gibi üretebiliriz:

ModSecurity, yaygın olarak kullanılan ve güvenliği ciddiye alan, herkesin katılabileceği zorluklarla ve sonuç olarak WAF’ın sertleşmesine neden olan başka bir açık kaynaklı WAF’dir. Bu WAF’ta göreceğimiz ilk güvenlik açığı, bu kursta defalarca bahsettiğimiz boş bayta dayanmaktadır. Sadece script etiketinin içindeki boş baytı kullanmalıyız. Bu, WAF’ı atlayacak ve XSS saldırısını sorunsuz gerçekleştirecektir. Örneğin:

ModSecurity, girdiden tüm boş baytları çıkaran bir filtre kuralı uygulayarak bu sorunu çözdü. Bir sonraki baypas tekniği, tarayıcıların boşluk karakterleri olarak değerlendirdiği karakterlere dayanmaktadır. Her tarayıcı, aşağıda görebileceğiniz bu karakterlerin farklı bir kümesine sahiptir:

* IExplorer = [0x09,0x0B, 0x0C, 0x20,0x3B]

* Chrome = [0x09,0x20,0x28,0x2C, 0x3B]

* FireFox = [0x09,0x20,0x28,0x2C, 0x3B]

* Opera = [0x09,0x20,0x2C, 0x3B]

* Android = [0x09,0x20,0x28,0x2C, 0x3B]


Bundan yararlanmak için, olay adı özniteliği (onmouseover ve onggle gibi) ve eşittir işareti karakteri arasında bu karakterlerden birini kullanıyoruz. Örneğin:

İşte burada internet explorer’ın bir uzay karakteri olarak işlediği ve yükü doğru bir şekilde çalıştırdığı% 0B’yi izliyoruz. Pratik bir örnek olarak şunları verebiliriz:

http://www.website.com/example.htmltest=%3Cinput+onfocus%0B%3Dalert%281%29%3E&disable_ xss_defense = & disable_browser_xss_defense = açık

Bu, ModSecurity WAF’nin önceki bir sürümünün gerçek bir atlama örneğidir. Son olarak, kullanıcının isteğinden üç veya daha fazla kez kaçan ortamlarda çalışan bir baypas örneğini görelim. ModSecurity’nin bu yaklaşımının bir istismarı şunlar olabilir:

XSS saldırıları ile incelediğimiz bu tekniklerin çoğunun SQL Enjeksiyon saldırıları üzerinde de çalıştığını söyleyerek bitirelim. Öyleyse, örneğin, aşağıdakileri sağlarsak:

1 + uni% 0Bon + se% 0Blekt + 1,2,3

ModSecurity WAF’ı atlar, çünkü Internet Explorer’daki% 0B’yi bir alan olarak tanır.

WAF baypas ile ilgili son örneklerimiz için, en gelişmiş işletme seviyeli WAF’lardan biri olan F5 Big IP’yi inceleyelim, ancak göreceğiniz gibi, en iyi düşüşü bile. İlk baypas yöntemi olay işleyicileri, onwheel ve onshow ile ilgilidir ve ikincisi yalnızca Firefox tarayıcısında çalışır. Örneğin:

Burada görebileceğiniz gibi, F5 Büyük IP WAF’ı atlamayı başaran hiçbir kodlama içermeyen oldukça basit bazı yüklerimiz var. Analiz ettiğimiz ve bu WAF’yi atlamada başarılı olduğumuz bir başka yol da JS-F ** K kodlamasıdır.Örneğin, önceki örneklerin bir uzantısı olarak şunlara sahibiz:

Anlayacağınız gibi, parantezlerin içinde bir JS-F * ck Yükü kullanabiliriz, örneğin, uyarı (1) vermek istersek, aşağıdakileri veririz:

(! [] + []) [+! + []] + (! [] + []) [! + [] +! + []] + (!! [] + []) [! + [] +! + [] +! + []] + (!! [] + []) [+! + []] + (!! [] + []) [+ []] + (! [] + [ ] [(! [] + []) [+ []] + ([! []] + [] [[]]) [+! + [] + [+ []]] + (! [] + [ ]) [! + [] +! + []] + (!! [] + []) [+ []] + (!! [] + []) [! + [] +! + [] +! + []] + (!! [] + []) [+! + []]]) [! + [] +! + [] + [+ []]] + [+! + []] + ( !! [] + [] [(! [] + []) [+ []] + ([! []] + [] [[]]) [+! + [] + [+ []]] + (! [] + []) [! + [] +! + []] + (!! [] + []) [+ []] + (!! [] + []) [! + [] + ! + [] +! + []] + (!! [] + []) [+! + []]]) [! + [] +! + [] + [+ []]]

Son olarak, göreceğimiz son baypas, HTML kodlama ve çift URL kodlama ile ilkimiz gibidir. Bu yöntemle, önceki örnekler şuna dönüşecektir:

Anlayacağınız gibi, WAF’ler o kadar güvenli değildir ve bu sektördeki birçok kişinin düşündüğü gibi güvenlik için mükemmel bir çözüm değildir. Öncelikle, gördüğümüz sınırlamalar nedeniyle, WAF’ler web uygulamalarını mevcut tüm olası güvenlik açıklarından koruyamıyor ve ayrıca korunacak belirli uygulama için WAF filtrelerini uyarlamak da bir zorunluluk haline gelmiş durumda.

Ayrıca, WAF’ler güvenlik açığını ortadan kaldırmıyor, saldırı vektörünü kısmen tarıyor. Uygulamanın kendisini güvence altına almalıyız ve sadece güvenlik açığını filtreleyecek ve bu kadar kolay yollarla başarısız olacak bir katman uygulamalıyız. WAF’ler dikkatle uygulanmalıdır ve uygulamalardan sonra bile uygulamaların bakımına devam etmeliyiz.

Son olarak, WAF, web uygulamalarının ölçeklenebilir korumasının uygulanması bağlamında yararlı bir aracı temsil eder. Uygulama satıcısı düzeltme eki yapıp güvenlik açığını ortadan kaldırana kadar, işini iyi yapan ve saldırı vektörünü engelleyen gerçekten kullanışlı bir tercih gibi duruyor. Şimdilik.

Serinin son yazısını da tamamladım. Okuyan herkese şimdiden çok teşekkür ederim. Esen kalın.

Z3DX​
 

exe

ez152
Mesajlar
46
Credits
20
Web Application Firewall(WAF)’ları Bypasslamak -6

Ekli dosyayı görüntüle 1746


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 her neyse çok yararlı bişi
 

GnG

xxxx.com
majorrr
Mesajlar
10,238
Credits
1,678
Devam etmek için, modül 3'te gördüğümüz gibi JavaScript’i çalıştıracak bir olay işleyiciyi denemeliyiz:

Ve bir kez daha, olayın soyulup kaldırılmadığını veya “açık” dan sonraki “fareyle üzerine gelme” kısmının yalnızca soyulup kaldırılmadığını kontrol ediyoruz ve WAF’ın tüm verileri filtrelemeye çalışıp çalışmadığını kontrol etmek için geçersiz bir olay işleyicisi olası olaylar veya yalnızca bazıları. Bunu yapmak için şöyle bir şey veriyoruz:

Şimdi bu olayı enjekte edebiliyorsak, bu, WAF’ın yalnızca bir dizi olayı filtrelediği, hepsini değil anlamına gelir. HTML5 ile, JavaScript’i birlikte kullanabileceğimiz 150'den fazla olay işleyicimiz var ve bunların tümünü WAF tarafından filtrelememede büyük bir değişiklik var. Daha az sıklıkla filtrelenen olay işleyicilerinden biri “onhashchange” dir ve şu şekilde kullanılabilir:

Bu, birinin bir WAF’ı atlamak için izleyebileceği yaklaşımlardan biriydi, ancak tek yaklaşım değil. Pentesterin beğenisine ve deneyimine ve ele aldığı durumlara bağlı olarak test etmenin daha fazla yolu var.

Bu bölümü bitirmek için, daha önce yaptığımız gibi JavaScript’i enjekte etmek için kullanabileceğimiz yaygın olarak kullanılan diğer bazı etiketleri kullandığımız bazı durumları inceleyelim. Src niteliğini içeren bazı etiketlerle başlayalım. Bu niteliği kullanan birçok etiket vardır ve bunları aşağıdaki şekilde test edebiliriz:

Burada görebileceğiniz gibi, src özniteliklerini kullanan etiketlere olay işleyicileri ekleyebiliriz ve etiketi src’den a / ile ayırarak kullanabiliriz. Bu şekilde WAF’ı birçok kez kandırabilir ve atlayabiliriz. Src özniteliğini kullanan diğer iki ilginç etiket, iframe ve gömülüdür ve bir WAF’yi denemek ve atlamak için bunları aşağıdaki gibi kullanabiliriz:

<embed / src = // goo.gl/wrDiR

Bir JavaScript’i düşünebileceğimizden çok daha fazla şekilde uygulayabileceğimizi görebilirsiniz. İlkinde, iframe ve src arasındaki boşluğu kaldırıyoruz, böylece WAF bunları anahtar kelime olarak tanımlayamaz. İkincisinde, ayırma için tekrar / kullandığımızı ve ardından olay işleyicisini kodlamak için base64 kullandığımızı görüyoruz. Kodu çözülürse , <body onmouseover = alert (document.cookie)> üretir . Kullanabileceğimiz bazı etiketlerin diğer özellikleri, bir WAF’ı kötü amaçlı olarak engelleme eğiliminde olmadıkları için birçok kez bir WAF’ı atlamak için kullanılabilen poster ve verilerdir. Örneğin:

Bunları daha önceki komut dosyalarıyla aşağı yukarı aynı şekilde kullandığımızı görebilirsiniz, bu da bize bir WAF’ı denemek ve atlamak için birçok alternatif yolumuz olabileceğini söyler. Şimdi, pek çok WAF tarafından filtrelenmediği kanıtlanmış bir özellik, nadir kullanımı nedeniyle formaction özelliğidir. Bunu şu şekilde kullanabiliriz:

Anlayacağınız gibi, bir WAF geliştirme ekibinin bir WAF’ı atlamak için üretilebilecek tüm olası varyasyonları toplaması imkansızdır. Burada sadece bu iş için kullanılabilecek bir dizi öznitelik ve etiket gördük, ancak liste, referans için daha fazla örnekle devam ediyor:

* Arka Plan Özniteliği (tablo etiketi)

* Veri Özelliği (nesne etiketi)

* Kod Özniteliği (uygulama, yerleştirme etiketi vb.)

* Eylem Özelliği (form etiketi vb.)

Şimdiye kadar WAF parmak izi bağlamında Nmap ve WafW00f gibi bazı araçlar gördük, ancak sadece parmak izimizi değil, aynı zamanda hedef WAF’ı atlamamıza da yardımcı olabilecek çok çeşitli araçlar var. Otomasyon gerçekten önemlidir, çünkü farklı bir görüş elde etmek için sonuçlarımızı otomatik bir aracın sonuçlarıyla karşılaştırmalıyız.

WAFNinja, WAF’ı otomatik olarak atlamak için en iyi araçlardan biri olan Python ile yazılmış bir komut dosyasıdır. WAFNinja, araçla birlikte gelen yerel bir veritabanı dosyasında depolanan çeşitli yükler ve fuzzing dizeleri ile birlikte gelir. Ayrıca, kolayca genişletilebilmesi ve kullanımı basit olması için bu şekilde oluşturulmuştur. Ayrıca, hem GET hem de POST istekleriyle HTTP bağlantılarını ve yetkilendirme gerektiren sayfalara erişmek için çerez kullanımını destekler. Son olarak, kesen bir proxy kurma seçeneğimiz var, ancak bunu bu bölümde incelemeyeceğiz. Aşağıdakileri uygulayarak WAFNinja’yı Linux makinemize kolayca indirip çalıştırabiliriz:

git clone https://github.com/khalilbijjou/WAFNinja

Ve bundan sonra, WAFNinja klasörünün içinde, python wafninja.py dosyasını çalıştırarak çalıştırabiliriz. WAFNinja uygulamasının mantığı şu şekildedir:

wafninja.py [-h] [-v] {fuzz, bypass, insert-fuzz, insert-bypass, set-db}…

Ve aşağıdaki işlevleri kullanabiliriz:

* fuzz — WAF tarafından hangi sembollere ve anahtar kelimelere izin verildiğini kontrol edin.

* bypass veri tabanından hedefe yükleri gönderir.

* insert-fuzz bir dize ekleyin.

* insert-baypas baypas listesine bir yük ekleyin.

* set-db başka bir veritabanı dosyası kullanın. Aynı veritabanını başkalarıyla paylaşmak için kullanışlıdır.

Şimdi fuzz işlevi, daha önce bahsettiğimizin aynısını yapıyor. Farklı semboller ve anahtar kelimeler göndererek WAF kural kümesini tersine çevirir ve her isteğin yanıtlarını analiz eder. Aşağıdakileri gerçekleştirerek böyle bir saldırı oluşturabiliriz:

python wafninja.py fuzz -u “http://www.website.com/index.php?id=FUZZ" -c “phpsessid = cookie” -t xss -o output.html

Burada aşağıdaki seçenekleri kullandık:

* -c kullanmak istediğimiz çerez için

* -t saldırı türü için (sql veya xss)

* -o .html biçiminde kaydedilen çıktı dosyası için

Bu, bir fuzzing saldırısı gerçekleştirmenin bir yoludur ve bunu fuzz işlevini vererek yaptık. Fuzz dizgilerini daha fazla genişletmek için, bir fuzzing stringi ekleyebileceğimiz insert-fuzz’ı ekleyebiliriz. Ve son olarak, diğer gerçekten önemli işlev, yükleri numaralandırarak ve bunları hedefe göndererek WAF’ı zorlayan bypassondur. Her talebin cevabını analiz eder ve aşağıdaki şekilde kullanabiliriz:

python wafninja.py bypass -u “http://www.website.com/index.php" -p “Name=PAYLOAD&amp;Submit=Submit” -c “phpsessid=cookie” -t xss -o output.html

Burada tek farklı parametre, POST parametresi aracılığıyla yükleri göndermek için kullanılan -p’dir. Ayrıca insert-bypass fonksiyonunun eklenmesiyle yükleri genişletebiliriz. Daha fazla parametre ve kullanım örneği için, yardım sayfasını görmek için python wafninja.py -h yazın.

Modül 2'de gördüğümüz gibi, SQL enjeksiyonu WAF’ın gerçekten önemli bir bölümüdür ve birçok yönden onu atlayabiliriz. Ancak, elbette, onu atlamak için otomatik bir yola ihtiyacımız var. Bu nedenle modül 2'nin bir videosunda gördüğümüz SQLMap’i kullanacağız, ancak onu farklı bir şekilde kullanacağız. Öncelikle, SQLMap genel olarak, SQL enjeksiyon kusurlarını tespit etme ve kullanma ve veritabanı sunucularını devralma sürecini otomatikleştiren açık kaynaklı bir sızma test aracıdır. Bu bölümde, WAF’leri ve IDS’leri atlamak için SQLmap’i nasıl kullanabileceğimizi göreceğiz.

Bunu yapmak için, sunucuya otomatik olarak gönderilen yükleri değiştiren kurcalama betikleri kullanacağız. Bazı durumlarda, WAF’ı kandırmak için birkaç kurcalama komut dosyasını bir araya getirmemiz gerekebilir ve bunların tam listesini burada bulabiliriz

https://svn.sqlmap.org/sqlmap/trunk/sqlmap/tamper/

MySQL veritabanlarını hedef alacak iki komut dosyasını inceleyelim. Bu komut dosyaları, tüm boşlukları rastgele metin içeren yorumları engellemek için dönüştürür. Kali Linux’ta SQLmap’i başlatmak için, bir terminal penceresinde sadece sqlmap’i çalıştırıyoruz ve kurcalama betikleri için -tamper seçeneğini kullanıyoruz.

Örneğin:
sqlmap -u ‘http://192.168.85.128/dvwa/vulnerabilities/sqli/?id=1' — cookie=’cookiehere’ — dbms “MySQL” — technique U -p id — tamper “space2morehash.py”

Burada kullandığımız space2hash.py kurcalama betiğinin genişletilmiş sürümü olan space2morehash.py de açıklamaları belirli işlev adları ile parantez arasına ekleyecektir. Ayrıca kullandığımız seçenekler şunlardır:

-u Saldırmak istediğimiz URL

- cookie = HTTP Çerez başlık değerini nereye ekleriz

-dbms Sunucunun kullandığı dbms’yi zorlayan seçenek

- teknik Hangi SQL enjeksiyon tipinin test edileceğini belirtin. (U birleşim sorgusu tabanlıdır)

-p Test edilebilir parametreyi belirtin

Elbette bunun yanında, kurcalama betiklerini kullanmak için -tamper seçeneğini ve ardından betik adını kullanmalıyız.

Ekli dosyayı görüntüle 1747

Artık SQLmap’i çalıştırdığımıza göre, kurcalama betiği boşlukları% 23randomText% 0A ile değiştirdi, görebildiğimiz gibi URL kodlu. Modül 2'de incelediğimiz CHAR (), USER () ve CONCAT () fonksiyonları FUNCTION% 23randomText% 0A () olarak değiştirildi, çünkü bizim örneğimizde WAF tarafından engellendikleri tespit edildi. Neden bununla değiştirildiği bu ders kapsamında değildir.

Devam etmek için, kullanabileceğimiz ve kodlama işlemlerini otomatikleştirmeye yardımcı olabileceğimiz diğer iki program charencode.py ve chardoubleencode.py’dir

Bunlar, WAF anahtar kelimeleri filtrelediğinde baypas için gerçekten yararlı komut dosyalarıdır. En iyi çıkış yolunu bulabilirler ve -tamper seçeneğiyle bunları tekrar kullanabiliriz. Örnek bir saldırı şu şekilde olabilir:

sqlmap.py -u “http://localhost/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" — cookie=”security=low; PHPSESSID=bb61j7e8jrsfd87s9037fsdgf3" -D dvwa -tables -tamper “chardoubleencode.py”

Uygulama istekle URL’yi çözerse, ikinci komut dosyası olan chardoublebleencode.py’yi kullanırız. Basit charencode.py, kodlamada bize yardımcı olan basittir. Ek olarak, uygulama ASP / ASP.NET’te programlanmışsa, charunicodeencode.py ve percent.py betikleri gerçek yükü gizlemek için kullanılabilir. ASP’nin ilginç bir özelliği, karakterler arasına istediğimiz kadar yüzde işareti ekleme yeteneğidir, bu nedenle aşağıdaki resim 3'te görebileceğimiz AND 1 = %%%%%%%% 1 , tamamen geçerlidir.

Ekli dosyayı görüntüle 1748

SQLmap’te kendi kullanımlarına sahip birçok kurcalama komut dosyası vardır, bu nedenle neyin var olduğunu görmeniz ve her durumda uygun komut dosyasını kullanmanız gerekir. Kolaylıkla ve iyi sonuçlarla kullanılabilen gerçekten kullanışlı bir özelliktir.

Eline saglik
 

Bu konuyu görüntüleyen kullanıcılar