Pengalihan terbuka di aplikasi Harvest memungkinkan pencurian token OAuth akun Microsoft

 (eval.blog)
1 poin oleh GN⁺ 2023-10-23 | 1 komentar | Bagikan ke WhatsApp
  • Dalam alur koneksi OAuth Outlook Calendar milik Harvest, URL callback diarahkan kembali ke tujuan dari nilai state, sehingga terjadi pengalihan terbuka, dan jika digabungkan dengan alur pemberian implisit, token dapat terekspos ke URL eksternal
  • Masalahnya bukan pada Microsoft, melainkan pada sisi integrasi Harvest; redirect_uri OAuth yang terdaftar menjadi titik transit pengalihan yang mengirim pengguna ke domain yang ditentukan penyerang
  • state adalah JSON yang dienkode sebagai URI, dan jika domain eksternal dengan garis miring seperti example.com/ dimasukkan ke subdomain, pengguna akan diarahkan ke bentuk seperti example.com/.harvestapp.com/...
  • PoC menunjukkan alur di mana fragmen #id_token=... ditambahkan ke target pengalihan, dengan menggunakan client_id=0dcef4db-36d8-4aed-9cc5-ab43e1814884, response_type=id_token, response_mode=fragment, scope=openid pada URL authorize Microsoft OAuth
  • Kerentanan ini dilaporkan pada 23 Agustus 2020, patch dikonfirmasi pada 1 Agustus 2023, dan pada 22 Oktober 2023 Harvest meminta maaf dengan menyebut keterlambatan tersebut sebagai human error

Alur kebocoran token dari callback OAuth

  • Harvest adalah perangkat lunak pelacakan waktu yang memungkinkan pengguna menghubungkan Outlook Calendar melalui OAuth
  • Jika otorisasi berhasil, pengguna diarahkan ke https://outlook-integration.harvestapp.com/auth/outlook-calendar/…
  • Callback ini kemudian memindahkan pengguna lagi ke URL yang diberikan di dalam state, dan dalam proses itu terjadi pengalihan terbuka
  • Nilai state pada URL callback yang awalnya dikonfirmasi adalah JSON yang dienkode sebagai URI
    • Setelah didekode, bentuknya adalah {"return_to":"/","subdomain":"hackerone295"}
    • Nilai subdomain digunakan untuk memperkirakan ruang aplikasi Harvest seperti hackerone295.harvestapp.com
  • Jika subdomain diberi garis miring seperti example.com/, URL callback akan menjadi bentuk yang berpindah ke domain eksternal
  • Karena URL callback ini adalah redirect_uri yang terdaftar pada aplikasi OAuth, jika pengalihan terbuka digabungkan dengan alur pemberian implisit, token dapat terekspos ke target pengalihan
  • URL authorize PoC menggunakan nilai berikut
  • Pengguna pada akhirnya diarahkan ke bentuk seperti berikut
  • Ini bukan kerentanan di sisi Microsoft

