İçeriğe atla
heworxBLOG
Yazılım yapay zeka anthropic openai linux çekirdeği futex igalia

Blog / Yazılım

API Key Anahtarınızı Çaldırmayın

Public olarak erişilebilen kod depolarını, sunucuları, açık dizinleri ve yanlış yapılandırılmış servisleri sürekli tarayan botlar var.

Hakan E. · 7 dk okuma
XFacebookWhatsAppLinkedIn

Bir API anahtarını yanlışlıkla GitHub’a yüklediğinizde başınıza bir şey gelmesi için birilerinin projenizi keşfetmesini beklemeniz gerekmiyor. Kimsenin sizin küçük projenizle ilgilenmediğini düşünmek rahatlatıcı olabilir. Yeni açılmış bir repository, birkaç dosyadan oluşan deneme uygulaması, henüz ziyaretçisi bile olmayan bir web sitesi. Fakat internette işler böyle yürümüyor.

Public olarak erişilebilen kod depolarını, sunucuları, açık dizinleri ve yanlış yapılandırılmış servisleri sürekli tarayan botlar var. Bunların önemli bir bölümü belirli dosya isimlerini, anahtar biçimlerini ve erişim tokenlarını arıyor. AWS anahtarı nasıl görünür biliyorlar. GitHub tokenı nasıl görünür biliyorlar. OpenAI, Stripe, Telegram, Google Cloud ve yüzlerce başka servise ait anahtarların genel yapısını biliyorlar. Dolayısıyla anahtarınızı gören ilk kişi büyük ihtimalle bir insan bile olmayacak.

Birkaç dakikalık pencere

Bir geliştiricinin yaptığı hata genellikle çok sıradan başlıyor. Projeyi lokal ortamda çalıştırabilmek için API anahtarı doğrudan dosyaya yazılıyor. Test başarılı oluyor. Ardından alışkanlıkla git add ., git commit ve git push çalıştırılıyor.

Birkaç dakika sonra hata fark ediliyor. Dosya siliniyor, yeni commit gönderiliyor ve geliştirici de konunun kapandığını düşünüyor. Asıl problem burada başlıyor. Çünkü dosyayı son committen silmiş olmanız anahtarın hiç yayınlanmadığı anlamına gelmiyor. Anahtar Git geçmişinde kalmış olabilir. Daha önemlisi, siz hatayı fark edene kadar başka bir sistem onu çoktan görmüş olabilir.

İLGİLİBungie Geri Adım Attı - Destiny 2’nin Kaldırılan İçerikleri Geri Dönüyor

Güvenlik araştırmalarında public repositorylere bırakılan erişim anahtarlarının otomatik sistemler tarafından dakikalar içinde bulunabildiği defalarca gösterildi. Secret scanning sistemlerinin var olma nedenlerinden biri de bu. Burada yarıştığınız kişi gece bilgisayar başına oturup GitHub’da proje arayan bir hacker değil. Yazılımla yarışıyorsunuz.

Anahtarı alan biri ne yapabilir

Bu tamamen anahtarın hangi servise ait olduğuna ve ona hangi yetkileri verdiğinize bağlı. Bir yapay zeka servisinin anahtarı ele geçirildiyse hesabınız üzerinden binlerce hatta milyonlarca istek gönderilebilir. Bir bulut servisinin anahtarı ele geçirildiyse yeni sunucular açılabilir, depolama alanlarına erişilebilir, dosyalar indirilebilir veya yeni kullanıcılar oluşturulabilir.

Bir ödeme servisinin yüksek yetkili anahtarı sızdıysa konu doğrudan finansal verilere kadar gidebilir. GitHub tokenı sızdıysa private repositorylerinize erişim sağlanabilir. Bir deployment anahtarı ele geçirildiyse saldırgan yalnızca verilerinizi okumakla kalmayıp uygulamanıza kod gönderebilir.

Bu yüzden API key dediğimiz şey çoğu zaman yalnızca rastgele üretilmiş uzun bir karakter dizisi değildir. O anahtar sizin adınıza işlem yapabilme yetkisidir.

Sabah uyandığında yüzlerce sunucu çalışan insanlar oldu

Bulut hesaplarının ele geçirilmesinde yıllardır görülen yöntemlerden biri kripto para madenciliği. Saldırgan sizin AWS, Azure veya Google Cloud hesabınıza erişiyor. Mümkün olduğu kadar güçlü makineler açıyor, bunları farklı bölgelerde çalıştırıyor ve hesap sahibinin limitleri elverdiği sürece kaynak tüketmeye devam ediyor.

Amaç verinizi çalmak bile olmayabiliyor. Amaç sizin kredi kartınızla işlemci satın almak.

