การใช้ประโยชน์จาก Entra OAuth เพื่อเข้าถึงแอปพลิเคชันภายในของ Microsoft

 (research.eye.security)
2 คะแนน โดย GN⁺ 2025-08-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักวิจัยพบว่าการใช้ประโยชน์ขั้นตอนการขอความยินยอมและการมอบสิทธิ์ของ Entra OAuth ทำให้สามารถเข้าถึงแอปพลิเคชันภายในของ Microsoft ได้
  • ช่องโหว่นี้เป็นภัยคุกคามใหม่ต่อ การปกป้องระบบภายใน โดยแสดงให้เห็นว่าผู้ใช้จากภายนอกอาจค้นพบช่องทางในการเข้าถึงบริการภายใน
  • กลไกการขอความยินยอมพื้นฐานและการกำหนด สิทธิ์การเข้าถึง ที่ไม่สมบูรณ์เป็นต้นเหตุหลัก
  • จากการวิจัยพบว่ามาตรการความปลอดภัยเดิมยังมีจุดอ่อนต่อ การร้องขอความยินยอม OAuth และการควบคุมการเข้าถึง
  • องค์กรและหน่วยงานต่าง ๆ ยืนยันความจำเป็นในการเสริมความเข้มแข็งของ การจัดการการยินยอมและสิทธิ์ OAuth

ภาพรวมการวิจัยและภูมิหลัง

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

การวิเคราะห์สาเหตุ

  • ช่องโหว่นี้เกิดจากการใช้ประโยชน์ขั้นตอน การร้องขอความยินยอม OAuth
  • หากแอปพลิเคชันไม่ถูกจำกัดอย่างเหมาะสม ผู้โจมตีสามารถชักจูงให้ผู้ใช้ให้ความยินยอมและได้ โทเค็นทรัพยากรภายใน
  • กลไกการให้ความยินยอมและการมอบอำนาจที่มีให้มาโดยค่าเริ่มต้นไม่ละเอียดพอ ทำให้บริการภายในบางรายการมีความเสี่ยงต่อการถูกเปิดเผยต่อผู้ใช้จากภายนอก
โฆษณา

ผลกระทบและความเสี่ยง

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

