Stacklify (kurgusal şirket) dashboard’ları üzerinde sabah kahvemi yudumlarken, SIEM ekranında garip bir trafik fark ettim. Normalde sadece iç ağdan (internal network) gelmesi gereken sorgular, garip bir şekilde setup/validate uç noktasına (endpoint) doğru akıyordu. Hem de hiçbir yetkilendirme (authorization) header’ı olmadan. O an anladım ki, yine bir şeyler patladı. Metabase üzerinde keşfedilen ve aktif olarak sömürülen (exploited in the wild) bu sıfırıncı gün (zero-day) zafiyeti, aslında siber güvenlik dünyasındaki o çok sevdiğimiz 'içerideyiz, o yüzden güvendeyiz' balonunu iğneleyen son örnek oldu.
Sektörde yıllardır sızma testi (penetration testing) yapan biri olarak şunu söyleyebilirim: Birçok ekip, Metabase gibi veri görselleştirme ve iş zekası (business intelligence) araçlarını 'şirket içi kutsal kase' gibi görüyor. 'Nasılsa VPN arkasında', 'Nasılsa sadece adminler erişiyor' diyerek bu araçların güvenliğini hep bir sonraki sprint'e erteliyorlar. Ama işte bu son olay, kimlik doğrulaması (authentication) gerektirmeyen bir admin erişimi sağlayarak tüm o 'savunma derinliği' (defense in depth) stratejilerini tek bir HTTP isteğiyle çöpe attı. (Kaynak: The Hacker News)
Olayın teknik boyutu aslında çok trajikomik. Bir uygulamanın kurulum aşamasında (setup phase) kullandığı geçici bir anahtarın (setup token), uygulama kurulduktan sonra bile sistemde asılı kalması ve dışarıdan bir saldırganın bu anahtarı kullanarak kendini 'admin' olarak tanımlayabilmesi... Bunu ilk gördüğümde 'Hadi canım, bu kadar basit olamaz' demiştim, ama artık şaşırmıyorum. Sahada o kadar çok 'yanlış yapılandırılmış' (misconfigured) sistem gördüm ki, en büyük güvenlik duvarlarının arkasında unutulmuş bir setup-token her zaman daha tehlikelidir.
Stacklify (kurgusal şirket) tarafında bu sızıntıyı simüle ederken şunu fark ettim; saldırgan sadece admin yetkisi almıyor, aynı zamanda veritabanı bağlantılarını manipüle ederek tüm ham verilere (raw data) doğrudan erişim sağlayabiliyor. 192.168[.]1[.]100 gibi iç IP'ler üzerinden dönen bu trafik, çoğu zaman güvenlik ekiplerinin radarına bile girmiyor çünkü 'güvenilir bölgeden' geliyor. İşte buradaki en büyük yanılgı şu: Biz saldırganın kapıyı kırmasını bekliyoruz, oysa o açık bırakılmış pencereden içeri süzülüp ev sahibi gibi koltukta oturuyor.
Aslında yanlış söyledim, sadece bir pencere değil bu; direkt anahtarı paspasın altına bırakmak gibi bir durum. Daha doğrusu, paspasın altındaki anahtarı herkesin görebileceği bir API uç noktasında (endpoint) açıkta bırakmak.
Geçenlerde Stacklify ofisindeki küçük mutfakta yeni aldığımız mekanik klavyenin switch sesleri üzerine tartışıyorduk. Bir yandan da arka planda çalışan bir DAST (dinamik uygulama güvenliği testi) aracının raporlarını inceliyordum. O an düşündüm; biz bazen araçların mükemmelliğine o kadar odaklanıyoruz ki, mantık hatalarını (logic flaws) gözden kaçırıyoruz. Bir araç size 'SQL Injection yok' diyebilir ama 'Burada yetki kontrolü (access control) tamamen unutulmuş' demez. En azından her zaman demez. Güvenlik sadece araçlarla değil, o aracın nasıl düşündüğünü anlamakla ilgili.
Bu Metabase olayı, 'VPC içindeyiz, güvendeyiz' diyen o konfor alanını darmaduman ediyor. Saldırgan attacker[.]example[.]com üzerinden bir istek gönderdiğinde ve bu istek sizin load balancer'ınızdan geçip içerideki Metabase konteyner'ına ulaştığında, o konteyner dış dünyadan mı yoksa iç ağdan mı geldiğini her zaman doğru ayırt edemeyebilir. Özellikle Kubernetes ortamlarında (K8s) network policy'ler düzgün yapılandırılmadıysa, sızan bir saldırganın yatayda ilerlemesi (lateral movement) çocuk oyuncağına dönüyor.
Sektörde yaygın bir efsane vardır: 'Zafiyetler sadece karmaşık kod bloklarında olur.' Hayır, en tehlikeli zafiyetler genellikle en basit 'if-else' bloklarının eksikliğinden çıkar. Metabase örneğinde gördüğümüz gibi, 'kullanıcı admin mi?' sorusundan önce 'kullanıcı gerçekten kullanıcı mı?' sorusunu sormayı unutan bir mantık yapısı var. Bir DevSecOps pratisyeni olarak, CI/CD süreçlerimizde kullandığımız IaC (Infrastructure as Code) dosyalarında, örneğin Terraform veya Helm chart'larda, bu tür hassas araçların dış dünyaya nasıl açıldığını kılı kırk yararak incelemeliyiz. 'Internal' etiketi, bir zırh değil, sadece bir konum bilgisidir.
Kendi deneyimlerimden biliyorum, bir keresinde bir müşterimin ağında test yaparken, sırf geliştiriciler kolaylık olsun diye bir debugging (hata ayıklama) arayüzünü şifresiz bırakmışlardı. Sadece 5 dakika içinde tüm müşteri veritabanına ulaştım. Onlara bunu söylediğimde aldığım cevap şuydu: 'Ama oraya kimsenin erişebileceğini düşünmemiştik.' Siber güvenlikte 'düşünmemiştik' kelimesi, bir zafiyet bildirim raporunun (vulnerability report) giriş cümlesidir.
Yıllar geçse de değişmeyen tek şey, bizim 'güvenli' sandığımız limanların aslında en çok fırtına alan yerler olması. Metabase'deki bu durumu kapatmak için yayınlanan yamayı (patch) uygulamak teknik olarak kolay, ama o 'güven' sarsıldıktan sonra onu geri kazanmak zor. Şirketler şimdi 'Acaba başka hangi iç aracımızda benzer bir açık var?' diye soruyorlar. Ve dürüst olmak gerekirse, muhtemelen birçoğunda var. Sadece henüz keşfedilmedi ya da şu an sessizce sömürülüyor.
Şimdi Stacklify'daki loglara tekrar bakıyorum. Saldırganın bıraktığı izler (footprints) aslında çok net, ancak o gürültünün içinde kaybolup gitmişler. Veri tabanı yöneticilerimizden biri 'Metabase zaten çok fazla sorgu atıyor, normaldir' demişti sabah. Normal olan ne? Bir admin panelinin yetkisiz biri tarafından yönetilmesi mi, yoksa bizim buna bu kadar alışmış olmamız mı?
Bakalım bu sıfırıncı günün artçı şokları daha ne kadar sürecek ve daha hangi 'dokunulmaz' görülen araçlar listeye eklenecek?