Geçmişte ele geçirilen bulut sistemleri üzerinden yapılan izinsiz kripto madenciliği şirketlere yüz binlerce dolarlık faturalar çıkardı. Daha küçük ölçekte aynı olay bugün de yaşanabilir. Akşam deneme projenizi GitHub’a gönderirsiniz. Sabah sağlayıcınızdan kullanım alarmı gelir. Normalde ayda 20 dolar ödediğiniz hesap birkaç saat içinde yüzlerce dolarlık tüketim üretmiş olabilir.

Saldırganın sizi tanımasına gerek yoktur. Sadece anahtarınızı bulması yeterlidir.

Codecov olayı neden önemliydi

2021 yılında yaşanan Codecov saldırısı işin ne kadar büyüyebileceğini gösteren iyi örneklerden biri. Codecov birçok yazılım ekibinin test süreçlerinde kullandığı bir araçtı. Saldırganlar Codecov tarafından kullanılan Bash Uploader isimli scripti değiştirdi.

Değişiklik oldukça tehlikeliydi. Script çalıştığı ortamda bulunan bazı environment variable değerlerini dışarı gönderiyordu. Bu değişkenlerin içinde API anahtarları, erişim tokenları, deployment bilgileri, cloud hesaplarına ait kimlik bilgileri ve başka servislerin şifreleri bulunabiliyordu.

Bu script çok sayıda şirketin CI ve CD sisteminde çalışıyordu. Böylece tek bir noktadaki saldırı başka şirketlerin sistemlerinde kullanılan gizli bilgilere ulaşma ihtimali yarattı. Olay yaklaşık iki ay boyunca fark edilmeden devam etti ve HashiCorp dahil çok sayıda kuruluşun olaydan etkilendiği açıklandı.

Anahtarların illa config.php dosyasına açık açık yazılması gerekmiyor. Build sistemi de sızdırabilir. Log dosyası da sızdırabilir. Docker image da sızdırabilir. CI sistemi de sızdırabilir.

.env dosyası güvenli bir kasa değildir

Geliştiriciler arasında çok sık gördüğüm başka bir yanlış anlaşılma da .env dosyasının güvenli olduğu düşüncesi. .env kullanmak doğru bir yöntemdir ama yalnızca dosya dışarı çıkmıyorsa.

Dosyanın adının .env olması içeriğini şifrelemiyor. Bir şekilde repository içine girdiyse düz metin dosyasından farkı yok. Bu yüzden projeye ilk eklenmesi gereken dosyalardan biri .gitignore. İçinde de çoğu projede en azından .env, .env.local ve .env.production gibi dosyaların bulunduğundan emin olmak gerekiyor.

Repository geçmişini de ara sıra secret scanner ile kontrol etmek gerekiyor. Çünkü bugün temiz görünen repositorynin üç yıl önceki commitlerinden birinde hala çalışan bir anahtar bulunabilir.

Dosyayı silmek yeterli değil

API anahtarınızı yanlışlıkla GitHub’a gönderdiğinizi fark ettiğinizde ilk refleksiniz dosyayı silmek olabilir. Ama yapılması gereken ilk şey bu değil. İlk iş anahtarı iptal etmek.

Çünkü saldırgan anahtarı zaten aldıysa repositoryden silmeniz hiçbir şeyi değiştirmez. Eski anahtar artık güvenilir kabul edilmemeli. Yeni anahtar oluşturulmalı, uygulamalar yeni anahtara geçirilmeli ve eski anahtar tamamen iptal edilmeli.

Ardından ilgili servisin kullanım kayıtları kontrol edilmeli. Tanımadığınız IP adresleri var mı, normal olmayan saatlerde istek yapılmış mı, kullanım miktarında ani artış olmuş mu, yeni kaynak oluşturulmuş mu, dosya indirilmiş mi veya yetki değişikliği yapılmış mı bunlara bakılmalı.

Anahtarı değiştirmek saldırıyı durdurabilir. Ama anahtarın daha önce kullanılıp kullanılmadığını size söylemez.

GitHub neden anahtar arıyor

Bu problem o kadar yaygın hale geldi ki GitHub yıllardır repositorylerde secret scanning yapıyor. Sistem bilinen servis sağlayıcılarına ait token ve API key biçimlerini tespit etmeye çalışıyor. Bazı durumlarda push protection daha kod repositoryye girmeden geliştiriciyi uyarabiliyor.

Bunun nedeni oldukça basit. Sorun istisnai değil. Modern bir web uygulamasında bugün rahatlıkla on farklı gizli bilgi bulunabiliyor. Veritabanı şifresi, mail servisinin anahtarı, yapay zeka servisi, ödeme sistemi, object storage, analytics, GitHub, deployment, CDN ve DNS erişimleri bunlardan sadece bazıları.

Her biri ayrı bir kapı.

Asıl hata anahtarı kaybetmek değil, ona gereğinden fazla yetki vermek

