Kasus ketiga dan keempat kerentanan bypass log masuk Azure Entra ID diungkap

 (trustedsec.com)
1 poin oleh GN⁺ 2026-03-22 | 1 komentar | Bagikan ke WhatsApp
  • Sejak 2023, total 4 kerentanan bypass log masuk Azure Entra ID telah ditemukan, dan dua kasus terbaru dipastikan sebagai masalah serius yang tetap memungkinkan penerbitan token valid
  • GraphGoblin melewati pembuatan log dengan mengulang parameter scope pada alur OAuth2 ROPC, sementara Graph**** membuat log benar-benar tidak tercatat dengan string User-Agent lebih dari 50.000 karakter
  • Kedua kerentanan diduga disebabkan oleh kegagalan logging akibat panjang kolom SQL terlampaui, dan Microsoft telah memperbaikinya setelah laporan diterima
  • Microsoft mengklasifikasikan masalah ini sebagai tingkat “Medium” dan memperbaikinya diam-diam tanpa imbalan atau pengakuan resmi, meski menurut CVSS tingkatnya dinilai High (7,5~8,7)
  • Karena cacat akibat kegagalan validasi input yang berulang terus muncul, verifikasi silang log dan penguatan aturan deteksi berbasis KQL disebut sebagai tugas penting bagi penanggung jawab keamanan

Pengungkapan kerentanan bypass log masuk Azure Entra ID

  • Sejak 2023, total 4 kerentanan bypass log masuk Azure Entra ID telah ditemukan
    • Dua kasus awal hanya memungkinkan verifikasi validitas kata sandi, tetapi dua kasus terbaru berada pada tingkat yang lebih serius karena memungkinkan penerbitan token valid
    • Semua kerentanan kini telah diperbaiki oleh Microsoft

  • Ringkasan GraphNinja dan GraphGhost

    • GraphNinja: saat mencoba login dengan menentukan endpoint tenant lain, validitas kata sandi dapat diketahui tetapi log tidak dibuat
      • Penyerang dapat mengirim permintaan autentikasi ke tenant eksternal dan memeriksa dari respons apakah kata sandi benar
      • Microsoft kemudian menambahkan logging tambahan untuk mengatasi masalah ini
    • GraphGhost: jika menggunakan Client ID yang salah, alur autentikasi gagal setelah verifikasi kata sandi, dan di log hanya ditampilkan sebagai kegagalan
      • Informasi bahwa kata sandi benar tidak tercatat di log admin
      • Microsoft memperbaikinya dengan menambahkan status verifikasi kata sandi ke log masuk

  • Kerentanan GraphGoblin

    • GraphGoblin melewati pembuatan log dengan mengulang parameter scope pada alur OAuth2 ROPC
      • Jika dimasukkan berulang ribuan kali dalam bentuk "openid openid openid ...", token valid tetap diterbitkan tetapi tidak ada catatan sama sekali di log masuk Entra ID
    • Penyebabnya diduga adalah kegagalan INSERT akibat panjang kolom SQL terlampaui
      • Diperkirakan penyimpanan log gagal karena string scope berulang melebihi panjang field database
    • Microsoft kesulitan mereproduksi masalah ini, tetapi memperbaikinya setelah bukti video diberikan

  • Graph****** (bypass berbasis User-Agent)

    • Jika string panjang lebih dari 50.000 karakter dimasukkan ke field User-Agent, log tidak akan dibuat
      • Permintaan autentikasi diproses normal dan token diterbitkan, tetapi log sepenuhnya hilang
      • Diduga karena kegagalan logging akibat panjang kolom SQL terlampaui
    • Ditemukan pada 2025-09-28, dan pada 2025-10-08 Microsoft ternyata sudah menyelesaikan perbaikannya sebelum laporan masuk

  • Ringkasan timeline

    • 2025-09-20: GraphGoblin pertama kali ditemukan
    • 2025-09-26: GraphGoblin dilaporkan ke Microsoft
    • 2025-09-28: Graph****** ditemukan
    • 2025-10-08: Perbaikan Graph****** selesai
    • 2025-11-21: Microsoft berhasil mereproduksi GraphGoblin dan mulai memperbaikinya

