Penyalahgunaan Entra OAuth untuk Akses Aplikasi Internal Microsoft

• Peneliti mengidentifikasi adanya kemungkinan akses ke aplikasi internal Microsoft dengan mengeksploitasi proses persetujuan dan delegasi Entra OAuth
• Kerentanan ini menjadi ancaman baru bagi perlindungan sistem internal, karena menampilkan kemungkinan pengguna eksternal memperoleh jalur akses ke layanan internal
• Mekanisme persetujuan dasar dan pengaturan izin yang tidak memadai merupakan akar penyebab utama
• Hasil penelitian menunjukkan adanya celah pada permintaan persetujuan dan kontrol akses OAuth yang tidak tertangani hanya dengan kontrol keamanan yang ada
• Perusahaan dan organisasi mengonfirmasi kebutuhan untuk memperkuat pengelolaan persetujuan dan izin OAuth

---

Gambaran Penelitian dan Latar Belakang

• Microsoft Entra OAuth adalah kerangka otentikasi/otorisasi di mana berbagai aplikasi memperoleh hak akses ke layanan yang berbeda berdasarkan persetujuan pengguna
• Peneliti menemukan bahwa pada lingkungan target, aplikasi Microsoft yang biasanya hanya dapat diakses secara internal menjadi dapat diakses dari luar saat skenario persetujuan dan delegasi izin tertentu disalahgunakan

Analisis Akar Masalah

• Kerentanan terjadi karena penyalahgunaan proses permintaan persetujuan OAuth
• Jika aplikasi tidak dibatasi dengan benar, penyerang dapat memperoleh token sumber daya internal dengan memancing persetujuan pengguna
• Mekanisme persetujuan dan pemberian izin yang disediakan secara bawaan tidak cukup terperinci, sehingga beberapa layanan internal berisiko terekspos ke luar

Dampak dan Risiko

• Pengguna berbahaya berpotensi mengakses sistem internal dan aplikasi Microsoft melalui celah ini
• Jika akses diberikan, ada risiko kebocoran data sensitif atau penyalahgunaan fitur internal

Tindakan dan Rekomendasi

• Organisasi perlu meninjau ulang kerangka pengelolaan OAuth dan mengendalikan secara ketat seluruh proses persetujuan serta alokasi izin
• Pendekatan yang membatasi cakupan sumber daya dan rentang izin yang disetujui berdasarkan prinsip least privilege perlu diterapkan
• Perlu dibangun audit berkala aplikasi OAuth dan proses manajemen persetujuan untuk memperkuat pengelolaan

[GN⁺]

Komentar Hacker News

• Dokumentasi Microsoft itu benar-benar mimpi buruk; tidak mengejutkan sama sekali kalau ternyata ada kerentanannya Baru-baru ini saya membangun login SSO dengan Entra ID, dan (syukurlah hanya single-tenant) saya nyaris harus mencoba secara acak sampai dapat scope yang tepat dan pengaturan return field tambahan yang benar untuk access token Kalau mencari panduan awal, hasil pencariannya berujung ke banyak sub-halaman, lalu yang muncul lagi adalah istilah khas Microsoft yang sulit dipahami dan tautan dokumentasi yang tidak begitu membantu

• Hasilnya memang tidak mengejutkan Pengaturan dan dokumentasi OAuth2 Entra sangat berantakan Sangat membingungkan sampai-sampai tampak jelas Microsoft sendiri pun tak bisa membuatnya bekerja dengan baik Solusi mereka untuk masalah ini adalah menambahkan "lebih banyak dokumentasi", padahal dokumentasi yang ada pun sudah seperti spaghetti dan susah dibaca

  • Saya pernah mengalaminya beberapa minggu lalu Menurut dokumentasi resmi, tidak memungkinkan menjalankan authorization code flow dengan scope sekaligus untuk beberapa resource server Namun, "openid $clientid/.default" akan berjalan ketika diminta Di akhir flow, Anda menerima ID token dan access token, dan ID token menunjukkan bahwa scope OIDC sudah diterapkan Tetapi di access token, "openid" hilang dari scope Secara praktis, Microsoft Graph (yang berperan sebagai UserInfo endpoint) tidak bisa dipanggil Saya belum menemukan materi yang menjelaskan mengapa perilaku ini terjadi

