Peretas Mencuri Token Akses dari Unit Dukungan Okta

 (krebsonsecurity.com)
1 poin oleh GN⁺ 2023-10-22 | 1 komentar | Bagikan ke WhatsApp
  • Akibat pembobolan sistem dukungan pelanggan Okta, file yang diunggah sebagian pelanggan ke kasus dukungan terekspos, dan penyerang tampaknya memiliki akses ke platform dukungan selama setidaknya 2 minggu sebelum diblokir
  • Penyerang masuk ke sistem manajemen kasus dukungan menggunakan kredensial yang dicuri, dan dapat melihat file HAR yang dikirim pelanggan untuk pemecahan masalah
  • File HAR dapat berisi cookie dan token sesi, sehingga jika dicuri ada risiko penyerang dapat menggunakan kembali sesi seolah-olah sebagai pengguna yang sah
  • BeyondTrust mendeteksi upaya pembuatan akun administrator di lingkungan Okta miliknya pada 2 Oktober, dan 30 menit sebelumnya telah membagikan file HAR berisi token sesi Okta yang valid kepada Okta
  • Okta memberi tahu sekitar 170 pelanggan, sekitar 1% dari lebih dari 18.000 pelanggannya; 1Password dan Cloudflare juga mengungkap bahwa platform autentikasi Okta mereka terdampak, tetapi menyatakan tidak ada dampak pada informasi pelanggan maupun sistem

File pelanggan yang terekspos di sistem manajemen kasus dukungan

  • Okta adalah perusahaan yang menyediakan alat identitas termasuk autentikasi multifaktor dan single sign-on kepada ribuan perusahaan, dan insiden ini bermula dari pembobolan unit dukungan pelanggan
  • Dalam pemberitahuan yang dikirim kepada sebagian pelanggan pada 19 Oktober, Okta menyatakan bahwa kredensial yang dicuri digunakan untuk mengakses sistem manajemen kasus dukungan
  • Penyerang dapat melihat file yang baru-baru ini diunggah oleh sebagian pelanggan Okta ke kasus dukungan
  • Cakupan dampaknya awalnya digambarkan sebagai “jumlah yang sangat kecil”, dan kemudian dikonfirmasi bahwa pemberitahuan dikirim kepada sekitar 170 pelanggan, sekitar 1% dari basis pelanggan Okta

Mengapa file HAR menjadi berbahaya

  • Saat menyelesaikan masalah pelanggan, Okta terkadang meminta file HTTP Archive(HAR), yaitu rekaman sesi peramban web
  • File HAR bersifat sensitif karena dapat berisi cookie pelanggan dan token sesi
  • Penyerang dapat menyamar sebagai pengguna yang sah menggunakan cookie atau token di dalam file
  • Okta bekerja sama dengan pelanggan yang terdampak untuk melakukan investigasi dan mengambil langkah perlindungan, termasuk mencabut token sesi bawaan
  • Sebelum membagikan file HAR, semua kredensial, cookie, dan token sesi harus dihapus

Alur serangan yang ditangkap BeyondTrust

  • Perusahaan keamanan BeyondTrust adalah salah satu pelanggan yang menerima pemberitahuan Okta pada 19 Oktober
  • CTO BeyondTrust Marc Maiffret mengatakan pemberitahuan tersebut tiba lebih dari 2 minggu setelah BeyondTrust memberi tahu Okta tentang potensi masalah
  • Pada 2 Oktober, tim keamanan BeyondTrust mendeteksi seseorang mencoba membuat akun administrator dengan privilese tinggi di lingkungan Okta mereka menggunakan akun Okta yang ditetapkan untuk salah satu insinyur perusahaan
  • Setelah meninjau aktivitas akun karyawan tersebut, ditemukan bahwa 30 menit sebelum aktivitas tidak sah itu, seorang insinyur dukungan telah membagikan file HAR berisi token sesi Okta yang valid kepada Okta atas permintaan Okta
  • Penyerang mencoba melakukan pembajakan sesi menggunakan cookie dalam riwayat peramban dan bertindak atas nama pengguna tersebut
  • BeyondTrust memberi tahu Okta pada 3 Oktober bahwa Okta kemungkinan besar mengalami pembobolan, dan menyampaikan penilaian yang sama dalam panggilan pada 11 Oktober dan 13 Oktober
  • BeyondTrust menyatakan bahwa mereka mendeteksi serangan saat sedang berlangsung, dan pelanggan mereka tidak terdampak