Respons dan penilaian Microsoft

  • Microsoft mengklasifikasikan kerentanan ini sebagai tingkat “Medium” dan tidak memberikan imbalan maupun pengakuan publik
    • Pada dua kasus sebelumnya (2023~2024), ada imbalan dan pengakuan
    • Kali ini, meski merupakan masalah serius yang memungkinkan penerbitan token valid, masalah tersebut dinilai tidak penting
  • Berdasarkan CVSS v3.1 nilainya 7,5 (High), dan berdasarkan v4.0 8,7 (High)
    • Skor tinggi dihasilkan karena dampak terhadap Integrity
    • Hilangnya log dianggap sebagai kerusakan langsung pada komponen keamanan
  • Microsoft menyelesaikan perbaikan dalam 2 minggu setelah berhasil mereproduksi masalah
    • Sebelumnya, perbaikan GraphNinja memakan waktu 7 bulan, dan GraphGhost 5 bulan

Cara mendeteksi bypass log

  • Melalui kueri KQL, Session ID atau UniqueTokenIdentifier pada log Graph Activity dapat dibandingkan dengan Sign-In log
    • Sesi yang ada di Graph Activity tetapi tidak ada di Sign-In log dapat dianggap sebagai login yang dibypass
    • Namun, pengumpulan log Graph Activity hanya tersedia jika memiliki lisensi E5
  • Contoh kueri KQL: 
    MicrosoftGraphActivityLogs
| where TimeGenerated > ago(8d)
| join kind=leftanti (union isfuzzy=true
SigninLogs,
AADNonInteractiveUserSignInLogs,
AADServicePrincipalSignInLogs,
AADManagedIdentitySignInLogs,
MicrosoftServicePrincipalSignInLogs
| where TimeGenerated > ago(90d)
| summarize arg_max(TimeGenerated, *) by UniqueTokenIdentifier
)
on $left.SignInActivityId == $right.UniqueTokenIdentifier
    • Jika perlu, perbandingan juga bisa dilakukan berdasarkan SessionId
    • Berdasarkan hasil deteksi, Azure Log Search Alert Rule dapat dikonfigurasi

Ringkasan empat bypass log masuk

Waktu ditemukan Metode Token diterbitkan Diakui Microsoft
2023-08 / 2024-05 Log verifikasi kata sandi tidak dibuat dengan menentukan tenant ID eksternal X X
2024-12 / 2025-04 Memicu kegagalan autentikasi dengan Client ID yang salah X X
2025-09-20 Overflow kolom SQL melalui pengulangan input scope O X
2025-09-28 Overflow kolom SQL melalui string User-Agent panjang O N/A

Kritik terhadap proses keamanan Microsoft

  • Cacat ditemukan pada banyak parameter fitur logging login Entra ID

    • Kerentanan berulang terjadi pada field inti seperti tenant ID, client ID, scope, dan user-agent
    • Ini bukan serangan kompleks, melainkan masalah akibat kegagalan validasi input yang sederhana
    • Muncul kritik atas kurangnya review keamanan dan kontrol kualitas Microsoft
    • Cacat serupa terus berulang di area yang sama selama bertahun-tahun
    • Muncul dugaan soal kemungkinan penggunaan AI code generation atau celah dalam proses pengelolaan kode

  • Kurangnya transparansi pengungkapan

    • Keempat kasus tidak menerima CVE dan tidak ada pengumuman resmi
    • Microsoft sebagai CNA secara eksklusif menentukan apakah kerentanan produknya sendiri akan diungkap atau tidak

Kesimpulan

  • Log masuk Azure Entra ID adalah data inti deteksi intrusi bagi organisasi di seluruh dunia
    • Jika log hilang, seluruh sistem deteksi serangan bisa lumpuh
  • Keempat kerentanan yang ditemukan semuanya berada pada tingkat yang bisa dideteksi hanya dengan input fuzzing sederhana
  • Microsoft perlu memperkuat penjelasan publik dan prosedur review keamanan yang transparan terkait cacat berulang ini
  • Administrator dan penanggung jawab keamanan perlu melengkapi pertahanan melalui verifikasi silang log dan aturan deteksi berbasis KQL

Bacaan terkait

