F5 BIG-IP AWAF ile Parametrelerde Base64 Korumasını Devreye Almak

Bu makalede, base64 ile kodlanmış parametrelerdeki korumaları nasıl devreye alabileceğimizden bahsedeceğiz.

Base64'ün ne olduğu ya da nasıl bir algoritma olduğu ile alakalı burada bilgi vermeyeceğim, araştıracağınıza eminim :).

Normal şartlarda, bir AWAF yöneticisinin uygulama ekibiyle birlikte çalışarak güvenlik politikasını oluşturması ve geliştirmesi, en ideal süreçtir. Bu iş birliği, uygulama davranışlarının doğru anlaşılmasını ve koruma politikalarının gereksiz engellemelere yol açmadan etkili şekilde uygulanmasını sağlar.

Uygulama ekibi size belirli bir URL’ye ait bir parametrenin base64 ile kodlandığını söylediğinde ya da loglarda parametre isimleri arasında “base64” ifadesine rastladığınızda, bu durum için koruma amacıyla bir aksiyon almanız gerekir.

Elbette, kodlanmış bir bilgiyi analiz edebilmek için önce onu çözmemiz gerekir. Bu noktada karşımıza “encode” ve “decode” kavramları çıkar; yani veriyi bir biçimde kodlamak ve ardından çözmek.

Daha önce de bahsettiğim gibi, olabildiğince Türkçe kelimeler kullanacağım lakin İngilizce terimlere de aşina olmakta fayda var.

Aşamalara geçmeden önce önemli bir not: uygulamanızda base64 ile ilgili bir kodlama veya çözme işlemi yoksa bu korumayı devreye almanız gerekmez. Örneğin saldırganlar veriyi base64 ile gönderse bile, uygulamanız bu kodlamayı çözemiyorsa saldırı uygulamayı etkilemez. Bu yüzden önceliğimiz her zaman mevcut sistemi korumak; var olan işleyişi göz önünde bulundurarak, gerçekten ihtiyaç varsa koruma eklemektir.

Test ortamımızda, her zamanki gibi, DVWA (Damn Vulnerable Web Application) uygulamasını kullanıyor olacağız. Base64 ile kodlanmış metinleri çözümlemek için de herhangi bir siteden yararlanmanız yeterli olacaktır. Ben bu siteden yararlanıyor olacağım.

Denemelerimizi yapacağımız alan, DVWA uygulamasındaki SQL Injection sekmesinde yer alan bölüm olacaktır.

Arayüzde gördüğümüz parametre alanı

/vulnerabilities/sqli/ URL’inde kullanılan id isimli parametre ile testlerimi gerçekleştireceğim. Burp Suite ile araya girip paketi inceleyerek parametre isminden emin olacağım ki tanımlama yaparken sorun yaşamayayım.

URL’de kullanılan parametreler

Oluşturduğum AWAF politikasında, bahsettiğim URL ve parametre tanımlı değil. İşe önce bunları tanımlayarak başlayacağım. Genel bir parametre tanımlayabileceğim gibi spesifik alanlarda kullanılan parametreler de tanımlayabilirim. Ben id parametresini, /vulnerabilities/sqli/ URL’inde kullanılan bir parametre olarak tanımlayacağım.

/vulnerabilities/sqli/ URL’ini protokol ve HTTP metodu belirterek, olabildiğince net bir şekilde oluşturdum.

‘/vulnerabilities/sqli/’ URL’ini oluşturdum

id parametresini tanımlayıp hangi URL ve lokasyonda kullanıldığını belirtiyorum.

Parametre tanımı

Son görünüm de bu şekilde olacak.

‘id’ parametresini oluşturdum

Test yaparken log profil seçimini ‘Log all request’ profilinden yana kullanacağım ancak unutmayın, bu profilin uzun süreli kullanımı yararlı olmayacaktır.

Gerekli tüm tanımları yaptım;

• AWAF politikasına URL tanımını yaptım.
• Bu URL ile bağlantılı parametre tanımını yaptım.
• Saldırıları SQL Injection yöntemiyle test edeceğim için AWAF politikasına SQL Injection saldırı setini ekledim ve ‘staging’ aşamasını kapattım.

İlk SQL Injection saldırımızı deneyelim; "' OR '1'='1 ".

Saldırı denemesi

‘Submit’ butonuna bastıktan sonra AWAF’ın blok sayfası ile karşılaştım. F5 BIG-IP’deki logları inceleyelim.

AWAF istek logu

