Hasil Investigasi Teknis Utama tentang Perolehan Kunci Storm-0558

 (msrc.microsoft.com)
1 poin oleh GN⁺ 2023-09-07 | 1 komentar | Bagikan ke WhatsApp
  • Hasil investigasi teknis atas insiden ketika pelaku ancaman berbasis di China, Storm-0558, memalsukan token menggunakan kunci penandatanganan konsumen MSA yang dicuri untuk mengakses OWA dan Outlook.com
  • Pada April 2021, dump crash yang dibuat akibat crash sistem penandatanganan konsumen memuat kunci karena race condition, dan sistem gagal mendeteksinya
  • Dump crash yang berisi kunci dipindahkan dari jaringan produksi terisolasi ke lingkungan debugging di jaringan perusahaan yang terhubung ke internet, dan juga tidak terdeteksi oleh pemindaian kredensial
  • Penyebab email enterprise dapat diakses dengan kunci konsumen adalah pengembang sistem email keliru berasumsi bahwa library melakukan validasi scope, sehingga tidak menambahkan validasi issuer/scope
  • Semua cacat telah diperbaiki, dan penguatan pertahanan berlapis seperti otomatisasi validasi scope kunci diterapkan sebagai langkah tindak lanjut

Kronologi Perolehan Kunci

  • Microsoft mengoperasikan lingkungan produksi yang terisolasi dan dibatasi, dengan pemeriksaan latar belakang, akun khusus, workstation akses aman, serta autentikasi multifaktor berbasis token perangkat keras
    • Lingkungan ini memblokir penggunaan alat kolaborasi seperti email, rapat, dan riset web untuk mencegah jalur kompromi akun seperti infeksi malware dan phishing
    • Akses ke sistem dan data dibatasi melalui kebijakan Just in Time / Just Enough Access
  • Lingkungan perusahaan (corporate environment) mensyaratkan autentikasi keamanan dan perangkat aman, tetapi mengizinkan penggunaan email, rapat, dan alat kolaborasi, sehingga rentan terhadap spear phishing, malware pencuri token, dan sejenisnya
    • Berdasarkan prinsip Zero-Trust dan "assume breach", materi kunci tidak boleh keluar dari lingkungan produksi
  • Pada April 2021, crash pada sistem penandatanganan konsumen menghasilkan dump crash (snapshot crashed process)
    • Dump crash seharusnya tidak memuat kunci penandatanganan karena informasi sensitif dimasking, tetapi kunci ikut termuat akibat race condition (telah diperbaiki)
    • Sistem gagal mendeteksi keberadaan kunci dalam dump crash (telah diperbaiki)
  • Dump crash yang saat itu dinilai tidak berisi kunci dipindahkan dari jaringan produksi terisolasi ke lingkungan debugging
    • Hal ini sesuai dengan prosedur debugging standar, dan pemindaian kredensial gagal mendeteksi keberadaan kunci (telah diperbaiki)
  • Setelah kunci bocor, pelaku Storm-0558 mengompromikan akun perusahaan milik seorang engineer Microsoft
    • Akun tersebut memiliki hak akses ke lingkungan debugging tempat dump crash yang berisi kunci berada
    • Karena kebijakan retensi log, tidak ada log bukti spesifik atas kebocoran tersebut, tetapi ini merupakan jalur perolehan kunci yang paling mungkin

Penyebab Email Enterprise Dapat Diakses dengan Kunci Konsumen

  • Untuk merespons permintaan pelanggan agar mendukung aplikasi konsumen maupun enterprise, pada September 2018 diperkenalkan endpoint publikasi metadata kunci umum
    • Sebagai bagian dari penyediaan terpadu, dokumentasi diperbarui untuk memperjelas persyaratan validasi scope kunci untuk akun enterprise dan konsumen
  • API untuk memverifikasi tanda tangan secara kriptografis disediakan, tetapi library tidak diperbarui agar melakukan validasi scope secara otomatis (telah diperbaiki)
  • Sistem email diperbarui pada 2022 untuk menggunakan endpoint metadata umum
    • Pengembang sistem email keliru berasumsi bahwa library melakukan validasi lengkap dan tidak menambahkan validasi issuer/scope yang diperlukan
    • Akibatnya, sistem email menerima permintaan email enterprise dengan token keamanan yang ditandatangani menggunakan kunci konsumen (telah diperbaiki dengan library yang diperbarui)

