เปิดเผยกรณีที่สามและสี่ของช่องโหว่ข้ามบันทึกล็อกการเข้าสู่ระบบ Azure Entra ID

 (trustedsec.com)
1 คะแนน โดย GN⁺ 2026-03-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตั้งแต่ปี 2023 เป็นต้นมา มีการค้นพบ ช่องโหว่ข้ามบันทึกล็อกการเข้าสู่ระบบ Azure Entra ID รวมทั้งหมด 4 กรณี โดย 2 กรณีล่าสุดได้รับการยืนยันว่าเป็น ปัญหาร้ายแรงที่สามารถออกโทเค็นที่ใช้งานได้ตามปกติ
  • GraphGoblin ข้ามการสร้างล็อกได้ในโฟลว์ OAuth2 ROPC โดยป้อนพารามิเตอร์ scope ซ้ำๆ และ Graph**** ทำให้ ล็อกหายไปทั้งหมด ด้วยสตริง User-Agent ที่ยาวเกิน 50,000 ตัวอักษร
  • ช่องโหว่ทั้งสองกรณีถูกชี้ว่าเกิดจาก ความล้มเหลวในการบันทึกล็อกจากการที่ความยาวคอลัมน์ SQL เกินกำหนด และ Microsoft ได้แก้ไขหลังจากได้รับรายงานแล้ว
  • Microsoft จัดปัญหานี้ไว้ในระดับ “ปานกลาง (Medium)” และ แก้ไขแบบเงียบๆ โดยไม่มีรางวัลหรือการรับรองอย่างเป็นทางการ ขณะที่ตามเกณฑ์ CVSS ถูกประเมินว่าอยู่ในระดับ High (7.5~8.7 คะแนน)
  • เนื่องจากข้อบกพร่องจากการตรวจสอบค่าป้อนซ้ำๆ ยังคงเกิดขึ้นอย่างต่อเนื่อง จึงมีการชี้ว่าการ ตรวจสอบล็อกแบบข้ามแหล่งและการเสริมกฎตรวจจับด้วย KQL เป็นภารกิจสำคัญสำหรับผู้ดูแลความปลอดภัย

