Konuyu Okuyanlar: 1 Ziyaretçi

Zeabur İkinci İhlal: 3,2 Milyon Ortam Değişkeni Okundu, Platform Kapanıyor

Zeabur İkinci İhlal: 3,2 Milyon Ortam Değişkeni Okundu, Platform Kapanıyor
[Resim: attachment.php?aid=345]

Selamlar,

Geliştirici barındırma platformu Zeabur, 19 Ekim 2026'da Ekim ayı güvenlik olayının ön raporunu yayınladı. Özet: saldırgan, sızdırılmış Zeabur dahili kimlik bilgileriyle paylaşımlı kümeyi, bazı GCP Dedicated Server'ları ve dahili sistemleri ele geçirdi; sonunda platform veritabanını okudu. Onaylanan sayılar: 3.218.965 ortam değişkeni kaydı ve 321.810 hesap verisi. Zeabur ayrıca 31 Aralık 2026'da kapanacağını duyurdu.

Konuda anlatılacaklar
  1. İki yol nasıl birleşti?
  2. Hangi veriler okundu?
  3. Ağustos olayından sonra neden yine oldu?
  4. Etkilenen kullanıcılar için eylem listesi
  5. PaaS güvenliği için çıkarılacak dersler

İki yol nasıl birleşti?
Zeabur'un raporuna göre saldırgan iki yoldan ilerledi:

Yol A - paylaşımlı küme ve AWS: 14 Ekim 01:36 UTC'den itibaren Zeabur'un dahili AWS anahtarları ve paylaşımlı küme yönetici token'ları kullanıldı. Bu kimlik bilgileri düz metin olarak özel bir yapılandırma deposundaydı. Yönetici arayüzü internete açıktı ve token'ların son kullanma tarihi yoktu. Saldırgan 9 bölgedeki paylaşımlı kümeye dışarıdan erişti; 12:39'dan itibaren tüm servislerin ayarlarını ve sırlarını (ortam değişkenleri dahil) okudu; 865 veritabanı servisi içinde okuma komutları çalıştırdı.

Yol B - GCP Dedicated Server'lar: Aynı gün 13:40'tan itibaren saldırgan, Zeabur'un GCP üzerinde yönettiği 101 Dedicated Server'a root olarak giriş yaptı. Sunucu başlatma ayarlarında root parolası düz metindi; eski bir GCP anahtarıyla bu ayarlar okunabiliyordu.

İki yol 15 Ekim'de birleşti: Saldırgan, ele geçirdiği bir GCP sunucusundan Yol A'dan elde ettiği dahili ağ yönetici kimlik bilgileriyle Zeabur'un dahili ağına bir düğüm ekledi. Dahili ağ kuralları bu düğümün platform veritabanına bağlanmasına izin veriyordu. 16:10-16:47 arasında salt okunur bir hesapla veritabanı okundu; 8.903 işlem kaydı eşleştirildi.

Hangi veriler okundu?
  • Platform veritabanı: 3.218.965 ortam değişkeni (ad ve değer), 321.810 hesabın profil verileri, 566 zSend API anahtarı (düz metin), Access Token'lar (yalnızca hash; hepsi iptal edildi)
  • Paylaşımlı küme: 9 bölgede servis sırları; 865 veritabanı konteyneri içinde okuma komutları (n8n, PostgreSQL, new-api/one-api dahil)
  • GCP Dedicated Server: 101 sunucu, 92 kullanıcı; 50'sine kalıcılık için SSH anahtarı eklendi
  • GitHub App özel anahtarı: 15:05-18:54 arası okundu; şirket şu ana kadar kullanım bulamadığını söylüyor
Saldırganın davranışı AI servis anahtarlarını aramaya yoğunlaşmış görünüyor; n8n ve new-api/one-api okumaları ve Amazon Bedrock çağrı denemeleri (başarısız) bunu destekliyor. Zeabur yine de okunan her şeyi sızmış kabul ediyor.

Ağustos'tan sonra neden yine?
Bu, iki aydan kısa sürede Zeabur'un ikinci güvenlik olayı. Ağustos'ta sızdığı doğrulanan dahili anahtarlar döndürülmüştü; ancak yapılandırma deposundaki düz metin küme yönetici token'ları ve AWS anahtarları o rotasyona dahil edilmemişti. GCP sunucu başlatma ayarlarındaki root parolaları da Eylül'de tespit edilmesine rağmen olay öncesi düzeltilmemişti. Zeabur, Ağustos raporundaki "tüm dahili yönetici anahtarları devre dışı bırakıldı veya döndürüldü" ifadesinin eksik olduğunu bu raporda düzeltiyor.

Olumlu taraf: Ağustos rehberliğini takip edip ortam değişkenlerini kendi Dedicated Server'ına taşıyan projeler, platform veritabanı okumasının kapsamı dışında kaldı.

Etkilenen kullanıcılar için eylem listesi
Zeabur'un vurgusu: beklemeyin, hemen harekete geçin; Ağustos'tan sonra değiştirdiğiniz kimlik bilgilerini de yeniden değiştirin.
  1. Ortam değişkenlerindeki tüm API anahtarlarını, bulut anahtarlarını, veritabanı parolalarını, imzalama/şifreleme anahtarlarını sağlayıcıda iptal edip yenileyin, yeniden deploy edin.
  2. Platform Access Token'larını yeniden oluşturun (hepsi iptal edildi).
  3. zSend kullananlar: API anahtarlarını yeniden yaratın.
  4. GitHub: 15 Ekim 15:05-18:54 UTC arasında Zeabur GitHub App'inin beklenmeyen clone/push, deploy key veya webhook değişikliklerini denetleyin.
  5. 14 Ekim'den (GCP Dedicated kullanıcıları için 1 Eylül'den) itibaren faturaları ve kullanım kayıtlarını gözden geçirin.
  6. Paylaşımlı küme: Veritabanı içindeki parolaları değiştirin; n8n encryption key'ini yenileyip üçüncü taraf kimlik bilgilerini yeniden oluşturun; new-api/one-api için üst akış anahtarlarını iptal edin.
  7. GCP Dedicated: Sunucuyu yeniden kurmak en güvenli yol. En azından /root/.ssh/authorized_keys içinde @zeabur-pentest yorumlu veya tanınmayan anahtarları silin, root parolasını değiştirin, parola ile SSH'yi kapatın.

PaaS güvenliği için dersler
  • Yönetici token'larının son kullanma tarihi olmalı, internete açık olmamalı ve rotasyon listesinde unutulmamalıdır.
  • Küme yedekleri sırları içermemeli; yedek erişim anahtarı diğer sırlarla aynı ortamda tutulmamalıdır.
  • Kullanıcı servisleri ile dahili servisler aynı kümede çalışıyorsa, bir kullanıcı konteynerinin ele geçirilmesi dahili kimlik bilgilerine giden yol olabilir.
  • 16 saatten fazla saldırı etkinliğinin alarm üretmemesi, denetim ve tespit kapsamının en az yetki kadar kritik olduğunu gösteriyor.

PaaS üzerinde ortam değişkeni tutanlar: sırlarınızı kendi sunucunuza taşıma planınız var mı?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar


Ek DosyalarEkran Görüntüleri
   
Cevapla



Hızlı Menü: