13 poin oleh GN⁺ 2024-10-13 | 2 komentar | Bagikan ke WhatsApp
  • Seorang remaja 15 tahun yang gemar berburu bug di waktu luangnya menemukan bug terkait verifikasi email di Zendesk, yang digunakan oleh perusahaan-perusahaan Fortune 500
  • Ia melaporkan hal ini ke berbagai perusahaan dan menghasilkan lebih dari $50.000, tetapi tulisan ini memperkenalkan proses ketika Zendesk menambal bug tersebut namun sama sekali tidak memberi imbalan kepada pelapornya

Pengenalan Zendesk

  • Zendesk adalah alat layanan pelanggan yang digunakan oleh perusahaan-perusahaan terkemuka di dunia
  • Jika email dukungan dihubungkan ke Zendesk, Zendesk akan mengelola email yang masuk dan membuat tiket
  • Cukup mengejutkan bahwa banyak perusahaan besar mengandalkan Zendesk alih-alih membangun sistem tiket mereka sendiri

Mata rantai terlemah

  • Seperti ungkapan "kekuatan hanya sekuat mata rantai terlemahnya", Zendesk sering dianggap sekadar alat tiket sederhana dan digunakan tanpa konfigurasi yang cermat
  • Jika domain @company.com digunakan untuk single sign-on (SSO) dan dihubungkan ke Zendesk, celah keamanan bisa muncul
  • Karena Zendesk memproses email domain tersebut, jika sistem SSO tidak memverifikasi alamat email dengan benar, siapa pun yang mendapat akses ke Zendesk dapat menyalahgunakan sistem internal.

Email spoofing

  • Ditemukan kerentanan serius di Zendesk, yang memungkinkan penyerang membaca tiket dukungan pelanggan milik perusahaan yang menggunakan Zendesk
  • Zendesk tidak memiliki perlindungan yang efektif terhadap email spoofing
  • Jika penyerang mengetahui alamat email dukungan dan ID tiket, mereka dapat menggunakan email spoofing untuk menyamar sebagai pengirim asli dan mengakses tiket
  • Penulis melaporkan bug tersebut, tetapi pada awalnya Zendesk tidak tertarik
    • Mereka menjawab bahwa email spoofing (isu SPF, DKIM, DMARC) berada di luar cakupan
  • Laporan diproses melalui layanan HackerOne, dan ketika diminta untuk melapor langsung ke anggota tim Zendesk, permintaan itu ditolak

Memperluas isu ini menjadi pengambilalihan Slack

  • Bug email spoofing ini bisa saja dilaporkan ke masing-masing perusahaan, tetapi penulis ingin memberikan dampak yang lebih besar
  • Di masa lalu, ada kasus peneliti lain yang berhasil menyusup ke Slack ratusan perusahaan melalui Zendesk (TICKETTRICK)
  • Penulis mencoba mereproduksi hal tersebut menggunakan bug miliknya, tetapi menghadapi beberapa kesulitan
  • Slack telah mengubah metode verifikasinya dengan menambahkan token acak ke alamat email
  • Namun, saat login dengan Apple ID menggunakan OAuth, token tersebut tidak digunakan sehingga bisa dilewati

Langkah reproduksi: Apple → Zendesk → Slack

  1. Buat Apple ID dengan support@company.com dan minta kode verifikasi, maka tiket Zendesk akan dibuat
  2. Buat tiket dengan email sendiri di portal dukungan company.com untuk melacak rentang ID
  3. Dengan bug email spoofing, coba tambahkan diri sendiri ke semua tiket dalam rentang ID tersebut
  4. Login ke portal dukungan perusahaan itu dengan akun daniel@wearehackerone.com dan periksa tiket yang di-CC
  5. Masukkan kode verifikasi ke Apple ID
  6. Gunakan fitur "Masuk dengan Apple" milik Slack untuk login dengan Apple ID yang terhubung ke email @company.com, lalu login ke Slack
    Penulis menerapkan 6 langkah ini ke ratusan instance Zendesk dan Slack

Dampak insiden

  • Selama seminggu, penulis melaporkan kerentanan ini ke masing-masing perusahaan; beberapa segera mengambil tindakan, tetapi ada juga yang mengklaim ini adalah masalah Zendesk
  • Setelah beberapa perusahaan menghubungi Zendesk, Zendesk akhirnya meminta agar laporan ini tetap dirahasiakan dan meminta langkah reproduksi untuk kerentanan Slack
  • Setelah PoC pengambilalihan Slack diberikan, Zendesk mengonfirmasi masalah tersebut, tetapi butuh 2 bulan untuk memperbaikinya
  • Banyak perusahaan melindungi instance mereka dengan menonaktifkan fitur kolaborasi email
  • Melalui laporan bug bounty ini, penulis menerima hadiah lebih dari $50.000 dari masing-masing perusahaan di HackerOne dan platform lainnya
  • Beberapa perusahaan memutus kontrak mereka dengan Zendesk

Perbaikan Zendesk dan bounty $0 untuk saya

  • Setelah 2 bulan, Zendesk mengonfirmasi bahwa masalah telah diselesaikan
  • Mereka menggunakan filter spam Cloudmark dan Rspamd EAP, tetapi karena skor Rspamd tidak dimanfaatkan, banyak email tidak ditahan
  • Awalnya, perbaikan dilakukan dengan beralih otomatis ke Rspamd dalam kondisi tertentu
  • Setelah itu, mereka menerapkan filter yang secara otomatis menahan email verifikasi dari Apple dan Google
  • Meskipun masalah telah diperbaiki, Zendesk pada akhirnya memutuskan untuk tidak membayar hadiah untuk laporan bug bounty ini
    • Karena penulis membagikan kerentanan tersebut kepada perusahaan-perusahaan yang terdampak, sehingga dianggap melanggar pedoman pengungkapan HackerOne