การตอบสนองและข้อแนะนำ

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

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

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

 
GN⁺ 2025-08-11
ความคิดเห็นจาก Hacker News

  • เอกสารของ Microsoft น่าแย่จริง ๆ และไม่น่าแปลกใจเลยที่มันมีช่องโหว่
    ผมเพิ่งตั้งค่า SSO ด้วย Entra ID เมื่อไม่นานมานี้ (อย่างน้อยก็เป็นแอปเทนแนนต์เดียว) และสุดท้ายต้องสุ่มลองๆ ไปเรื่อย ๆ เพื่อให้ได้ scope ที่ถูกต้องพร้อมการตั้งค่าคืนค่าฟิลด์เพิ่มเติมใน access token
    ถ้าค้นหาคู่มือเริ่มต้นก็จะกระโดดไปหน้าต่าง ๆ จำนวนมาก และสุดท้ายเจอแต่เอกสารแบบศัพท์เทคนิคเฉพาะของ Microsoft ที่ไม่ค่อยช่วยอะไรกับการใช้งานจริง

  • ผลลัพธ์แบบนี้ไม่ใช่เรื่องน่าตกใจเลย
    การตั้งค่า Oauth2 และเอกสารของ Entra สับสนกันเป็นก้อนใหญ่
    สับสนจนชัดเจนว่า Microsoft เองก็คงยังทำให้มันทำงานได้อย่างถูกต้องไม่ครบ
    แนวทางแก้ปัญหาของเขาคือการ “เพิ่มเอกสารให้มากขึ้น” แต่เอกสารที่มีอยู่ตอนนี้ก็เป็นก้อนสปาเกตตีอ่านยากอยู่แล้ว

    • ผมก็เจอปัญหานี้เช่นเดียวกันเมื่อไม่กี่สัปดาห์ก่อน
      ตามเอกสารทางการระบุว่าไม่สามารถใช้ authorization code flow กับ scope ของ resource server หลายตัวพร้อมกันได้
      แต่ถ้าขอ openid $clientid/.default กลับทำงานได้
      ในช่วงท้ายของ flow จะได้ทั้ง ID token และ access token โดยแสดงว่า ID token ใช้ OIDC scope แล้ว
      แต่ใน access token แล้วกลับไม่เห็น openid ใน scope
      ทำให้ไม่สามารถเรียก Microsoft Graph (ในฐานะ UserInfo endpoint) ได้
      ผมไม่พบแหล่งข้อมูลที่อธิบายให้ชัดเจนว่าเหตุใดมันถึงเป็นแบบนี้

    • พูดได้ 100% ว่าเห็นด้วย
      ตามหลักแล้ววิศวกรต้องอ่านคู่มือทางการให้ครบ
      แหล่งข้อมูลประกอบมีอยู่ใน เอกสารทางการตรวจสอบ claims

      • แนะนำให้สันนิษฐานว่า token ทุกตัวอาจถูกปลอมได้
        ควรออกแบบให้ปลอดภัยตั้งแต่ค่าเริ่มต้นเสมอ
        ถึงแม้จะใช้ CPU เพิ่ม แต่ควรตรวจทุกฟิลด์ให้ครบถ้วน
        การตรวจ signature จึงมีความหมายได้ก็ต่อเมื่อข้อมูลนั้นถูกต้องเท่านั้น
        หากทำได้ก็ควรตรวจเทียบกับฐานข้อมูล identity เพิ่มเติม
        นักพัฒนาควรเรียนรู้เสมอว่า ก่อนอนุญาตสิ่งใด ๆ ต้องตรวจ tenant, ผู้ใช้, กลุ่ม, และทรัพยากรอย่างละเอียดทุกอย่าง

      • ผมเห็นด้วยทั้งหมด
        นักพัฒนาจริง ๆ ควรอ่านคู่มือทางการอย่างจริงจียน
        คู่มือที่เกี่ยวข้องสามารถดูได้ที่ ที่นี่

      • ก็สงสัยเหมือนกันว่าจะมี “คู่มือสิ่งที่ต้องเช็ก” แบบชัดเจนหรือไม่
        โดยเดิมน่าจะเป็นสิ่งที่สรุปเป็น Yes/No ได้
        ไม่เคยเห็นว่าสิ่งใดเคยมี checkbox แบบ “ผู้ใช้กลุ่มนี้ควรอ่านบันทึกส่วนตัวของทุกคนได้หรือไม่?”

  • แม้ละเลยความซับซ้อนของ Entra ไปแล้ว โดยเฉพาะเมื่อมีเทนแนนต์ภายในของ Microsoft และเทนแนนต์ลูกค้า 3P ผสมปนกันมาก ทำให้เกิดความเสี่ยงง่ายขึ้น
    สิ่งที่น่ากลัวกว่าคือการเชื่อว่าความปลอดภัยจะได้รับการแก้ไขได้แค่ด้วย “authentication token” ตัวเดียว
    เว็บไซต์ลักษณะนี้ควรไม่เคยถูกเปิดเผยต่ออินเทอร์เน็ตตั้งแต่แรก (ตอนนี้ไม่ได้เปิดเผยต่อสาธารณะแล้ว)
    ความปลอดภัยของเครือข่ายจริง ๆ มักถูกผลักไปไว้ท้ายสุด แต่กลับเป็นมาตรการป้องกันที่มีประสิทธิภาพสูงสุด

    • เครือข่ายก็คือชั้นป้องกันเพียงหนึ่งชั้นเท่านั้น
      แก่นสำคัญคือการมีหลายชั้นป้องกัน (แนวคิด defense-in-depth)

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

    • ในช่วง 10 ปีที่ผ่านมา Google เริ่มเทรนด์ “Zero Trust” โดยแทบจะเลิกใช้ VPN ไปแล้ว
      เพราะทุกคนที่เข้าเพียง VPN แล้วเข้าถึงข้อมูลสำคัญได้จึงยากมากที่จะควบคุม
      ดังนั้นปัจจุบันแม้บริการที่เคยเป็น “ภายใน” ก็ถูกเปิดสู่ภายนอก และต้องจัดการ permissions ตามชั้นต่าง ๆ เป็นสิ่งจำเป็น
      ทำให้การโจมตีแบบยกหลายบริการเข้าด้วยกันในครั้งเดียวทำได้ยากขึ้นมาก
      แนะนำแนวคิด Zero Trust

    • ในมุมมองผม เรื่องที่ไม่ใช่ปัญหาจริงไม่ใช่การที่แอปนี้ถูกเปิดสู่เครือข่ายสาธารณะ (คือไม่ใช่ intranet)
      แต่ปัญหาคือ Entra ID นี้เป็น multi-tenant
      ข้อมูลรับรองสำคัญถูกเก็บและแชร์ในฐานข้อมูลเดียวกันกับเทนแนนต์หลากหลายรวมถึงนักร้ายด้วย
      ทำให้การละเมิด multitenancy เกิดได้บ่อย
      แม้ Entra ID จะมี tenant check ที่ robust มากแค่ไหน ช่องโหว่ก็ยังคงอยู่
      อย่างเช่นคำขอข้ามกว่า 2 เทนแนนต์อย่างที่ในบล็อกกล่าว โดยพื้นฐานแล้วเป็นการ authorize ที่ยากมาก และความผิดพลาดเล็กน้อยอย่างใดอย่างหนึ่งอาจก่อให้เกิดความเสี่ยงทั้งหมดได้
      ถ้าเทียบกับแอปเทนแนนต์เดียว ผู้โจมตีต้องเป็นผู้ใช้ในเทนแนนต์นั้นเสียก่อน จึงต้องมีการยืนยันตัวตนล่วงหน้า ทำให้งานโจมตียากกว่ามาก

    • แม้ว่าเรามักได้ยินว่า “ให้ขึ้นคลาวด์ มันปลอดภัยกว่า, ไม่ต้องมีทีมฝ่ายปฏิบัติการไว้เอง” มากมาย แต่แก่นคืออย่างที่ดูได้จากบล็อกนี้คือผู้พัฒนาที่ทำงาน resource server authorization ล้วนไม่ยืนยัน claim พื้นฐานอย่าง issuer, audience, subject จาก token หากความผิดพลาดนี้เกิดซ้ำ ๆ แม้จะอยู่ใน intranet ก็ไม่มีประโยชน์
      สุดท้ายปัญหาไม่ใช่เรื่องคลาวด์หรือ self-hosted แต่ความปลอดภัยแท้จริงแล้วยาก และระบบแก้ไขจริง ๆ มักไม่เกิดจนกว่าจะเกิดเหตุจนจริงจัง
      วางไว้บน intranet หรือ VPN ไม่ได้ทำให้ปัญหาความปลอดภัยเหล่านี้หายไป

    • คำว่า “Defence in depth” (การป้องกันเชิงหลายชั้น) ตอนนี้ดูจะออกตัวแล้วหรือเปล่า?

    • สำหรับบริษัทส่วนใหญ่ น่าจะยังเป็นคำแนะนำที่ดีที่จะใช้ทีมเซิร์ฟเวอร์ของตัวเอง
      แม้จะมีผู้รับเหมาซ่อมหลังคาที่ดีที่สุดใน 3 รัฐ ก็ยังไม่อยากให้เขาดูแลเว็บอีเมล ระบบการจอง และระบบจองต่าง ๆ ของคุณทั้งหมด
      คนที่อยู่ในฟอรั่มนี้คงจัดสรรและดูแลเซิร์ฟเวอร์เองได้ แต่พวกเขาไม่ใช่ “ผู้ใช้ทั่วไป”

  • เมื่อพบ RCE ใน Windows build server แล้วให้รางวัล bounties เป็น 0 ดอลลาร์ ถือว่าห้ามรับได้
    แม้จะไม่ใช่ช่องโหว่ zero-day เพียงแต่มองเป็นปัญหาการตั้งค่า แต่หากสามารถปนเปื้อนสภาพแวดล้อม build ด้วย backdoor DLL ได้ ก็อาจกลายเป็นภัยพิบัติระดับโลกได้

    • ผมเคยเป็นวิศวกร build ของ Microsoft Windows
      ผมไม่ค่อยคุ้นกับ UI การจัดการ build tool ตัวนี้ (อาจเพิ่มเข้ามาหลังจากผมลาออก) แต่ไม่รู้สึกว่ามันถูกออกแบบให้ทำ RCE ได้
      ต้องดึงแพ็กเกจจาก NuGet เสมอ และดูเหมือนว่าจะใส่แพ็กเกจหรือ source ไหนก็ได้ได้ แต่จริง ๆ มี whitelist ที่บังคับให้ใช้เฉพาะ internal Microsoft NuGet feed เท่านั้น
      การควบคุม NuGet package เป็นเรื่องสำคัญมากในทีม Windows engineering ของเรา
      การใช้ NuGet package สาธารณะถูกห้ามอย่างเด็ดขาด และถ้าจำเป็นต้องใช้ ต้อง repackaging และอัปโหลดกลับไปยัง internal source เสมอ

  • ถึงแม้ Microsoft จะมีคนเก่งจำนวนมาก แต่เมื่อเห็นเหตุการณ์ล่าสุดทั้งการรั่วไหลของ master key, ข่าวว่าฝั่งวิศวกรให้ GPT เขียนโค้ดใน PR และคำพูดของ CEO ว่าจะไม่เหลือ backend engineer ผมก็ไม่รู้สึกไว้ใจได้
    แน่นอนว่าคนส่วนใหญ่ยอมรับว่าตัวเลือกอื่นแทบไม่เหลือ
    หากยังคงอยู่ก็ยิ่งเห็นเป็นการกระทำที่ไม่รับผิดชอบไปอีก

    • รู้สึกว่าคำว่า “วิศวกรขอให้ GPT ทำฟีเจอร์ใน PR” หมายถึงอะไรแน่
      กำลังพูดถึง dotnet/runtime หรือเปล่า?

  • แนวคิดของผมจริง ๆ ง่ายมาก
    Entra (หรือชื่ออื่น ๆ อย่าง Azure AD ในอนาคตก็ได้) ไม่ควรใช้เพื่อ AuthZ (authorization) โดยตรง
    AuthN (authentication) ใช้ได้ แต่ AuthZ ต้อง implement เอง
    ถ้าทำ AuthZ เอง ความเสี่ยงพวกนี้จะหลุดมือได้ง่าย
    *- ผมเองก็ไม่รู้ว่าเพราะเหตุใดจึงเปลี่ยนชื่อสืบต่อมา ดูเหมือนผู้บริหารบางคนใน Microsoft ใช้คำขวัญ “ฉันเปลี่ยนชื่อ จึงดำรงอยู่”

    • ชื่อ “Azure AD” ทำให้เข้าใจผิดคิดว่ามันคือตัว AD ที่รันอยู่บน Azure
      แท้จริงตอนนี้มันได้ขยายไปไกลกว่าเดิมมาก

    • ใช้ Entra เพื่อทำ AuthZ ได้
      แค่ติ๊กช่องว่า “ต้องกำหนดผู้ใช้ให้กับแอปนี้” และ assign เองก็พอ[1]
      แต่ฟังก์ชัน AuthZ แห่งเดียวที่ Entra มีจริงๆ คืออย่างนี้เท่านั้น
      ถ้าไม่เปิดใช้งาน AuthZ คุณจะเข้าใจผิดว่า Entra จะจัดการ authorization ให้โดยอัตโนมัติ
      โดยทั่วไปการอนุญาตแบบ allow/deny จะมีความหมายเฉพาะแอปที่ผู้ใช้ทุกคนมีสิทธิ์เท่ากัน
      ส่วนแอปที่ซับซ้อนมากขึ้นแต่ละคนมักมีระดับการเข้าถึงต่างกัน ดังนั้นการ authorization จริงควร implement ในแอป
      [1] วิธีกำหนดสิทธิ์ผู้ใช้หรือกลุ่มผ่านพอร์ทัลผู้ดูแลระบบ

  • นี่เป็นปัญหาคือ Entra ID multi-tenant app ไม่สามารถ blacklist/whitelist เทนแนนต์เฉพาะได้
    และ MSAL ก็ไม่ทำงานกับ browser extensions ด้วย จึงทำให้ผู้ใช้ต้อง implement กลไกความปลอดภัยเพิ่มเติมในการสื่อสารกับ Entra ID เอง
    จึงไม่แปลกที่ปัญหาหลายอย่างยังคงเกิดซ้ำ

    • เรื่องที่ระคายมากที่สุดใน Entra ID คือไม่สามารถกำหนดให้ multi-tenant app อนุมัติ/ปฏิเสธเทนแนนต์แบบเจาะจงได้
      อยากมีตัวเลือก “อนุญาตเฉพาะเทนแนนต์เหล่านี้” แต่ตอนนี้มีแค่ “เทนแนนต์ของฉัน” หรือ “เทนแนนต์ทั้งหมดของ Azure” เท่านั้น
      วิธีแก้ของผมคือ ตั้ง app เป็น “เทนแนนต์นี้เท่านั้น” แล้วเชิญผู้ใช้เทนแนนต์อื่นเข้ามาที่เทนแนนต์ของผม
      หรือปล่อยเป็น “อนุญาตทุกเทนแนนต์” แล้วจัดการ user ตามกลุ่มเพื่อคัดกรองการใช้งานจริง
      ไม่รู้ว่าข้อจำกัดนี้เกิดจากข้อจำกัดทางเทคนิค หรือเพราะลูกค้าที่สำคัญยังไม่เคยขอมา

  • Azure ยิ่งสับสน
    Okta ก็มีปัญหาของตัวเอง แต่เอกสารชัดเจนกว่า และถึงแม้ราคาแพงขึ้น มันสามารถแยกการจัดการความปลอดภัยออกจาก Azure services ได้
    ผมคิดว่ามันคุ้มค่ากับต้นทุนที่จ่าย