Sızan API anahtarları ve ardından gelen ihlaller artık olağandışı değil. Peki neden hassas tokenler hala bu kadar kolay açığa çıkıyor?
Bunu öğrenmek için Intruder’ın araştırma ekibi, geleneksel güvenlik açığı tarayıcılarının gerçekte neyi kapsadığına baktı ve mevcut yaklaşımlardaki boşlukları gidermek için yeni bir sır tespit yöntemi geliştirdi.
Bunu 5 milyon uygulamayı tarayarak geniş ölçekte uygulamak, 334 gizli türde 42.000’den fazla açıkta kalan jetonu ortaya çıkardı ve özellikle tek sayfalı uygulamalarda (SPA’lar) mevcut araçlar tarafından iyi yönetilmeyen büyük bir sızdırılmış sırlar sınıfını açığa çıkardı.
Bu makalede, mevcut sır tespit yöntemlerini ayrıntılı olarak ele alıyoruz ve milyonlarca uygulamayı JavaScript paketlerinde gizlenmiş sırlar için taradığımızda ne bulduğumuzu açıklıyoruz.
Yerleşik sır tespit yöntemleri (ve sınırlamaları)
Geleneksel sır tespiti
Uygulama sırlarını tespit etmeye yönelik geleneksel, tam otomatik yaklaşım, bilinen bir dizi yolu aramak ve bilinen gizli formatlarla eşleştirmek için düzenli ifadeler uygulamaktır.
Bu yöntem yararlı olsa ve bazı riskleri tespit edebilse de, açık sınırlamaları vardır ve tüm sızıntı türlerini, özellikle de tarayıcının uygulamayı taramasını veya kimlik doğrulamasını yapmasını gerektiren sızıntıları algılamaz.
Bunun güzel bir örneği Nuclei’nin GitLab kişisel erişim belirteci şablonudur. Tarayıcıya https://portal.intruder.io/ gibi bir temel URL beslenir ve bu, şablonun şunları yapmasına neden olur:
- https://portal.intruder.io/ adresine bir HTTP GET isteği yapın
- Bu tek isteğe verilen doğrudan yanıtı inceleyin, JavaScript dosyaları gibi diğer sayfaları ve kaynakları göz ardı etmek
- GitLab kişisel erişim belirtecinin modelini belirleme girişimi
- Bulunursa, belirtecin etkin olup olmadığını kontrol etmek için GitLab’ın genel API’sine bir takip isteğinde bulunun
- Etkinse bir sorun bildirin
Bu açıkça basit bir örnek, ancak bu yaklaşım etkilidir. Özellikle de şablonlar, sırların yaygın olarak açığa çıktığı birçok yolu tanımladığında.
Bu format, genellikle başsız bir tarayıcı çalıştırmayan altyapı tarayıcılarının tipik bir örneğidir. Tarayıcıya taraması için temel URL verildiğinde (örneğin, https://portal.intruder.io), bir tarayıcı tarafından yapılacak sonraki istekler (sayfayı oluşturmak için gereken JavaScript dosyaları gibi, örneğin https://portal.intruder.io/assets/index-DzChsIZu.js) bu eski tarz yaklaşım kullanılarak yapılmayacaktır.
Dinamik Uygulama Güvenliği Testi (DAST)
Dinamik Uygulama Güvenliği Testi (DAST) araçları genellikle uygulamaları taramanın daha sağlam bir yoludur ve uygulamaların tam olarak taranmasına, kimlik doğrulama desteğine ve uygulama katmanı zayıflıklarının tespitinde daha geniş bir yeteneğe olanak tanıyan daha karmaşık işlevlere sahip olma eğilimindedir. Aslında DAST tarayıcıları, uygulama ön uçlarında gizli bilgilerin tespiti için doğal bir seçenek gibi görünebilir. DAST tarayıcısının mevcut JavaScript dosyalarını keşfetmesini veya bunların içindeki sırları taramasını engelleyen hiçbir şey olmamalıdır.
Ancak bu tür tarama daha pahalıdır, derinlemesine yapılandırma gerektirir ve gerçekte genellikle az sayıda yüksek değerli uygulamaya ayrılır. Örneğin, geniş bir dijital alanda sahip olduğunuz her uygulama için bir DAST tarayıcısını yapılandırmanız pek mümkün değildir. Ayrıca birçok DAST aracı, iyi bilinen komut satırı araçlarıyla karşılaştırıldığında yeterince geniş bir düzenli ifade aralığı uygulamaz.
Bu açık bir boşluk bırakıyor yapmalı geleneksel altyapı tarayıcısı tarafından kapsanmaktadır ancak kapsanmamaktadır ve dağıtım, bütçe ve bakım sınırlamaları nedeniyle büyük olasılıkla DAST tarayıcıları tarafından da kapsanmamaktadır.
Statik Uygulama Güvenliği Testi (SAST)
Statik Uygulama Güvenliği Testi (SAST) araçları, güvenlik açıklarını belirlemek için kaynak kodunu analiz eder ve kod üretime ulaşmadan önce gizli bilgileri tespit etmenin birincil yoludur. Sabit kodlanmış kimlik bilgilerini yakalamada ve bazı risk sınıflarının önlenmesinde etkilidirler.
Ancak, SAST yöntemlerinin de resmin tamamını kapsamadığını gördük ve bir kez daha, JavaScript paketleri içindeki bazı sırlar, statik analizin gözden kaçıracağı şekilde boşluklardan sızdı.
JavaScript paketleri için gizli dizi algılama kontrolü oluşturma
Bu araştırmaya başladığımızda bu sorunun ne kadar yaygın olacağı belli değildi. Sırlar aslında JavaScript ön uçlarında toplanıyor mu ve otomatik bir yaklaşımı haklı çıkaracak kadar yaygın mı?
Her sonucu tam olarak önceliklendirmedik ancak incelediğimiz örnekler arasında çok sayıda yüksek etkili maruz kalma tespit ettik.
Ne bulduk
Kod Havuzu Belirteçleri
Tespit ettiğimiz en etkili riskler GitHub ve GitLab gibi kod deposu platformlarına yönelik tokenlardı. Toplamda 688 token bulduk, bunların çoğu hâlâ aktifti ve depolara tam erişim sağlıyordu.
Aşağıda gösterilen bir durumda, GitLab kişisel erişim belirteci doğrudan bir JavaScript dosyasına yerleştirildi. Tokenın kapsamı, AWS ve SSH gibi ileriye yönelik hizmetler için CI/CD ardışık düzen sırları da dahil olmak üzere kuruluş içindeki tüm özel depolara erişime izin verecek şekilde tasarlandı.
Proje Yönetimi API Anahtarları
Bir diğer önemli risk, doğrudan ön uç koduna yerleştirilmiş bir proje yönetimi uygulaması olan Linear için bir API anahtarıyla ilgiliydi:
Token, dahili biletler, projeler ve alt hizmetlere ve SaaS projelerine bağlantılar da dahil olmak üzere kuruluşun tüm Linear örneğini açığa çıkardı.
Ve daha fazlası
Aşağıdakiler de dahil olmak üzere çok çeşitli diğer hizmetlerde açığa çıkan sırları belirledik:
CAD yazılımı API’leri – hastane dahil olmak üzere kullanıcı verilerine, proje meta verilerine ve bina tasarımlarına erişim
Bağlantı kısaltıcılar – Bağlantı oluşturma ve numaralandırma yeteneği
E-posta platformları – posta listelerine, kampanyalara ve abone verilerine erişim
Sohbet ve otomasyon platformları için web kancaları – 213 Slack, 2 Microsoft Teams, 1 Discord ve 98 Zapier, hepsi aktif
PDF dönüştürücüler – üçüncü taraf belge oluşturma araçlarına erişim
Satış zekası ve analiz platformları – kazınmış şirket ve iletişim verilerine erişim
Sırlarınızı göndermeyin
Shift-sola kontroller önemlidir. SAST, depo taraması ve IDE korkulukları gerçek sorunları yakalar ve tüm sınıfların maruz kalmasını önler. Ancak bu araştırmanın gösterdiği gibi, bir sırrın üretime geçebileceği her yolu kapsamıyorlar.
Derleme ve dağıtım sırasında tanıtılan sırlar, bu korumaları atlayabilir ve sola kaydırma kontrollerinin zaten çalıştığı noktadan çok sonra ön uç koduna ulaşabilir. Otomasyon ve yapay zeka tarafından üretilen kodlar yaygınlaştıkça bu sorun daha da büyüyecek.
Bu nedenle sırların üretime ulaşmadan önce yakalanması için tek sayfalık uygulama örümceklerine ihtiyaç vardır. Ekiplerin bunu gerçekten yakalayabilmesi için Intruder’a otomatik SPA sırları algılama özelliği ekledik. Daha fazla bilgi edin.