Snowflake veri sızıntısı: Hackerların infostealer bulaşması üzerinden erişim sağladığı doğrulandı

 (hudsonrock.com)
1 puan yazan GN⁺ 2024-06-01 | 1 yorum | WhatsApp'ta paylaş
  • 31 Mayıs 2024'te bulut şirketi Snowflake büyük çaplı bir veri sızıntısı yaşadı.
  • Hackerların, infostealer bulaşması yoluyla erişim sağladığı Hudson Rock'a doğrulandı.
  • Hackerlar, Ticketmaster ve Santander Bank dahil birçok büyük şirketin verilerini Rusça bir siber suç forumunda sattı.

Saldırının yöntemi

  • Hackerlar, Snowflake çalışanının ServiceNow hesabına çalınmış kimlik bilgilerini kullanarak giriş yaptı.
  • OKTA'yı aşarak oturum belirteci oluşturdu ve büyük miktarda veriyi dışarı aktardı.
  • Hackerlar, yaklaşık 400 şirketin etkilendiğini iddia etti.

Ek kanıtlar

  • Hackerlar, Hudson Rock araştırmacılarıyla Snowflake sunucularına erişimi gösteren bir CSV dosyası paylaştı.
  • Bu dosya, Snowflake'in Avrupa sunucularıyla ilişkili 2.000'den fazla müşteri örneğini belgeliyor.

Hackerların hedefi

  • Hackerlar, verileri geri vermek karşılığında Snowflake'ten 20 milyon dolar talep etti.
  • Şirket buna yanıt vermedi.

Infostealer bulaşmalarındaki artış

  • Infostealer bulaşmaları 2018'den bu yana %6000 artarak başlıca ilk saldırı vektörlerinden biri haline geldi.
  • Bu yöntem, fidye yazılımı, veri sızıntısı, hesap ele geçirme ve kurumsal casusluk gibi siber saldırıları gerçekleştirmek için kullanılıyor.

GN⁺ görüşü

  • Siber güvenliğin önemi: Bu olay, şirketlerin siber güvenliğe daha fazla önem vermesi gerektiğini gösteriyor. Özellikle çalışan kimlik bilgilerinin yönetimi kritik.
  • Infostealer tehdidi: Infostealer'lar çok hızlı yayılıyor ve şirketlerin buna karşı hazırlık yapması gerekiyor.
  • Müdahale stratejisi: Bir hack olayı yaşandığında hızlı müdahale ve zararı en aza indirme stratejileri gerekli. Snowflake'in müdahalesindeki gecikme zararın büyümesine yol açtı.
  • Güvenlik eğitimi: Çalışanlara güvenlik eğitiminin güçlendirilmesi, kimlik bilgisi yönetimi ve phishing saldırılarına yönelik farkındalığın artırılması önemli.
  • Alternatif çözümler: Snowflake'e benzer işlevler sunan başka bulut depolama çözümleri değerlendirilebilir. Örneğin AWS S3 veya Google Cloud Storage.

İlgili okumalar

