Kebocoran Data Snowflake: Hacker Dipastikan Masuk Melalui Infeksi Infostealer

 (hudsonrock.com)
1 poin oleh GN⁺ 2024-06-01 | 1 komentar | Bagikan ke WhatsApp
  • Pada 31 Mei 2024, perusahaan cloud Snowflake mengalami kebocoran data berskala besar
  • Hudson Rock mengonfirmasi bahwa hacker memperoleh akses melalui infeksi infostealer
  • Hacker menjual data dari sejumlah perusahaan besar, termasuk Ticketmaster dan Banco Santander, di forum kejahatan siber berbahasa Rusia

Metode Peretasan

  • Hacker masuk ke akun ServiceNow milik karyawan Snowflake menggunakan kredensial curian.
  • Mereka melewati OKTA untuk membuat token sesi dan mengekfiltrasi data dalam jumlah besar.
  • Hacker mengklaim sekitar 400 perusahaan terdampak.

Bukti Tambahan

  • Hacker membagikan file CSV kepada para peneliti Hudson Rock yang menunjukkan hak akses ke server Snowflake.
  • File ini mendokumentasikan lebih dari 2.000 instance pelanggan yang terkait dengan server Snowflake di Eropa.

Tujuan Hacker

  • Hacker menuntut $20 juta dari Snowflake untuk mendapatkan kembali data tersebut.
  • Perusahaan tidak menanggapi hal itu.

Peningkatan Infeksi Infostealer

  • Infeksi infostealer meningkat 6000% sejak 2018 dan menjadi salah satu vektor serangan awal utama.
  • Ini digunakan untuk melancarkan serangan siber, termasuk ransomware, kebocoran data, pengambilalihan akun, dan aktivitas spionase perusahaan.

Opini GN⁺

  • Pentingnya keamanan siber: Insiden ini menunjukkan bahwa perusahaan perlu memberi perhatian lebih besar pada keamanan siber. Khususnya, pengelolaan kredensial karyawan sangat penting.
  • Ancaman infostealer: Infostealer menyebar sangat cepat, dan perusahaan perlu menyiapkan langkah antisipasi terhadap ancaman ini.
  • Strategi respons: Saat insiden peretasan terjadi, diperlukan respons cepat dan strategi untuk meminimalkan kerugian. Respons Snowflake yang terlambat memperbesar dampaknya.
  • Pelatihan keamanan: Penting untuk memperkuat pelatihan keamanan bagi karyawan agar meningkatkan pengelolaan kredensial dan kesadaran terhadap serangan phishing.
  • Solusi alternatif: Solusi penyimpanan cloud lain dengan fungsi serupa Snowflake dapat dipertimbangkan, misalnya AWS S3 atau Google Cloud Storage.

Bacaan terkait