Bir API anahtarı yalnızca hava durumunu okumak için kullanılacaksa bütün hesabı yönetme yetkisine sahip olmamalı. Bir uygulama sadece dosya okuyacaksa dosya silememeli. Bir servis yalnızca belirli bir bucket içine dosya gönderecekse bütün storage hesabına erişememeli.

Bu yaklaşımın adı least privilege. Yani bir kullanıcıya veya anahtara işini yapabilmesi için gereken en düşük yetkiyi vermek.

Bunun faydası anahtar hiç çalınmayacak demek değil. Anahtar çalınırsa saldırganın yapabileceklerini azaltmak. Sadece okuma yetkisi olan bir anahtarın ele geçirilmesi kötü bir durumdur ama aynı anahtarın kullanıcı oluşturma, veri silme ve ödeme yapma yetkisi olması çok daha kötü bir durumdur.

Sunucunuzun sabit IP adresi varsa birçok servis API anahtarını belirli IP adresleriyle sınırlandırmanıza izin verir. Bunu kullanın. Anahtar çalınsa bile başka bir makineden kullanılmasını zorlaştırır.

Aynı şekilde mümkün olan servislerde günlük kullanım limiti koyun. Harcama alarmı tanımlayın. Beklenmedik trafik için uyarı oluşturun. Bir serviste normal kullanımınız günde 3 dolar ise 100 dolara ulaştığınızda haberiniz olmaması teknik bir sorun değil, yapılandırma sorunudur.

Frontend içine koyduğunuz anahtar gizli değildir

Sık yapılan bir hata da API keyi JavaScript kodunun içine koyup sitenin ziyaretçilerinden gizli olduğunu düşünmek.

Tarayıcıya gönderdiğiniz hiçbir secret gerçekten secret değildir. Kullanıcı Developer Tools açabilir, network trafiğini inceleyebilir, JavaScript dosyalarını indirebilir ve source map dosyalarına bakabilir.

Mobil uygulamalarda da benzer bir durum var. Uygulamanın içine gömülen anahtar çıkarılabilir. Bu yüzden gizli kalması gereken işlemlerin backend üzerinden yapılması gerekir. Tarayıcı sizin sunucunuza istek gönderir, sunucunuz API sağlayıcısıyla konuşur ve anahtar sunucuda kalır.

Küçük proje diye düşünmeyin

Belki projenizde on kullanıcı var. Belki henüz kimse kullanmıyor. Belki sadece hafta sonu yaptığınız bir deneme. Bot açısından bunların hiçbirinin önemi yok.

Bot projenizin yatırım alıp almadığını bilmiyor. Şirket olup olmadığınızı bilmiyor. Repositoryde iki yıldız mı iki yüz bin yıldız mı olduğunu önemsemiyor.

Bir pattern görüyor, bir token buluyor, deniyor. Çalışıyorsa kullanıyor. O kadar.

Bu yüzden güvenlikte en tehlikeli cümlelerden biri muhtemelen şu olabilir.

Beni kim bulacak

Sizi kimsenin bulmasına gerek yok. Botlar zaten arıyor.

API key sızdırdıysanız

Panik yapmanın anlamı yok ama hızlı davranmak gerekiyor. Anahtarı hemen iptal edin. Yeni anahtar oluşturun. Uygulamaları yeni anahtara geçirin. Repository geçmişini kontrol edin. Hesap kullanım kayıtlarını inceleyin. Beklenmedik harcama veya trafik olup olmadığına bakın.

Aynı anahtarı başka projelerde kullandıysanız hepsini değiştirin. Anahtarın sahip olduğu yetkileri yeniden değerlendirin. Ardından projeye secret scanning ve push protection ekleyin.

Aynı anahtarı tekrar kullanmayın.

Bir secret internete çıktıysa artık secret değildir. Bunu geri alamazsınız. Sadece eskisini kapatıp yenisini oluşturabilirsiniz.


API anahtarları bize fiziksel bir anahtar kadar önemli görünmüyor. Ekranda duran uzun bir karakter dizisi sonuçta. Kopyalıyoruz, mesajla gönderiyoruz, test dosyasına yapıştırıyoruz, bazen kodun içine bırakıyoruz.

Fakat o anlamsız görünen karakterlerin arkasında sunucular, kredi kartları, müşteri verileri, veritabanları ve üretim sistemleri olabilir.

Kapınızın anahtarını sokağa bırakıp ertesi gün yerinden aldığınızda güvende olduğunuzu düşünmezsiniz. API anahtarı için de aynı şeyi düşünmeyin.

Çünkü siz onu geri almadan önce birileri kopyalamış olabilir. Büyük ihtimalle o birisi insan bile değildir.

Bu yazı size ne hissettirdi?

Hakan E.

heworx'un kurucusu. Yazılım, barındırma ve mağaza içi yayın işleri üzerine yazıyor.

İlginizi çekebilir