เปิดเผยช่องโหว่ข้ามบันทึกล็อกการเข้าสู่ระบบ Azure Entra ID

  • ตั้งแต่ปี 2023 เป็นต้นมา มีการค้นพบ ช่องโหว่ข้ามบันทึกล็อกการเข้าสู่ระบบ Azure Entra ID รวมทั้งหมด 4 กรณี
    • 2 กรณีแรกตรวจสอบได้เพียงความถูกต้องของรหัสผ่าน แต่ 2 กรณีล่าสุดเป็นปัญหาระดับร้ายแรงที่สามารถ ออกโทเค็นปกติ ได้
    • ปัจจุบัน Microsoft ได้แก้ไขช่องโหว่ทั้งหมดแล้ว

  • สรุป GraphNinja และ GraphGhost

    • GraphNinja: เมื่อพยายามเข้าสู่ระบบโดยระบุเอนด์พอยต์ของเทนเนนต์อื่น จะสามารถทราบได้ว่ารหัสผ่านถูกต้องหรือไม่ แต่จะไม่มีการสร้างล็อก
      • ผู้โจมตีสามารถส่งคำขอรับรองความถูกต้องไปยังเทนเนนต์ภายนอก และตรวจสอบจากการตอบกลับได้ว่ารหัสผ่านถูกต้องหรือไม่
      • ต่อมา Microsoft ได้เพิ่มการบันทึกเพิ่มเติมเพื่อแก้ปัญหานี้
    • GraphGhost: หากใช้ Client ID ที่ไม่ถูกต้อง โฟลว์การยืนยันตัวตนจะล้มเหลวหลังจากตรวจสอบรหัสผ่านแล้ว และในล็อกจะแสดงเพียงว่าล้มเหลว
      • ข้อมูลว่ารหัสผ่านถูกต้องจะไม่ถูกบันทึกไว้ในล็อกของผู้ดูแลระบบ
      • Microsoft แก้ไขโดยเพิ่มข้อมูลการตรวจสอบรหัสผ่านลงในล็อกการเข้าสู่ระบบ

  • ช่องโหว่ GraphGoblin

    • GraphGoblin ข้ามการสร้างล็อกได้ในโฟลว์ OAuth2 ROPC โดยป้อนพารามิเตอร์ scope ซ้ำๆ
      • หากป้อนซ้ำหลายพันครั้งในรูปแบบ "openid openid openid ..." จะมีการออกโทเค็นปกติ แต่ จะไม่เหลือบันทึกใดๆ ในล็อกการเข้าสู่ระบบของ Entra ID
    • สาเหตุถูกชี้ว่าเป็น ความล้มเหลวของคำสั่ง INSERT จากการที่ความยาวคอลัมน์ SQL เกินกำหนด
      • คาดว่าสตริง scope ที่ถูกทำซ้ำทำให้เกินความยาวของฟิลด์ในฐานข้อมูลจนไม่สามารถบันทึกล็อกได้
    • Microsoft มีปัญหาในการทำซ้ำปัญหานี้ แต่หลังได้รับหลักฐานวิดีโอก็ได้แก้ไขแล้ว

  • Graph****** (การข้ามโดยอาศัย User-Agent)

    • หาก ป้อนสตริงยาวเกิน 50,000 ตัวอักษรในฟิลด์ User-Agent จะไม่มีการสร้างล็อก
      • คำขอรับรองความถูกต้องจะถูกประมวลผลตามปกติและมีการออกโทเค็น แต่ล็อกจะหายไปทั้งหมด
      • คาดว่าเกิดจากความล้มเหลวในการบันทึกล็อกเพราะความยาวคอลัมน์ SQL เกินกำหนด
    • ค้นพบเมื่อ 2025-09-28 และ Microsoft ได้แก้ไขเสร็จสิ้นไปแล้วก่อนมีการรายงานในวันที่ 2025-10-08

  • สรุปไทม์ไลน์

    • 2025-09-20: ค้นพบ GraphGoblin ครั้งแรก
    • 2025-09-26: รายงาน GraphGoblin ให้ Microsoft
    • 2025-09-28: ค้นพบ Graph******
    • 2025-10-08: แก้ไข Graph****** เสร็จสิ้น
    • 2025-11-21: Microsoft ทำซ้ำ GraphGoblin สำเร็จและเริ่มแก้ไข

การตอบสนองและการประเมินของ Microsoft

  • Microsoft จัดช่องโหว่นี้ไว้ในระดับ “ปานกลาง (Medium)” และ ไม่มีการให้รางวัลหรือการรับรองต่อสาธารณะ
    • 2 กรณีก่อนหน้า (2023~2024) เคยมีการมอบรางวัลและการรับรอง
    • แต่ครั้งนี้ แม้จะเป็นปัญหาร้ายแรงที่มีการออกโทเค็นปกติได้ ก็ยังถูกประเมินว่าไม่สำคัญมาก
  • ตามเกณฑ์ CVSS v3.1 ได้ 7.5 คะแนน (High) และตาม v4.0 ได้ 8.7 คะแนน (High)
    • ได้คะแนนสูงจากผลกระทบด้าน Integrity (ความถูกต้องสมบูรณ์)
    • การที่ล็อกหายไปถือเป็นความเสียหายโดยตรงต่อคอมโพเนนต์ด้านความปลอดภัย
  • Microsoft แก้ไขเสร็จสิ้นภายใน 2 สัปดาห์หลังทำซ้ำปัญหาได้
    • ในอดีต GraphNinja ใช้เวลาแก้ 7 เดือน และ GraphGhost ใช้เวลา 5 เดือน

วิธีตรวจจับการข้ามล็อก

  • ผ่าน คิวรี KQL สามารถเปรียบเทียบ Session ID หรือ UniqueTokenIdentifier ระหว่าง Graph Activity log กับ Sign-In log ได้
    • หากมีอยู่ใน Graph Activity แต่ไม่มีใน Sign-In log สามารถพิจารณาได้ว่าเป็นการเข้าสู่ระบบที่ข้ามล็อก
    • อย่างไรก็ตาม ต้องมี ไลเซนส์ E5 จึงจะเก็บ Graph Activity log ได้
  • ตัวอย่างคิวรี 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
    • หากจำเป็น สามารถเปรียบเทียบโดยใช้ SessionId ได้
    • จากผลการตรวจจับ สามารถตั้งค่า Azure Log Search Alert Rule ได้