1 komentar

 
GN⁺ 2026-03-22
Komentar Hacker News

  • Ini mengingatkan pada laporan insiden pelanggaran Microsoft yang diumumkan CISA
    Itu adalah kasus ketika peretas yang didukung negara menembus Microsoft lalu menyusupi berbagai lembaga termasuk Departemen Luar Negeri AS
    Hal yang mengejutkan adalah, yang menemukan intrusi itu bukan Microsoft melainkan seorang administrator sistem di Departemen Luar Negeri yang melihat anomali pada log email
    Tautan laporan CISA

  • Dalam artikel yang secara frontal mengkritik Azure oleh ProPublica dan ArsTechnica, disebutkan bahwa para pakar siber federal menyebut cloud Microsoft itu “payah”
    Tautan artikel

    • Sebenarnya satu pakar menggambarkan kualitas dokumentasi seperti itu, tetapi tampaknya ProPublica memperluas tafsirnya ke Azure secara keseluruhan
    • Ars hanya menerbitkan ulang lisensi-nya
    • Para engineer keamanan Azure yang saya kenal hampir semuanya dalam kondisi mental runtuh. Dari sekitar 12 orang, separuh burnout, sisanya kompetensinya terlalu rendah
    • Bloomberg maupun CNBC tidak meliput kasus ini. Semoga ada yang memberi tahu lewat jaringan kontak media

  • Kondisi keamanan siber saat ini terlalu rapuh untuk sistem yang diandalkan seluruh peradaban
    Rasanya seperti menutup kapal bocor dengan duct tape lalu berlayar ke tengah samudra

    • Yang lebih parah, respons industrinya seolah-olah ingin menutup kebocoran itu dengan menambah lebih banyak menara senapan mesin

  • Dalam diskusi terkait log SQL, tampaknya penyerang mengirim input yang terlalu panjang sehingga INSERT gagal karena melebihi panjang kolom
    Akibatnya, catatan percobaan login tidak tersimpan

    • Strukturnya berupa dua layanan yang berjalan terpisah. Layanan validasi mendeteksi kegagalan lalu meminta layanan log untuk mencatatnya, tetapi meski layanan log gagal, layanan validasi tetap mengirim respons seperti biasa
      Ini tampak seperti masalah struktural dari alur autentikasi yang dirancang terlalu rumit

  • Saya pernah mengalami audit log Azure tercatat berbeda dari tindakan yang benar-benar terjadi
    Saya menghapus client secret, UI mengatakan akan menghapus B, tetapi API justru bertindak dengan hanya menyisakan A
    Pada akhirnya log mencatat seolah itu tindakan saya, padahal sebenarnya bug sistem
    Setelah pengalaman seperti ini, kepercayaan saya bukan hanya pada log Azure tetapi juga audit log secara umum ikut goyah
    Menurut saya, itu berbahaya jika dipakai sebagai bukti di pengadilan

    • Karena itu saya lebih suka UI yang selalu punya langkah konfirmasi sebelum perubahan diterapkan. Antarmuka auto-save bergaya ‘video game’ terlalu berisiko
    • Portal Azure (versi baru maupun lama) memang penuh bug, jadi tidak mengejutkan. Ada juga kasus satu tombol salah tekan lalu objek lain yang berubah
    • Kasus ini adalah contoh pendidikan yang bagus tentang risiko operasi set vs operasi delete di lingkungan edit bersamaan. Log-nya akurat, masalahnya ada pada desain UI
    • Pada akhirnya terasa menyeramkan bahwa pengguna hanya menyatakan niat, sementara eksekusi sebenarnya dikendalikan frontend

  • Dibanding kerentanan EntraID belakangan ini, bypass log terlihat kurang penting

    • Tetapi jika log autentikasi inti hanya bekerja secara ‘best-effort’, itu masalah serius sebagai dasar audit keamanan
    • Pada akhirnya serangan yang berhasil dan diam-diam memang biasanya terjadi lewat kolaborasi beberapa kerentanan

  • Microsoft bahkan pernah menaruh kerentanan kritis di Notepad, jadi hal seperti ini tidak mengejutkan

  • Saat dulu mengevaluasi Azure VPN, sama sekali tidak ada log sukses/gagal koneksi
    Ketika saya mengangkat masalah itu, Microsoft malah menyuruh saya “daftarkan itu sebagai permintaan fitur baru”
    Sejak saat itu saya kehilangan kepercayaan sepenuhnya pada Azure. Seiring waktu rasanya tidak membaik, malah makin buruk

  • Alasan para admin TI terus memakai Microsoft adalah karena tidak ada pilihan lain

    • Di lingkungan seperti saya yang harus mengelola aplikasi LOB berbasis .NET dan berbagai SaaS, solusi Microsoft adalah pilihan paling realistis
      Anggaran kecil dan tenaga kerja juga kurang, jadi dipertahankan hanya sampai level cukup untuk terima gaji dan pulang kerja
    • Admin yang lebih muda cenderung tidak suka Microsoft. Mungkin memang ada perbedaan generasi
    • Seperti pepatah “tak ada yang dipecat karena membeli X”, memilih Microsoft punya risiko karier yang lebih kecil

  • Saat Microsoft gagal mereproduksi kerentanan Azure lalu meminta bukti video, sangat mengesankan bahwa itu ditunjukkan hanya dengan satu baris perintah curl
    Benar-benar momen yang memuaskan