CVE-2021-22175: GitLab Server-Side Request Forgery (SSRF) Vulnerability

Zorluk Seviyesi: Orta | Kaynak: CISA KEV

Zafiyet Analizi ve Giriş

Gelişen teknoloji ile birlikte, web uygulamalarında güvenlik açıkları da önemli bir sorun haline gelmiştir. GitLab, açık kaynak kodlu bir platform olarak çok sayıda geliştirici ve işletme tarafından kullanılmakta ve bu nedenle güvenliğinin sağlanması kritik öneme sahiptir. CVE-2021-22175, GitLab'daki bir sunucu tarafı istek sahteciliği (SSRF) zafiyetidir. Bu zafiyet, internal (iç) ağa yapılan web kancaları için istekler açıkken, kötü niyetli kullanıcıların hassas verilere erişim sağlayabilme ihtimalini barındırmaktadır. Özellikle bu tür zafiyetlerin kötüye kullanımları, saldırganların uzaktan kod çalıştırma (RCE - Remote Code Execution) yeteneği kazanmasına sebep olabilir.

CVE-2021-22175 zafiyetinin tarihçesi incelendiğinde, GitLab platformunun belirli sürümlerinde, iç ağa yönelik isteklerin yeterince doğrulanmadığı tespit edilmiştir. Bu durum, GitLab’ın webhook işlevselliğinin kötüye kullanılmasına olanak tanır. Özellikle, webhook kullanımı yaygın olan uygulamalarda, saldırganlar bu açıkları hedef alarak, kötü amaçlı istekler gönderip sistemin iç yapısına sızmayı amaçlayabilirler.

Güvenlik açığının temelinde, GitLab’ın kullandığı bazı kütüphanelerdeki hatalar yer almaktadır. GitLab, kullanıcıların çeşitli harici sistemlere otomatik bildirim göndermesi için webhook özelliğini sağlamaktadır. Ancak, bu özelliğin güvenli bir şekilde yapılandırılmaması, SSRF türündeki saldırıların etkili olmasına yol açmaktadır. Saldırganlar, bu açığı kullanarak iç sunuculara istek gönderebilir, bu da genellikle veri sızıntısına veya başka zayıf noktaların keşfine neden olabilir.

CVE-2021-22175 zafiyetinin dünya genelindeki etkileri oldukça geniştir. Özellikle yazılım geliştirme, bilgi teknolojileri ve finans sektörleri gibi veri hassasiyetinin yüksek olduğu alanlar, bu tür zafiyetlerden en çok etkilenen sektörlerdir. Bu sektörlerde, GitLab gibi popüler araçların kullanılması, veri kaybı veya izinsiz erişim riskini artırmaktadır. Örneğin, bir finans kuruluşunda devreye alınmış bir GitLab sunucusu, bu tür bir zafiyetten etkilenirse, kullanıcı bilgileri veya mali veriler gibi kritik bilgiler kötü niyetli kişilerin eline geçebilir.

Gerçek dünya senaryoları incelendiğinde, bu tür bir SSRF açığı üzerinden gerçekleştirilen bir saldırı, bir yazılım geliştirme sürecinde ciddi sıkıntılara neden olabilir. Saldırgan, GitLab sunucusunu kullanarak iç yapıya erişim sağladığında, işletmenin iş sürekliliği ve bilgi güvenliği büyük tehdit altına girecektir. Örneğin, bir uygulamanın bir bileşenindeki veri sınıfları açığa çıkabilir ya da bir iç API’ye yapılan yetkisiz erişim, sistemin tüm denetim mekanizmalarını aşabilme yeteneği verebilir.

Sonuç olarak, CVE-2021-22175 zafiyetinin ciddiyeti, GitLab kullanıcılarının bu tür güvenlik tehditlerine karşı hazırlıklı olmalarını ve sürekli güncellemeler ile sistemi güvenli tutmalarının gerekliliğini göstermektedir. Geliştiricilerin ve sistem yöneticilerinin, güvenlik politikalarını gözden geçirip gerekli tedbirleri alması, yazılım dünyasında bu tür zayıflıkları minimize etmek için hayati öneme sahiptir. Uzaktan kod çalıştırma (RCE) ve diğer potansiyel güvenlik zafiyetlerine karşı, sürekli bir farkındalık ve eğitim políticasi, güvenilir bir yazılım geliştirme sürecinin temel taşlarını oluşturur.