สรุป 4 วิธีข้ามล็อกการเข้าสู่ระบบ

ช่วงเวลาที่ค้นพบ วิธีการ มีการออกโทเค็นหรือไม่ Microsoft รับรองหรือไม่
2023-08 / 2024-05 ระบุ external tenant ID เพื่อไม่ให้เกิดล็อกการตรวจสอบรหัสผ่าน X X
2024-12 / 2025-04 ทำให้การยืนยันตัวตนล้มเหลวด้วย Client ID ที่ไม่ถูกต้อง X X
2025-09-20 ป้อน scope ซ้ำจน SQL column overflow O X
2025-09-28 ใช้สตริง User-Agent ยาวเพื่อทำให้ SQL column overflow O N/A

คำวิจารณ์ต่อกระบวนการความปลอดภัยของ Microsoft

  • พบข้อบกพร่องในหลายพารามิเตอร์ของฟังก์ชันบันทึกการเข้าสู่ระบบ Entra ID

    • เกิดช่องโหว่ซ้ำๆ ในฟิลด์สำคัญอย่าง tenant ID, client ID, scope, user-agent
    • เป็นปัญหาจาก ความล้มเหลวในการตรวจสอบค่าป้อน แบบเรียบง่าย ไม่ใช่การโจมตีที่ซับซ้อน
    • มีการชี้ถึงการขาด การทบทวนด้านความปลอดภัยและการควบคุมคุณภาพ ของ Microsoft
    • ข้อบกพร่องลักษณะคล้ายกันเกิดซ้ำในพื้นที่เดิมตลอดหลายปี
    • มีการตั้งข้อสังเกตถึงความเป็นไปได้ของการนำ AI มาสร้างโค้ดหรือการตกหล่นในกระบวนการจัดการโค้ด

  • การเปิดเผยข้อมูลที่ขาดความโปร่งใส

    • ทั้ง 4 กรณีไม่ได้รับ CVE และไม่มีประกาศอย่างเป็นทางการ
    • Microsoft ในฐานะ CNA เป็นผู้ตัดสินใจแบบผูกขาดว่าจะเปิดเผยช่องโหว่ของตนเองหรือไม่

