เมื่อระบบที่ไว้ใจ กลายเป็นช่องทางให้ผู้ไม่หวังดีเข้ามาป่วน: เจาะลึก The Confused Deputy

เมื่อระบบที่ไว้ใจ กลายเป็นช่องทางให้ผู้ไม่หวังดีเข้ามาป่วน: เจาะลึก The Confused Deputy

เคยจินตนาการไหมว่าระบบรักษาความปลอดภัยที่เราไว้ใจ

อย่างบริการที่ทำงานด้วยสิทธิ์สูง ๆ

อาจถูกหลอกให้ทำเรื่องไม่ดีได้โดยไม่รู้ตัว

นี่ไม่ใช่เรื่องแฟนตาซี แต่เป็นช่องโหว่ทางไซเบอร์ที่เรียกว่า The Confused Deputy

มันคือสถานการณ์ที่ระบบหรือบริการที่มีอำนาจมาก ถูกบิดเบือนให้กระทำสิ่งที่เป็นประโยชน์กับผู้โจมตี ทั้งที่ผู้โจมตีไม่มีสิทธิ์โดยตรง

เหมือนกับการที่ผู้ช่วยส่วนตัวที่ซื่อสัตย์ของเรา

ถูกหลอกให้ไปเปิดประตูห้องลับให้กับคนแปลกหน้า

The Confused Deputy คืออะไร?

ลองนึกภาพพนักงานทำความสะอาดคนหนึ่ง ที่ได้รับกุญแจหลักสำหรับทุกห้องในบริษัท

วันหนึ่ง มีพนักงานที่ไม่ได้รับอนุญาตให้เข้าห้อง CEO

เขาเดินไปหาพนักงานทำความสะอาด แล้วบอกว่า “ช่วยเปิดห้อง CEO ให้หน่อย พอดีลืมของสำคัญไว้”

พนักงานทำความสะอาดก็เปิดให้ทันที โดยไม่ได้ตรวจสอบว่าพนักงานคนนั้นมีสิทธิ์เข้าห้อง CEO จริง ๆ หรือไม่

นี่แหละคือหลักการของ The Confused Deputy

พนักงานทำความสะอาดคือ “ผู้ช่วยที่สับสน” (Deputy)

ผู้โจมตีคือพนักงานที่หลอกล่อ

และห้อง CEO คือทรัพยากรที่ถูกเข้าถึงโดยไม่ได้รับอนุญาต

องค์ประกอบสำคัญของเหตุการณ์

ช่องโหว่นี้มักมีองค์ประกอบหลักสามส่วน:

หนึ่ง ผู้ถือครองอำนาจที่แท้จริง (Principal) คือผู้ที่ควรจะเข้าถึงทรัพยากรนั้น ๆ ได้จริง ๆ หรือเป็นเจ้าของทรัพยากรนั้น

สอง ผู้ช่วยที่สับสน (Deputy) คือระบบ บริการ หรือกระบวนการที่มีสิทธิ์สูง

สามารถเข้าถึงหรือจัดการทรัพยากรได้

และเป็นจุดที่ถูกผู้โจมตีใช้ประโยชน์

สาม ผู้โจมตี (Attacker) คือบุคคลหรือระบบที่มีสิทธิ์ต่ำกว่า

พยายามหลอกล่อ Deputy ให้กระทำการในสิ่งที่ตนเองไม่มีสิทธิ์

เหตุการณ์นี้เกิดขึ้นได้อย่างไร?

มันเกิดขึ้นเมื่อ Deputy ซึ่งเป็นบริการที่มีสิทธิ์สูง

ไม่ได้ตรวจสอบว่าใครคือ ผู้ริเริ่มคำขอที่แท้จริง

มันมักจะตรวจสอบเพียงแค่ว่าตัวมันเองมีสิทธิ์ที่จะทำสิ่งนั้นหรือไม่

หรือผู้ที่ส่งคำขอเข้ามา โดยตรง มีสิทธิ์แค่ไหน

แต่ไม่ได้เจาะลึกไปถึง บริบท หรือ แหล่งที่มาดั้งเดิม ของคำขอทั้งหมด

ทำให้ผู้โจมตีสามารถสอดแทรกตัวเองเข้าไปเป็นคนกลาง

แล้วใช้สิทธิ์ของ Deputy เพื่อเข้าถึงทรัพยากรที่ตนไม่มีสิทธิ์

ตัวอย่างที่พบเห็นบ่อย

ตัวอย่างคลาสสิกของช่องโหว่นี้มักเกิดในบริการจัดเก็บข้อมูลบนคลาวด์ เช่น Amazon S3

สมมติคุณมี S3 Bucket ที่เก็บข้อมูลสำคัญ

และมี Policy ให้ บริการของ AWS บางอย่าง (เช่น EC2, Lambda) สามารถเข้าถึง Bucket นั้นได้

ผู้โจมตีอาจสร้างโค้ดบางอย่างในบัญชีของตนเอง

แล้วหลอกให้ บริการของ AWS ที่มีสิทธิ์นั้นในบัญชีของคุณ

ไปอ่านหรือเขียนข้อมูลใน Bucket ของคุณ

โดยที่ผู้โจมตีเองไม่มีสิทธิ์โดยตรงในการเข้าถึง S3 Bucket ของคุณเลย

บริการของ AWS (Deputy) ก็เข้าใจว่ากำลังทำงานตามคำขอที่มาจากภายในระบบของมัน

จึงดำเนินการให้ตามปกติ

การป้องกันช่องโหว่ Confused Deputy

การป้องกันต้องเน้นไปที่การตรวจสอบบริบทและจำกัดสิทธิ์ให้รัดกุมที่สุด:

อันดับแรก จำกัดสิทธิ์ให้ต่ำที่สุด (Principle of Least Privilege)

ให้ Deputy มีสิทธิ์เพียงเท่าที่จำเป็นต่อการทำงานเท่านั้น

ไม่ควรมีสิทธิ์มากเกินไป

สอง ตรวจสอบบริบทของการอนุญาต (Contextual Authorization)

ไม่ใช่แค่ตรวจสอบว่า Deputy มีสิทธิ์หรือไม่

แต่ต้องตรวจสอบด้วยว่า ใครคือผู้ที่ส่งคำขอเริ่มต้น มาจริงๆ

และผู้นั้นมีสิทธิ์ที่จะทำสิ่งนั้นหรือไม่

ใน AWS มีเงื่อนไขใน Policy ที่ช่วยได้ เช่น aws:SourceAccount หรือ aws:SourceArn เพื่อระบุว่าคำขอมาจากบัญชีหรือทรัพยากรใดโดยเฉพาะ

สาม ออกแบบ API ให้ปลอดภัย

กำหนดขอบเขตและสิทธิ์ในการเรียกใช้งาน API อย่างชัดเจน

สี่ ตรวจสอบและตรวจสอบอีกครั้ง

ทบทวนการตั้งค่าสิทธิ์และการกำหนดค่าระบบอย่างสม่ำเสมอ

เพื่อให้แน่ใจว่าไม่มีช่องโหว่ที่อาจถูกใช้ประโยชน์ได้

การทำความเข้าใจช่องโหว่นี้ช่วยให้มองเห็นมิติใหม่ของการรักษาความปลอดภัย

ที่ต้องระมัดระวังแม้ระบบที่ไว้ใจที่สุด