Dropbox saldırısının perde arkası: Lenovo ID açığı hesaplara nasıl erişim sağladı?

Dropbox, yaklaşık 5.000 hesabın 4-21 Ağustos 2026 tarihleri arasında Lenovo ID ile bağlantılı bir tek oturum açma (SSO) açığı kullanılarak ele geçirildiğini açıkladı. Şirket, etkilenen hesapların üçte birinden azında dosyaların görüntülendiğini veya indirildiğini bildirdi. 146

Bu olayın en dikkat çekici yönü, saldırganların kullanıcıların Dropbox parolalarını bilmesine ya da e-posta kutularına girmesine gerek kalmamasıydı. Saldırganlar, bir e-posta adresini hesap sahipliğinin kanıtı gibi değerlendiren iki farklı sistem arasındaki güven ilişkisini kötüye kullandı.

Dropbox hesaplarına erişim nasıl sağlandı?

Saldırı zinciri, mevcut raporlara göre üç adımdan oluşuyordu:

1. Saldırgan, başka bir kişiye ait e-posta adresini kullanarak Lenovo ID oluşturdu.
2. Lenovo’nun e-posta doğrulama sürecindeki bir kusur, saldırganın gelen kutusuna erişimi olmamasına rağmen bu kimliğin geçerli görünmesine izin verdi.
3. Dropbox’ın eski SSO entegrasyonu, Lenovo’dan gelen kimlik bildirimindeki e-posta adresini aynı adresle kayıtlı mevcut Dropbox hesabıyla eşleştirdi ve hesabın mevcut Dropbox parolasını istemeden erişim sağladı. 3511

Başka bir deyişle saldırganlar Dropbox’ın parola sistemini kırmadı ve e-posta güvenliğini aşmadı. Lenovo ID’yi kimlik sağlayıcı, Dropbox’ı ise bu kimlik iddiasına güvenen hizmet olarak kullanan bir güven zincirindeki boşluktan yararlandılar.

Çok faktörlü kimlik doğrulama neden önemliydi?

Etkilenen hesaplar Lenovo ID’ye bağlıydı ancak Dropbox’ın çok faktörlü kimlik doğrulama (MFA) özelliği etkin değildi. 11012

Federatif giriş akışında, üçüncü taraf bir sağlayıcıdaki başarılı oturum açma işlemi, hizmet veren platformda da oturum açılmasını sağlayabilir. Dropbox MFA etkin olsaydı Lenovo’dan gelen sahte kimlik iddiasının ardından Dropbox’ın kontrolündeki ek bir doğrulama adımı daha gerekecekti. Bu nedenle olay, MFA’nın aşıldığını değil, MFA kullanmayan hesapların sahte bir Lenovo kimliğiyle korunmasız kaldığını gösteriyor. 1015

Saldırganlar hangi verilere erişti?

Dropbox, saldırganların etkilenen hesaplarda saklanan içerikleri görüntülediğini ve indirdiğini söyledi. Kamuya açık haberlerde, dosyaların yaklaşık 5.000 hesabın üçte birinden azında erişildiği belirtiliyor. 145

Mevcut raporlar, kurbanların tamamında ortak bir dosya türü, toplam indirme hacmi veya aynı düzeyde hassas veri bulunduğunu ortaya koymuyor. Bazı kullanıcılara Dropbox günlüklerinde yetkisiz hesap erişiminin görüldüğü, ancak dosyalarının görüntülendiğine veya indirildiğine dair kanıt bulunmadığı bildirildi. 2

Kullanıcılar ve araştırmacılar ne fark etti?

Bazı etkilenen kullanıcılar, kendi e-posta adresleriyle ilişkilendirilmiş tanımadıkları Lenovo ID’ler tespit etti. Güvenlik araştırmacısı Yoni Levy de Dropbox’tan gelen ve 4-21 Ağustos tarihleri arasındaki yetkisiz erişimi, Lenovo SSO sorununu ve olayın ayrıntılarını anlatan bildirimin bir kopyasını paylaştı. 23

Bazı raporlarda Dublin’le ilişkilendirilen giriş etkinliklerinden de söz edildi. Bu gözlemler, sahte kimlik sağlayıcı hesaplarının giriş noktası olarak kullanılmasıyla uyumlu. Ancak tek başına bu veriler, her saldırganın bulunduğu yeri veya tüm hesaplarda aynı saldırı adımlarının izlendiğini kanıtlamıyor.

Dropbox kullanıcıları ve düzenleyicileri ne zaman bilgilendirdi?

Dropbox, yetkisiz erişimi tespit ettikten sonra etkilenen kullanıcılara yaklaşık 31 Ağustos ve 1 Eylül tarihlerinde bildirim göndermeye başladı. Şirket ayrıca veri koruma düzenleyicilerini de bilgilendirdi. 346