• Otorisasi aplikasi multi-tenant terus menghasilkan masalah yang tidak diharapkan Saya adalah mantan PM (yang sudah keluar) yang mengerjakan patch berdasarkan hasil riset Wiz di Microsoft Di artikel, salah satu usulan perbaikannya menulis bahwa saat otorisasi aplikasi multi-tenant, cukup cek klaim “iss” atau “tid” Rekomendasi sebenarnya sedikit lebih rumit dari itu Kalau hanya memvalidasi tenant, ada kemungkinan service principal apa pun mendapat akses yang diizinkan Selalu validasi juga subject untuk token Misalnya validasi token dengan kombinasi tid+oid, atau verifikasi tenant dan subject keduanya sebelum otorisasi Detailnya bisa dilihat di dokumentasi resmi claims validation

  • Menekankan pendekatan menganggap semua token pasti dipalsukan Secara default harus didesain aman Walau membuang CPU lebih banyak, perlu memvalidasi semua field Validasi signature hanya berarti sesuatu jika memang diverifikasi Kalau bisa, sebaiknya juga divalidasi silang dengan basis data identity Saya sudah lama menekankan ke pengembang bahwa tenant, user, group, dan resource harus divalidasi dengan hati-hati sebelum mengizinkan akses

  • 100% tepat Faktanya, engineer memang harus membaca panduan resmi Rujukan terkait bisa dilihat di sini

  • Saya juga penasaran apakah ada panduan yang jelas soal “apa saja yang harus diperiksa” Menurut saya, ini seharusnya cukup dirangkum sederhana ya/tidak Saya belum pernah melihat checkbox di sistem bertanya “Apakah user di grup ini boleh membaca catatan pribadi semua orang?”

• Kalau mengesampingkan kompleksitas Entra, terutama di Microsoft di mana banyak tenant internal dan tenant untuk pelanggan pihak ketiga bercampur tanpa pembedaan yang jelas, mudah sekali tak sadar jika terjadi kesalahan Yang lebih mengkhawatirkan lagi adalah keyakinan bahwa keamanan bisa diselesaikan hanya dengan satu "authentication token" Situs seperti ini seharusnya memang tidak diekspos ke internet (sekarang tidak diekspos secara publik) Keamanan jaringan memang sering dikesampingkan, tapi ia sebenarnya benteng paling efektif

  • Keamanan jaringan juga akhirnya cuma satu lapis pertahanan Intinya adalah menerapkan defense-in-depth (banyak lapisan pertahanan)

• Mereka bilang pindahkan ke cloud, bilang cloud lebih aman dari intranet, bilang tak perlu lagi tim operasi internal Aku merasa sudah terlalu tua dan kaku sampai-sampai sulit memahami mengapa aplikasi internal Microsoft bisa diakses dari luar

  • Selama 10 tahun terakhir, Google mendorong tren meninggalkan VPN penuh dengan konsep Zero Trust Karena begitu seseorang masuk ke VPN, sangat sulit untuk mencegah akses ke data penting Karena itu sekarang layanan "internal" pun diekspos ke publik dan perlu manajemen permission per-layer Ini membuat serangan yang menembus banyak layanan sekaligus menjadi jauh lebih sulit Pengenalan konsep Zero Trust

  • Menurut saya, masalahnya bukan aplikasinya terbuka di jaringan publik (bukan intranet) Masalah utamanya justru karena aplikasi semacam ini (Entra ID) bersifat multi-tenant Informasi autentikasi penting disimpan dan dibagi dalam database yang sama untuk banyak tenant termasuk tenant penyerang Jadi pelanggaran multi-tenancy terjadi dengan cukup sering Walau Entra ID punya pengecekan tenant yang kuat pun, kerentanannya tetap ada Contohnya, seperti di blog ini, permintaan lintas lebih dari 2 tenant (permintaan multi-tenant) pada dasarnya sangat sulit diotorisasi, dan satu kesalahan kecil bisa menciptakan risiko besar Dibandingkan aplikasi single-tenant, penyerang harus menjadi user dalam tenant itu sendiri, sehingga serangan pra-otorisasi jauh lebih sulit

  • Tapi memang sering juga didengar klaim “Pergi ke cloud, karena lebih aman dari jaringan internal, tak perlu tim operasi internal” Intinya, seperti yang terlihat di blog, developer yang mengerjakan otorisasi resource server pun sering tidak memeriksa klaim dasar pada token seperti issuer, audience, subject Kalau kesalahan seperti ini terus terulang, tidak ada gunanya meski ditempatkan di intranet Akhirnya, poin utamanya bukan soal cloud atau on-premise, melainkan keamanan memang sulit secara inheren dan siklus perbaikan tidak berjalan sebelum masalah nyata terjadi Menaruhnya di intranet atau jaringan VPN tidak membuat praktik keamanan buruk ini hilang

  • Apakah istilah "Defence in depth" (pertahanan berlapis) memang sudah lewat masa jayanya?

  • Sebagian besar perusahaan tetap lebih baik mempertahankan operasi server sendiri Sekalipun Anda adalah penyedia jasa atap terbaik di tiga negara, Anda mungkin tak ingin menyerahkan semuanya—website, email, sistem reservasi—kepada mereka Mereka yang aktif di forum ini mungkin bisa mengelola dan membangun server sendiri, tapi itu bukan "pengguna biasa"