Teknik Sömürü (Exploitation) ve PoC

GitLab içerisinde bulunan CVE-2021-22175 zafiyeti, sunucu tarafı istek sahteciliği (Server-Side Request Forgery - SSRF) açıklarının bir örneğidir. Bu açık, GitLab kullanıcılarının, webhooks aracılığıyla iç ağa beklenmedik istekler göndermelerine olanak tanımaktadır. Eğer bu özellik etkinse, saldırganlar GitLab’ın iç ağında bulunan hizmetlere erişim sağlamaya çalışabilirler.

Gerçek dünya senaryolarında, bu tür bir zafiyetin sömürülmesi, kendi başına önemlidir çünkü saldırganların bir sistemin iç ağında bulunan veri tabanlarına, API'lere veya diğer kritik bileşenlere erişim sağlamasına yol açabilir. Özellikle, bir saldırganın iç servislerin bilgilerini (örneğin, bir yönetici paneli ya da veri tabanı sunucusu) öğrenebilmesi veya güvenlik duvarlarının dışındaki bileşenler üzerinde kötü niyetli talepler gerçekleştirmesi durumunu düşünelim.

Bu zafiyeti sömürmek için aşağıdaki adımları takip edebilirsiniz:

Zafiyet Tespiti: İlk olarak, GitLab uygulamanızda webhooks özelliğinin etkin olup olmadığını kontrol edin. Bunu yapmak için, yöneticiler genellikle GitLab ayarlarında ilgili alanları düzenleyebilir. Özellikle Allow requests to the internal network from webhooks seçeneği aktifse, zafiyetiniz mevcut demektir.
Hedef Belirleme: Zafiyetin etkisini değerlendirmek için iç ağda hangi kaynakların kullanılabilir olduğunu gözlemleyin. Bu, genellikle bir iç ağ keşfi aracı kullanarak veya port tarayıcılarla gerçekleştirilebilir. Örneğin, nmap kullanarak arka planda çalışan hizmetleri bulabilirsiniz.

nmap -sP 192.168.1.0/24

Payload Hazırlama: SSRF zafiyetini kullanmak için uygun bir payload oluşturmalısınız. Hedef IP adresini ve portunu içeren bir HTTP isteği oluşturmak, örneğin bir iç hizmete erişim sağlamak için gerekir. GitLab webhook’ları ile istek gönderme şekli aşağıdaki gibi olabilir:

import requests

webhook_url = "http://&lt;gitlab-server-url&gt;/api/v4/projects/&lt;project_id&gt;/trigger/pipeline"
payload = {
    'token': '&lt;your_trigger_token&gt;',
    'ref': 'main',
    'variables[URL]': 'http://&lt;target_internal_ip&gt;:&lt;target_port&gt;'
}

response = requests.post(webhook_url, json=payload)

print(response.text)

Sistem Üzerinde Test: Bu adımda, oluşturduğunuz payload’ı kullanarak GitLab sunucusuna istek gönderebilirsiniz. Eğer zafiyet başarıyla sömürüldüyse, iç ağda bulunan değerlere erişiminiz olacaktır. Örneğin, hedef bir veri tabanına ait bilgi alma isteği şu şekilde yazılabilir:

internal_service_url = "http://&lt;target_internal_service&gt;"
response = requests.get(internal_service_url)

if response.status_code == 200:
    print("İç hizmete erişim sağlandı:")
    print(response.text)
else:
    print("Erişim sağlanamadı. Hata kodu:", response.status_code)

Veri Toplama: Elde ettiğiniz verileri kullanarak sisteminize zarar verebilir ya da istediğiniz istihbarat bilgilerini çıkarabilirsiniz. Bu bilgileri kullanarak daha ileri seviye saldırılar (örneğin, uzaktan kod çalıştırma RCE - Remote Code Execution) gerçekleştirebilirsiniz.

