1Password mendeteksi “aktivitas mencurigakan” di akun Okta internal

 (arstechnica.com)
1 poin oleh GN⁺ 2023-10-25 | 1 komentar | Bagikan ke WhatsApp
  • 1Password mendeteksi aktivitas mencurigakan pada 29 September di instance Okta internal yang digunakan untuk mengelola akses aplikasi karyawan, dan tidak menemukan pelanggaran data pengguna atau sistem sensitif
  • Akses ini terkait dengan pembobolan sistem manajemen dukungan pelanggan Okta, dan penyerang dapat memperoleh cookie autentikasi serta token sesi dari file HAR yang diunggah pelanggan
  • Laporan Notion internal 1Password merangkum bahwa penyerang memperoleh file HAR yang dibuat oleh staf IT saat bekerja dengan dukungan Okta, dan file tersebut berisi trafik Okta serta cookie sesi
  • Penyerang meminta laporan pengguna admin di tenant Okta 1Password serta memperbarui dan mengaktifkan IDP untuk autentikasi lingkungan produksi Google, tetapi upaya penggunaan ulang berikutnya gagal karena IDP telah dihapus
  • Pembobolan Okta menjadi contoh serangan lanjutan ketika intrusi ke pemasok berujung pada serangan terhadap perusahaan pelanggan, dan 1Password menjadi target pelanggan Okta kedua yang diketahui

Deteksi akses Okta internal 1Password

  • 1Password adalah pengelola kata sandi yang digunakan oleh jutaan pengguna dan lebih dari 100.000 perusahaan
  • Perusahaan mengonfirmasi aktivitas mencurigakan pada 29 September di instance Okta yang digunakan untuk mengelola aplikasi karyawan
  • CTO Pedro Canahuati mengatakan aktivitas tersebut segera dihentikan dan diselidiki, serta tidak ditemukan pembobolan data pengguna maupun sistem sensitif untuk karyawan atau pengguna
  • Setelah itu, 1Password bersama Okta menyelidiki bagaimana penyerang tak dikenal mengakses akun tersebut

Pembobolan sistem dukungan Okta dan risiko file HAR

  • Insiden 1Password dipastikan berasal dari pembobolan sistem manajemen dukungan pelanggan yang diungkap Okta
  • Okta mengatakan pelaku ancaman mendapatkan akses tidak sah ke sistem manajemen kasus dukungan pelanggan dan melihat file yang diunggah oleh sebagian pelanggan Okta
  • File yang diperoleh mencakup file HAR, yang digunakan staf dukungan Okta untuk mereproduksi aktivitas browser pelanggan saat pemecahan masalah
  • File HAR dapat menyimpan informasi sensitif seperti cookie autentikasi dan token sesi, sehingga dapat disalahgunakan penyerang untuk menyamar sebagai pengguna sah

Target kedua yang diketahui setelah BeyondTrust

  • Perusahaan keamanan BeyondTrust menemukan intrusi setelah penyerang mencoba mengakses akun Okta mereka menggunakan cookie autentikasi yang valid
  • Di BeyondTrust, penyerang dapat melakukan “beberapa tindakan terbatas”, tetapi kontrol kebijakan akses menghentikan aktivitas tersebut dan memblokir akses akun
  • 1Password menjadi pelanggan Okta kedua yang diketahui menjadi target serangan lanjutan setelah pembobolan Okta

Alur insiden dalam laporan Notion internal

  • Laporan bertanggal 18 Oktober yang dibagikan di workspace Notion internal 1Password menyebutkan bahwa penyerang memperoleh file HAR yang dibuat oleh staf IT perusahaan
    • Staf tersebut baru-baru ini membuat file itu saat bekerja dengan dukungan Okta
    • File tersebut berisi catatan seluruh trafik antara browser karyawan 1Password dan server Okta, serta cookie sesi
  • 1Password tidak menanggapi permintaan verifikasi keaslian dokumen yang diberikan oleh seorang karyawan anonim dalam bentuk teks dan tangkapan layar
  • Menurut laporan tersebut, penyerang juga mengakses tenant Okta 1Password
    • Tenant Okta digunakan untuk mengelola hak akses sistem dan tingkat izin yang diberikan kepada karyawan, mitra, dan pelanggan
    • Penyerang melihat penetapan grup dan melakukan tindakan lain, tetapi sebagian tindakan tidak tercatat di log peristiwa
    • Saat login, penyerang memperbarui IDP(identity provider) yang digunakan untuk autentikasi lingkungan produksi yang disediakan Google

