WHMCS <= 5.2.8 SQL Injection Zafiyeti Analizi

Merhaba

WHMCS, web sunucuları için yönetimsel arayüz hizmete veren ve PHP ile yazılmış bir yazılımdır. Bir çok web sunucusunda kurulu olan bu uygulamanın 5.2.8 versiyonu ve öncesini etkileyen SQL Injection zafiyeti bulunmaktadır. Bu yazıda WHMCS 5.2.8 SQL Injection zafiyetinin nasıl oluştuğu analiz edilecektir.

Yazılım genel olarak incelendiğinde pek çok  SELECT sorgusu select_query adından ki bir fonksiyon ile oluşturulmaktadır. Bu fonksiyonun tanımlandığı dosyayı aşağıdaki bash script betiği ile bulunabilir.

./whmcs_5.2.8_mtimer-master/includes/dbfunctions.php dosyası metin editörü ile açıldığında select_query fonksiyonu aşağıdaki şekilde tanımlandığı görülmektedir.

Yukarıdaki PHP kodları analiz edildiğinde; WHERE statement’ı için birden fazla durum kontrol edildiği görülmektedir. Her durum kontrolü sonunda ise $value değeri db_escape_string() fonksiyonuna gönderilmektedir.

db_escape_string fonksiyonu gene aynı dosyada tanımlıdır ve kodları aşağıdaki gibidir.

Beklenildiği üzere mysql_real_escape_string fonksiyonu burada görev almaktadır. Bu fonksiyon sql injection saldırılarına önlem alınması için geliştirilmiştir. Şu ana kadar herhangi bir SQL Injection zafiyeti tespit edilememiş gibi gözüksede, gizli bir sql injecition zafiyeti bulunmaktadır.

Mysql_real_escape_string Ne işe yarar ?

SQL Injection saldırı payloadları genellikle tek tırnak işareti ile başlar. Bunun sebebi kod tarafından native tanımlanmış olan sql query syntax’ında hatadan kurtulmaktır.

Yukarıdaki örnekte $id değişkeni kullanıcı tarafından tanımlanmakta olan bir user input’udur. SQL sorgusunda syntax hatası olmaması için SQL Injection payload’ı tek tırnak ile başlayıp ‘ or ‘1’=’1  şeklinde olmalıdır. Buradaki en önemli nokta payload’ın sonunda tek tırnak olmamasıdır. Bu sayede syntax hatasından kaçılmış olur.

Bu durumun farkına varan PHP geliştiricileri mysql_real_escape_string fonksiyonunu geliştirmişlerdir. Bu fonksiyon tek tırnakları \’ işareti ile değiştirmektedir.

Bu sayede sql injection saldırısı yapılsa bile ters slash işaretlerinden ötürü syntax hatasına neden olunacağı için saldırı başarıya ulaşamayacaktır.

ve GOL!

Uygulama geliştirici arkadaşlar mysql_real_escape_string fonksiyonunu kullandıklarında her zaman SQL Injection zafiyetine karşı korunmuş olmazlar. Eğer kod tarafında tanımlanmış native sorgu WHERE statement’ında TEK TIRNAK içermiyorsa bu sefer saldırı başarılı olacaktır.

Saldırgan bu sefer sql injection payload’ı olarak ‘ or ‘1’=’1 yazmak zorunda değildir. Çünkü sql sorgusunda herhangi bir tek tırnak bulunmamaktadır. Bu nedenle 1 or 1=1 yazıldığında sorgu hatası çalışacaktır. Kullanıcı girdisinde sadece tek tırnak için işlem yapan mysql_real_escape_string fonksiyonunun kullanılmasıda herhangi bir koruma sağlayamamış olacaktır.

Analize Devam ve viewticket.php Dosyası

select_query fonksiyonunun analizine devam ettiğimizde aşağıdaki durum özet olarak ifade edilebilir.

Parametre olarak alınan $where değişkeni üzerinden iterasyon yapılarak her WHERE statement’i değeri db_escape_string fonksiyonundan geçirilmektedir. Bu durumda tüm WHERE statement oluşturma aşamalarından sorumlu döngü kontrol edildiğinde aşağıdaki satır dikkat çekmektedir.

Eğer sqltype değeri TABLEJOIN eşitse, değer db_escape_string fonksiyonundan geçirilerek $criteria dizisine yazılmaktadır. Burada ki en önemli nokta. aşağıdaki satırdır.

Dikkatlice okunduğunda db_escape_string fonksiyonundan dönen değer direk eşittir ifadesinin sağ tarafında atanmıştır. Bu atama işlemide TEK TIRNAK’ların arasına yazılmadan gerçekleştirilmiştir. Bu durumda db_escape_string fonksiyonu, bir önceki alt başlıkta anlatılan nedenlerden ötürü herhangi bir işe yaramayacaktır.

Exploitation

select_query fonksiyonunda potansiyel bir SQL Injection zafiyeti olduğu görülmektedir.  Şimdi ise yazılım genelinde bu exploiti kullanabileceğimiz uygun bir select_query kullanılmış PHP dosyası bulunmalıdır. Bu durumda viewticket.php  , istenileni tam olarak vermektedir. Ayrıca en büyük tehlikeye neden olan kısım ise bu dosyaya erişim için herhangi bir oturumun olmasına gerek yoktur. Bu dosya web üzerinden herhangi bir kullanıcıya açık durumdadır.

Ticketview.php dosyasından alınan aşağıdaki kodların sadece 6, 35 ve 36. satırlarını okuyunuz.

6. satırda kullanıcıdan POST talebi ile tid değişkeni alınmaktadır.

35. satırda alınan bir $tid değişkeni select_query fonksiyonuna $where parametresi olarak aktarılmıştır.

36. satırda ise select_query tarafından oluşturulan sql sorgusu çalıştırılmaktadır.

SQLi Payloadı

select_query fonksiyonunda tek tırnakların kullanılmamasından ötürü sql injection potansiyeli bulunduran if kısmına girebilmek için sqltype değerinin TABLEJOIN olması gerekiyordu. Eğer bu durum sağlanırsa value değeri db_escape_string fonksiyonundan geçirilerek SQL sorgusuna yerleştirilmekteydi. Bu şartları sağlamak için aşağıdaki HTTP POST talebi değişkeni oluşturulmalıdır.

Value değeri -1 olarak tanımlamıştır ve bu değer üzerinden SQL Injection gerçekleştirilebilmektedir.

whmcs

 

Dönen sayfada ile admin kullanıcısının hash’i bulunmaktadır.

 Python ile Exploit Kodunun Geliştirilmesi

Şimdiye kadar anlatılan ve teknik analizi gerçekleştirilen bu SQL Injection zafiyetini otomatize olarak kullanılmak istenebilir. Bu işlemleri otomatize halde gerçekleştiren exploit kodu python ile yazmış bulunmaktadır.

Sonuç:

whmcs python exploit

  • burak karacali

    Eline saglik,
    Bu egitimde olaylarin adim adim anlatilmasi,
    Whmcs ye plugin gelistirenler icinde iyi olur,

    Kolay gelsin, iyi calismalar