Analiz ettiğim log üzerinde dikkat çekmek istediğim bazı alanlar var;

• Parameter Level — URL: Bu alan, yaptığım konfigürasyonu doğrular niteliktedir. Çünkü, spesifik olarak bir URL belirleyip parametreyi ona bağlı olacak şekilde oluşturdum.
• Parameter Name — id: Burası da URL’e bağlı oluşturduğum parametrenin devreye girdiğini gösterir.

Eğer bu alanlarda “Wildcard” ile alakalı bir ifade görürseniz, yaptığınız konfigürasyonları bir daha gözden geçirmenizi öneririm :).

Şu anda herhangi bir kodlama olmadan, AWAF’ın isteği blokladığını gördük. Peki, aynı ifadeyi base64 ile kodlandıktan sonra isteği gönderdiğimde AWAF ne yapacak?

Test etmek için, "' OR '1'='1 " ifadesini base64’e çevirdim, elde edilen değer JyBPUiAnMSc9JzE= oldu.

Şimdi DVWA uygulamasındaki deneme alanına bu ifadeyi ekleyelim ve isteği gönderelim.

F5 BIG-IP’deki logu görüntüleyelim.

Görüldüğü üzere, gönderilen istek hiçbir kural tarafından ihlal olarak işaretlenmedi , yani AWAF base64 ile kodlanmış bir ifadeden hiçbir anlam çıkaramadı. AWAF bu saldırıyı “görmedi”, saldırı olarak bildiğimiz ifade rahatça uygulama seviyesine indi.

Base64 korumasını devreye almanın vakti geldi. Daha önce oluşturduğum id isimli parametrenin içerisindeki alanlara bakalım.

Base64

İlgili parametrenin içerisinde, “Base64 Decoding” ayarını görüyoruz. Bu ayar, id parametresinde base64 çözümlemesini devreye alacak. Bu ayarı açtıktan sonra, AWAF politikasını Apply edip aynı isteği bir daha gönderelim ve logları kontrol edelim.

Özel karakter tespiti

Öncelikle ilk ihlalimizi inceleyelim; ‘Illegal meta character in value’. İlgili parametrenin değerinde, tek tırnak (‘) kullanımını yakaladığını söylüyor. Eğer ekstra bir ayar yapmazsanız bu karakter varsayılanlarda izinli olarak gelmez.

Saldırı imza tespiti

İkinci ihlal ise görmek istediğimiz ana ihlal olan ‘Attack signature detected’. Yani, SQL Injection için saldırı imza tespiti yapılmış.

“Parameter value” kısmında base64 ile şifrelenmiş ifadeyi görürken “Detected Keyword” kısmında çözümlenmiş ifadeyi görebilirsiniz.

Test ortamımızı oluşturduk ve başarılı bir koruma sağlayabildik. Burada yaşayacağımız yanlış pozitif durum ne olabilir peki?

AWAF, bir parametre üzerinde “Base64 decode” ayarını açtıktan sonra, o parametrede, her zaman, base64 ile kodlanmış bir değer bekler. Çözümlemesini yaptıktan sonra normal taramalarını yapmaya devam eder. Mesela, test yaptığımız id parametresine normal bir değer (kodlanmamış) girelim.

Hızlıca bir blok sayfası karşılıyor bizi. AWAF üzerindeki logu kontrol edelim.

Yanlış pozitif

“Base64 decode” ayarının açık olduğu bir parametreye normal bir ifade girersek ‘Illegal Base64 value’ ihlali ile karşılaşırız. İhlalin açıklaması olarak, AWAF’ın kendi açıklama metnini aynen aşağıya ekleyeceğim.

Sistem, değerin geçerli bir Base64 ifadesi olup olmadığını kontrol eder. Eğer değer gerçekten Base64 formatındaysa, sistem bu değeri çözümler (decode eder) ve güvenlik kontrollerine devam eder.

Kullandığınız bazı ifadelerde bu ihlal tetiklenmeyebilir; ‘sinem’ örneğinde tetiklendi lakin ‘lale’ ifadesinde tetiklenmeyecektir. Bunun nedeni de base64 ile kodlanmış ifadelerin uzunluğunun 4'ün katı olmasıdır.

Farklı durumlar ile karşılaşmış olmanız olasıdır, ben bizim yaşadığımız durumları anlatmak istedim.

Bu konu ile alakalı yaralanabileceğiniz F5 makalesini aşağıya ekliyorum.

https://techdocs.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-11-5-0/30.html