Tindakan yang dilakukan penyerang dan upaya ulang yang diblokir

  • Tim IT 1Password mengetahui adanya akses pada 29 September setelah menerima email tak terduga yang mengindikasikan permintaan daftar pengguna 1Password dengan hak admin
  • Anggota tim menilai bahwa karyawan yang berwenang tidak membuat permintaan tersebut dan memberi tahu tim respons keamanan perusahaan
  • Tindakan yang dilakukan penyerang adalah sebagai berikut
    • Mencoba mengakses dasbor Okta staf IT, tetapi diblokir
    • Memperbarui IDP yang sudah ada dan terhubung dengan lingkungan Google produksi 1Password
    • Mengaktifkan IDP tersebut
    • Meminta laporan pengguna admin
  • Pada 2 Oktober, penyerang kembali login ke tenant Okta 1Password dan mencoba menggunakan Google IDP yang sebelumnya diaktifkan, tetapi gagal karena IDP telah dihapus
  • Kedua akses tersebut dilakukan dari server host cloud LeaseWeb di Amerika Serikat, menggunakan versi Chrome pada mesin Windows
  • Setelah insiden tersebut, 1Password mengubah pengaturan tenant Okta agar menolak login melalui penyedia identitas non-Okta

Struktur pembobolan pemasok yang berujung pada serangan pelanggan

  • Pembobolan Okta adalah salah satu dari rangkaian serangan dalam beberapa tahun terakhir yang menargetkan penyedia software dan layanan dengan basis pelanggan besar
  • Penyerang membobol penyedia, lalu memanfaatkan posisi itu untuk melakukan serangan lanjutan yang menargetkan perusahaan pelanggan
  • Ada kemungkinan lebih banyak pelanggan Okta akan teridentifikasi ke depannya

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-25
Komentar Hacker News

  • Menyerahkan SSO ke pihak eksternal bukan sekadar soal apakah secara teknis lebih mudah atau apakah ada kemampuan operasional. Faktor besarnya adalah perusahaan bisa menulis dalam kontrak pelanggan bahwa mereka memakai penyedia SSO bereputasi baik, dan penyedia itu juga menanggung tanggung jawab dokumentasi terkait cara pengelolaan kunci dan perlindungan material kunci
    1Password kemungkinan besar sudah memiliki kerangka seperti itu, jadi kasusnya agak tidak biasa, tetapi biasanya jauh lebih mudah mengatakan “tidak ada siapa pun di organisasi yang bisa mengakses kunci” daripada “Bob adalah pengecualian; dia menjalankan server SSO dan kami memercayainya”

    • Apa yang membuat Okta lebih baik daripada “kami memercayai Bob”? Itu berarti memercayai orang-orang yang sama sekali tidak dikenal, dan mereka sudah menyebabkan beberapa insiden keamanan besar yang terkenal
    • Saya setuju dari sisi pesan/komunikasi, tetapi dari sisi keamanan yang sebenarnya, bagaimana dengan Bob di pihak penyedia layanan?

  • Menarik bahwa kerentanan keamanan memori di C paling sering dibicarakan, tetapi dalam praktiknya dampak yang besar sering kali justru berasal dari runtuhnya wawasan akibat kompleksitas berlebihan saat mengikuti apa yang disebut desain praktik terbaik

    • Orang-orang yang mengkritik C yang tidak aman sering kali berada di kubu yang sama dengan mereka yang kemudian menciptakan monster Bizantium lagi. Sepertinya ada insentif yang sudah dinormalisasi untuk mengubah perangkat sederhana menjadi mesin Rube Goldberg agar pekerjaan tetap ada
    • Bug organisasi bisa berdampak besar pada organisasi tersebut, tetapi bug keamanan memori biasanya dapat dieksploitasi secara otomatis dan memengaruhi semua organisasi yang memakai perangkat lunak itu. Heartbleed banyak dibahas juga karena dampaknya memang besar
    • Pada akhirnya ini soal kompleksitas. Ada hal yang terlewat, dan ketika sesuatu diperbarui, efek berantainya terhadap logika lain tidak terlihat. Kompleksitas melahirkan kerentanan, tetapi pertahanan keamanan berlapis dan langkah penanggulangan dapat mengurangi risiko
      Menurut saya akar penyebabnya adalah keterbatasan manusia dalam memahami kompleksitas yang sangat besar
    • Apa yang bisa diukur cenderung dioptimalkan. Untuk kerentanan perangkat lunak, ada data numerik yang mudah dikumpulkan, tetapi informasi tentang bagaimana data dicuri dari organisasi, dan kadang bahkan kapan data itu dicuri, masih kurang
      Yang terakhir kemungkinan besar rumit karena melibatkan manusia, sehingga lebih mudah mencari penyelamatan lewat teknologi
    • Saya penasaran apa itu “runtuhnya wawasan”. Kedengarannya seperti konsep yang sangat menarik

  • Dari bagian yang mengatakan, “Kami mengganti semua kredensial sistem milik anggota tim IT, dan mengubah MFA agar hanya menggunakan Yubikey,” semoga ini menjadi pemicu agar seluruh karyawan menggunakan autentikasi dua langkah berbasis Yubikey. Apa pun di bawah FIDO2 benar-benar lemah
    Saya penasaran kenapa orang masih memilih Okta. Secara pribadi, memakai GSuite sebagai penyedia ID terasa jauh lebih nyaman. Okta pernah mengalami pelanggaran yang cukup serius, dan sejujurnya bahkan sebelum itu pun saya tidak pernah mendengar hal baik tentang praktik keamanannya

    • Yubikey atau MFA berbasis browser lainnya tidak akan mencegah serangan ini. Sebab penyerang mendapatkan token sesi admin yang valid setelah MFA selesai
      Mewajibkan MFA berbasis hardware adalah praktik yang baik dan bisa mencegah serangan seperti spear phishing di masa depan, tetapi tidak berkaitan dengan insiden ini sendiri
      Orang memilih Okta kira-kira seperti “tidak ada orang yang dipecat karena membeli IBM.” Kalau menjalankan Keycloak sendiri lalu kebobolan, itu tanggung jawab saya; tetapi kalau Okta, strukturnya menjadi outsourcing sehingga itu bukan masalah saya, dan faktor ini juga berperan
    • Yang dicuri adalah cookie sesi, dan autentikasi dua langkah tidak ada hubungannya dengan masalah ini
      Saya ragu apakah Anda pernah benar-benar memakai Google Workspace untuk penggunaan serius. Itu salah satu penyedia ID yang paling minim fitur, sedangkan Okta termasuk yang paling kaya fitur. Membandingkan keduanya hanya karena sama-sama punya dua roda itu seperti membandingkan sepeda dengan sepeda motor
      Saya tidak menyangka akan melihat Google Workspace direkomendasikan sebagai penyedia ID di forum teknis
    • Kebanyakan orang tidak memilih Okta. Seseorang di level eksekutif memilih Okta, lalu yang lain harus menanggung akibatnya
      Kalau memakai Yubikey, semua masalah dukungan pelanggan terkait kata sandi akan ditangani departemen IT internal, bukan vendor outsourcing
      MFA punya masalah teknis dan masalah sosial; aspek keamanan teknis dari implementasi seperti key, token, ponsel, atau SMS sebenarnya hampir sepele, sementara masalah sosial seperti dukungan pelanggan, kata sandi yang hilang, key yang masuk mesin cuci, atau tidak bisa menerima email jauh lebih besar
      Semua orang ingin mengalihdayakan peran dukungan pelanggan yang besar dan bodoh dalam keamanan, tetapi setelah itu semua pihak terdorong untuk menekan biaya. Hasilnya adalah Okta
    • Memakai GSuite sebagai penyedia ID sangat terbatas. Ia memang memenuhi checkbox “ini penyedia ID”, tetapi begitu melampaui sekadar “bisa terhubung”, semuanya menjadi sulit atau mustahil
      Misalnya, untuk memberi akses ke organisasi AWS bagi organisasi yang semua karyawannya ada di GSuite, cara yang direkomendasikan adalah AWS SSO[1]. Setelah koneksi disiapkan, akses memang bisa dilakukan, tetapi ada celah
      Tidak ada fitur untuk secara otomatis memprovisi atau menghapus pengguna di AWS SSO berdasarkan grup pengguna GSuite. Dengan dukungan SCIM di SSO, Anda bisa menulis kode sendiri, tetapi harus memeliharanya
      Tidak ada cara untuk mewajibkan pemeriksaan MFA saat membuat sesi SSO, baik di sisi GSuite maupun AWS SSO. GSuite tidak bisa mewajibkan pemeriksaan MFA sebelum autentikasi aplikasi SAML, dan AWS SSO juga tidak bisa memaksa pemeriksaan MFA jika memakai penyedia ID, berbeda dengan saat memakai Directory internal
      Okta dan produk sejenis melakukan hal-hal seperti ini, dan katanya juga bisa menerapkan pemeriksaan MFA bergantung pada endpoint yang digunakan. Saya belum mencobanya sendiri; ini berdasarkan materi pemasaran dan penjelasan sales
      Singkatnya, Okta menyediakan jauh lebih banyak perekat otomatisasi dan keamanan antara penyedia ID dan aplikasi yang digunakan
      [1] Di sini AWS SSO berarti produk AWS “AWS IAM Identity Center (Successor to AWS Single Sign-On)”
    • Apakah ada bukti bahwa Okta lebih baik atau lebih buruk daripada solusi lain? Pengukuran keamanan sangat sulit
      Bukti yang terlihat saat ini hanya sebatas Okta mengalami pelanggaran tahun lalu, kembali mengalami pelanggaran kali ini, dan pelanggaran kali ini terjadi di departemen atau sistem dukungan pelanggan. Pengungkapan pelanggaran mungkin terlambat, tetapi bisa juga karena banyaknya laporan palsu sehingga mereka belum menemukan bukti sampai baru-baru ini. Mereka tidak memberi kredit kepada pelanggan yang pertama kali melapor, dan mungkin tidak berkomunikasi dengan baik dengan pelanggan setelah laporan itu
      Yang tidak kita ketahui jauh lebih banyak. Kita tidak tahu seberapa terampil penyerangnya, berapa kali masing-masing penyedia ID dibobol, berapa kali mereka mendeteksinya, apakah ada yang dideteksi lalu ditutup-tutupi, seberapa banyak dan seberapa parah bug keamanan di tiap layanan serta seberapa mudah ditemukan, seperti apa kemampuan deteksi pelanggarannya, seberapa baik pelatihan karyawannya, atau berapa proporsi karyawan yang benar-benar peduli pada keamanan
      Kita tidak bisa menyimpulkan produknya lebih buruk hanya karena Okta melaporkan pelanggaran. Kita tidak tahu seberapa bagus produk lain, dan mungkin saja Okta lebih baik daripada sebagian atau semua pesaingnya, meskipun tentu bisa juga lebih buruk

  • Dulu saya membeli 1Password dengan harga penuh, dan perangkat lunaknya berjalan sepenuhnya offline sambil menyimpan vault terenkripsi secara lokal atau di Dropbox. Karena tidak ada yang bisa dicuri secara online, saya tidak perlu khawatir soal peretas
    Lalu seseorang menghitung-hitung, dan memutuskan bahwa jalan untuk meningkatkan profitabilitas adalah memindahkan data semua orang ke cloud dan menarik biaya berlangganan. Dan sekarang kita khawatir apakah data sudah bocor

    • Benar juga bahwa kenyamanannya meningkat banyak bagi orang-orang yang tidak cukup terampil untuk mengurusnya sendiri
      Dan sejauh yang kita tahu sekarang, seberapa berbeda ini dengan menaruh vault di Dropbox? Dropbox juga bisa diretas, dan data di sana terkenal tidak terenkripsi. Bukankah belum ada kasus yang kita ketahui di mana vault 1Password benar-benar dibobol?

  • https://blog.1password.com/okta-incident/
    Laporan insiden asli: https://blog.1password.com/files/okta-incident/okta-incident...

    • Bagian yang menarik. Saat seorang anggota tim IT bekerja dengan tim dukungan Okta, atas permintaan mereka ia membuat file HAR di Chrome Developer Tools dan mengunggahnya ke portal dukungan Okta. File ini berisi catatan semua lalu lintas antara browser dan server Okta, termasuk informasi sensitif seperti cookie sesi
      Setelah itu, aktor tak dikenal mengakses portal admin Okta menggunakan sesi Okta yang sama dengan yang dipakai saat file HAR tersebut dibuat
      Seperti yang selalu dikatakan bank, jangan berikan kata sandi Anda kepada petugas dukungan

  • Kali ini tanggung jawabnya jelas ada pada Okta. Saat meminta sesi HAR terenkripsi sebagai teks polos untuk menyelesaikan masalah, mereka hanya berharap pengguna akhir membersihkannya dengan benar
    Bukankah seharusnya data HAR dibersihkan saat diunggah, sehingga ketika masuk ke sistem dan dilihat oleh teknisi dukungan yang bergaji rendah serta kekurangan staf, yang tersisa hanya bagian yang relevan dan aman?
    HAR adalah data terstruktur, jadi sangat mudah dibersihkan dengan program. Ini bukan ilmu roket

  • Orang-orang terus bertanya mengapa ada yang memakai pengelola kata sandi yang di-host sendiri dan disinkronkan sendiri alih-alih layanan online yang supermudah dan superramah; alasannya sama. Sama seperti Anda tidak melempar kunci apartemen ke brankas di stasiun kereta lingkungan

    • Dengan begitu Anda mungkin merasa lebih aman, tetapi belum tentu benar-benar demikian. Jika penyerang yang berdedikasi bisa menembus Okta, mereka juga sangat mungkin bisa menembus pengelola kata sandi self-hosted Anda yang mungkin lupa Anda perbarui tepat waktu, atau pembaruannya datang terlambat
      Organisasi seperti ini memperbaiki masalah berminggu-minggu, kadang berbulan-bulan, sebelum mengeluarkan pernyataan
      Jika Anda memakai open source lalu ditemukan bug kritis, Anda akan mendapat patch bersamaan dengan siaran pers, tetapi layanan besar kemungkinan besar sudah memperbaiki masalah itu. Bagi pengguna rata-rata, rasio risiko terhadap manfaat lebih condong ke solusi berbasis layanan
    • Itu tidak relevan. Kata sandi di 1Password dienkripsi dengan kunci yang hanya dimiliki pengguna. Sangat meragukan apakah server rumahan pribadi bisa dijaga lebih aman daripada server 1Password
    • Saya juga memakai alat baris perintah pass + git, dan sejauh ini belum pernah ada masalah sekali pun
      Bisa dipakai di skrip juga
      Tidak ada kompromi server, tidak ada kerentanan ekstensi web, dan tidak ada risiko kehilangan semua kata sandi karena kesalahan server. Pokoknya berfungsi dengan baik
    • Saya paham intinya, tetapi kalau vault kata sandinya berupa perangkat lunak self-hosted dan file vault self-hosted, rasanya saya akan khawatir soal kehilangan data setiap hari
    • Penasaran Anda memakai apa

  • Kalimat “1Password menjadi pelanggan Okta kedua yang diketahui menjadi target serangan lanjutan” terasa aneh. Apakah Ars tidak tahu Cloudflare juga korban?
    https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...

    • Sepertinya maksudnya BeyondTrust melaporkan masalahnya, Cloudflare adalah pelanggan Okta pertama yang diketahui menjadi target serangan, dan 1Password yang kedua

  • Saya penasaran dengan praktik terbaik untuk memantau perilaku mencurigakan di aplikasi. Saya paham hal-hal dasar seperti memeriksa request rate atau error rate di lingkup layanan, tetapi dalam praktiknya seberapa canggih ini bisa menjadi?
    Saya penasaran apakah ada alat cerdas yang, jika diberi event stream, bisa menemukan perilaku anomali, atau apakah kita harus memikirkan semua hal yang perlu dipantau terlebih dahulu lalu menambahkan aturan

    • Saya orang awam rumahan tanpa pengalaman di bidang ini, jadi jangan ditelan mentah-mentah. Prioritasnya adalah audit trail. Semua tindakan yang dilakukan pada akun pengguna atau data, serta semua perubahan pada sistem, harus ada di audit log dengan timestamp, pengguna, dan sebagainya. Terutama hal-hal seperti perubahan kata sandi atau detail akun
      Setelah event stream seperti ini ada, Anda bisa menjalankan alat analisis data. Buat baseline normal dari aktivitas selama beberapa hari, minggu, atau bulan, lalu buat perilaku yang mencolok—seperti perubahan kata sandi massal atau perubahan email—memicu peringatan
      Namun ini hanya hipotesis orang rumahan, jadi saya penasaran apakah ada orang yang benar-benar pernah menangani audit log dan pemanfaatannya
    • Ini ide startup AI yang lumayan. Jadikan Security as a Service: proksikan semua permintaan melalui layanan pihak ketiga dan biarkan mereka mendeteksi anomali. Tapi kalau mereka gagal mendeteksi, layanan itu mungkin tidak akan bertanggung jawab
    • https://www.obsidiansecurity.com/

  • Terdeteksi lagi?
    https://news.ycombinator.com/item?id=37991863