Azure Entra ID लॉगिन लॉग बायपास भेद्यता के तीसरे और चौथे मामले सार्वजनिक

• 2023 के बाद से Azure Entra ID लॉगिन लॉग बायपास भेद्यता के कुल 4 मामले मिले हैं, और हाल के दो मामलों को वैध token जारी करने में सक्षम गंभीर समस्या के रूप में पुष्टि किया गया है
• GraphGoblin OAuth2 ROPC flow में scope parameter को बार-बार देकर लॉग निर्माण को बायपास करता है, जबकि Graph**** 50,000 से अधिक वर्णों की User-Agent string से लॉग को पूरी तरह गायब कर देता है
• दोनों भेद्यताओं का कारण SQL column length overflow के कारण logging failure बताया गया, और Microsoft ने रिपोर्ट के बाद इन्हें ठीक कर दिया
• Microsoft ने इस समस्या को 'मध्यम(Medium)' स्तर में वर्गीकृत किया और बिना किसी इनाम या आधिकारिक मान्यता के चुपचाप सुधार दिया, जबकि CVSS के अनुसार High(7.5~8.7) स्तर का आकलन किया गया
• बार-बार होने वाली input validation failure से ऐसी खामियां जारी हैं, इसलिए log cross-validation और KQL-आधारित detection rules को मजबूत करना सुरक्षा टीमों के लिए अनिवार्य कार्य बताया गया है

---

Azure Entra ID लॉगिन लॉग बायपास भेद्यता सार्वजनिक

• 2023 के बाद से Azure Entra ID लॉगिन लॉग बायपास भेद्यता के कुल 4 मामले मिले
  • शुरुआती दो मामलों में केवल password validity की जांच संभव थी, लेकिन हाल के दो मामले वैध token जारी करने तक सक्षम गंभीर स्तर की समस्याएं थे
  • सभी भेद्यताओं को Microsoft ने अब ठीक कर दिया है

• GraphNinja और GraphGhost सारांश

  • GraphNinja: किसी दूसरे tenant के endpoint को निर्दिष्ट कर login attempt करने पर password सही है या नहीं यह पता चल जाता है, लेकिन कोई लॉग नहीं बनता
    • हमलावर बाहरी tenant को authentication request भेजकर response से password सही होने की पुष्टि कर सकता है
    • बाद में Microsoft ने इस समस्या के समाधान के लिए अतिरिक्त logging जोड़ी
  • GraphGhost: गलत Client ID इस्तेमाल करने पर authentication flow password validation के बाद fail होता है, और लॉग में केवल failure दिखता है
    • password सही था, यह जानकारी admin logs में दर्ज नहीं होती
    • Microsoft ने login logs में password validation है या नहीं, यह संकेत जोड़कर समस्या ठीक की

• GraphGoblin भेद्यता

  • GraphGoblin OAuth2 ROPC flow में scope parameter को बार-बार देकर लॉग निर्माण को बायपास करता है
    • "openid openid openid ..." के रूप में हजारों बार दोहराने पर वैध token जारी हो जाता है, लेकिन Entra ID login logs में कोई रिकॉर्ड नहीं बचता
  • कारण SQL column length overflow के कारण INSERT failure माना गया
    • अनुमान है कि दोहराई गई scope string ने database field length पार कर दी, जिससे लॉग सहेजना विफल हुआ
  • Microsoft को समस्या reproduce करने में कठिनाई हुई, लेकिन video evidence देने के बाद सुधार पूरा किया गया

• Graph****** (User-Agent आधारित बायपास)

  • User-Agent field में 50,000 से अधिक वर्णों की लंबी string डालने पर लॉग नहीं बनता
    • authentication request सामान्य रूप से process होती है और token जारी हो जाता है, लेकिन लॉग पूरी तरह गायब रहता है
    • SQL column length overflow के कारण logging failure की आशंका
  • 2025-09-28 को खोजा गया, और 10-08 को Microsoft ने रिपोर्ट से पहले ही इसे ठीक कर दिया था

• टाइमलाइन सारांश

  • 2025-09-20: GraphGoblin पहली बार मिला
  • 2025-09-26: Microsoft को GraphGoblin की रिपोर्ट
  • 2025-09-28: Graph****** मिला
  • 2025-10-08: Graph****** सुधार पूरा
  • 2025-11-21: Microsoft ने GraphGoblin को सफलतापूर्वक reproduce किया और fix शुरू किया

Microsoft की प्रतिक्रिया और मूल्यांकन

• Microsoft ने इस भेद्यता को 'मध्यम(Medium)' स्तर में वर्गीकृत किया और कोई इनाम या सार्वजनिक मान्यता नहीं दी
  • पहले के दो मामलों (2023~2024) में इनाम और मान्यता दी गई थी
  • इस बार वैध token जारी होने जैसी गंभीर समस्या के बावजूद इसे महत्वपूर्ण नहीं माना गया