Tinjauan Pasca-Insiden dan Langkah Perbaikan

  • Mengidentifikasi dan menyelesaikan race condition yang menyebabkan kunci penandatanganan ikut termuat dalam dump crash
  • Memperkuat pencegahan, deteksi, dan respons untuk kasus ketika materi kunci keliru dimasukkan ke dump crash
  • Memperkuat pemindaian kredensial agar dapat mendeteksi keberadaan kunci penandatanganan dengan lebih baik di lingkungan debugging
  • Mendistribusikan library yang ditingkatkan untuk mengotomatiskan validasi scope kunci pada library autentikasi serta memperjelas dokumentasi terkait

Pembaruan Tambahan 12 Maret 2024

  • Hipotesis utama tetap bahwa, karena kesalahan operasional, materi kunci keluar dari lingkungan penandatanganan token keamanan dan diakses di lingkungan debugging melalui akun engineer yang telah dikompromikan; tidak ada perubahan pada dampak terhadap pelanggan/Microsoft maupun aktivitas pelaku
  • Sebelumnya disebutkan bahwa dump crash tahun 2021 mungkin menjadi penyebab akses pelaku, tetapi tidak ditemukan dump crash yang berisi materi kunci yang terdampak
  • Race condition yang disebutkan memengaruhi apakah dump crash dapat dikeluarkan dari lingkungan penandatanganan aman, bukan apakah kunci ada di dalam dump crash
  • Pernyataan bahwa pengeluaran dump crash sesuai dengan prosedur debugging standar berarti hal tersebut tidak dilarang pada masa lalu; prosedur debugging standar Microsoft saat ini melarang pengeluaran materi tersebut dari lingkungan produksi
  • Investigasi yang sedang berlangsung mengungkap keterbatasan teknologi pemindaian kredensial, dan akan diselesaikan begitu ditemukan

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-07
Pendapat di Hacker News

  • Sepertinya ada mata rantai yang hilang di sini: mudah dipahami bahwa bug konkurensi atau bug keamanan memori bisa secara tidak sengaja membuat kunci privat masuk ke artefak debugging, tetapi bukankah penyerang harus mengetahui fakta terjadinya crash, struktur crash dump, dan sedang menunggu di dalam jaringan internal Microsoft?
    Defense assuming breach adalah strategi keamanan jaringan yang baik, tetapi kita tidak boleh begitu saja menerima asumsi bahwa memang sudah terjadi kompromi

    • Jika saya adalah penyerang advanced persistent threat (APT) dari pihak Tiongkok dan berhasil menembus jaringan internal Microsoft dengan kredensial karyawan, hal pertama yang akan saya lakukan adalah mencari lokasi penyimpanan crash log lalu mengekstraknya diam-diam bersama debug symbol
      Data seperti ini sering kali tidak disimpan seaman yang seharusnya jika dibandingkan dengan nilai nyatanya. Dari pengalaman bekerja di FAANG, hampir semua karyawan baru yang tidak punya pengalaman di bidang keuangan atau regulasi perusahaan mengira data crash boleh saja ditempelkan ke bug tracker. Jadi kebiasaan harus diubah agar hal seperti crash dump dimasukkan ke brankas yang cukup mudah dipakai sehingga orang tidak ingin mencari jalan pintas
      Jika ada akun engineer yang sudah dikompromikan, setidaknya harus diasumsikan akun itu punya akses ke bug tracker, dan mungkin juga bisa memperoleh atau membuat debug symbol untuk binary. Sisanya tinggal menunggu satu engineer ceroboh mengunggah crash dump sebagai lampiran bug, lalu mengambilnya sebelum ada yang sadar dan menghapusnya
    • Menurut tulisannya, kompromi akun karyawan terjadi setelah crash dump dipindahkan ke jaringan internal. Microsoft mengatakan tidak ada bukti eksfiltrasi, tetapi saya membacanya seolah ada bukti tertentu terkait kompromi akun
      Selain itu, alat pemindaian kredensial Microsoft tidak menemukan kunci tersebut, dan masalah itu sudah diperbaiki, jadi tampaknya kunci itu berada dalam bentuk yang bisa dideteksi lewat pemindaian
      Secara keseluruhan, kelihatannya seorang engineer memindahkan dump berisi kunci ke akunnya sendiri lalu membiarkannya selama beberapa waktu, kemudian penyerang membobol akun itu, mengambil semua file yang bisa digunakan, lalu memindai kunci dengan alat yang lebih baik daripada milik Microsoft dan mendapatkan jackpot
    • Jika mengikuti kutipan tersebut, setelah April 2021 kunci bocor ke lingkungan internal lewat crash dump, lalu Storm-0558 mengompromikan akun internal seorang engineer Microsoft, dan akun itu punya akses ke lingkungan debugging yang berisi crash dump yang salah memasukkan kunci tersebut
      Dengan kata lain, penyerang sudah berada di dalam jaringan dan kebetulan menemukan dump saat melakukan pemindaian yang tidak terdeteksi, atau sejak awal memang menargetkan akun khusus ini
    • Setahu saya, sejak era serangan cold boot sudah ada alat standar untuk mencari materi kriptografis di memory dump. Bisa dibayangkan penyerang secara oportunistis mencari crash dump dari sudut pandang seperti itu
      Meski begitu, dari sisi penyerang, rangkaian kejadian ini terasa terlalu beruntung
    • Kalau sudah menyusup ke sistem lalu melihat sshd.core di filesystem, tentu saja akan diambil, bukan?

  • Ada kelas-kelas rekayasa sistem yang membahas bagaimana masalah-masalah kecil berurutan dalam urutan tertentu hingga akhirnya menjadi kegagalan katastropik. Kasus ini bisa disebut kegagalan katastropik itu
    Pertama harus ada race condition, dan race condition itu harus menghasilkan akibat yang tak terduga. Jika kodenya sudah diuji dan sering dipakai, kemungkinan terjadinya mungkin sudah di bawah 10% pada tahap ini. Berikutnya, engineer harus kebetulan menilai crash dump ini diperlukan, perangkat lunak pemindaian kredensial harus gagal menemukan kredensial tertentu ini, satu akun harus dikompromikan sehingga mendapat akses jaringan, pengguna itu harus punya akses ke dump tersebut, dan hacker harus menemukannya lalu mengambilnya
    Meski begitu, kuncinya sudah lama dan seharusnya aman karena hanya bisa dipakai untuk mengakses akun email konsumen, tetapi ternyata masih ada bug yang menerima kunci lama dan bug lain yang tidak menolak kunci tanda tangan ini untuk token akun email perusahaan
    Ini pelajaran rekayasa sistem yang bagus. Sebesar apa pun usaha kita, pada akhirnya jika cukup banyak hal kecil menumpuk, insiden besar akan terjadi, jadi sistem harus dirancang agar sekalipun meledak, blast radius-nya terbatas

    • Dalam keamanan, perlu ada petunjuk bahwa rantai semacam ini tidak datang seperti proses acak, melainkan ditargetkan dan dieksploitasi secara aktif. Penyerang bukan entitas yang melempar koin secara acak; mereka bisa melempar koin yang lebih sering keluar sisi kepala demi keuntungan mereka
      Analisis pascainsiden disajikan seolah rangkaian kejadian sial bertumpuk secara acak. Seolah penyerang kebetulan menargetkan Microsoft, kebetulan ada race condition, kebetulan terjadi crash, dan kebetulan menemukan crash dump di suatu tempat
      Namun kemungkinan bahwa bug race condition awal itu ditanam dengan sengaja juga harus dipikirkan. Crash bisa saja dipicu secara sengaja, penyerang bisa saja menunggu dump muncul di lokasi tertentu, dan bisa saja ada kaki tangan
    • Sepertinya diasumsikan bahwa Microsoft melakukan rekayasa sistem dan menguji produknya, tetapi kenyataannya tampak jauh dari itu
      Ekosistem Microsoft terlihat seperti mobil Lego yang dirakit asal-asalan dari komponen yang dibawa anak-anak tetangga masing-masing dari rumah
    • Race condition adalah alasan yang dipakai semua orang untuk menjelaskan kepada manajemen saat mereka menulis bug bodoh. Kalimat “masker bersifat asinkron, jadi writer mulai menulis dump sebelum masker diterapkan” terdengar seperti implementasi yang benar-benar tidak masuk akal
      Kalau disebut race condition, orang akan bilang “kemungkinannya di bawah 10%”, tetapi kenyataannya bisa saja itu terjadi pada setiap crash besar, hanya saja crash-nya tidak sering terjadi
      Hanya Tuhan yang tahu mengapa masking tidak dilakukan sebelum ditulis ke disk
    • Kegagalan katastropik berupa unknown unknown seperti ini selalu ada dan akan terus muncul. Karena itu diperlukan resiliensi, dan mungkin juga sudut pandang yang kurang tersentralisasi
      Struktur ketika lebih dari separuh dunia bisnis Barat bergantung pada Outlook.com nyaris merupakan kondisi yang sangat keliru, tetapi insentif finansial saat ini tidak mengarah pada resiliensi atau pemecahan entitas supertersentralisasi seperti Outlook.com, jadi sepertinya hal seperti ini akan terus terjadi
    • Saat membacanya, saya berpikir, “wah, ini benar-benar melewati banyak lubang jarum.” Rasanya seperti lintasan bantuan gravitasi Grand Tour Voyager terjadi karena kesalahan

  • Ada beberapa hal yang tidak dijelaskan dengan jelas: jika ini terdeteksi pada 11 Juli 2023 dan diduga terjadi pada April 2021, berarti penyerang memiliki kredensial ini selama lebih dari 2 tahun, dan butuh 2 bulan dari deteksi hingga pengungkapan
    Jumlah token palsu dan sejauh mana akses yang terjadi juga tidak disebutkan. Jika tidak diungkapkan, orang akan cenderung berasumsi buruk
    Tidak ada juga jadwal dari deteksi hingga penerapan perbaikan, hanya pernyataan “masalah ini sudah diperbaiki”. Kita hanya bisa berharap mereka memperbaikinya dengan cepat
    Mereka memperbaiki 4 masalah langsung, tetapi jelas terlihat ada masalah sistemik, dan tidak tampak apa yang akan mereka lakukan terkait hal itu

  • Pelanggaran seperti ini membutuhkan pemahaman yang sangat mendalam terhadap infrastruktur internal Microsoft. Aman untuk menganggap ini adalah pekerjaan terorganisasi dari sebuah tim peretas
    Ini bukan hal yang murah untuk dilakukan, tetapi imbalannya luar biasa besar. Super-sentralisasi membuat peretas memusatkan upaya pada sejumlah kecil target bernilai tinggi. Karena jika berhasil, hasil yang didapat sangat besar
    Saya hampir yakin ada tim peretas yang didukung negara yang sudah mempelajari dan menganalisis secara mendalam infrastruktur internal tempat seperti Google, Microsoft, dan Amazon. Pelanggaran kali ini menunjukkan seberapa baik mereka sudah memahaminya
    Menurut saya sudah waktunya melakukan desentralisasi dalam batas keamanan yang lebih luas

    • Jika skala organisasi cukup besar, harus diasumsikan bahwa ada aktor negara yang bekerja dari dalam. Sayangnya, siapa pun bisa diretas kapan saja, sehingga asumsi ini sulit dihindari

  • Jika ungkapan hati-hatinya disingkirkan, seseorang mengunduh minidump dari lingkungan produksi ke workstation pengembangan, lalu kemungkinan file itu membusuk di suatu tempat di OneDrive internal milik pengembang tersebut sampai akunnya diretas. Seseorang mengambil dump itu, menemukan kuncinya, dan mendapatkan jackpot

    • Yang menentukan sehingga serangan ini benar-benar bisa berhasil sejauh itu adalah bahwa para developer Microsoft gagal mengimplementasikan pemeriksaan autentikasi yang aman di atas library dan infrastruktur mereka sendiri
    • Lalu ada sistem redaksi/masking yang gagal menyembunyikan kunci, dan sistem deteksi yang gagal menemukan kunci tersebut. Setelah itu, meski kunci itu digunakan pada sistem yang benar-benar berbeda dengan tingkat akses yang benar-benar berbeda, semuanya tetap berjalan begitu saja
      Ungkapan “beberapa bug samar dieksploitasi secara canggih” terasa agak meleset. Ini lebih mirip rangkaian kesalahan berantai di mana tidak satu pun sistem keamanan menjalankan tugasnya

  • Saya tidak tahu mengapa mereka tidak memakai HSM. Bukankah tujuan utama perangkat keras semacam itu adalah mencegah kebocoran material kunci?

    • Perusahaan-perusahaan ini [1] mengklaim sebagai “HSM pembayaran tercepat di dunia yang mampu memproses lebih dari 20.000 transaksi per detik”. Beban puncak penandatanganan token autentikasi akun Microsoft mungkin jauh lebih tinggi dari itu
      [1] https://www.futurex.com/download/excrypt-ssp-enterprise-v-2-...
    • Dari cara penjelasannya, saya sempat mengira log crash yang mereka dapatkan berasal dari HSM

  • Ini berarti kunci tersebut tidak disimpan di perangkat keras yang tidak bisa dipulihkan, melainkan dapat diakses oleh proses server biasa berupa kode terkompilasi yang berjalan di lingkungan dengan hak istimewa tinggi
    Tidak ada juga penyebutan bahwa sistem yang bisa mengakses kunci ini berada di lingkungan terpisah, bukan lingkungan operasi biasa. Jadi dapat diasumsikan bahwa perangkat operasional mana pun bisa mengakses kunci, dan siapa pun yang memiliki akses ke lingkungan itu berpotensi membocorkan material kunci

  • Jika melihat bagian validasi di https://learn.microsoft.com/en-us/azure/active-directory/dev..., kalau saya tidak melewatkan sesuatu, sepertinya pentingnya memeriksa tanggal penerbit atau apakah kunci sudah dicabut masih belum disebutkan
    Itu juga tidak ada di pseudocode, jadi besar kemungkinan masih ada implementasi lain yang mempercayai kunci apa pun yang pernah dipublikasikan Microsoft. Kecuali pengecualian seperti penghapusan cache, maksudnya

    • Justru itu bagian yang paling saya khawatirkan. Para developer Microsoft gagal mengimplementasikan pemeriksaan autentikasi yang aman di atas library dan infrastruktur mereka sendiri
      Jika Microsoft saja tidak bisa menggunakan platform identitas mereka sendiri dengan benar di produk andalannya, Outlook, peluang apa yang dimiliki orang lain?
    • Inilah masalah intinya. Semua orang membicarakan crash dump dan kebocoran, tetapi intinya adalah Microsoft tidak memvalidasi keabsahan kunci, dan juga tidak memvalidasi konteks penggunaan kunci. Kunci yang bocor itu sebenarnya sudah tidak valid, dan kunci itu juga bukan kunci yang diizinkan untuk membuat token administrator
      Mereka pada dasarnya hanya memeriksa apakah token ditandatangani oleh Microsoft CA. Ini adalah masalah yang terlihat sangat jelas dalam code review sampai sulit dipercaya

  • Salah satu alasan mereka benar-benar kena besar tampaknya karena mereka tidak merotasi kunci. Kedengarannya ada jeda waktu yang cukup lama antara saat kunci dipindahkan ke tempat yang seharusnya tidak memuatnya dan saat kunci itu benar-benar dicuri
    Jika kunci sering dirotasi, pemalsuan token dengan kunci tersebut tidak akan mungkin dilakukan

  • Setiap kali tulisan seperti ini muncul, saya selalu merasa struktur yang menyerahkan respons terhadap serangan tingkat negara kepada perusahaan swasta hanya karena serangannya bersifat digital, bukan fisik, benar-benar terlihat aneh
    Jika jet tempur Tiongkok menembak jatuh pesawat FedEx di atas Samudra Pasifik, itu akan dianggap sebagai serangan terhadap kedaulatan AS dan pemerintah akan merespons dengan semestinya. Tidak ada yang akan berharap FedEx memiliki sendiri skuadron jet tempur untuk melindungi pesawat angkutnya. Tidak akan ada pula yang berkata, “ini salah FedEx karena tidak menyiapkan pertahanan udara dengan benar”
    Namun begitu masuk ke ranah digital, suasananya menjadi menerima bahwa Microsoft harus membela diri sendiri melawan Tiongkok dan Rusia

    • Jika sekelompok warga Tiongkok membobol bank AS, misalnya Federal Reserve, dan menimbulkan kerugian finansial besar tetapi tidak ada korban jiwa, responsnya akan mirip. Apalagi jika keterkaitannya dengan pemerintah Tiongkok yang sebenarnya dicurigai, tetapi sulit dibuktikan secara pasti
      Pemerintah cukup rutin menangkap agen asing, tetapi penangkapan semacam itu tidak berujung pada perang total
    • Berbeda dengan contoh pesawat FedEx, kali ini infrastruktur tidak diserang atau dihancurkan, dan tidak ada korban jiwa. Hanya email para pejabat pemerintah AS yang dibaca
      Kedua, AS juga selalu melakukan hal seperti ini, termasuk terhadap negara sahabat, sehingga sulit membenarkan tindakan yang lebih keras
    • Ranah digital pada dasarnya memiliki tingkat bahaya yang lebih rendah dan lebih sulit dipertahankan dibanding ranah fisik. Tidak merespons serangan siber seperti serangan fisik adalah hal yang baik. Kalau tidak, eskalasinya mungkin sudah sampai perang nuklir lebih dari 10 tahun lalu
      Cakupan dan volume serangan siber sangat besar, tetapi saya memahami bahwa AS juga melakukan banyak serangan luar negeri dalam skala yang sepadan
    • Ada beberapa contoh ketika sebuah negara menembak jatuh pesawat penumpang atau menyita kapal, tetapi tidak diperlakukan sebagai tindakan perang
    • Pesawat sipil dari AS menuju Asia yang membawa anggota DPR AS ditembak jatuh, tetapi pada kenyataannya Perang Dunia III tidak terjadi: https://en.wikipedia.org/wiki/Korean_Air_Lines_Flight_007