Siber Güvenlik

Yük Dengeleyiciler ve Gerçek IP Adresi Karmaşası

Güvenlik uzmanı olarak çalışıyor olmanın getirmiş olduğu en güzel artılardan bir tanesi şüphesiz nerede ise her ekip ile içli dışlı oluyor olmaktır. Güvenlik denetimi sonrası tespit edilen bulgular sebebiyle başta yazılım geliştiriciler olmak suretiyle  orta ve alt katman sorumluluları, veri tabanı yöneticileri ve analistler ile sayısız kez emek verme imkanım oldu. Bir uygulamanın muntazam ve güvenli emek vermesi için teoride bir arada, gerçekte ise birbirinden tamamiyle uç noktalarda çalışan bu takımlar temeli ortak olan güvenlik zafiyetleri ile baş etmeye çalışırlar. Bu yazıda dile getireceğim hususlar ve yaşanmış tecrübeler de tam olarak bununla ilgili olacak.

Günümüz web uygulamaları birden fazla uygulama sunucusu ve veri tabanı sistemleri üstünde çalışır. Temel anlamda tamamiyle aynı kaynak kodu paylaşan iki tane uygulama sunucusu düşünün. Kullanıcıdan gelen istekler, yük durumuna bakılırsa bu iki sunucudan herhangi birisi tarafınca karşılanmak suretiyle hazırdır. Hangi talebin hangi uygulama sunucusuna aktarılacağının kararını, HTTP taleplerini uygulama sunucularının önünde karşılayan yük dengeleyici -load balancer- mekanizma yapar. Buda bizi, orta katman sistem yöneticileri ve yazılımcıların dahil bir büyük probleme götürür. Kullanıcının gerçek IP adresi nedir ?

load-balancing-diagram-2

Yukarıdaki diagram, “yük dengeleyici” kelimesini fazlaca net bir halde özetleyen grafiktir. Güvenlik uzmanları açısında yük dengeleyiciler, time-based sql injection ataklarında fazlaca ciddi problemler yaşatıyor olsada bizim bu yazıda ki mevzumuz tamamiyle IP Spoofing ile ilgili olacak.

Proxy ve Real IP

Proxy kelime olarak vekil sunucu anlamına gelir. Doğrusu iki sistem arasındaki iletişimi taşımaktan görevli vekillerdir. Yukarıdaki resme bakıldığında da vekil görevini load balancer’ın yüklendiği görülmektedir. Doğrusu hem kullanıcı hemde uygulama sunucusu ile konuşan tek bir sistem mevcuttur. Ağ trafiği anlamında baktığımızda da web1 yada web2 sunucuları devamlı load balancer’ın IP adresi ile konuşmaktadır. Aynı durum kullanıcılar içinde geçerlidir pek doğal olarak.

Bir Yazılımcı, Bir Orta Katman Sorumlusu ve XFF

Varsayalım ki, bu uygulamayı geliştiren şahıs bir şahıs var. İş birimide diyor ki “Kullananların hatalı parola denemeleri vb benzer biçimde tüm aktiviteler IP adresleri ile beraber kayıt altına alınacaktır.” . İlk başta kullanılan programlama dilinin sağlamış olduğu olanak ile HTTP talebinin karşılandığı anda kullanıcının IP adresini tespit eden geliştirici, uygulamanın tüm akışı içinde bu veriyi kullanmaya devam eder. Geliştirme süreci süresince devamlı kendi ip adresi durağan(durgun) olacağı için (kurumsal ağlarda kullanıcı bilgisayarları MAC adresi üstünden static IP tahsis edilir) kendi testleri süresince hep aynı adresi görmesi düzgüsel olacaktır. Bir süre sonrasında iş birimi tarafınca meydana gelen kabul testlerinde bu mesele ortaya çıkar ve yazılım geliştiriciye durum iletilir. Bu aşamada şahıs “E madem bir halde her insanın IP adresi aynı geliyor… Development ortamında kendime bir controller yazayımda uygulamaya iletilen HTTP request’ini raw halde döküp bakayım.” diyecektir. İşte kim bilir ilk sefer, kim bilir fazlaca benzer bir hikayeyi daha ilkin yaşamış olduğu için X-Forwarded-For ile tanışılan an gelir.

Uygulama sunucusuna X-Forwarded-For isminde bir header bilgisi gelmektedir ve içinde hep loglarda görmüş olduğu load balancer’ın değil ipconfig ile denetim etmiş olduğu  kendi ip adresini görmektedir. Peki o vakit aşağıdakine fazlaca benzer kod ile bu problemi çözebilirim der.

function get_ip_address() {
    $ip_keys = array('HTTP_CLIENT_IP', 'HTTP_X_FORWARDED_FOR', 'HTTP_X_FORWARDED', 'HTTP_X_CLUSTER_CLIENT_IP', 'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED', 'REMOTE_ADDR');
    foreach ($ip_keys as $key) 
        if (array_key_exists($key, $_SERVER) === true) 
            foreach (explode(',', $_SERVER[$key]) as $ip) 
                // trim for safety measures
                $ip = trim($ip);
                // attempt to validate IP
                if (validate_ip($ip)) 
                    return $ip;
                
            
        
    
    return isset($_SERVER['REMOTE_ADDR']) ? $_SERVER['REMOTE_ADDR'] : false;
}

(Oldukça iyimser yaklaşmış olsamda, gelen değerin geçerli bir IP adresi olup olmadığının denetim edilmesinin elzem bulunduğunu yazılım başka bir hikayede öğrenecektir aslen.)

Bu yaklaşım ile yazılımcının aslen bilincinde olmadan kabul etmiş olduğu bir varsayım ortaya çıkmaktadır.

