Uygulama güvenliği şirketi Aikido, GitLab'deki Email work item to this project özelliğine ait e-posta adreslerinin zaman zaman README dosyalarında, katkı kılavuzlarında ve herkese açık destek sayfalarında göründüğünü açıkladı. Bu adresler geliştirici hesabıyla ilişkili uzun ömürlü bir belirteç içeriyor; bu da söz konusu adreslerin yayımlanmasını, hata bildirimlerini almak için kullanılan sıradan bir yöntemin yayımlanmasından çok kimlik bilgilerinin açığa çıkarılmasına yaklaştırıyor.
Bu özellik, herhangi bir tarafın adrese bir mesaj göndererek GitLab projesinde sorun veya görev oluşturmasına olanak tanıyor. Ancak Aikido'nun gerçekleştirdiği testler, saldırganın adresteki -issue son ekini -merge-request olarak değiştirebildiğini ve GitLab'in mesajı kabul ederek projede bir birleştirme isteği oluşturduğunu gösterdi.
Pratikte ne olabilir?
Etkinin kapsamı, belirteçle ilişkili hesabın yetkilerine bağlıdır. Olası sonuçlar arasında kodda değişiklik yapılması, CI/CD işlerinin çalıştırılması, özel depolara erişilmesi veya CI/CD değişkenlerinde saklanan gizli bilgilerin çıkarılması ve ayrıca gizli sorunların görüntülenmesi bulunabilir. Açık kaynak projelerinde açığa çıkan adresler, çok sayıda kullanıcının bağlı olduğu projelere değişiklik eklemek için kullanılmaları hâlinde tedarik zinciri açısından bir riske dönüşebilir.
Aikido araştırmacıları tek bir öğleden sonra boyunca herkese açık belgelerde yayımlanmış yaklaşık 12 etkin adres buldu ve bunların bazılarının yaygın olarak kullanılan açık kaynak projelerine ait olduğunu söyledi. Saldırganın belirteç sahibinin e-posta adresini taklit etmesi gerekmiyor; GitLab mesajı belirteç sahibinden gönderilmiş gibi işliyor. Testler ayrıca IP adresi kısıtlamalarının aşılabildiğini gösterdi.
İstismar sınırları ve yöneticilerin sorumluluğu
Adresin açığa çıkması, hesabın yetkilerinin aşılması anlamına gelmez; kullanıcının yetkileri temel bir kısıt olmaya devam eder. Saldırganın ayrıca projenin yolunu ve tanımlayıcısını bilmesi gerekir. Bu bilgiler herkese açık projelerde mevcutken, özel bir projeyi hedef almak için yolun sızdırılması gerekir; tanımlayıcı kaba kuvvetle tahmin edilebilse bile.
GitLab'in kendi belgeleri de bu adreslerin paylaşılmasına karşı uyarıyor ve adresleri özel, ilgili kullanıcı için oluşturulmuş adresler olarak tanımlıyor; bu adresleri bilen bir kişinin, sahibiymiş gibi sorunlar veya birleştirme istekleri oluşturabileceğini belirtiyor. Platform, sızıntıdan şüphelenilmesi hâlinde belirtecin derhâl sıfırlanmasını öneriyor.
Bu, projeler açısından ne anlama geliyor?
Aikido, sorunu mayıs ayında HackerOne üzerinden GitLab'e bildirdi, ancak bildirim davranışın kasıtlı olduğu gerekçesiyle kapatıldı. Haziran ayında yapılan ikinci bildirimin ardından GitLab arayüzünü, birleştirme istekleri oluşturulabileceğini belirtecek şekilde güncelledi; belirteç verilerine erişimle ilgili doğru olmayan ifadeleri kaldırdı ve e-posta üzerinden mesaj alınmasının IP kısıtlamalarını aştığını belgeledi.
En önemli pratik adım proje yöneticilerinin sorumluluğunda: bu adresleri herkese açık belgelerden kaldırmak ve daha önce yayımlanmış projelere ait belirteçleri sıfırlamak. Açık sorular ise GitLab'in gelecekte, ek bir savunma katmanı olarak gönderen adresini belirteç sahibinin e-postasıyla eşleştirmeye ne ölçüde güveneceğiyle ilgili; Aikido, platformun şu anda bu mekanizmayı incelediğini söyledi.