Şirketin açıkladığı müdahale kapsamında etkilenen oturumlar sonlandırıldı, Lenovo hesap bağlantıları kaldırıldı veya ayrıştırıldı, kullanıcılara parolalarını değiştirmeleri ve iki adımlı doğrulamayı etkinleştirmeleri önerildi. Etkilenen giriş yolu da kısıtlandı ve bu entegrasyona ek güvenlik önlemleri getirildi. 101230

Sorumluluk Lenovo ve Dropbox arasında nasıl paylaşılıyor?

Bu olay yalnızca tek bir şirketin doğrudan ele geçirildiği klasik bir veri ihlali olarak değerlendirilmiyor. Sorun, iki şirketin sistemlerinin birlikte çalıştığı noktadaki ortak güvenlik açığından kaynaklandı.

• Lenovo’nun görünen kusuru: Eski kimlik akışının, saldırganların kontrol etmedikleri bir e-posta adresiyle Lenovo ID oluşturmasına izin verdiği bildirildi. Temel sorun, e-posta adresinin gerçekten kime ait olduğunun yeterince doğrulanmamasıydı. 3512
• Dropbox’ın görünen kusuru: Dropbox, Lenovo’dan gelen harici kimlik bildirimini mevcut bir hesabı bağlamak ve hesaba erişim vermek için yeterli kabul etti. Mevcut Dropbox parolası, yeniden kimlik doğrulama veya daha güçlü bir hesap bağlama süreci talep edilmedi. 3911
• Şirketlerin yanıtı: Lenovo, konuyu eski bir entegrasyonla ilişkili olarak nitelendirdi ve ilgili doğrulama sorununu giderdiğini söyledi. Dropbox ise açığı tespit edip düzelttiğini, oturumları sonlandırdığını, entegrasyonu değiştirdiğini ve kullanıcılarla düzenleyici kurumları bilgilendirdiğini açıkladı. 101214

Bu ayrım önemli: Lenovo’daki doğrulama zayıflığı sahte bir kimlik iddiası oluşturdu; ancak bu iddianın mevcut ve değerli bir bulut hesabının kilidini açıp açamayacağını Dropbox’ın hesap bağlama mantığı belirledi.

Dropbox hisseleri ne kadar geriledi?

İhlalin açıklanmasının ardından Dropbox hisselerinde mesai sonrası işlemlerde düşüş görüldü. Ancak haberlerde düşüşün oranı konusunda farklı rakamlar yer aldı.

Reuters’a dayandırılan bazı haberlerde, genişletilmiş işlemlerde yaklaşık yüzde 2,4’lük gerileme bildirildi. Investing.com ise mesai sonrası düşüşü yüzde 1,8 olarak verdi. 69 Başka bir haberde hissenin yüzde 6’dan fazla gerilediği öne sürüldü. 8 Mevcut kanıtlar, özellikle yüzde 6,6’lık rakamı doğrulamıyor; bu oran farklı bir piyasa referansına veya işlem seansına ait olabilir.

Federatif kimlik sistemleri için daha geniş ders

Bir e-posta adresi bir tanımlayıcıdır; o adresi kullanan kişinin gelen kutusunu kontrol ettiğini veya bu adresle ilişkili hesabın sahibi olduğunu otomatik olarak kanıtlamaz.

Federatif giriş, bir hizmetin başka bir hizmet üzerinden kullanıcı doğrulamasına izin vererek işlemi kolaylaştırır. Ancak aşağıdaki uygulamalar ciddi risk yaratabilir:

• Kimlik sağlayıcının e-posta iddiasını bağımsız bir doğrulama yapmadan kabul etmek;
• Yeni bir üçüncü taraf kimliğini eski bir hesaba otomatik olarak bağlamak;
• Mevcut parola, MFA, yeniden kimlik doğrulama veya doğrulanmış kurtarma kanalını devre dışı bırakmak;
• Hesap bağlantısındaki değişikliği yüksek riskli bir güvenlik olayı yerine sıradan bir giriş işlemi gibi değerlendirmek.

Daha güvenli bir tasarım, yeni bir kimlik sağlayıcı hesabını mevcut hesaba bağlamadan önce hesabın gerçek sahibinden açık kanıt ister. Bu kanıt, yeniden kimlik doğrulama, doğrulanmış bir kurtarma kanalı veya kimlik avına dayanıklı bir doğrulama yöntemi olabilir.

Dropbox olayı, kimlik sağlayıcılarına duyulan güvenin de parolalar kadar sıkı incelenmesi gerektiğini gösteriyor. Bir sistemdeki doğrulama açığı, hesap bağlama mantığı yeterince güçlü değilse başka bir hizmetteki bulut hesabına erişim kapısına dönüşebiliyor.