• CVSS v3.1 के अनुसार 7.5 (High) और v4.0 के अनुसार 8.7 (High) आंका गया
  • Integrity (अखंडता) पर प्रभाव के कारण उच्च स्कोर मिला
  • लॉग का गायब होना security component को सीधे नुकसान के रूप में देखा गया
• Microsoft ने समस्या reproduce करने के 2 सप्ताह के भीतर सुधार पूरा किया
  • पहले GraphNinja fix में 7 महीने और GraphGhost में 5 महीने लगे थे

लॉग बायपास का पता लगाने के तरीके

• KQL query के जरिए Graph Activity logs और Sign-In logs के Session ID या UniqueTokenIdentifier की तुलना की जा सकती है
  • जो session Graph Activity में मौजूद हो लेकिन Sign-In logs में न हो, उसे बायपास किए गए login के रूप में माना जा सकता है
  • हालांकि Graph Activity logs संग्रह के लिए E5 license आवश्यक है
• उदाहरण KQL query:

  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
  

  • आवश्यकता हो तो SessionId के आधार पर भी तुलना की जा सकती है
  • detection results के आधार पर Azure Log Search Alert Rule सेट किया जा सकता है

चार लॉगिन लॉग बायपास का सारांश

खोज का समय	तरीका	token जारी हुआ या नहीं	Microsoft की मान्यता
2023-08 / 2024-05	बाहरी tenant ID निर्दिष्ट कर password validation log न बनना	X	X
2024-12 / 2025-04	गलत Client ID से authentication failure प्रेरित करना	X	X
2025-09-20	scope को दोहराकर SQL column overflow	O	X
2025-09-28	लंबी User-Agent string से SQL column overflow	O	N/A

Microsoft की सुरक्षा प्रक्रिया पर आलोचना

• Entra ID login logging function के कई parameters में खामियां मिलीं

  • tenant ID, client ID, scope, user-agent जैसे मुख्य fields में बार-बार भेद्यताएं सामने आईं
  • यह किसी जटिल हमले के बजाय साधारण input validation failure से उत्पन्न समस्या थी
  • Microsoft के security review और quality control की कमी की आलोचना हुई
  • वर्षों तक उसी क्षेत्र में समान खामियां दोहराई गईं
  • AI code generation के उपयोग या code management प्रक्रिया में छूट की संभावना भी उठाई गई

• सार्वजनिक पारदर्शिता की कमी

  • चारों मामलों को CVE नहीं दिया गया, और कोई आधिकारिक सूचना भी नहीं आई
  • CNA के रूप में Microsoft अपनी भेद्यताओं के सार्वजनिक खुलासे पर एकाधिकार रखता है

निष्कर्ष

• Azure Entra ID के login logs दुनिया भर के संगठनों के लिए intrusion detection का मुख्य डेटा हैं
  • लॉग गायब होने पर पूरी attack detection व्यवस्था निष्प्रभावी हो सकती है
• मिलीं चारों भेद्यताएं साधारण input fuzzing से भी खोजी जा सकने वाली थीं
• Microsoft को ऐसी दोहराई जाने वाली खामियों पर सार्वजनिक स्पष्टीकरण और अधिक पारदर्शी security review प्रक्रिया की जरूरत है
• admins और security teams को log cross-validation और KQL-आधारित detection rules के जरिए अपनी defense व्यवस्था मजबूत करनी चाहिए

[GN⁺]

Hacker News की टिप्पणियाँ

• इससे CISA की Microsoft breach incident report याद आती है
  यह वही मामला था जिसमें राज्य-समर्थित हैकर्स ने Microsoft को भेदकर U.S. State Department समेत कई संस्थानों में घुसपैठ की थी
  हैरानी की बात यह थी कि घुसपैठ का पता Microsoft ने नहीं, बल्कि State Department के एक system administrator ने mail logs में गड़बड़ी देखकर लगाया था
  CISA रिपोर्ट लिंक

  • लगता है CISA जैसी संस्थाएँ भी अब DOGE की वजह से निष्प्रभावी हो चुकी हैं
  • Azure security तो बहुत पहले से ही मज़ाक के स्तर की रही है
    Windows दौर की समस्याएँ ज्यों-की-त्यों cloud में उठा लाई गईं, और tenants के बीच isolation fail होने की घटनाएँ दो बार हो चुकी हैं
    संबंधित लेख: Azure’s Security Vulnerabilities Are Out of Control / Microsoft comes under blistering criticism for “grossly irresponsible” security
  • उस दौर में अमेरिका के पास सचमुच cyber defense experts हुआ करते थे

• ProPublica और ArsTechnica के Azure पर सीधे हमला बोलने वाले लेख में कहा गया कि federal cyber experts ने Microsoft cloud को “बेहद खराब” बताया था
  लेख लिंक

  • असल में एक विशेषज्ञ ने documentation quality के लिए ऐसा कहा था, लेकिन लगता है ProPublica ने उसे पूरे Azure पर लागू कर दिया
  • Ars ने बस license के तहत पुनर्प्रकाशित किया था
  • जिन Azure security engineers को मैं जानता हूँ, वे लगभग मानसिक टूटन की हालत में हैं. करीब 12 में से आधे burnout का शिकार हैं, और बाकी की क्षमता बहुत कम है
  • Bloomberg या CNBC ने इस मामले को कवर नहीं किया. काश कोई इसे media contacts तक पहुँचा दे