บทสรุป

  • ล็อกการเข้าสู่ระบบของ Azure Entra ID คือ ข้อมูลหลักในการตรวจจับการบุกรุกขององค์กรทั่วโลก
    • หากล็อกสูญหาย ระบบตรวจจับการโจมตีทั้งหมดอาจถูกทำให้ไร้ประสิทธิภาพ
  • ช่องโหว่ทั้ง 4 กรณีที่พบ ล้วนอยู่ในระดับที่สามารถตรวจพบได้ด้วย การทำ fuzzing กับค่าป้อนอย่างง่าย
  • Microsoft จำเป็นต้องมี คำอธิบายต่อสาธารณะและเสริมความเข้มแข็งของกระบวนการทบทวนความปลอดภัยอย่างโปร่งใส ต่อข้อบกพร่องที่เกิดซ้ำเหล่านี้
  • ผู้ดูแลระบบและผู้รับผิดชอบด้านความปลอดภัยควรเสริมมาตรการป้องกันผ่าน การตรวจสอบล็อกแบบข้ามแหล่งและกฎตรวจจับบน KQL

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-22
ความคิดเห็นจาก Hacker News

  • ทำให้นึกถึง รายงานเหตุการณ์การเจาะระบบของ Microsoft ที่ CISA เผยแพร่
    เป็นกรณีที่แฮ็กเกอร์ซึ่งได้รับการสนับสนุนจากรัฐเจาะ Microsoft แล้วแทรกซึมเข้าไปยังหลายหน่วยงานรวมถึงกระทรวงการต่างประเทศสหรัฐฯ
    สิ่งที่น่าตกใจคือ คนที่ตรวจพบความผิดปกติในเมลล็อกและพบการบุกรุกไม่ใช่ Microsoft แต่เป็น ผู้ดูแลระบบ ของกระทรวงการต่างประเทศ
    ลิงก์รายงาน CISA

    • แม้แต่หน่วยงานอย่าง CISA ก็ให้ความรู้สึกเหมือนถูก DOGE ทำให้หมดสภาพไปแล้ว
    • ความปลอดภัยของ Azure เป็น เรื่องตลก มานานแล้ว
      มันยกปัญหาสมัย Windows ขึ้นมาบนคลาวด์แบบเดิมทุกประการ และเคยมีเหตุการณ์ล้มเหลวของการแยกเทนเนนต์ข้ามกันถึงสองครั้ง
      บทความที่เกี่ยวข้อง: Azure’s Security Vulnerabilities Are Out of Control / Microsoft comes under blistering criticism for “grossly irresponsible” security
    • ในยุคนั้น สหรัฐฯ มี ผู้เชี่ยวชาญด้านการป้องกันไซเบอร์ ตัวจริงอยู่

  • ในบทความที่ ProPublica และ ArsTechnica วิจารณ์ Azure แบบตรงไปตรงมา มีการบอกว่าผู้เชี่ยวชาญไซเบอร์ของรัฐบาลกลางเรียก Microsoft cloud ว่า “ห่วย”
    ลิงก์บทความ

    • แต่จริงๆ แล้วดูเหมือนว่าผู้เชี่ยวชาญคนหนึ่งพูดแบบนั้นถึง คุณภาพของเอกสาร และ ProPublica น่าจะขยายความไปเป็น Azure ทั้งหมด
    • Ars แค่ นำสิทธิ์เผยแพร่มาลงซ้ำ เท่านั้น
    • วิศวกรความปลอดภัย Azure ที่ฉันรู้จักแทบจะอยู่ในสภาพ สติแตก กันหมด จากประมาณ 12 คน ครึ่งหนึ่งหมดไฟ และที่เหลือก็มีความสามารถต่ำเกินไป
    • Bloomberg หรือ CNBC ไม่ได้ทำข่าวนี้เลย อยากให้มีใครส่งต่อผ่าน เครือข่ายสื่อ หน่อย

  • สภาพไซเบอร์ซีเคียวริตี้ตอนนี้ หละหลวมเกินไปสำหรับระบบที่อารยธรรมทั้งระบบพึ่งพาอยู่
    เหมือนเอาเทปผ้ามาปิดรูเรือที่รั่วแล้วออกสู่มหาสมุทร

    • ที่แย่กว่านั้นคือ เวลาจะตอบโต้กัน อุตสาหกรรมกลับทำเหมือนว่าควรตั้ง ป้อมปืนกล เพิ่มเพื่ออุดรูพวกนั้น

  • ในการคุยกันเรื่อง SQL log ดูเหมือนว่าผู้โจมตีส่งอินพุตที่ยาวเกินไปจน เกินความยาวคอลัมน์ ทำให้ INSERT ล้มเหลว
    ผลก็คือไม่มีการบันทึกประวัติความพยายามล็อกอินนั้นไว้

    • โครงสร้างเป็นแบบที่สองบริการทำงานแยกกัน บริการตรวจสอบจับความล้มเหลวได้และขอให้บริการล็อกบันทึกไว้ แต่ถึงบริการล็อกจะล้มเหลว บริการตรวจสอบก็ยังตอบกลับตามปกติ
      มันดูเป็น ปัญหาเชิงโครงสร้างจากการออกแบบ flow การยืนยันตัวตนที่ซับซ้อนเกินไป

  • เคยเจอกรณีที่ audit log ของ Azure บันทึกไม่ตรงกับสิ่งที่เกิดขึ้นจริง
    ฉันลบ client secret แต่ UI บอกเหมือนจะลบ B ขณะที่ API กลับทำงานเป็นการเหลือแค่ A
    สุดท้ายในล็อกมันถูกบันทึกเหมือนเป็นการกระทำของฉัน ทั้งที่จริงๆ เป็นบั๊กของระบบ
    หลังจากเจอแบบนี้ ความเชื่อมั่นของฉันต่อ Azure log รวมถึง ความน่าเชื่อถือของ audit log โดยรวม ก็สั่นคลอน
    ฉันคิดว่ามันเสี่ยงเกินกว่าจะใช้เป็นหลักฐานในศาล

    • เพราะแบบนี้ฉันเลยชอบ UI ที่มี ขั้นตอนยืนยัน ก่อนเปลี่ยนแปลงเสมอ อินเทอร์เฟซแบบ autosave สไตล์ “วิดีโอเกม” อันตรายเกินไป
    • Azure portal (ทั้งเวอร์ชันใหม่และเก่า) เต็มไปด้วยบั๊ก จนไม่แปลกใจเลย บางทีกดปุ่มผิดครั้งเดียวก็ไปเปลี่ยนวัตถุอีกตัวได้
    • กรณีนี้เป็นตัวอย่างการสอนที่ดีเรื่องอันตรายของ set operation vs delete operation ในสภาพแวดล้อมที่มีการแก้ไขพร้อมกันหลายคน ล็อกนั้นถูกต้อง แต่ปัญหาอยู่ที่การออกแบบ UI
    • สุดท้ายแล้ว ผู้ใช้แค่ แสดงเจตนา เท่านั้น ส่วนการลงมือทำจริงถูกควบคุมโดยฟรอนต์เอนด์ ซึ่งให้ความรู้สึกน่ากลัวมาก

  • เมื่อเทียบกับช่องโหว่ EntraID ช่วงหลังๆ แล้ว การหลบเลี่ยงล็อก ดูสำคัญน้อยกว่า

    • แต่ถ้าล็อกการยืนยันตัวตนหลักทำงานแค่แบบ ‘best-effort’ ก็เป็นปัญหาร้ายแรงสำหรับการใช้เป็น หลักฐานของการตรวจสอบความปลอดภัย
    • ท้ายที่สุด การโจมตีที่สำเร็จและแนบเนียนก็มักเกิดจาก การทำงานร่วมกันของหลายช่องโหว่ อยู่แล้ว

  • Microsoft เคยใส่ช่องโหว่ร้ายแรงไว้แม้กระทั่งใน Notepad มาแล้ว เพราะงั้นเรื่องนี้ก็ไม่น่าแปลกใจ

  • ตอนที่เคยประเมิน Azure VPN ในอดีต ไม่มีล็อกการเชื่อมต่อสำเร็จ/ล้มเหลวเลยแม้แต่นิดเดียว
    พอทักท้วงไป Microsoft กลับบอกว่าให้ไปลงทะเบียนเป็น คำขอฟีเจอร์ใหม่
    ตั้งแต่นั้นมาก็ หมดความเชื่อมั่น ใน Azure อย่างสิ้นเชิง เวลาผ่านไปก็ไม่ดีขึ้น แถมเหมือนจะแย่ลงด้วย

  • เหตุผลที่ผู้ดูแลระบบ IT ยังใช้ Microsoft ต่อไปก็เพราะ ไม่มีตัวเลือกอื่น

    • ในสภาพแวดล้อมแบบฉันที่ต้องดูแลแอป LOB บน .NET และ SaaS อีกสารพัด Microsoft solution คือทางเลือกที่สมจริงที่สุด
      งบก็น้อย คนก็ไม่พอ เลยทำได้แค่รักษาไว้ให้อยู่ในระดับ รับเงินเดือนแล้วกลับบ้านได้ตามปกติ
    • ผู้ดูแลระบบรุ่นใหม่มักมีแนวโน้ม ไม่ชอบ Microsoft อย่างชัดเจน อาจเป็นความต่างระหว่างรุ่นก็ได้
    • อย่างคำพูดที่ว่า “ไม่มีใครถูกไล่ออกเพราะซื้อ X” การเลือก Microsoft จึงมีความเสี่ยงต่ออาชีพต่ำ

  • ตอนที่ Microsoft ไม่สามารถทำซ้ำช่องโหว่ Azure ได้และขอ หลักฐานเป็นวิดีโอ นั้น สิ่งที่น่าประทับใจคือมีการแสดงให้เห็นด้วย คำสั่ง curl เพียงบรรทัดเดียว
    เป็นช่วงเวลาที่สะใจจริงๆ