Uygulama sunucusuna gelen X-Forwarded-For güvenilirdir. Kullanıcı aslına bakarsan proxy kullanıyorsa onun IP adresi değiştirilemez ki… Zira HTTP protokolünde IP spoofing yapılamaz.(!)

Hikayemiz burada yazılım geliştirici için son buldu. Lakin girizgahta söylediğim “Bir uygulamanın muntazam ve güvenli emek vermesi için teoride bir arada, gerçekte ise birbirinden tamamiyle uç noktalarda çalışan bu takımlar temeli ortak olan güvenlik zafiyetleri ile baş etmeye çalışırlar” cümlesini hatırlamakta yarar var. Birde load balancer’ın konfigürasyonundan görevli şahıs açısından vakası ele alalım.

Network alanında son aşama donanımlı olan sistem yöneticisi aşağıdaki cümleleri düşünür.

Yazılımcılar kim bilir X-Forwarded-For vb benzer biçimde detayları kayıt altına alıyordur. Esasen HTTP talebi içinde ki hiçbir veriye güvenilmeyeceğini hepimiz bilir. Ben gelen X-Forwarded-For’u de ileteyim. Herhangi bir probleme sebebiyet vermek istemiyorum.

Bundan dolayı dış dünyadan gelen X-Forwarded-For’ü iletir. Lakin bunun yanı sıra kendisine talebi gönderen sistemin TCP source adresini ikinci bir header kıymeti olarak -Mesela; True-Client-IP- gönderir.

İki değişik birimin özünde aynı olan mesele ile ilgili iki değişik yaklaşımı bir zafiyet doğurmuş olur. Client IP Spoofing zafiyeti. Bundan dolayı hiçbir IP bazlı loglama ve daha da kritiği IP bazlı yetkilendirmenin işe yaramayacağı son aşama tehlikeli sonuç bir durum ortaya çıkar. Benim pentestlerde tespit ettiğim garip vakalar bir yana dursun -NDA-  http://blog.ircmaxell.com/2012/11/anatomy-of-attack-how-i-hacked.html şu hikayeyi her insanın okumasını tavsiye ederim. Bu yazıda ele alınan mevzuya mükemmel bir örnektir.

Pentestler

Şahsen ben tüm güvenlik denetimlerimde Firefox kullanmaktayım. Firefox’ü kolay bir eklenti ile konfigüre ederek tüm HTTP taleplerinde “X-Forwarded-For: 127.0.0.1” eklenmesini sağlıyorum. Böylece tüm pentestlerde bu tür zafiyetleri soruşturma imkanım artmakta. Doğal olarak OWASP Checklist’e bakılırsa denetim gerçekleştirmek, bu tür zafiyetleri denetim etmeyi unutmayı engeller lakin XFF zafiyetnin varlığını saptamak için, uygulama içinde sizin yada alınan aksiyonların ip adresini gösteren vb bir modülünün olması koşul.

Çözüm ve Tavsiyeler

Kurumlar için eğer olmazsa olmazlardan bir tanesi, tüm yazılım ekiplerine ve dış kaynak firmalara uymaları için mecburi tutulacak bir güvenli uygulama geliştirme dokümanıdır. Bunu hazırlamak koşul. Mesela kurum olarak; “Kullanıcı IP adresine ihtiyacın var ise, XXX adlı header bilgisini kullanın” deniyor olmalıdır. Ters halde değişik takımlar ve özelliklede kod kalitesinin ölçülmesi son aşama zorluk derecesi yüksek ve ihale ile iş verilen dış kaynak firmalarda ki yazılım geliştiricilerin insiyatifine kalacaktır.

Spesifik olarak bu problemi çözmek için aşağıdaki F5 kuralı kullanılabilir.

when HTTP_REQUEST 
  HTTP::header remove X-Forwarded-For    
  HTTP::header insert X-Forwarded-For [IP::remote_addr]

Bu kaide, dış dünyadan gelen HTTP talebi içindeki X-Forwarded-For alanını kaldırır. Peşinden kendisine talebi ileten sistemin IP adresini (buraya dikkat, bu kıymeti TCP source adresinden hesaplar. Böylece spoof edilemezdir) ilave ederek talebi iletir. Böylece hali hazırda X-Forwarded-For’a bakılırsa hareket eden yazılımlar için güvenilir bir sıralama sunulmuş olur.

Ve son önerim ise, yazılım geliştiricilere “SDLC Eğitimi” haricinde gerçek hayatta karşılaşılan zafiyetleri ve bu benzer biçimde durumların analizlerini çözümleri ile beraber özetleyen hususi eğitimlerin organize edilmesi. INVICTUS EUROPE olarak bilhassa kurumsal firmalarda çalışan yazılım geliştiriciler için hazırladığım “Gerçek Yaşam Örnekleri ile Web Uygulama Güvenliği” eğitiminde, 10 yılı aşkın süredir deneyim ettiğim bu tür disipliner farklılıkların ürettiği zafiyetlere karşı yazılım geliştiriciler olarak hangi alışkanlıklar edinilmelidiri anlatmaktayım.


Merhaba, beni Instagram'da takip etmeyi unutmayın : @tahamumcu
Taha Mumcu
Ben Taha Mumcu, Bilişim sektöründe uzun süreden beri tecrübe edinerek bir yerlere gelmek için çalışmalarına devam eden ve sektörü yakından takip ederek hiç bir veriden geri kalmayan, girişimci ruhu ile tüm işlere elinden geldiğinde çalışma yapan bir girişimciyim. Henüz genç yaşta birçok tecrübeye ulaşan ve koyulan engelleri aşarak bir yerlere gelmek için çaba göstermekten çekinmiyorum.

Leave a reply

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

You may also like

Next Article:

0 %