1 komentar

 
GN⁺ 2024-06-01
Komentar Hacker News

  • Saat ini URL yang ditautkan melakukan redirect 302 ke /. @dang, sepertinya lebih baik diganti dengan tautan arsip di bawah
    https://web.archive.org/web/20240531140540/https://www.hudso...

    • Memanggil @dang tidak ada gunanya, jadi lebih baik menghubungi lewat email di footer
      Namun, fakta bahwa Hudson Rock menurunkan postingan blog itu juga merupakan sinyal yang menarik, jadi sebaiknya jangan sekadar menggantinya dengan tautan arsip lalu lanjut begitu saja. Apa yang berubah?
      Tambahan: Tanggapan resmi Snowflake tampaknya pada dasarnya membantah hampir semua klaim inti dari artikel aslinya. Bisa jadi Hudson Rock tertipu oleh sumber yang tidak jujur, lalu menyadari kesalahannya dan menurunkan artikelnya
      https://community.snowflake.com/s/question/0D5VI00000Emyl00A...

  • Saya Felipe dari Snowflake. Posisi terbaru Snowflake terkait isu ini ada di sini: https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
    Jika ada kabar tambahan, saya akan terus memperbarui URL ini

    • Tautannya terlalu penuh dengan bahasa korporat, jadi saya ingin memastikan dengan jelas. Artikel Hudson Rock secara eksplisit menyatakan bahwa pelanggaran Ticketmaster dan Santander Bank terjadi karena kredensial Snowflake milik karyawan yang dicuri
      Namun, kalimat Snowflake yang berbunyi “serupa dengan akun pelanggan yang terdampak, kami menemukan bukti bahwa pelaku ancaman memperoleh kredensial pribadi untuk akun demo milik mantan karyawan Snowflake dan mengaksesnya. Tidak ada data sensitif di sana” terbaca seolah Snowflake menganggap penjelasan Hudson Rock itu salah. Apakah pemahaman saya benar?
    • Artikel asli Hudson Rock terbaca bukan sekadar bahwa kredensial satu pelanggan dibobol, tetapi bahwa kredensial karyawan dicuri dan, karena tidak ada autentikasi dua faktor, akun pelanggan lain dimasuki dengan hak akses engineer tersebut
      Sebaliknya, tulisan Snowflake terlihat seperti mengatakan bahwa kredensial akun pelanggan bocor, selesai sampai di situ, dan tidak ada akses ke akun pusat atau akun lain. Tidak ada pernyataan apa pun tentang penggunaan info akun karyawan tanpa autentikasi dua faktor
      Jelas Snowflake pasti ingin semua kredensial akses internal karyawannya memakai autentikasi dua faktor. Dulu, jika pelanggan menginginkannya, mereka bisa membuat nama pengguna/kata sandi untuk login ke data mereka sendiri dan mengaksesnya tanpa autentikasi dua faktor
    • Apakah akan ada komentar langsung mengenai artikel ini?
    • Muncul pesan bahwa server salesforce.com sementara tidak dapat merespons permintaan. Hanya ada pesan permintaan maaf atas ketidaknyamanan ini dan diminta mencoba lagi sebentar lagi

  • Screenshot log chat itu benar-benar mengesankan. Perusahaan ini mengklaim sedang berkomunikasi dengan penjahat sungguhan, dan penjahat itu berkata bahwa jika perusahaan ini digunakan, pelanggaran tersebut bisa dibantu untuk dicegah
    Jadi saya memperbarui penilaian saya tentang kredibilitas perusahaan ini

    • Ini murni spekulasi, tetapi tampaknya setelah diabaikan Snowflake, si peretas menghubungi Hudson Rock dan memberi mereka kesempatan publisitas untuk meledakkan laporan ini, dengan tujuan membalas Snowflake yang tidak membayar tebusan
      Hudson Rock tampaknya lalu membesar-besarkan ceritanya agar terlihat seperti pelanggaran yang lebih besar dari kenyataannya. Saya juga penasaran apakah peretas itu mendatangi Hudson Rock lebih dulu, atau Hudson Rock adalah perusahaan pertama yang bersedia menanggapinya
    • Percakapan itu aneh dan terasa seperti kartun. Saya tidak tahu harus memaknainya bagaimana
      “Kalian seharusnya membeli perlindungan dari Hudson Rock, dan kalau begitu kejadian ini bisa dicegah”
      “Betul, itu pasti akan membantu”
    • Itu adalah eufemisme yang umum dalam ransomware atau pemerasan uang perlindungan. Salah satu pesan favorit saya yang ditinggalkan grup Akira pada mesin yang terinfeksi kurang lebih seperti ini
      “Selamat. Perusahaan Anda telah lulus audit keamanan informasi dadakan dan menjadi korban ransomware.”
      [...]
      Yang disediakan: 1) bantuan dekripsi penuh 2) bukti penghapusan data 3) laporan keamanan tentang kerentanan yang ditemukan 4) jaminan bahwa data tidak akan dipublikasikan atau dijual 5) jaminan tidak akan menyerang lagi di masa depan
      Pada akhirnya ini cuma perusahaan konsultan keamanan yang tidak Anda sadari sudah Anda masukkan ke daftar penggajian
      Sebagai catatan, ketika saya melihat apa yang mereka berikan sebagai bukti penghapusan data, itu secara harfiah hanyalah output standar dari rm -vrf data. Saya paham bahwa memberikan bukti ketiadaan itu mustahil dan korban tidak punya daya tawar, tetapi drama ini cukup saya sukai
    • Dari screenshot-nya, ini terlihat sepenuhnya direkayasa, atau sepenuhnya untuk tujuan pemasaran
      Bahkan jika itu nyata, masuk akal untuk menghapus pesan Hudson Rock. Saya sudah memasukkan perusahaan ini ke daftar hitam di kepala saya
    • Kedengarannya seperti pemerasan tersirat

  • Jika hanya melihat ungkapan pelaku, Snowflake tampak seolah merancang sistem dengan memberi kewenangan penuh atas segalanya pada satu akun admin tunggal
    Fakta bahwa dalam pengumuman 31 Mei Snowflake mengatakan sedang menyelidiki “serangan berbasis identitas yang berdampak pada sebagian pelanggan dan terjadi di seluruh industri” juga menambah kredibilitas pada cerita Ticketmaster dan Santander
    https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
    Jika pelaku ancaman melakukannya dengan benar, ini bisa menjadi salah satu kebocoran data terbesar sepanjang masa

    • Tulisan itu memang mengisyaratkan demikian, tetapi tampaknya berlebihan. Sayangnya, ada cukup informasi yang diberikan untuk mengidentifikasi pemilik kredensial yang dicuri itu, dan orang tersebut adalah seorang sales engineer
      Datanya tampaknya berasal dari akun Snowflake milik orang itu yang digunakan saat membuat demo untuk pelanggan atau calon pelanggan. Memang ada kemungkinan pelanggan memberi hak akses agar sebagian data nyata dipakai dalam demo, tetapi itu jauh berbeda dari akses tak terbatas ke database Snowflake milik pelanggan itu sendiri
      Sangat mungkin peretas mengambil data palsu untuk demo yang terlihat meyakinkan, lalu tidak menyadari perbedaannya
    • Masalahnya adalah Hudson Rock tampak menebak-nebak tanpa memahami prosesnya, atau berusaha terdengar berwibawa
      Satu sales engineer menangani beberapa akun. Sales engineer Snowflake biasanya tidak membangun di dalam lingkungan pelanggan, melainkan menyiapkan akun demo kredit $400 yang bisa dibuat siapa saja. Karena akun demo akan kedaluwarsa seiring waktu, mereka terus membuat yang baru
      Sales engineer membangun di dalam akun demo yang mereka buat lalu menunjukkannya ke pelanggan. Setelah 30 hari, Snowflake akan mengunci akun itu jika tidak ada kartu kredit, lalu menghapus instance demo dan datanya
      Untuk pekerjaan tersebut, pelanggan bisa membagikan data dari instance Snowflake mereka sendiri ke instance demo yang dibuat sales engineer, atau memberi hak akses kepada sales engineer Snowflake itu melalui SSO
      Mana pun caranya, ini lebih merupakan masalah organisasi yang tidak menjalankan postur keamanan mereka secara cukup ketat. Ini bukan serangan yang menghadirkan hal baru selain menemukan seorang sales engineer yang bekerja keras, serta pelanggan yang tidak membatasi cakupan izin karyawan/kontraktor/tamu dengan benar
    • Dari pengalaman sekitar setahun lalu saat menerima dukungan Snowflake, agar tim Snowflake bisa melihat atau melakukan sesuatu, admin dari akun pelanggan harus memberi hak akses secara eksplisit kepada Snowflake, dan kalau saya ingat benar akses itu juga memiliki masa berlaku
    • Jika pelaku ancaman bergerak dengan tepat, ini sangat mungkin menjadi pelanggaran data terbesar dalam sejarah
    • Intinya, semuanya dimungkinkan hanya dengan satu serangan malware-as-a-service yang menargetkan karyawan yang tepat. Yang digunakan adalah Lumma
      Menariknya, di halaman pertama juga ada cerita terkait tentang penggunaan Pegasus terhadap LSM di Eropa Timur. Prinsip least privilege itu penting, tetapi keamanan perangkat juga penting
      https://news.ycombinator.com/item?id=40535912

  • Saya bukan karyawan Snowflake, tetapi banyak bekerja bersama Snowflake dan organisasi sales engineer mereka
    Saat membuat demo dengan pelanggan, para sales engineer membuat lingkungan demo dengan akun demo Snowflake senilai 400 dolar yang bisa dibuat siapa saja. Untuk membuat demo, pelanggan memberi hak akses kepada sales engineer tersebut, lalu sales engineer memindahkan sebagian data ke lingkungan demo untuk dikerjakan. Nama lingkungan yang diungkap Hudson Rock juga mendukung hal ini
    Menurut saya, ini adalah masalah proses: ID milik orang yang dulu berbagi data itu tidak dibuat kedaluwarsa oleh pelanggan, lalu pelaku ancaman mencuri kredensialnya. Karena ini bukan eksploitasi kerentanan, tidak ada hal baru di sini
    Dan Hudson Rock, selamat karena telah secara terbuka mengekspos seseorang yang menjadi korban gara-gara komputernya terkena malware. Tidak berbeda dengan kasus memberi kredensial kepada kontraktor lalu kredensial itu dicuri. Ini tindakan yang sangat jahat

    • Bahwa ini bukan “eksploitasi kerentanan baru” tidak berarti ini bukan masalah besar
      Snowflake tahu bahwa kredensial sales engineer bisa dicuri, kredensial itu bisa melewati autentikasi multi-faktor, dan menurut artikelnya juga tidak memiliki masa berlaku. Itu strike 1, 2, dan 3
      Praktik keamanan Snowflake menciptakan situasi di mana pelanggan diharuskan, atau setidaknya didorong, untuk membagikan akses ke dataset yang luas kepada karyawan Snowflake. Itu strike 4
      Pelanggan memang juga bertanggung jawab karena memberi akses yang terlalu luas, tetapi Snowflake juga bertanggung jawab karena tidak membuat sistem yang lebih baik agar akses seperti ini tidak diperlukan, atau setidaknya tidak mengawasi dan mengendalikan akses transitif ini dengan lebih baik
      Begitu akun seperti ini diberi hak akses ke data pelanggan, itu bukan lagi “akun demo”. Itu adalah akun nyata, dengan data nyata yang sangat berharga, sehingga harus diperlakukan demikian
      Tambahan: Snowflake mengklaim akun demo tersebut tidak mengakses data pelanggan dan bukan sumber kebocoran, yang bertentangan dengan klaim penyerang
    • Menyebut nama login dari akun yang diretas benar-benar tampak tidak profesional dan tidak perlu
    • Deskripsi salah satu produk utama Hudson Rock, “Bayonet”, adalah sebagai berikut
      “Bayangkan Anda memiliki akses ke platform pencarian prospek dengan ratusan ribu perusahaan yang telah diretas dan kerentanan aktif di seluruh dunia, dan dapat mengubah mereka menjadi pelanggan.”
      Saya pernah melihat dan berurusan dengan beberapa perusahaan tipe seperti ini, dan taktiknya cukup murahan, dengan tingkat keterampilan maupun usaha teknis yang rendah
    • Saya membaca cepat beberapa tulisan Hudson Rock lainnya, dan banyak yang berakhir dengan nada “seharusnya Anda membeli perlindungan dari kami”. Tercium aroma jual perlindungan
    • Seluruh tulisan blog itu berbau pujian diri yang ekstrem, dan mengekspos korban memang tindakan yang benar-benar sampah. Secara keseluruhan, capaian Hudson Rock sangat buruk

  • Tanggapan resmi Snowflake menyatakan seperti ini
    “Kami meyakini ini merupakan hasil dari serangan berbasis identitas yang sedang berlangsung di seluruh industri, dengan tujuan memperoleh data pelanggan. Penyelidikan menunjukkan bahwa serangan ini dilakukan menggunakan kredensial pengguna milik pelanggan yang terekspos melalui aktivitas ancaman siber yang tidak terkait. Hingga saat ini, kami tidak melihat aktivitas ini terjadi karena kerentanan dalam produk Snowflake, kesalahan konfigurasi, atau aktivitas jahat di dalam Snowflake.”
    [0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...

  • Sepertinya artikelnya diubah menjadi privat, tetapi masih tersimpan di Wayback Machine: https://web.archive.org/web/20240531140540/https://www.hudso...

    • Ini terlihat buruk. Jika ada yang salah, setelah membuat klaim dan tuduhan seperti ini, ralat adalah langkah yang tepat. Menghapus tulisan begitu saja tanpa penjelasan itu tidak bertanggung jawab dan tidak profesional

  • Tulisan ini mengklaim bahwa pelanggaran Ticketmaster beberapa hari lalu sebenarnya adalah peretasan yang jauh lebih luas, yang memengaruhi lebih dari 400 perusahaan, melalui kredensial curian milik karyawan Snowflake
    Saat ini ini tampak seperti cerita besar yang hanya diberitakan oleh hudsonrock.com. Saya baru pertama kali mendengar Hudson Rock, adakah yang tahu apakah itu sumber yang dapat dipercaya?

    • Saya pertama kali tahu Hudson Rock ketika “CEO” mereka mulai menyebarkan spam blog berkualitas rendah di berbagai subreddit keamanan selama berbulan-bulan, dengan klaim tentang banyak pelanggaran
      Sejumlah akun diblokir oleh operator dan admin Reddit. Secara pribadi saya tidak menganggapnya sebagai sumber yang tepercaya atau layak dipercaya
    • Ada laporan BBC News tentang peretasan besar pada bank Santander, dan itu terhubung ke Snowflake
      https://www.bbc.co.uk/news/articles/c6ppv06e3n8o
    • Karyawan Snowflake perlu diberi waktu untuk menjual semua saham mereka. Berita ini akan menghantam harga saham SNOW dengan keras

  • Snowflake tampaknya mengatakan ini bukan salah mereka, melainkan salah pelanggan
    https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
    Jika https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... bukan cerita yang sepenuhnya dibuat-buat, maka Snowflake sedang menyampaikan fakta dengan cara yang agak kurang jujur
    Frasa “penyelidikan menunjukkan…” tidak jelas apakah itu merujuk pada penyelidikan internal mereka sendiri atau riset keamanan yang lebih umum. Kalimat “kami tidak melihat ini terjadi karena kerentanan dalam produk Snowflake, kesalahan konfigurasi, atau aktivitas jahat” juga menolak sejumlah skenario yang mungkin, sambil dengan lihai menghindari penjelasan tentang bagaimana ini sebenarnya terjadi
    Jika percaya pada Hudson Rock, Snowflake telah dihubungi oleh pelaku jahat, jadi kemungkinan besar mereka sudah mengetahui cukup jelas bagaimana hal ini terjadi

    • Bukankah dalam kutipan itu sudah tersirat bagaimana ini terjadi?
      Mereka mengatakan serangan itu “dilakukan menggunakan kredensial pengguna milik pelanggan yang terekspos melalui aktivitas ancaman siber yang tidak terkait”, jadi kalau ini bukan karangan, tampaknya mereka menilai kredensial itu diperoleh dari tempat lain
      Di bagian akhir mereka juga meminta pelanggan meninjau pengaturan akun mereka, jadi arahnya memang mengalihkan tanggung jawab dari diri mereka sendiri. Namun saat ini sumbernya adalah perusahaan yang diretas dan perusahaan yang memanfaatkan insiden ini untuk mempromosikan produknya sendiri sambil dengan berani membeberkan identitas karyawan, jadi sebaiknya menunggu sampai ada informasi yang lebih rinci
    • Atau mereka bisa saja berasumsi pihak pelanggan yang dibobol dan menyalahkan mereka tanpa analisis mendalam yang layak
      Peretas juga mengklaim mereka bahkan tidak membuat refresh token kedaluwarsa, dan jika itu benar, itu adalah masalah yang sangat besar dan sangat jelas

  • Artikel itu tampaknya tidak terlalu konsisten dengan judul “ratusan pelanggan dibobol”
    Pertama, kata sandi lift/okta tampaknya hanya memberi akses ke portal ServiceNow dan bukan akses ke akun pelanggan, sehingga masalah refresh token tampaknya terbatas pada portal ServiceNow dan tidak terlihat terkait dengan paparan data di akun Snowflake pelanggan yang sebenarnya
    Kedua, dalam tangkapan layar yang menyebutkan 10 akun perusahaan dibobol, terlihat 4 kredensial akun Snowflake yang berbeda, salah satunya tampak seperti akun demo pribadi. Jadi paling jauh itu bisa menjelaskan sekitar 3 pelanggan yang dibobol, tetapi tidak ada detail yang menunjukkan pelanggaran pelanggan lain
    Bahkan jika diasumsikan semua kredensial untuk semua pelanggan yang sedang ditangani oleh sales engineer itu ikut bocor, jumlah pelanggan yang dibobol kemungkinan hanya berada di kisaran dua digit rendah. Karena setiap akun pelanggan harus secara terpisah memberikan hak akses kepada sales engineer tersebut
    Mengatakan seluruh basis pelanggan Snowflake dibobol berdasarkan masalah refresh token di portal Okta internal adalah lompatan besar, dan masalah itu tidak terhubung ke akun Snowflake pelanggan mana pun

    • Sulit untuk menilai tanpa mengetahui secara tepat bagaimana akun yang dibobol itu dikonfigurasi dan hak akses apa yang diberikan. Bahkan di “operator telekomunikasi besar yang berfokus pada keamanan” yang saya tahu, Anda akan terkejut melihat tingkat akses yang dimiliki sebagian staf teknis. Tentu saja semua akses dicatat
    • Sangat mungkin ada kredensial atau hal lain di dalam ServiceNow yang bisa digunakan untuk pergerakan lateral ke tempat lain. Tentu saja ini hanya spekulasi