Kesimpulan

  • Bug email kecil dapat berujung pada penyusupan ke sistem internal perusahaan-perusahaan terbesar di dunia
  • Zendesk pada akhirnya memperbaiki kerentanan tersebut, tetapi proses penolakan, respons lambat, dan pengabaian membuat semuanya terasa berat
  • Itulah realitas bug hunting: kadang menang, kadang kalah

Pendapat GN⁺

  • Kasus Zendesk menunjukkan risiko mengadopsi solusi pihak ketiga tanpa evaluasi kritis. Seberapa pun terkenal produknya, peninjauan keamanan tetap wajib.
  • Pengambilalihan sistem internal perusahaan besar dapat menimbulkan kerugian besar, sehingga respons lambat Zendesk sangat tidak bertanggung jawab. Penolakan pembayaran bounty yang mematahkan semangat peneliti keamanan juga tidak diinginkan.
  • Perusahaan perlu memilih domain SSO dengan hati-hati dan memperkuat proses verifikasi email. Teknologi autentikasi email seperti DMARC, SPF, dan DKIM perlu dimanfaatkan secara aktif.
  • Pedoman pengungkapan HackerOne dari sudut pandang peneliti terasa terlalu kaku. Karena kerentanan serius perlu dibagikan dengan cepat, penerapan yang lebih fleksibel sesuai situasi tampaknya diperlukan.
  • Bug hunting seharusnya menjadi win-win bagi perusahaan dan peneliti. Diharapkan budaya yang menghormati niat baik dan usaha peneliti serta memberi kompensasi yang layak bisa terbentuk.

2 komentar

 
aer0700 2024-10-13

Kalau melihat isu seperti ini, rasanya untuk solusi terkait keamanan jauh lebih baik merekrut dan membina ahli keamanan sendiri daripada sekadar memakai solusi jadi T_T

 
GN⁺ 2024-10-13
Opini Hacker News
  • Seorang pengguna menyebut bahwa pada Juni 2024 ia melaporkan bug yang sama ke Zendesk, Apple, dan Slack, dan alasan mereka kemungkinan tidak memberi imbalan adalah karena dia bukan yang pertama menemukannya

    • Opsi SSO non-direktori, Sign in with Apple (SIWA), diimplementasikan secara keliru, dan hal ini juga terjadi di perusahaan besar seperti Slack
    • SSO non-direktori tidak bisa memiliki tingkat kepercayaan yang sama dengan SSO direktori, dan penyedia SSO tidak saling dapat dipertukarkan meskipun menggunakan alamat email yang sama
  • Pengguna lain menuduh Zendesk membuat band palsu bernama "Zendesk Alternative" untuk mencemari hasil pencarian Google

    • Disebutkan bahwa ini mungkin tidak ilegal, tetapi merupakan tindakan manipulatif yang menunjukkan pola pikir mereka
  • Seorang pengguna mengatakan mengecewakan bahwa Zendesk menolak memberi imbalan untuk bug tersebut, dan menyebut ini sebagai cara agar orang enggan ikut program hadiah besar

    • Ia menambahkan bahwa pengalaman wawancaranya dengan Zendesk sangat buruk
  • Pengguna lain menyebut program bug bounty yang tidak efisien berdampak negatif pada layanan perangkat lunak

    • Ia berpendapat Zendesk seharusnya memberi imbalan, meminta maaf, dan memperbaiki programnya
  • Seorang pengguna mengkritik bahwa meskipun Zendesk adalah perusahaan dengan pendapatan 1,3 miliar dolar, mereka tetap tidak memberi imbalan, yang menunjukkan pandangan jangka pendek

    • Ia menyebut ini bukan keputusan yang rasional, dan bahwa modal privat sedang memangkas biaya sambil mengikis merek
  • Pengguna lain menjelaskan bahwa Zendesk mungkin mengabaikannya karena tidak benar-benar memahami dampak bug tersebut

    • Ia menyebut banyak kerentanan bisa terlihat hanya sebagai bug biasa jika dampaknya tidak jelas
  • Seorang pengguna menunjukkan bahwa Zendesk hanya memperbaiki masalah email verifikasi akun Apple, tetapi tidak menyelesaikan masalah mendasarnya

    • Ia menyebut dalam pengaturan default, siapa pun yang mengetahui email dan ID tiket bisa berpotensi mengambil alih tiket dukungan
  • Dijelaskan bahwa ada dua kerentanan terpisah

    • Zendesk awalnya mengizinkan balasan dikirim dari alamat email peminta asli sambil menambahkan CC
    • Slack mengizinkan login seluruh domain melalui Sign in with Apple tanpa verifikasi tambahan
  • Zendesk dikritik karena mengabaikan masalah tersebut dan berusaha merahasiakannya

    • Disebutkan bahwa ini adalah sikap yang tidak profesional, dan bisa menjadi alasan mengapa mereka tidak memberi imbalan
  • Terakhir, seorang pengguna mengkritik Zendesk karena menolak memberi imbalan untuk bug tersebut, sambil menekankan bahwa pelapor telah menjalani semua prosedur dengan benar