GitLab’daki Gizli E-posta Adresleri Kod Değişikliklerine Açılan Bir Saldırı Yüzeyi Oluşturuyor
GitLab projelerinde iş öğesi oluşturmak için kullanılan özel e-posta adreslerinin herkese açık dokümanlarda paylaşılması, saldırganların proje adına işlem yapmasına yol açabilecek bir güvenlik riski oluşturuyor. Aikido araştırmacıları, README dosyaları, katkı rehberleri ve hata bildirim sayfalarında bulunan adreslerin GitLab hesabına bağlı uzun süre geçerli bir kimlik doğrulama belirteci içerdiğini belirledi. Saldırganlar ele geçirilen adresleri kullanarak proje üzerinde issue veya merge request oluşturabilirken hesabın yetkilerine bağlı olarak kod, CI/CD süreçleri ve gizli verilere erişim riski de ortaya çıkabiliyor.
GitLab E-posta Adresleri Proje Adına İşlem Yapılmasını Sağlıyor
GitLab, geliştiricilerin e-posta üzerinden doğrudan proje içinde iş öğeleri oluşturabilmesi için “Email work item to this project” adlı bir özellik sunuyor. Sistem, geliştirici hesabına özel olarak oluşturduğu e-posta adresine gönderilen mesajları otomatik şekilde işleyerek issue veya task olarak projeye ekliyor.
Söz konusu adresler sıradan iletişim adreslerinden farklı bir yapıya sahip bulunuyor. GitLab tarafından oluşturulan her adres, projeye erişim sağlayan uzun süre geçerli bir belirteç görevi gören glimt- dizisini içeriyor.
Aikido araştırmacıları, söz konusu adreslerin kamuya açık belgelerde yer almasının yalnızca istenmeyen hata bildirimlerine yol açmadığını ortaya koydu. Adrese sahip olan bir saldırgan, e-posta üzerinden GitLab’ın iş öğesi oluşturma mekanizmasını kullanarak proje adına işlem gerçekleştirebiliyor.
GitLab’ın kendi dokümantasyonu da bu adreslerin gizli tutulması gerektiği konusunda uyarıyor. Şirket, adresi bilen kişilerin kullanıcı adına issue veya merge request oluşturabileceğini belirterek adresin sızdırıldığından şüphelenilmesi durumunda belirtecin sıfırlanmasını öneriyor.
Aikido’nun yaptığı testler, riskin yalnızca issue oluşturmakla sınırlı olmadığını gösteriyor. Araştırmacılar, özel e-posta adresindeki -issue bölümünün -merge-request olarak değiştirilmesi durumunda GitLab’ın gönderilen mesajı merge request olarak işlediğini belirledi.
Bu yöntem, saldırganın doğrudan GitLab hesabına giriş yapmasına gerek kalmadan proje adına kod değişikliği talebi oluşturmasına olanak tanıyor. İşlemin sonucunda oluşabilecek etki ise adresin bağlı olduğu hesabın proje üzerindeki yetkileriyle sınırlı kalıyor.
Aikido, gönderici e-posta adresinin belirtecin sahibi olan hesabın e-posta adresiyle karşılaştırılmasının ek bir güvenlik katmanı sağlayabileceğini belirtiyor. Araştırmacılara göre GitLab mevcut yapıda böyle bir doğrulama gerçekleştirmiyor ve sistem, internet üzerindeki herhangi bir posta kutusundan gelen mesajı belirtecin sahibi tarafından gönderilmiş gibi işleyebiliyor.
Araştırmacıların testleri ayrıca gelen e-posta mekanizmasının IP adresi kısıtlamalarını da aşabildiğini ortaya koydu. Bu durum, kurumsal GitLab ortamlarında ağ tabanlı erişim kontrollerinin tek başına yeterli koruma sağlamayabileceği anlamına geliyor.
Saldırının gerçek etkisi, özel e-posta adresinin bağlı olduğu GitLab hesabının izin seviyesine göre değişiyor. Yetkili bir hesabın belirteci ele geçirildiğinde saldırganlar proje üzerinde kod değişiklikleri oluşturabilir, CI/CD işlerini tetikleyebilir veya özel repository içeriklerine erişim sağlayabilir.
CI/CD ortamlarında kullanılan gizli değişkenler de risk kapsamına girebiliyor. Projenin yapılandırmasına ve hesabın sahip olduğu izinlere bağlı olarak saldırganlar kaynak kodunun yanı sıra otomasyon süreçlerinde kullanılan hassas bilgilere ulaşabilecek işlemler gerçekleştirebilir.
Saldırının gerçekleşmesi için saldırganın hedef projenin yolunu ve proje kimliğini de bilmesi gerekiyor. Genel projelerde bu bilgiler zaten erişilebilir durumda bulunurken özel projelerde proje kimliğinin tahmin edilmesi veya brute-force yöntemleriyle bulunması söz konusu olabiliyor.
Özel projelerde proje yolunun ayrıca sızdırılması gerektiği için saldırı her durumda otomatik olarak gerçekleştirilemiyor. Aikido araştırmacıları, kullanıcı izinlerinin de aşılamayan bir sınır olduğunu belirtiyor.
Aikido araştırmacıları, tek bir öğleden sonra gerçekleştirdikleri incelemede kamuya açık README dosyaları, katkı rehberleri ve destek sayfalarında çalışan çok sayıda GitLab gelen e-posta adresi buldu. Araştırmacılar, adreslerin önemli bölümünün geliştiricilerin hata raporlarını kolayca gönderebilmesi amacıyla proje dokümantasyonuna bilerek eklendiğini aktardı.
Tespit edilen adreslerin bir bölümü geniş kullanıcı topluluklarına sahip popüler açık kaynak projelerine aitti. Böyle bir projede geliştirici hesabına bağlı özel e-posta adresinin kötüye kullanılması, yalnızca tek bir repository için değil, projeyi kullanan daha geniş bir ekosistem için tedarik zinciri riski oluşturabiliyor.
Aikido, konuyu Mayıs ayında HackerOne üzerinden GitLab’a bildirdi. GitLab ilk bildirimi “beklenen davranış” gerekçesiyle kapattı. Araştırmacıların Haziran ayında yaptığı ikinci bildirimin ardından GitLab, kullanıcı arayüzündeki bazı açıklamaları güncelledi.
GitLab daha sonraki düzenlemelerde özelliğin merge request oluşturma davranışını daha açık şekilde belirtti. Şirket ayrıca token verilerine erişimle ilgili hatalı ifadeleri kaldırdı ve gelen e-postaların IP kısıtlamalarını aşabildiğini dokümantasyonunda açıkladı.
Proje yöneticilerinin kamuya açık belgelerde özel GitLab e-posta adreslerini paylaşmaması gerekiyor. Daha önce README, katkı rehberi veya destek sayfalarında bu adresleri yayınlayan yöneticilerin ilgili belirteçleri sıfırlaması, eski adreslerin saldırganlar tarafından kullanılma ihtimalini azaltmak açısından önem taşıyor.