Respons Okta dan pertanyaan yang tersisa

  • Deputy CISO Okta Charlotte Wylie mengatakan bahwa pemberitahuan BeyondTrust pada 2 Oktober awalnya tidak dianggap sebagai hasil dari pembobolan sistem Okta
  • Hingga 17 Oktober, Okta telah mengidentifikasi dan memblokir insiden tersebut, menonaktifkan akun manajemen kasus pelanggan yang dibobol, serta membatalkan token akses Okta terkait
  • Wylie tidak mengungkap jumlah pasti pelanggan yang menerima pemberitahuan potensi masalah keamanan, tetapi menggambarkannya sebagai “sebagian yang sangat, sangat kecil” dari lebih dari 18.000 pelanggan
  • Berapa lama penyusup memiliki akses ke akun manajemen kasus perusahaan, dan siapa pihak di balik serangan tersebut, tidak diungkapkan
  • Wylie menyatakan bahwa penyerang kali ini adalah aktor ancaman yang dikenal pernah menargetkan Okta dan pelanggan tertentu Okta

Pembobolan terkait dan pengungkapan lanjutan

  • Pengungkapan Okta muncul beberapa minggu setelah peretasan Caesar’s Entertainment dan MGM Resorts
  • Dalam insiden di dua perusahaan kasino tersebut, penyerang menggunakan rekayasa sosial terhadap karyawan untuk mereset persyaratan login autentikasi multifaktor akun administrator Okta
  • Pada Maret 2022, Okta mengungkap pembobolan terkait kelompok peretas LAPSUS$ yang berspesialisasi dalam serangan rekayasa sosial
  • Menurut laporan pascainsiden Okta, LAPSUS$ memperoleh akses melalui rekayasa sosial ke workstation insinyur dukungan Sitel, vendor outsourcing pihak ketiga yang memiliki hak akses ke sumber daya Okta
  • Okta kemudian menerbitkan artikel blog terkait insiden dan menyertakan indikator kompromi agar pelanggan dapat memeriksa apakah mereka terdampak
    • Okta menyatakan telah memberi tahu semua pelanggan yang terdampak
    • Okta menekankan bahwa lingkungan atau tiket dukungan pelanggan Okta yang tidak menerima kontak terpisah tidak terdampak
  • BeyondTrust juga mengungkap hasil investigasinya sendiri
  • Dalam pembaruan pada 24 Oktober, 1Password dan Cloudflare mengungkap bahwa platform autentikasi Okta mereka terdampak akibat pembobolan Okta
    • Kedua perusahaan menyatakan bahwa hasil investigasi menunjukkan informasi pelanggan maupun sistem tidak terdampak
    • Juru bicara Okta mengatakan kepada TechCrunch bahwa Okta telah memberi tahu sekitar 1% dari basis pelanggannya, yakni sekitar 170 pelanggan

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-22
Komentar di Hacker News

  • Bagian lucu dari artikel ini adalah Okta diberi tahu oleh pihak ketiga tentang aktivitas tenant yang mencurigakan, awalnya tidak menemukan bukti kompromi, lalu baru menyelidiki ulang dan mengonfirmasi kompromi setelah BeyondTrust terus mendesak.
    Okta mengunggah posting blog di sini: https://sec.okta.com/harfiles
    Kalimat pembukanya adalah “Okta Security has identified adversarial activity”, tetapi tidak ada penyebutan soal pemberitahuan dari pihak ketiga. Transparansi yang bagus ya

    • Saya masih tidak mengerti siapa yang masih memakai Okta. Autentikasi adalah bagian terpenting dari seluruh TI, dan Okta sudah berulang kali membuktikan diri sebagai pihak yang tidak bisa dipercaya dan kurang berintegritas. Rasanya seperti bom waktu yang tinggal menunggu meledak
    • Judul dari Okta mungkin judul paling melempem dalam sejarah pengumuman pelanggaran keamanan: “Tracking Unauthorized Access to Okta's Support System”
      Judulnya buruk, tidak transparan, dan tidak langsung ke inti. Sangat payah Okta bahkan tidak menyebutkan fakta bahwa BeyondTrust memberi tahu mereka pada 2 Oktober, 30 menit setelah mengunggah file HAR ke Okta Support

  • “Wakil CISO Okta, Charlotte Wylie, mengatakan Okta awalnya menganggap peringatan BeyondTrust pada 2 Oktober bukan hasil dari kompromi sistem mereka. Namun ia mengatakan pada 17 Oktober perusahaan telah mengidentifikasi dan memblokir insiden tersebut”
    Artinya, sebuah perusahaan yang mengklaim sebagai pakar keamanan siber dan autentikasi diberi tahu dalam 30 menit bahwa mereka diretas, lalu perusahaan itu mengatakan pemberitahuan tersebut salah dan selama 15 hari tidak mengakuinya sementara penyerang berkeliaran bebas.
    Wylie, harusnya bisa lebih baik

  • Lihat saja posting blog yang ditautkan di artikel asli ini. Sebuah perusahaan keamanan yang merupakan salah satu pelanggan Okta mendeteksi aktivitas mencurigakan di jaringannya sendiri tepat setelah membagikan file HAR dengan Okta, lalu memberi tahu Okta tentang kompromi tersebut.
    https://www.beyondtrust.com/blog/entry/okta-support-unit-bre...

    • Layanan Amazon baru saja meminta saya membagikan file HAR, dan saya merasa itu jelas merupakan risiko keamanan. Bukankah itu berarti agen dukungan akan mendapatkan cookie autentikasi akun saya? Saya tidak mengerti bagaimana praktik seperti ini bisa umum dilakukan
    • Tulisan itu agak melewati begitu saja bagaimana persisnya mereka mendeteksi pembajakan sesi. Mereka mengatakan, “deteksi ini mencari sesi mencurigakan yang muncul tanpa event autentikasi, dan konsisten dengan pembajakan sesi”, tetapi agar sebuah sesi ada, tentu pada suatu titik pasti pernah ada autentikasi.
      Mungkin itu cara rumit untuk mengatakan bahwa setelah login IP-nya berubah. Tentu saja solusi termudah adalah tidak secara sukarela membagikan file HAR dari sesi yang aktif
    • Tulisan ini punya detail yang cukup masuk akal untuk memahami masalahnya. Sebaliknya, tulisan Okta membutuhkan banyak konteks agar bisa dipahami

  • Mungkin ini tidak populer, tetapi menurut saya gerbang inti SSO dengan OAuth, SAML, dan 2FA seharusnya dijalankan on-premise, bukan menekan “tombol mudah” SaaS.
    Ini mencakup bukan hanya Okta, tetapi juga Auth0 (diakuisisi Okta), Authy, dan Duo

    • Sayangnya, menjalankannya on-premise tidak mencegah pelanggaran keamanan, dan bisa jadi jauh lebih buruk daripada menyerahkan autentikasi ke penyedia cloud.
      Semua perangkat lunak punya bug keamanan, dan perangkat lunak on-premise tidak terkecuali. Banyak organisasi TI tidak punya keahlian untuk mengoperasikan dan melindungi direktori. Ini bukan sekadar memasang software, membuat beberapa akun, lalu menaruhnya di pojok; ini pekerjaan yang sangat sulit yang mencakup disaster recovery, pengujian backup, hingga menentukan apakah telah terjadi kompromi.
      Tidak ada yang membuktikan bahwa keamanan TI on-premise lebih baik daripada keamanan penyedia cloud. Di antara departemen TI on-premise yang pernah saya lihat sendiri, ada yang keamanannya sangat buruk: ada yang menjalankan VPN dengan sertifikat MD5 bahkan antara 2010–2020, ada yang menerapkan layanan web tempat pengguna tanpa autentikasi bisa mengakses informasi pribadi seperti nomor jaminan sosial/nomor pajak, alamat, nama, dan nomor telepon, ada yang memberikan editor teks berbasis iklan kepada perawat untuk menulis catatan pasien, ada yang tidak memperbarui versi Redcap yang sudah end-of-support dan punya bug keamanan yang diketahui, dan lain-lain.
      Sejauh yang saya tahu, Redcap adalah perangkat lunak yang menyimpan informasi yang digunakan untuk riset medis dan perhitungan statistik kesehatan masyarakat, jadi banyak datanya sensitif.
      Intinya, memindahkan dari cloud ke on-premise bisa saja meningkatkan keamanan, bisa juga tidak. Itu bergantung pada kemampuan organisasi TI masing-masing, dan banyak organisasi tidak mampu mengoperasikan layanan identitas seperti Okta. Selain itu, penyedia cloud biasanya punya anggaran yang jauh lebih besar dan dapat menyebarkan biaya ke banyak pelanggan, sehingga bisa berinvestasi lebih banyak pada pakar keamanan, perlindungan sistem, dan deteksi kompromi
    • Saya setuju, tetapi saat ini perhitungan biaya on-premise ditelaah cukup ketat, sementara untuk cloud, siapa pun yang berkata “kami mengubah belanja modal menjadi biaya operasional dan mengimplementasikan solusi cloud-native auto-scaling kelas atas” akan diperlakukan seperti jenius.
      Manajer dan eksekutif seperti itu tidak mendapat pertanyaan apa pun
    • Menambahkan satu lagi hal yang mungkin tidak populer: kalau tidak perlu terhubung ke jaringan, jangan hubungkan.
      Anda benar-benar bisa menulis dan menguji perangkat lunak di sistem yang sama sekali tidak pernah terhubung. Mengejutkan, tapi benar
    • Jangan lupakan Azure AD juga. Di sanalah root key pernah bocor
    • Apakah ada versi on-premise dari Duo? Atau apakah saya harus menerapkan dan menguasai lima solusi berbeda supaya bisa mendapatkan sebagian besar fungsinya di domain saya?

  • Tempat seperti penyedia identitas, pengelola kata sandi, dan perusahaan VPN sama sekali tidak boleh diretas. Mereka adalah perusahaan yang menghasilkan uang dari produk keamanan, dan saya tidak akan memakai layanan yang pernah dibobol. Besar kemungkinan ada masalah yang lebih mendalam

    • Semua bisa diretas. Jelas bahwa tidak ada yang tahu cara memakai perangkat lunak yang sepenuhnya aman. Tidak ada juga yang tahu cara sama sekali tidak melakukan kesalahan operasional, tidak membuat salah konfigurasi, tidak lupa mencabut hak akses, dan selalu mengganti nilai rahasia
    • Saya tidak tahu mengapa harus memakainya sebelum mereka membuktikan bahwa mereka tidak bisa dibobol
      Asumsi dasarnya adalah semuanya bisa dibobol, dan beban pembuktian bahwa mereka tidak akan dibobol ada pada mereka. Alih-alih memberi praduga baik kepada pihak yang berulang kali menunjukkan ketidakmampuan, tampaknya lebih bijak menunggu bukti positif yang mendukung klaim luar biasa bahwa mereka tidak bisa diretas
    • Seperti pepatah lama, keamanan bukanlah produk, melainkan proses. Namun karena proses itu sangat sulit, selalu ada godaan untuk bersandar pada yang pertama daripada yang kedua
    • Layanan seperti itu, menurut definisinya, adalah honeypot. Naif jika mengira mereka tidak akan pernah diretas. Diretas hanya soal waktu
      Jika mereka cukup kompeten dan bertanggung jawab, mereka akan mendeteksi dan mengungkapkannya, tetapi sepertinya kebanyakan tidak akan begitu. Karena orang-orang seperti Anda akan langsung berhenti menggunakannya. Jadi siapa pun yang sedikit saja khawatir sebaiknya memakai alternatif offline, self-hosted, atau buatan sendiri

  • Tantangan Okta tidak diretas selama sebulan: tingkat kesulitan mustahil
    Selain bercanda, Okta terlihat seperti suka dibobol. Saya berharap akan ada perubahan jika harga sahamnya terus turun karena insiden seperti ini, tetapi sepertinya tidak

    1. https://www.malwarebytes.com/blog/news/2023/01/okta-breached...
    2. https://www.theverge.com/2022/4/20/23034360/okta-lapsus-hack...
    3. https://techmonitor.ai/technology/cybersecurity/okta-cyberat...

  • Iblis ada pada detailnya. Mungkin mereka beroperasi dengan zero trust
    Di satu sisi, ini bukan pembobolan produk inti. Di sisi lain, setiap pembobolan produk inti selalu disertai pembobolan tidak langsung pada bagian non-inti

  • Syukurlah mereka diizinkan mengakuisisi pesaingnya, Auth0

  • Suatu hari nanti, dalam presentasi konferensi, saya akan melakukan eksperimen: membayar orang untuk masuk ke posisi dukungan di beberapa perusahaan, lalu membobol perusahaan-perusahaan itu dengan hak akses sistem yang diberikan kepada mereka

  • Di bagian bawah email tertulis seperti ini
    “Informasi ini adalah informasi rahasia Okta dan tidak boleh dibagikan ke luar organisasi Anda”
    Jujur saja, ini cukup lucu

    • Jika mereka meminta file HAR sebagai prosedur dukungan standar, mengapa tidak secara otomatis melakukan penghapusan informasi sensitif saat diunggah?