• Menemukan kerentanan RCE di build server Windows lalu memberi bounty 0$ itu tidak masuk akal Meskipun mungkin itu sekadar isu konfigurasi dan bukan zero-day, kalau bisa menyuntikkan backdoor DLL lalu mengontaminasi build environment, dampaknya bisa jadi bencana global

  • Saya pernah jadi Windows build engineer di Microsoft Saya memang tidak familiar dengan antarmuka UI pengelola tool build ini (mungkin ditambahkan setelah saya keluar), tapi tidak merasa UI ini dirancang agar memungkinkan RCE Selalu harus mengambil paket dari NuGet; walau kelihatan bisa memilih sumber dan paket apa pun, sebenarnya ada whitelist yang membatasi ke internal Microsoft NuGet feed Pengendalian paket NuGet dulu jadi topik penting di tim Windows Engineering kami Penggunaan paket NuGet publik eksternal dilarang total, dan kalau harus memakai, diwajibkan re-packaging lalu diunggah ke source internal

• Karena Microsoft punya banyak orang hebat, tapi melihat kejadian kebocoran master key akhir-akhir ini, insinyur yang meminta GPT coding lewat PR, sampai CEO bilang backend engineer menghilang— saya tidak merasa bisa lagi mempercayai perusahaan itu Memang banyak orang mengaku tak punya opsi lain Meski begitu, bertahan di sana rasanya agak tidak bertanggung jawab

  • Saya penasaran sebenarnya apa yang dimaksud dengan insinyur meminta GPT melakukan coding di PR Mungkin ini kasus dotnet/runtime?

• Menurut saya sangat sederhana Entra* (atau nama apa pun setelahnya seperti Azure AD) tidak boleh dipakai untuk keperluan AuthZ Untuk AuthN, boleh Tugas AuthZ sebaiknya diimplementasikan sendiri Kalau otorisasi dilakukan sendiri, kasus seperti ini bisa dihindari dengan mudah *- Saya juga tak tahu kenapa nama-namanya diganti-ganti, rasanya ada orang di tim manajemen Microsoft yang berprinsip, "Aku mengganti nama, maka aku ada"

  • Nama "Azure AD" bikin orang salah paham seolah hanya AD yang di-host di Azure Padahal sekarang ia sudah lebih dari itu

  • Implementasi AuthZ langsung dengan Entra memang oke Cukup centang kotak "Assign user to this app" dan lakukan assignment langsung sendiri[1] Tapi ini satu-satunya fitur AuthZ yang disediakan oleh Entra Salah kalau berasumsi Entra akan mengurus authorization secara otomatis jika AuthZ tak diaktifkan Sebagai catatan, authorization izinkan/tolak sederhana hanya relevan untuk aplikasi sangat sederhana di mana semua user punya izin sama Untuk aplikasi kompleks pada umumnya, user punya level akses yang berbeda, jadi authorization sebenarnya harus dibangun di dalam aplikasi [1] Cara meng-assign user atau grup di portal manajemen

• Yang seperti ini jadi masalah di aplikasi Entra ID multi-tenant: tidak bisa blacklist/whitelist tenant tertentu Di samping itu, MSAL pun tidak bekerja untuk ekstensi browser, jadi user dipaksa implementasi ekstra keamanan untuk komunikasi ke Entra ID Wajar kalau muncul satu demi satu masalah

  • Tidak bisa whitelist/blacklist tenant tertentu untuk aplikasi multi-tenant Entra ID, ini benar-benar menyebalkan Seandainya ada fitur "Izinkan tenant berikut saja" akan jauh lebih baik, sekarang pilihannya cuma "tenant saya" atau "semua tenant di Azure" Workaround yang saya pakai adalah set app jadi "tenant-only" lalu mengundang user dari tenant lain ke tenant saya Atau set jadi "allow all tenants" lalu gunakan grup untuk mengelola user yang diizinkan Saya sama sekali tak tahu apakah batasan ini karena alasan teknis atau karena pelanggan besar tak pernah meminta

• Azure memang benar-benar membingungkan Okta juga punya masalahnya sendiri, tapi dokumentasinya jauh lebih baik, dan walau mahal, keamanannya bisa dikelola sepenuhnya terpisah dari layanan Azure Harga tersebut menurut saya sepadan