1 yorum

 
GN⁺ 2024-06-01
Hacker News yorumları

  • Şu anda bağlantılı URL / adresine 302 yönlendirmesi yapıyor. @dang, aşağıdaki arşiv bağlantısıyla değiştirmek daha iyi görünüyor
    https://web.archive.org/web/20240531140540/https://www.hudso...

    • @dang’i etiketlemenin hiçbir etkisi yok; footer’daki e-posta adresinden iletişime geçmek daha iyi olur
      Ancak Hudson Rock’ın blog yazısını kaldırması da ilginç bir işaret; bu yüzden sadece arşiv bağlantısıyla değiştirip geçmemek gerek. Ne değişti?
      Ek: Snowflake’in resmî yanıtı, orijinal yazının temel iddialarının neredeyse tamamını fiilen reddediyor gibi görünüyor. Hudson Rock dürüst olmayan bir kaynağa kanmış ve hatasını fark edip yazıyı kaldırmış olabilir
      https://community.snowflake.com/s/question/0D5VI00000Emyl00A...

  • Snowflake’ten Felipe ben. Snowflake’in bu konudaki en güncel tutumu burada: https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
    Ek gelişme olursa bu URL’yi güncellemeye devam edeceğim

    • Bağlantı kurumsal ifadelerle fazlasıyla dolu olduğu için netleştirmek istiyorum. Hudson Rock yazısı, Ticketmaster ve Santander Bank ihlallerinin Snowflake çalışanının çalınmış kimlik bilgileri nedeniyle gerçekleştiğini açıkça iddia ediyor
      Buna karşılık Snowflake’in “Etkilenen müşteri hesaplarına benzer şekilde, tehdit aktörünün eski bir Snowflake çalışanına ait demo hesabına kişisel kimlik bilgilerini elde ederek eriştiğine dair kanıt bulduk. Hassas veri yoktu” cümlesi, Snowflake’in Hudson Rock’ın anlatımını yanlış olarak gördüğü anlamına geliyor gibi okunuyor. Bu anlayış doğru mu?
    • Hudson Rock’ın orijinal yazısı, sadece bir müşterinin kimlik bilgilerinin ele geçirilmesi değil; çalışan kimlik bilgilerinin çalındığı ve iki faktörlü kimlik doğrulama olmadığı için o mühendisin yetkileriyle başka müşteri hesaplarına girildiği anlamına geliyor gibi okunuyor
      Buna karşılık Snowflake yazısı, müşteri hesabı kimlik bilgilerinin sızdığı, bununla sınırlı kaldığı ve merkezi bir hesaba ya da başka hesaplara erişim olmadığı izlenimi veriyor. İki faktörlü kimlik doğrulaması olmayan çalışan hesabı bilgilerinin kullanımı hakkında ise hiçbir şey söylemiyor
      Snowflake’in, dahili çalışanların tüm erişim kimlik bilgilerinde iki faktörlü kimlik doğrulama istemesi gerektiği açık. Geçmişte müşteriler isterse kendi verilerine giriş yapmak için yalnızca ad/parola oluşturup iki faktörlü kimlik doğrulama olmadan da erişebiliyordu
    • Buradaki makale hakkında doğrudan bir yorum gelecek mi?
    • salesforce.com sunucusunun geçici olarak isteklere yanıt veremediği yazıyor. Sadece rahatsızlık için özür dileyen ve biraz sonra tekrar denememi isteyen bir mesaj görünüyor

  • Sohbet kayıtlarının ekran görüntüsü gerçekten etkileyici. Bu şirket gerçek bir suçluyla iletişimde olduğunu iddia ediyor; suçlu da bu şirketi kullanmış olsalardı ihlali önlemeye yardımcı olabileceğini söylüyor
    Bu yüzden bu şirketin güvenilirliği konusundaki değerlendirmemi güncelledim

    • Tamamen tahmin ama hacker, Snowflake tarafından görmezden gelinince Hudson Rock ile temasa geçmiş ve fidye ödemeyen Snowflake’ten intikam almak amacıyla bu haberin patlaması için bir PR fırsatı sunmuş gibi görünüyor
      Hudson Rock da buna uyup hikâyeyi olduğundan daha büyük bir ihlal gibi şişirmiş gibi. Hacker’ın önce Hudson Rock’a mı gittiğini, yoksa onu kabul eden ilk şirketin Hudson Rock mı olduğunu da merak ediyorum
    • O konuşma tuhaf ve karikatür gibi. Nasıl değerlendirmek gerektiğini bilmiyorum
      “Hudson Rock’ın korumasını satın almalıydınız; o zaman bu olay önlenebilirdi”
      “Doğru, kesinlikle yardımcı olurdu”
    • Fidye yazılımı ya da koruma parası haraçlarında yaygın bir örtmece. Akira grubunun enfekte makinelerde bıraktığı mesajlardan sevdiğim biri aşağı yukarı şöyle
      “Tebrikler. Şirketiniz sürpriz bir bilgi güvenliği denetiminden geçti ve fidye yazılımı kurbanı oldu.”
      [...]
      Sunulanlar: 1) tam şifre çözme desteği 2) veri silme kanıtı 3) bulunan açıklar için güvenlik raporu 4) verileri yayımlamama veya satmama garantisi 5) gelecekte saldırmama garantisi
      Sonuçta, bordronuzda olduğunu bilmediğiniz bir güvenlik danışmanlık şirketinden ibaret
      Bu arada veri silme kanıtı olarak ne verdiklerine baktım; kelimenin tam anlamıyla yalnızca rm -vrf data komutunun standart çıktısıydı. Yokluğun kanıtını sunmanın imkânsız olduğunu ve kurbanın pazarlık gücü olmadığını anlıyorum, ama bu sahneleme oldukça hoşuma gidiyor
    • Ekran görüntüsüne bakınca bu ya tamamen uydurma ya da tamamen pazarlama amaçlı görünüyor
      Gerçek olsa bile Hudson Rock mesajlarını çıkarmak sağduyu gereği olurdu. Bu şirketi zihnimdeki kara listeye aldım
    • Üstü kapalı haraç gibi geliyor

  • Failin ifadelerine bakılırsa Snowflake sistemi, tek bir yönetici hesabına her şey üzerinde tam yetki verecek şekilde tasarlamış gibi görünüyor.
    Snowflake’in 31 Mayıs’taki duyurusunda “bazı müşterileri etkileyen sektör genelinde kimlik tabanlı bir saldırıyı” araştırdığını söylemesi de Ticketmaster ve Santander anlatılarına inandırıcılık katıyor.
    https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
    Tehdit aktörü bunu düzgün yapmış olsaydı, tarihin en büyük veri sızıntılarından biri olabilirdi.

    • Yazının ima ettiği bu ama bence abartılı. Ne yazık ki çalınan kimlik bilgilerinin sahibini tanımlamaya yetecek kadar bilgi verilmiş ve bu kişi bir satış mühendisi.
      Veriler, müşteriler veya potansiyel müşteriler için demolar hazırlarken kullandığı Snowflake hesabından çıkmış gibi görünüyor. Müşterilerin gerçek verilerinin bir kısmını demoda kullanması için erişim vermiş olma ihtimali var; ancak bu, müşterinin Snowflake veritabanına sınırsız erişimi olduğu anlamından çok uzak.
      Hacker’ın demo amaçlı, sahte ama gerçekçi görünen verileri çekmiş olması ve aradaki farkı bilmiyor olması gayet mümkün.
    • Sorun, Hudson Rock’ın süreci bilmeden tahmin yürütmesi ya da yetkin görünmeye çalışması.
      Tek bir satış mühendisi birden fazla hesaptan sorumludur. Snowflake satış mühendisleri genellikle müşteri ortamı içinde kurulum yapmaz; herkesin oluşturabileceği 400 dolarlık kredi içeren demo hesabı hazırlar. Demo hesaplarının süresi dolduğu için sürekli yenileri oluşturulur.
      Satış mühendisi, oluşturduğu demo hesabının içinde kurulum yapar ve bunu müşteriye gösterir. 30 gün sonra Snowflake, kredi kartı yoksa hesabı kilitler; ardından demo instance’ını ve verileri siler.
      Çalışma için müşteri, kendi Snowflake instance’ından satış mühendisinin oluşturduğu demo instance’ına veri paylaşabilir ya da SSO üzerinden o Snowflake satış mühendisine erişim verebilir.
      Her iki durumda da bu daha çok, kuruluşların güvenlik duruşunu yeterince kısıtlayıcı şekilde işletmemesiyle ilgili bir sorun. Çok çalışan bir satış mühendisini ve çalışan/yüklenici/misafir yetki kapsamını düzgün sınırlamayan müşterileri bulmuş olmaları dışında yeni bir tarafı olmayan bir saldırı.
    • Yaklaşık bir yıl önce Snowflake desteği aldığım deneyime göre, Snowflake ekibinin bir şeyi görmesi ya da yapması için müşteri hesabındaki yöneticinin Snowflake’e açıkça erişim izni vermesi gerekiyordu; hatırladığım kadarıyla bu erişimin bir sona erme süresi de vardı.
    • Tehdit aktörü doğru hareket etseydi, tarihin en büyük veri ihlali olma ihtimali çok yüksekti.
    • Tüm bunların, doğru çalışana yönelik tek bir hizmet olarak kötü amaçlı yazılım saldırısıyla mümkün olduğu söyleniyor. Kullanılan şey Lumma’ydı.
      İlginç biçimde ilk sayfada, Doğu Avrupa’daki STK’ları hedeflemek için Pegasus kullanıldığına dair bağlantılı bir hikâye de var. En az ayrıcalık ilkesi önemli, ama cihaz güvenliği de önemli.
      https://news.ycombinator.com/item?id=40535912

  • Snowflake çalışanı değilim ama Snowflake ve satış mühendisliği organizasyonuyla çok zaman geçirerek çalıştım.
    Müşterilerle demo hazırlarken satış mühendisleri, herkesin oluşturabileceği 400 dolarlık Snowflake demo hesabıyla gösterim ortamı kurar. Demo hazırlamak için müşteri o satış mühendisine erişim verir, satış mühendisi de bazı verileri demo ortamına taşıyıp üzerinde çalışır. Hudson Rock’ın yayımladığı ortam adları da bunu destekliyor.
    Bana göre bu, veri paylaşan kişinin kimliğini müşterinin süresini bitirmemesi ve tehdit aktörünün kimlik bilgilerini çalmasıyla ilgili bir süreç sorunu. Bir güvenlik açığı istismarı olmadığı için yeni bir tarafı yok.
    Ayrıca Hudson Rock, bilgisayarında kötü amaçlı yazılım olduğu için mağdur olan kişiyi kamuya açık biçimde ifşa ettiğiniz için tebrikler. Bir yükleniciye kimlik bilgileri verilip bunların çalınmasından farklı değil. Çok çirkin bir davranış.

    • “Yeni bir güvenlik açığı istismarı” olmaması, bunun ciddi olmadığı anlamına gelmez.
      Snowflake’te satış mühendisinin kimlik bilgileri çalınabiliyor; bu kimlik bilgileri çok faktörlü kimlik doğrulamayı atlatabiliyor ve makaleye göre süresi de dolmuyor. Bu strike 1, 2 ve 3.
      Snowflake’in güvenlik uygulamaları, müşterilerin geniş veri kümelerine erişimi Snowflake çalışanlarıyla paylaşmasının gerekli olduğu ya da en azından teşvik edildiği bir durum yaratmış. Bu da strike 4.
      Müşterinin aşırı geniş erişim vermesinde sorumluluğu var; ancak böyle bir erişime gerek bırakmayacak daha iyi sistemler kurmamak ya da en azından bu geçişli erişimi daha iyi denetleyip kontrol etmemek konusunda Snowflake’in de sorumluluğu var.
      Böyle bir hesap müşteri verilerine erişim aldığı anda artık “demo hesabı” değildir. Gerçek bir hesaptır ve gerçekten çok değerli veriler içerdiği için öyle ele alınmalıdır.
      Ek: Snowflake, söz konusu demo hesabının müşteri verilerine erişmediğini ve sızıntının kaynağı olmadığını iddia ediyor; bu da saldırganın iddiasıyla çelişiyor.
    • İhlal edilen hesabın oturum açma adını belirtmeleri gerçekten profesyonelce değil ve gereksiz görünüyor.
    • Hudson Rock’ın başlıca ürünlerinden biri olan “Bayonet”in açıklaması şöyle:
      “Dünya genelinde ele geçirilmiş yüz binlerce şirkete ve aktif zafiyetlere sahip potansiyel müşteri bulma platformuna erişip, bunları müşteriye dönüştürebildiğinizi hayal edin.”
      Bu tür şirketlerden birkaçını gördüm ve onlarla muhatap oldum; oldukça düşük seviye taktikler ve teknik açıdan da beceri ya da emek düzeyi düşük.
    • Hudson Rock’ın birkaç yazısını hızlıca okudum; birçoğu “bizden koruma satın almalıydınız” gibi bir noktada bitiyor. Koruma parası işi kokusu geliyor.
    • Blog yazısının tamamı aşırı bir kendini övme havası taşıyor; mağduru ifşa etmeleri de gerçekten berbat bir davranış. Genel olarak Hudson Rock’ın performansı çok kötü.

  • Snowflake’ın resmi yanıtında şöyle deniyor:
    “Bunun, müşteri verilerini elde etme niyetiyle sektör genelinde sürmekte olan kimlik tabanlı saldırıların sonucu olduğunu düşünüyoruz. İncelememize göre bu saldırılar, ilgisiz siber tehdit faaliyetleri yoluyla açığa çıkan müşterilere ait kullanıcı kimlik bilgileriyle gerçekleştiriliyor. Şu ana kadar bu faaliyetin Snowflake ürünündeki bir güvenlik açığı, yapılandırma hatası veya kötü niyetli faaliyet nedeniyle gerçekleştiğini düşünmüyoruz.”
    [0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...

  • Görünüşe göre makaleyi gizliye almışlar, ama Wayback Machine’de hâlâ duruyor: https://web.archive.org/web/20240531140540/https://www.hudso...

    • İyi görünmüyor. Eğer bir şey yanlışsa, böyle iddialar ve suçlamalardan sonra uygun olan bir düzeltme metni yayımlamaktır. Hiçbir açıklama yapmadan sadece yazıyı silmek sorumsuzca ve profesyonellik dışı

  • Bu yazı, birkaç gün önceki Ticketmaster ihlalinin aslında Snowflake çalışanına ait çalınmış kimlik bilgileri üzerinden 400’den fazla şirketi etkileyen çok daha geniş çaplı bir hack olduğunu iddia ediyor.
    Şimdilik yalnızca hudsonrock.com’da haberleştirilen büyük bir hikâye gibi görünüyor. Hudson Rock’ı ilk kez duyuyorum; güvenilir bir kaynak olup olmadığını bilen var mı?

    • Hudson Rock’ı, “CEO”larının aylar boyunca güvenlikle ilgili subreddit’lerin hepsine sayısız ihlal iddiası içeren düşük kaliteli blog spam’i yaymaya başlamasıyla tanıdım.
      Birden fazla hesabı Reddit moderatörleri ve yöneticileri tarafından yasaklandı. Kişisel olarak güvenilir ya da inanılır bir kaynak olarak görmüyorum
    • Santander bankasına yönelik ciddi bir hack hakkında BBC News haberi var ve Snowflake ile bağlantılı.
      https://www.bbc.co.uk/news/articles/c6ppv06e3n8o
    • Snowflake çalışanlarının kendi hisselerini satacak zaman kazanması gerekiyor. Bu haber SNOW hissesi üzerinde büyük darbe yaratacak

  • Snowflake, bunun kendi hataları değil müşterilerin hatası olduğunu söylüyor gibi.
    https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
    https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... tamamen uydurma bir hikâye değilse, Snowflake gerçeği biraz daha az dürüstçe anlatıyor.
    “İncelemeye göre…” ifadesi, bunun kendi incelemeleri mi yoksa genel güvenlik araştırması mı olduğu konusunda belirsiz. “Snowflake ürünündeki bir güvenlik açığı, yapılandırma hatası veya kötü niyetli faaliyet nedeniyle olduğunu düşünmüyoruz” cümlesi de olası senaryoları sıralayıp bunlar değil derken, olayın gerçekte nasıl gerçekleştiğini ustaca dışarıda bırakıyor.
    Hudson Rock’a inanırsak Snowflake, kötü niyetli aktör tarafından kendisiyle iletişime geçildiği için bunun nasıl gerçekleştiğini muhtemelen oldukça iyi biliyordu

    • Alıntıladığın cümlenin içinde nasıl gerçekleştiğini ima etmiyor mu?
      “İlgisiz siber tehdit faaliyetleri yoluyla açığa çıkan müşterilere ait kullanıcı kimlik bilgileriyle gerçekleştirildi” dediklerine göre, uydurma değilse kimlik bilgilerinin başka bir yerden elde edildiğini düşünüyorlar gibi.
      Sonunda müşterilerden hesap ayarlarını gözden geçirmelerini istiyorlar; yani sorumluluğu kendilerinden uzaklaştırma yönünde. Yine de şu anki kaynaklar, hacklendiğini söyleyen şirket ile bu olayı kendi ürününü tanıtmak için kullanırken bir çalışanı utanmazca doxxing yapan şirket olduğundan, daha ayrıntılı bilgi çıkana kadar beklemek gerek gibi
    • Ya da düzgün bir derinlemesine analiz yapmadan müşteri tarafının ihlal edildiğini varsayıp sorumluluğu onlara yüklemiş de olabilirler.
      Hacker, refresh token’ları bile geçersiz kılmadıklarını iddia ediyor; bu doğruysa inanılmaz derecede büyük ve bariz bir sorun

  • Makale, “yüzlerce müşteri ihlali” başlığıyla pek tutarlı görünmüyor.
    Birincisi, lift/okta parolası yalnızca ServiceNow portalına erişim sağlıyor gibi, müşteri hesaplarına erişim değil; dolayısıyla refresh token sorunu ServiceNow portalıyla sınırlı görünüyor ve gerçek müşteri Snowflake hesaplarındaki veri sızıntısıyla ilişkili görünmüyor.
    İkincisi, 10 şirket hesabının ihlal edildiğini gösteren ekran görüntüsünde farklı Snowflake hesaplarına ait 4 kimlik bilgisi görünüyor; bunlardan biri kişisel demo hesabı gibi duruyor. Bu nedenle en fazla 3 müşteri ihlalini açıklayabilir, ancak diğer müşteri ihlallerini gösteren ayrıntı yok.
    Satış mühendisinin üzerinde çalıştığı tüm müşterilere ait tüm kimlik bilgilerinin ihlal edildiğini varsaysak bile, ihlal edilen müşteri sayısı muhtemelen düşük iki haneli sayılarda olurdu. Çünkü her müşteri hesabının satış mühendisine ayrı ayrı erişim yetkisi vermiş olması gerekirdi.
    Dahili Okta portalındaki refresh token sorununa dayanarak tüm Snowflake müşterilerinin ihlal edildiğini söylemek büyük bir sıçrama; ayrıca o sorun herhangi bir müşteri Snowflake hesabıyla bağlantılı değil

    • İhlal edilen hesabın tam olarak nasıl yapılandırıldığını ve hangi erişim haklarını aldığını bilmeden bunu söylemek zor. Bildiğim “güvenlik odaklı büyük telekom” şirketlerinde bile teknik personelin hangi düzeyde erişim yetkisine sahip olduğuna şaşırırsınız. Elbette tüm erişimler kaydediliyor
    • ServiceNow içinde başka yerlere lateral movement için kullanılabilecek kimlik bilgileri vb. bulunmuş olması gayet mümkün. Elbette bu bir varsayım