• मौजूदा cybersecurity की हालत, उन systems के हिसाब से जिन पर पूरी सभ्यता निर्भर है, बेहद लचर है
  जैसे छेद वाले जहाज़ को duct tape से बंद करके समुद्र में उतार दिया गया हो

  • इससे भी बुरी बात यह है कि industry उन छेदों को बंद करने के बजाय मानो और machine-gun turrets लगाने की बात कर रही हो

• SQL logs वाली चर्चा में लगता है कि attacker ने इतना लंबा input भेजा कि column length exceed होने से INSERT fail हो गया
  नतीजतन login attempt का रिकॉर्ड बना ही नहीं

  • यह दो अलग services के चलने वाली संरचना थी. validation service ने failure पकड़ा और log service को record लिखने को कहा, लेकिन log service fail होने पर भी validation service ने सामान्य response भेज दिया
    यह authentication flow के ज़रूरत से ज़्यादा जटिल architecture की structural problem लगती है

• Azure के audit logs में वास्तविक behavior से अलग रिकॉर्ड होने का अनुभव मुझे भी हुआ है
  मैंने client secret delete किया था, UI कह रहा था कि B delete होगा, लेकिन API ने A को छोड़कर बाकी हटा दिया
  आखिर में log में वही दर्ज हुआ जैसे यह मैंने किया हो, जबकि असल में यह system bug था
  उस अनुभव के बाद Azure logs ही नहीं, audit logs पर समग्र भरोसा भी हिल गया
  मुझे लगता है कि अदालत में सबूत के तौर पर उनका इस्तेमाल करना खतरनाक होगा

  • इसी वजह से मुझे ऐसे UI पसंद हैं जिनमें change से पहले confirmation step ज़रूर हो. ‘video-game शैली’ के auto-save interfaces बहुत खतरनाक हैं
  • Azure portal (नया version और पुराना version दोनों) bugs से भरा है, इसलिए यह भी चौंकाने वाली बात नहीं है. कभी-कभी एक button गलत दबाने पर कोई और object बदल जाता है
  • यह मामला concurrent editing environment में set operation vs delete operation के ख़तरे को समझाने वाला अच्छा शैक्षिक उदाहरण है. logs सही थे, लेकिन UI design समस्या थी
  • आखिरकार user सिर्फ अपना इरादा व्यक्त करता है, असली execution frontend नियंत्रित करता है — यही बात डरावनी लगती है

• हाल की EntraID vulnerabilities के मुकाबले log bypass कम महत्वपूर्ण लग सकता है

  • लेकिन अगर core authentication logs सिर्फ ‘best-effort’ आधार पर काम करते हों, तो यह security audit के आधार के रूप में गंभीर समस्या है
  • आखिर सफल और गुप्त हमले अक्सर कई vulnerabilities के मेल से ही पूरे होते हैं

• Microsoft ने Notepad में भी कभी critical vulnerability डाल दी थी, इसलिए यह सब चौंकाने वाला नहीं है

• जब मैंने पहले Azure VPN का मूल्यांकन किया था, तब connection success/failure logs बिल्कुल दर्ज नहीं होते थे
  मुद्दा उठाने पर Microsoft ने कहा कि उसे new feature request के रूप में दर्ज करो
  उसी समय Azure पर मेरा भरोसा पूरी तरह खत्म हो गया. समय के साथ सुधार होने के बजाय यह और बिगड़ता ही लग रहा है

• IT administrators Microsoft का इस्तेमाल करते रहते हैं क्योंकि कोई वास्तविक विकल्प नहीं है

  • मेरे जैसे environment में, जहाँ .NET आधारित LOB apps और तरह-तरह के SaaS को manage करना पड़ता है, Microsoft solutions ही सबसे व्यावहारिक विकल्प हैं
    budget कम है और staff भी कम है, इसलिए बस इसे इतना चलाते रहो कि तनख्वाह मिलती रहे और शाम को घर जा सको वाले स्तर पर बनाए रखते हैं
  • युवा administrators में Microsoft के प्रति नापसंदगी ज़्यादा दिखती है. शायद यह पीढ़ीगत अंतर हो
  • जैसे कहा जाता है, “Nobody ever got fired for buying X”, उसी तरह Microsoft चुनने में career risk कम है

• यह बात प्रभावशाली लगी कि जब Microsoft Azure vulnerability को reproduce नहीं कर पाया और video evidence माँगा, तो जवाब में उन्हें सिर्फ एक पंक्ति की curl command दिखा दी गई
  वह सचमुच बहुत संतोषजनक पल रहा होगा