Waktu dari pelaporan hingga patch

  • Tim Harvest sangat minim memberi respons dalam proses pengungkapan dan patch kerentanan, dan meski kerentanan sudah diakui melalui triage, perbaikannya memakan waktu lama
  • Kerentanan dilaporkan pada 23 Agustus 2020, dan Harvest pertama kali menghubungi pada 16 Oktober 2020
  • Pada 27 November 2020, laporan masuk status triaged
  • Pada 28 April 2022, perusahaan mengatakan sedang melakukan perbaikan dan menyebut estimasi waktu 2 minggu, tetapi hingga perbaikan benar-benar dilakukan masih butuh sekitar 1 tahun lagi
  • Pada 1 Agustus 2023, patch kerentanan dikonfirmasi
  • Pada 21 Oktober 2023, laporan dipublikasikan melalui tulisan publik
  • Per tanggal yang sama, laporan masih berstatus triage, dan meski kebijakan bug bounty menyebutkan imbalan, tidak ada bounty maupun poin HackerOne yang diberikan
  • Setelah tulisan tersebut mendapat perhatian pada 22 Oktober 2023, Harvest meminta maaf dan menjelaskan bahwa keterlambatan itu disebabkan oleh human error

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-23
Opini Hacker News

  • Sebagai penanggung jawab program bug bounty, saya akan menjelaskan apa yang terjadi secara internal. Saya sudah meminta maaf kepada @0xcrypto dan menjelaskannya secara internal, tetapi saya rasa tepat juga untuk merangkumnya di sini
    Sejak awal kami tidak bisa mereproduksi masalah ini sepenuhnya, dan kami juga tidak bisa menutupnya karena khawatir ada sesuatu yang terlewat. Tepat setelah jawaban terakhir kami bahwa “kami akan mencari solusi”, kami sudah hampir menyimpulkan bahwa masalah ini tidak dapat direproduksi, lalu ada laporan terkait OAuth yang mirip masuk sehingga terjadi kebingungan internal dan kami keliru mengira laporan ini sudah ditangani dan diteruskan
    Karena pengaturan notifikasi, kami melewatkan pesan lanjutan, dan isu ini tetap berada dalam status Triage tanpa batas waktu tanpa pembaruan. Ini bukan alasan; saya sendiri sudah lama aktif sebagai pemburu bug bounty, jadi saya tahu betul betapa frustrasinya menunggu pembaruan dari perusahaan. Keamanan pelanggan adalah prioritas utama, dan apa yang tertulis di halaman keamanan kami benar adanya

    • Kesalahan memang bisa terjadi, tetapi masih belum dijelaskan mengapa, meski sudah beberapa kali menghubungi HackerOne selama 3 tahun, HackerOne tetap tidak bisa menghubungi Harvest
      Selain itu, sekarang juga belum jelas bagaimana laporan yang tidak dapat direproduksi lagi ini akan ditangani. Saya ingin membahasnya lebih lanjut di HackerOne, tetapi setelah pesan permintaan maaf, tampaknya kembali tanpa respons
    • Saya penasaran apakah pada akhirnya Anda percaya bahwa kerentanan itu benar-benar bekerja seperti yang dijelaskan, dan jika ya, mengapa gagal direproduksi
    • Senang bisa mendengar penjelasan langsung. Meski tidak bisa direproduksi, rasanya cukup mudah memastikan dari kode sumber apakah open redirect memungkinkan atau tidak
    • Setidaknya bagus bahwa Anda mengunggah tulisan yang menunjukkan bahwa ini dianggap serius. Siapa pun bisa membuat kesalahan, tetapi jika tidak bertanggung jawab saat kesalahan terjadi, masalahnya akan membesar
    • Saya menggunakan Harvest dengan baik, tetapi saya berharap aplikasi mobile baru di iOS juga segera diperbaiki. Ada terlalu banyak masalah kecil sampai saya berhenti melaporkannya ke tim dukungan
      Status aplikasi sering tidak sinkron dengan status server, dan perubahan di server baru terlihat setelah refresh paksa, atau perubahan di klien kembali seperti semula setelah disimpan. Pengalaman pengguna untuk pelacakan waktu juga tidak nyaman: tombol baru terlihat setelah menggulir, atau posisi tombol mulai/berhenti/mulai ulang/hapus terus berubah tergantung status item. Aplikasi lama memang tidak cantik, tetapi berfungsi tanpa masalah

  • Cukup mengkhawatirkan. Saat saya menggunakan Harvest, dukungannya benar-benar luar biasa, responsnya cepat, mereka memahami secara mendetail bagaimana pelanggan memakai produknya, dan juga menjelaskan secara rinci cara memanfaatkan fitur yang ada secara kreatif
    Untuk fitur yang belum diimplementasikan, jawabannya adalah “akan kami masukkan ke backlog, tetapi tidak bisa dijamin”. Disebutkan bahwa jumlah staf engineering adalah 30 orang [1], tetapi saya tidak begitu tahu tenaga itu dipakai untuk apa, karena saya juga tidak melihat fitur lain dirilis dengan cepat
    Sebagai “pengguna Harvest”, saya mulai menerima spam sehingga curiga apakah mereka menjual daftar pelanggan, tetapi para penanggung jawab perusahaan langsung menghubungi, membantah keras, dan menanganinya dengan serius sampai segera melakukan investigasi. Itu bagus
    Namun pada akhirnya ini juga tampak seperti masalah engineering. Saya menemukan cara yang cukup mudah untuk memperkirakan pelanggan aktif, dan ini juga masuk ke “backlog” lalu belum diperbaiki selama berbulan-bulan. Perbaikannya tampak sangat sepele. Selain itu, MFA hanya disediakan saat login dengan Google [2]. Meski begitu, aplikasinya sendiri benar-benar sangat baik untuk tugas utamanya
    1: https://www.getharvest.com/about/meet-the-team
    2: https://support.getharvest.com/hc/en-us/articles/36005266713...

    • Terima kasih atas penilaian yang baik. Saya jelas setuju bahwa tim dukungan kami hebat. Tim kami kecil, tetapi menangani semua hal dengan sangat serius, dan juga terlibat langsung dalam investigasi yang disebutkan tadi
      Miskomunikasi dengan pelapor di thread ini sepenuhnya adalah kesalahan saya, dan seperti yang saya jelaskan di jawaban teratas, saya akan memastikan hal seperti ini tidak terjadi lagi
    • Saya tidak tahu apakah ini memuji atau mengkritik. Apakah ini sarkasme?
    • Kualitas dukungannya memang jelas bagus. Permintaan selalu ditangani oleh orang-orang yang sangat ahli, dan biasanya saya mendapat jawaban dalam hitungan menit
      Beberapa permintaan fitur bahkan masuk ke produk nyata. Mungkin bukan karena pengaruh saya, tetapi setidaknya tampaknya kami punya pemikiran yang mirip tentang pelacak waktu yang baik

  • Judulnya terasa cukup tidak adil terhadap Microsoft. Rasanya seperti memanfaatkan perhatian yang baru-baru ini tertuju pada Microsoft karena insiden autentikasi, dan begitu melihat judulnya saya langsung berpikir, “apakah ini pelanggaran MS lagi?”
    Padahal sebenarnya itu adalah token Harvest, dan karena kerentanan injeksi pada kode Harvest, hanya hak akses aplikasi Harvest yang terekspos secara keliru. Kerentanannya akan sama saja meski berada di balik penyedia identitas lain

    • Saya penulis posting blog tersebut. Saya memahami kekhawatiran itu dan sempat ingin menghapus nama Microsoft dari judul, tetapi tidak terpikir ungkapan yang pas
      Kerentanan ini hanya berdampak pada implementasi OAuth untuk koneksi akun Microsoft. Judul awalnya adalah “Microsoft OAuth token leak via open redirect in Harvest App”, lalu saya ubah menjadi “Microsoft Account's OAuth tokens leaking via open redirect in Harvest App”. Saya masih berniat mengubahnya dan menerima saran
    • Saya juga berpikir begitu. Bahkan sampai bertanya-tanya apakah penulis benar-benar memahami cara kerja OAuth tetapi tetap menyebut ini token MS

  • RFC 6749 membahas secara rinci cara server otorisasi mencegah serangan seperti ini
    Server otorisasi wajib mengharuskan klien publik mendaftarkan URI pengalihan, dan sebaiknya juga mengharuskannya untuk klien rahasia. Jika URI pengalihan disediakan dalam permintaan, server otorisasi harus memverifikasinya dengan mencocokkannya terhadap nilai yang terdaftar
    Kalau begitu, aplikasi Harvest seharusnya tidak mendaftarkan redirect_uri berbahaya; jadi saya penasaran bagaimana ini bisa terjadi. Apakah server OAuth Microsoft mengabaikan parameter URL di dalam redirect_uri saat membandingkannya dengan URI pengalihan terdaftar milik klien OAuth?

    • Sepertinya mereka menumpangkan redirect kedua di atasnya dan memasukkannya ke parameter state. Mungkin tujuannya memang untuk mengalihkan ke mana saja
      Alur yang dimaksud kira-kira: masuk ke URL otorisasi Harvest → dialihkan ke URL otorisasi Microsoft dengan redirect_uri=registered_uri dan state=some_encoded_final_uri → pengguna memasukkan kredensial → dialihkan ke URI terdaftar → membaca state lalu mengalihkan lagi ke URI di dalamnya
      Serangan ini tetap mengalihkan ke URI yang diizinkan, tetapi endpoint tersebut membaca state dan meneruskan respons/token apa adanya. Ada tiga kesalahan: penyalahgunaan state, jika memang mau disalahgunakan seharusnya state dienkripsi dan diverifikasi, serta mengaktifkan implicit grant. Jika diperlukan, seharusnya dibuat pendaftaran terpisah untuk penggunaan yang terbatas
    • redirect_uri milik Harvest terdaftar di Microsoft. Setelah server OAuth Microsoft mengalihkan ke Harvest, Harvest mengimplementasikan redirect-nya sendiri berdasarkan data di state

  • Implicit grant cukup mengerikan karena alasan seperti yang terlihat di tulisan ini
    Sebagai catatan, ini akan dihapus dalam spesifikasi OAuth 2.1 yang segera hadir: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm...

    • Bukankah ini sudah direncanakan untuk dihentikan sejak sekitar 6 tahun lalu? CORS sudah menggantikan kegunaannya, jadi tidak ada alasan untuk mempertahankannya di spesifikasi baru

  • Maksudnya butuh 3 tahun untuk memperbaiki kerentanan ini? Dari Agustus 2020 sampai Agustus 2023, saya tidak tahu seberapa besar tim Harvest, tapi ini tetap terlihat benar-benar tidak masuk akal

    • Seperti yang umum terjadi di banyak perusahaan, mungkin masuk backlog dengan prioritas rendah, lalu melewati beberapa kali penataan ulang Jira dan reorganisasi, sampai akhirnya ditemukan lagi belakangan dan diperbaiki
    • Saya dari tim keamanan Harvest. Seperti yang juga saya jawab di komentar lain, pada dasarnya kami tidak bisa mereproduksinya dan tidak ada perbaikan eksplisit. Namun, isu yang seharusnya sudah ditutup tetap berada dalam status Triage karena kesalahan manusia dari saya

  • Saya berharap ada pakar OAuth yang bisa menjelaskan masalah ini sedikit lebih detail. Saya sudah membaca blognya beberapa kali, tetapi masih belum memahami kerentanan sebenarnya
    Dengan pengetahuan OAuth saya yang sangat terbatas, bukankah aplikasi Harvest meminta Microsoft memverifikasi pengguna, lalu setelah Microsoft memverifikasi pengguna, jika berhasil, Microsoft mengalihkan ke URL callback sambil mengirimkan access token dalam body respons?
    Dalam kasus ini, bukankah penulis blog hanya membuat URL rakitan sendiri yang membuat URL pengembalian menuju example.com, bukan URL pengembalian sebenarnya?

    • Benar. Penulis blog memang membuat URL rakitan seperti itu. Namun, URL callback dalam URL serangan adalah domain harvestapp, dan bagian yang dikendalikan penyerang berada di dalam state, yang bagi server OAuth hampir bersifat opaque
      Dengan URL itu, seseorang bisa mengirim tautan login.microsoftonline.com kepada orang lain, menampilkan prompt login yang meminta “login ke Harvest”, lalu penyerang dapat memperoleh izin terkait akun Harvest yang sebenarnya
      Biasanya ini tidak mungkin. Penyerang bisa mendaftarkan aplikasi baru yang diarahkan ke example.com, tetapi itu tidak berguna karena mereka tidak akan mendapatkan access token berisi izin terkait Harvest
      Aplikasi OAuth di sisi Microsoft memiliki daftar izin redirect yang valid, sehingga percobaan seperti login.microsoftonline.com/authorize?client_id=$harvestAppID&redirect_uri=attacker.com akan menghasilkan error di sisi Microsoft. Serangan ini mungkin karena URL outlook-integration.harvestapp.com yang valid menerima access token, lalu mengalihkan lagi ke situs penyerang sambil meneruskan access token tersebut
    • Kerentanannya berasal dari outlook-integration.harvestapp.com. Setelah callback OAuth2 berhasil, mereka menggunakan objek JSON sebagai state yang berisi instruksi untuk dijalankan
      Properti subdomain digunakan untuk mengalihkan browser ke subdomain harvestapp.com sambil meneruskan #id-token. Masalahnya adalah nilai subdomain disisipkan begitu saja ke URL berikut
      https://${subdomain}.harvestapp.com/...#id-token=...
      Jika subdomain dalam payload JSON disetel ke nilai seperti attacker-controlled.com/ dengan garis miring di belakang, URL-nya menjadi https://attacker-controlled.com/.harvestapp.com/...#id-token=.., dan browser berpindah ke domain lain sehingga token bocor
    • Microsoft memastikan URL pengembalian ada dalam allowlist yang ditentukan Harvest. Harvest tampaknya menambahkan mekanisme pengalihan sendiri di atasnya, mungkin untuk mendukung beberapa instance perangkat lunaknya, tetapi tidak membersihkan nilai input redirect dengan benar
      Jadi ini bukan masalah inheren OAuth itu sendiri, melainkan implementasi yang buruk
    • Saya tidak tahu persis, tetapi menurut saya masalahnya adalah Harvest mengizinkan semua URL sebagai URL callback. Seharusnya mereka memberi tahu Microsoft untuk hanya mengizinkan URL tertentu sebagai callback
      Saat menyiapkan workflow, alih-alih membuat daftar nyata URL callback tepercaya, mereka mungkin menggunakan wildcard di allowlist URL callback. Bisa saja saya sepenuhnya keliru

  • Tidak tahu mengapa mereka menunggu sampai 3 tahun. Masa tenggang sebelum pengungkapan publik 90 hari sudah cukup

    • Jika diperlukan perubahan yang sangat besar, dan tim yang cukup besar mengalokasikan sebagian besar jam kerjanya untuk masalah ini, bisa saja lebih lama dari 90 hari. Atau mungkin sudah ada solusi, tetapi karena pemberitahuan kepada pelanggan, prosesnya harus mengikuti jadwal tertentu yang relatif singkat
      Namun masa tenggang tambahan seperti itu seharusnya diberikan atas izin peneliti atau pengacara/perwakilannya. Untuk kasus yang lebih besar dari biasanya, ini adalah jenis permintaan yang bisa diajukan perusahaan dengan iktikad baik

  • Jika HackerOne membiarkan perusahaan menimbun hal seperti ini selama 3 tahun, rasanya mereka tidak menjalankan perannya dengan benar

    • HackerOne bergantung pada perusahaan yang menjalankan program bug bounty. Seberapa jauh mereka terlibat sangat bergantung pada layanan yang disediakan, misalnya apakah mereka menangani triase atau tidak
      Pada tingkat paling dasar, mereka hanya menyediakan platform pengungkapan kerentanan dan klausul hukum standar agar peneliti tidak dituntut oleh tim legal
      Dalam sebagian besar kasus, perusahaan menolak permintaan pengungkapan. Jika peneliti mengungkapkannya tanpa izin, ia melanggar perjanjian dengan HackerOne dan perusahaan serta terekspos tanggung jawab hukum. Dalam kasus ini, tampaknya perusahaan menyetujui pengungkapan, dan meski responsnya sangat lambat, menurut saya poin itu patut diakui
      Secara pribadi, saya juga beberapa kali mengalami bug dengan imbalan empat digit yang tidak diperbaiki selama lebih dari setahun, tetapi saya tidak menganggap itu salah HackerOne
    • Saya pernah menangani isu HackerOne dari sisi perusahaan, dan peserta HackerOne terus melanggar aturan HackerOne sendiri. Ada pelanggaran jadwal pengungkapan, unggahan media sosial palsu tentang bug, bahkan ancaman terhadap karyawan
      HackerOne tidak peduli. Meski beberapa kali diberi tahu bahwa orang tersebut melanggar aturan mereka, mereka mengatakan tidak bisa melakukan apa-apa
      Rasanya seperti perusahaan yang sudah mencapai kondisi operasional normal dipangkas hingga hanya menyisakan staf minimum, dengan petugas dukungan yang tidak punya wewenang menjawab pertanyaan. Itu sudah cukup lama, jadi mungkin sekarang sudah berubah, tetapi begitulah kesan saya saat itu
    • Di antara tiga pihak, yaitu HackerOne, perusahaan, dan peneliti yang menemukan bug, perusahaan memegang semua daya tawar
      Jika perusahaan merasa HackerOne melewati batas dan menentukan apa yang “boleh” dilakukan perusahaan, mereka akan begitu saja meninggalkan HackerOne dan membuat solusi internal
    • Mungkin perlu ada ulasan perusahaan, supaya kita bisa menghindari perusahaan buruk yang mengulur-ulur selama bertahun-tahun dan tidak membayar imbalan

  • Saya tidak mengerti mengapa isu ini tidak diteruskan ke Microsoft. Microsoft semestinya bisa mencabut hak akses aplikasi OAuth ini sampai masalahnya diperbaiki
    Meski begitu, sepertinya ada ribuan implementasi serupa yang sama buruknya yang terhubung ke Microsoft lewat OAuth

    • Saya tidak tahu hal seperti itu bisa dilakukan. Secara pribadi, saya rasa saya tidak akan pernah terpikir ke arah itu