Kecacatan Pengesahan Apl Bersarang Microsoft Entra ID Benarkan Penyerang Lencar MFA dan Semua Dasar Akses Bersyarat

Byrne mendapati bahawa mekanisme ini mempunyai kelemahan kritikal. Kelemahan ini khususnya menjejaskan aliran di mana klien ADIbizaUX – komponen pengurusan IAM Azure Portal – menjadi perantara token muat semula Azure Portal yang dicache untuk meminta token akses untuk API Microsoft Graph . Biasanya, pertukaran token muat semula tertakluk kepada penilaian Akses Bersyarat, tetapi NetSPI mendapati bahawa apabila menggunakan aliran NAA dengan ADIbizaUX terhadap sumber Microsoft Graph, Dasar Akses Bersyarat tidak dinilai langsung . Token akses dikeluarkan tanpa mengira mana-mana dasar yang dikonfigurasikan. Dua ID klien sambungan portal Microsoft Intune tambahan juga didapati mempamerkan tingkah laku pintasan yang sama .

Senario Serangan: Kekekalan Selepas Kompromi Tanpa Dikesan

Serangan memerlukan pra-syarat khusus – token muat semula Azure Portal yang dicuri – tetapi sangat berkesan untuk kekekalan dan pergerakan sisi selepas kompromi . Senario ini berlaku dalam empat langkah:

1. Kompromi awal: Penyerang mula-mula mencuri token muat semula Azure Portal yang sah, contohnya melalui pancingan data, serangan proksi penyerang-di-tengah (AITM) yang menyasarkan login.microsoftonline.com, atau kaedah kecurian token lain .
2. Perantaraan token melalui NAA: Penyerang menggunakan token muat semula Azure Portal yang dicuri dan aliran perantaraan NAA (melalui ADIbizaUX atau sambungan portal Intune) untuk menukarnya secara senyap bagi token akses Microsoft Graph .
3. Memintas semua kawalan: Token Graph dikeluarkan tanpa sebarang penilaian Akses Bersyarat – tiada gesaan MFA, tiada pemeriksaan pematuhan peranti, tiada sekatan lokasi – walaupun dasar tersebut dikonfigurasikan secara eksplisit .
4. Kekekalan dan pergerakan sisi: ADIbizaUX memegang kebenaran Graph yang dipersetujui secara meluas dan mendedahkan API yang tidak didokumenkan untuk mengurus pengguna, kumpulan, principal perkhidmatan, aplikasi, direktori, dan juga dasar Akses Bersyarat – semuanya dengan tiada pengelogan, bermakna tindakan tidak dapat dikesan sepenuhnya .

Kelemahan ini mempunyai had. Token muat semula Azure Portal yang dicuri mempunyai jangka hayat tetap 24 jam dan tidak boleh diperbaharui, mengehadkan tetingkap kekekalan . Penyerang mesti sudah mempunyai token muat semula mangsa, menjadikan ini teknik eskalasi dan kekekalan selepas kompromi, bukan pelaksanaan kod jauh . Walau bagaimanapun, pintasan ini diklasifikasikan sebagai keterukan sederhana oleh Pusat Tindak Balas Keselamatan Microsoft (MSRC) .

Tindak Balas Microsoft: Pembetulan Pelayan Tanpa CVE

NetSPI melaporkan isu ini kepada MSRC pada 17 Mac 2026 . MSRC mengklasifikasikannya sebagai kelemahan keterukan sederhana dan menggunakan pembetulan di sebelah pelayan. Ujian pasca-tampal mengesahkan bahawa aliran NAA yang sebelum ini berjaya kini mengembalikan ralat blok akses AADSTS53003 dengan betul apabila Dasar Akses Bersyarat digunakan . Microsoft tidak memberikan CVE untuk isu khusus ini, dan pembetulan tidak memerlukan sebarang tindakan pelanggan .

Konteks Lebih Luas: Dua Pintasan Akses Bersyarat Didedahkan Pada Hari Yang Sama

Pada 22 Jun 2026, penyelidik mendedahkan dua kaedah pintasan Akses Bersyarat Entra yang berasingan pada hari yang sama :

Perubahan Penguatkuasaan Akses Bersyarat Microsoft Yang Lebih Luas Pada 2026

Selain membetulkan pintasan NAA, Microsoft secara progresif menutup jurang penguatkuasaan Akses Bersyarat sepanjang 2026:

• 27 Mac 2026 – Jun 2026 (berperingkat): Microsoft mengubah cara dasar CA yang menyasarkan "Semua sumber" dikuatkuasakan apabila dasar tersebut termasuk pengecualian sumber. Sebelum ini, log masuk yang meminta hanya skop OIDC asas (seperti openid, profile, User.Read) boleh memintas Akses Bersyarat sepenuhnya jika dasar mempunyai sebarang pengecualian sumber. Perubahan penguatkuasaan memastikan dasar dengan pengecualian masih dinilai terhadap skop "Semua sumber" . Microsoft memberitahu penyewa yang terjejas melalui entri Pusat Mesej MC1223829 .

• 15 Jun 2026: Microsoft memulakan penguatkuasaan penguatkuasaan skop asas khusus untuk pintasan pengecualian sumber, menutup laluan pintasan token Graph yang didedahkan oleh Dirk-jan Molenaar .

• 31 Mac 2026: Microsoft menguatkuasakan persaraan pengesahan tanpa principal perkhidmatan untuk aplikasi multilayanan bukan Microsoft. Semua aplikasi mesti mengesahkan menggunakan principal perkhidmatan berdaftar; jika tidak, aliran log masuk akan gagal .

• Jun 2026: Microsoft mengumumkan kemas kini keselamatan Entra ID yang lebih luas termasuk menggantikan Kawalan Tersuai dengan MFA Luaran, menguatkuasakan Akses Bersyarat secara konsisten semasa pendaftaran kelayakan, dan memerlukan kaedah pengesahan berdaftar secara eksplisit untuk Tetapan Semula Kata Laluan Layanan Sendiri (SSPR) .

Pengambilan Utama Untuk Pembela

• Pintasan NAA telah diperbaiki di sebelah pelayan. Tiada tindakan di sisi penyewa diperlukan untuk penemuan khusus NetSPI .
• Untuk pintasan pengecualian sumber, dayakan pilihan penguatkuasaan skop asas di Pusat Admin Entra untuk memastikan penilaian CA yang betul .
• Pantau kod ralat AADSTS53003, yang kini menyekat pertukaran token berasaskan NAA yang tidak dibenarkan dengan betul .
• API ADIbizaUX yang tidak didokumenkan yang boleh beroperasi tanpa pengelogan masih menjadi kebimbangan – organisasi harus memantau log log masuk Azure Portal dan corak pengeluaran token dengan teliti .
• Dengan persaraan pengesahan tanpa principal perkhidmatan mulai 31 Mac 2026, pastikan semua aplikasi multilayanan mempunyai principal perkhidmatan berdaftar .