Bu tür zafiyetlerin sorumluluğuyla sorunsuz bir şekilde kullanılabilmesi için; güvenlik ekiplerinin zafiyet tespiti, hızlı yanıt, güncellemeler ve güçlü bir izleme sistemi kurmaları kritik öneme sahiptir. Bununla birlikte, her zaman etik sınırlar içinde kalmak ve bilgiyi kötüye kullanmamak gerektiğini unutmamak gerekir.

Forensics (Adli Bilişim) ve Log Analizi

CVE-2021-22175, GitLab platformunda bulunan bir server-side request forgery (SSRF) zafiyetidir. Bu tür bir zafiyet, kötü niyetli bir kullanıcının hedef sistem üzerinden başka bir sisteme veya hizmete istek göndermesine olanak tanır. GitLab, webhook'lar aracılığıyla dahili ağda bu tür istekleri işleyebilir, ancak bu durumda, siber saldırganların iç ağdaki kaynakları hedef alması kolaylaşır. Örneğin, saldırgan, GitLab'daki bir webhook yapılandırmasını kötüye kullanarak dahili bir uygulamaya veya veri tabanına istek göndererek hassas bilgileri elde edebilir veya sistemin daha kritik bir bileşenine erişim sağlamaya çalışabilir.

Sarmal olarak, bu tür bir saldırının önlenmesi ve tespit edilmesi için log analizi yapmak büyük önem taşır. Bir siber güvenlik uzmanı, bu tür bir SSRF saldırısının tespitine yönelik çeşitli logları analiz ederek farklı imzalara (signature) dikkat etmelidir. Özellikle, Access Log ve Error Log gibi önemli log dosyalarını incelemek gerekmektedir.

Access Log dosyaları, web sunucusuna gelen tüm isteklerin kaydını tutar. Kötü niyetli bir istek, genellikle alışılmadık URI'ler (Uniform Resource Identifier) veya başlıklarla kendini gösterebilir. Aşağıdaki gibi bir kayıt, bir SSRF saldırısının belirtisi olabilir:

192.168.1.10 - - [20/Mar/2021:15:24:16 +0000] "POST /webhooks/submit HTTP/1.1" 200 234 "http://internal-service.local/resource" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36"

Burada "http://internal-service.local/resource" gibi bir iç ağ adresinin hedef alınması dikkat çekicidir. Normal şartlarda, dışarıdan gelen isteklerin genellikle genel IP adreslerini hedef alması beklenir.

Error Log dosyalarında ise, belirli hata mesajları veya başarısız istekler SSRF saldırısının izlerini taşıyabilir. Örneğin, 401 Unauthorized hata mesajları ile sıkça karşılaşmak, yetkilendirme aşamasında bir sorun olduğunu ve dolayısıyla bir saldırının gerçekleştiğini gösterebilir. Özellikle şu tür kayıtları incelemek faydalı olacaktır:

[error] 12345#0: *67890 upstream sent too big header while reading response header from upstream, client: 192.168.1.10, server: gitlab.local, request: "POST /webhooks/submit HTTP/1.1", upstream: "http://internal-service.local/resource", host: "gitlab.local"

Bu tür hata mesajları, bir dış kaynaktan webhooks'a istek gönderildiğinde ve bu isteğin işlenmesi sırasında bir hata oluştuğunda meydana gelir. Bu durum, saldırganın hedefi test ederken karşılaştığı bir engel olarak değerlendirilebilir.

Log analizi yaparken dikkat edilmesi gereken diğer bir imza da, atipik istek sıklığı veya zamanlamasıdır. Özellikle belli bir zaman diliminde sıklıkla gelen iç ağ istekleri, normal kullanıcı trafiğinden çok daha fazla olması nedeniyle dikkat çekmelidir. Anahtar kelimeler arasında "SSRF" zafiyeti, "webhook" etkinliği, "iç ağ" istekleri ve "kötü niyetli trafik" analizi yer alır.

Sonuç olarak, GitLab platformundaki bu tür SSRF zafiyetinin tespiti, siber güvenlik uzmanları için önemli bir görevdir. Log analizi yaparak ve belirli imzalara (signature) yoğunlaşarak, potansiyel saldırılara karşı proaktif bir yaklaşım sergileyebilir ve bu tür zafiyetlerden kaynaklanan riskleri minimize edebiliriz.

