SecureRAG Helpdesk

Writeup NCSA AI CTF 2026
b
benzdeus
Apr 3, 2026·1 min read

Series note

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

หมวด Software & Data Integrity

ภาพรวมโจทย์

ถ้าจะเลือกโจทย์หนึ่งข้อมาอธิบายคำว่า "RAG isolation failure" ให้เห็นภาพชัดที่สุด ผมน่าจะเลือกข้อนี้ ระบบ SecureRAG Helpdesk พยายามสื่อว่ามันเป็น IT support assistant ที่แยก public documents ออกจาก admin documents อย่างเหมาะสม และผู้ใช้ทั่วไปควรเข้าถึงได้เฉพาะความรู้ฝั่ง public เท่านั้น

เป้าหมายของโจทย์คือ:

text
http://34.87.106.6:5020/

flag อยู่ในรูป:

text
ai{...}

แต่จุดแตกจริงของมันไม่ได้อยู่ที่การขอ flag ตรง ๆ หรือข้าม auth แบบคลาสสิก มันอยู่ที่การทำให้ตัวค้นคืนเอกสารหยิบเอกสาร restricted เข้ามาใส่ใน บริบทของคำตอบแทน

เริ่มจากการทำแผนที่ knowledge base

หน้าเว็บทิ้ง hint สำคัญไว้สองอย่าง:

  • จำกัดคำถามไม่เกิน 50 words

  • รองรับการ lookup ด้วย Document ID เช่น pub_001

สิ่งนี้บอกทันทีว่าระบบมี exact lookup path และน่าจะมี เส้นทางค้นหาเชิงความหมาย อีกอันควบคู่กัน เส้นทางแก้โจทย์ ที่ถูกต้องจึงควรเริ่มจากการไล่ public docs ทีละตัว เพื่อดูว่าระบบเปิดข้อมูลอะไรให้ผู้ใช้ปกติบ้าง

จากการไล่สำรวจ พบ public docs ประมาณ pub_001 ถึง pub_008 ซึ่งส่วนใหญ่เป็นหัวข้อ helpdesk ทั่วไป แต่หลายเอกสารมีถ้อยคำแปลก ๆ ปนมาด้วย เช่น:

  • administrative verification procedures

  • admin tenant

  • additional metadata not visible in public logs

  • privileged system components

  • administrative verification sequences

คำเหล่านี้ไม่ควรอยู่ใน public KB ธรรมดา และนั่นทำให้มันกลายเป็น จุดต่อยอด สำหรับ การค้นหาเชิงความหมาย ทันที

จุดที่ สมมติฐาน กลายเป็นหลักฐาน

ผมลองใช้ คำถามสั้น ๆ แต่แม่นมาก:

text
administrative verification sequence

คำตอบที่ได้ไม่ใช่คำอธิบายกว้าง ๆ ธรรมดา แต่มันอ้างถึง Internal Documentation (restricted) และยังปล่อยชิ้นส่วนของ flag ออกมาสองชิ้นในคำตอบเดียว:

  1. ai{v3ct0r_r3tr13v4l_

  2. f1lt3r_l34k_Zrel8mqPhw}

ณ จุดนี้แทบไม่ต้องเดาอะไรอีกแล้ว เพราะ citation บอกเองว่าระบบดึง restricted docs ขึ้นมาตอบให้ผู้ใช้ปกติ

ดึงส่วนที่เหลือของ flag

เมื่อรู้ว่าระบบมีข้อมูลไหลข้าม tenant ได้จริง ขั้นต่อไปคือหาคำถามที่ดึง ส่วนกลางของ flag ออกมา คำถามที่ใช้ได้คือ:

text
second verification component

คำตอบจะให้:

text
byp4ss_t3n4nt_

จากนั้นเมื่อนำทั้งสามส่วนมาต่อกัน:

text
ai{v3ct0r_r3tr13v4l_ + byp4ss_t3n4nt_ + f1lt3r_l34k_Zrel8mqPhw}

ก็จะได้ flag สุดท้ายครบถ้วน

ทำไมคำถามสั้น ๆ ถึงร้ายแรงขนาดนี้

เพราะโจทย์นี้ไม่ได้พังที่ ชั้น prompt แต่พังที่ ชั้น retrieval ระบบน่าจะออกแบบ public docs กับ admin docs อยู่ใน index ที่ เชิงความหมายอยู่ใกล้กัน และ public docs เองก็เผลอใช้คำศัพท์ที่ชี้ไปยังฝั่ง admin มากเกินไป

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

กล่าวอีกแบบคือ โมเดลไม่ได้ "ตัดสินใจเปิดเผยความลับ" ด้วยตัวเอง แต่ระบบป้อนความลับนั้นเข้าปากโมเดลตั้งแต่ต้นต่างหาก

บทเรียนจากโจทย์นี้

การทำ RAG ให้ปลอดภัยในระบบหลาย tenant หรือหลายระดับสิทธิ์ ต้อง บังคับใช้การแยกสิทธิ์ ให้ครบทุกชั้น ไม่ใช่เฉพาะชั้นเก็บเอกสาร:

  • document ingestion

  • embedding generation

  • vector search

  • reranking

  • citation rendering

หาก vector search ยังค้นข้าม tenant ได้ ต่อให้ public endpoint ดูเรียบง่ายแค่ไหน ผู้ใช้ก็ยังค่อย ๆ ขุด restricted knowledge ออกมาได้ผ่านคำถามธรรมชาติ

Flag

text
ai{v3ct0r_r3tr13v4l_byp4ss_t3n4nt_f1lt3r_l34k_Zrel8mqPhw}

In This Series

View All Parts