Savunma ve Sıkılaştırma (Hardening)

GitLab üzerinde bulunan CVE-2021-22175 açığı, server-side request forgery (SSRF) zafiyeti olarak bilinir. Bu, kötü niyetli bir kullanıcının GitLab sunucusunu iç ağdaki sistemlere, hizmetlere veya API'lere istek göndermeye zorlayabileceği anlamına gelir. Bu durum, iç ağdaki kritik bileşenlere yetkisiz erişim sağlaması açısından oldukça tehlikeli bir senaryo oluşturur. GitLab'ın webhooks özelliği, bu tür saldırılara zemin hazırladığı için dikkatli bir şekilde yapılandırılmalıdır.

Savunma ve sıkılaştırma (hardening) stratejileri, bu tür zafiyetlere karşı koruma sağlamada hayati öneme sahiptir. İlk olarak, GitLab ortamında webhooks kullanımını minimize etmek, gerektiğinde açmak ve bu özelliği sıkı bir şekilde denetlemek gerekiyor. Webhooks’a erişimi yalnızca belirli IP adresleriyle sınırlamak, bu zafiyeti kullanarak iç ağdaki kaynaklara ulaşmak isteyen kötü niyetli kullanıcılara karşı güçlendirici bir önlem olacaktır.

Bunun yanı sıra, bir web uygulama güvenlik duvarı (WAF) kullanmak, GitLab'ın doğrudan internete açılan yüzeyini korumada önemli bir rol oynar. WAF, gelen istekleri izleyerek ve filtreleyerek potansiyel SSRF saldırılarını engelleyebilir. Örneğin, aşağıdaki gibi bir WAF kuralı belirlenebilir:

SecRule REQUEST_HEADERS:Host "@streq gitlab.example.com" "id:1001,phase:2,deny,status:403,msg:'Malicious request detected'"

Bu kural, yalnızca beklenen alan adlarına gelen istekleri kabul eder ve diğerlerini engeller. Sunucunun iç adreslerine yapılacak istekleri tespit etmeye çalışan kurallar da eklemek, saldırı yüzeyini daraltabilir.

GitLab’ın ayarlarında yapılan sıkılaştırma önlemleri de esastır. Özellikle yapılandırmaların güncel tutulması ve varsayılan ayarların değiştirilmesi, güvenliği artırmak için atılacak ilk adımlardır. Örneğin, sosyal mühendislik saldırıları sonucu yetkisi olmayan kişilerin erişimini sağlamak, sistemin bütünlüğüne zarar verebilir. Bu nedenle, kullanıcıların ve rollerin dikkatli bir şekilde yönetilmesi ve en az ayrıcalık ilkesinin uygulanması büyük önem taşır.

Aynı zamanda, GitLab üzerinde düzenli güvenlik taramaları gerçekleştirmek ve açık kaynaklı tarama araçları kullanmak, (RCE) uzaktan kod çalıştırma, buffer overflow (tampon taşması) ve auth bypass (kimlik geçersiz kılma) gibi başka zafiyetleri bulma açısından faydalı olabilir. Örneğin, npm veya GitLab CI/CD alanında beyan edilen paketleri ve bağımlılıkları düzenli olarak kontrol etmek, potansiyel tehditleri önceden tespit etmek açısından kritik öneme sahiptir.

Son olarak, sistem güncellemeleri ve yamaları düzenli olarak uygulamak oldukça önemlidir. Yazılım güncellemeleri, mevcut zafiyetleri yani sıklıkla yeni keşfedilen güvenlik açıklarını kapatmada etkili bir yöntemdir. Bu yüzden, özellikle GitLab gibi sürekli gelişen bir platformda, yeni sürümlerin ve güncellemelerin takip edilmesi gerekmektedir.

Tüm bu önlemler bir arada kullanıldığında, GitLab üzerindeki SSRF zafiyeti ve benzeri açıkların etkisini azaltmaya yönelik önemli adımlar atılmış olacaktır. Güvenlik her zaman bir süreçtir ve durumsal farkındalık, kurumsal güvenlik maruziyetini minimize etmenin anahtarıdır.