ป้ายกำกับบน credential ไม่ใช่ขอบเขตของ credential

งานเข้ารหัสลับนั้นแข็งแกร่งไร้ที่ติ RFC 5054 SRP-6a, AES-256-GCM, การเปรียบเทียบแบบ constant-time, zero-knowledge proof 1Password ทำเรื่องการเข้ารหัสลับได้ถูกต้อง สิ่งที่พวกเขาทำผิดคือป้ายกำกับบนกระป๋อง

เดือนนี้ วิศวกรสองคนจาก Token Security ใช้เวลาสามวัน reverse-engineer โปรโตคอลการพิสูจน์ตัวตน SRP แบบ proprietary ของ 1Password พวกเขาไม่ได้มองหาช่องโหว่ แต่กำลังพยายามแทนที่ SCIM bridge ด้วย Python client สำหรับเครื่องมือด้าน non-human identity สิ่งที่พบคือช่องว่างระหว่างสิ่งที่ credential บอกว่าทำได้ กับสิ่งที่มันทำได้จริง [1][2]

service-account token ที่จำกัด scope ไว้ที่ vault เดียว และมีสิทธิ์อ่านอย่างเดียว สามารถ list ผู้ใช้ทุกคนในองค์กรได้ ทุกกลุ่ม ทุกการเป็นสมาชิกกลุ่ม สิทธิ์ระดับ vault ทุกรายการในทุก vault ชื่อ อีเมล สถานะ เวลา authentication ล่าสุด ป้ายกำกับของ token บอกว่า "vault เดียว" แต่ API บอกอีกอย่าง [1]

1Password ยืนยันแล้ว พฤติกรรมนี้เป็นไปตามการออกแบบ การจำกัด scope แบบละเอียดอยู่ใน roadmap แต่ไม่มีกำหนดวัน [2]

สิ่งที่ token เข้าถึงได้จริง

Gil Portnoy และ Henry จาก Token Security บันทึกไว้ว่ามี API endpoint ห้ารายการที่ service-account token แบบ "vault เดียว" เรียกใช้ได้สำเร็จเต็มรูปแบบ [1]:

/api/v2/users คืนค่าผู้ใช้ทุกคนในองค์กร: UUID, ชื่อ, อีเมล, สถานะ, ประเภท, เวลา authentication ล่าสุด /api/v1/groups คืนค่าทุกกลุ่มพร้อมสิทธิ์และสถานะ คำสั่ง CLI สำหรับการเป็นสมาชิกกลุ่ม ผู้ใช้และสิทธิ์ของ vault และกลุ่มของ vault ล้วนคืนข้อมูลสด /api/v3/account คืน metadata ของบัญชี /api/v2/vault/{id}/vaultaccess คืนข้อมูลการเข้าถึง vault

ไม่มี endpoint เหล่านี้เลยที่ถูกจำกัด scope ไว้ที่ vault เดียวซึ่ง token ถูก provision ให้ token ถูกสั่งว่า "อ่าน vault เดียว" แต่ API มอบแผนที่ขององค์กรทั้งหมดให้ [1]

จุดที่คมกว่านั้นคือ: การ enumeration ไม่สามารถทำผ่าน SDK ทางการของ 1Password ได้ เส้นทางนั้นจะคืนค่า UNSUPPORTED หรือ FORBIDDEN แต่ใช้ได้ผ่าน internal API ของ CLI ซึ่งนักวิจัยต้อง reverse-engineer เอง "scope" เป็นเพียงข้อจำกัดฝั่ง client ของ SDK credential ที่อยู่ใต้ระบบมีสิทธิ์อ่านทั่วทั้งองค์กร ผู้โจมตีไม่ได้ใช้ SDK ของคุณ [1]

นักวิจัยสร้าง client ด้วย Python ประมาณ 420 บรรทัด API endpoint ห้ารายการ มองเห็นทั้งองค์กร พวกเขาเผยแพร่บทความเมื่อวันที่ 16 กรกฎาคม [1]

ตัวล็อกไม่ใช่ปัญหา พวงกุญแจต่างหากที่เป็น

นักวิจัยระมัดระวังในจุดนี้ งานเข้ารหัสลับแข็งแกร่งจริง การ implement SRP ใช้ zero-knowledge proof มาตรฐาน RFC: เซิร์ฟเวอร์ไม่เคยเห็นรหัสผ่าน ไคลเอนต์ไม่เคยเห็น salt และทุกความล้มเหลวในการพิสูจน์ตัวตนคืนข้อความข้อผิดพลาดเดียวกัน เพื่อไม่ให้ผู้โจมตีเรียนรู้อะไร 1Password บันทึกการเบี่ยงเบนจากมาตรฐานของตนเองไว้ (รวมถึงเนื้อเพลงของ The Beatles จาก "Penny Lane" ที่ฝังอยู่ในค่าคงที่ทางการเข้ารหัสลับเป็น easter egg) และการเบี่ยงเบนเหล่านั้นไม่มีผลกระทบต่อความปลอดภัย [1]

ปัญหาไม่ใช่ตัวล็อก แต่คือสิ่งที่กุญแจเปิด เมื่อ credential ถูกติดป้ายกำกับว่า "จำกัด scope ไว้ที่ vault เดียว" ผู้ดูแลระบบจะ provision agent ด้วย credential นั้นโดยเชื่อว่า blast radius แคบ agent ได้รับ credential credential ได้รับแผนผังองค์กร ไม่มีใครตั้งใจให้เป็นแบบนั้น แต่ก็ไม่มีใครมองเห็นว่ามันเกิดขึ้นเช่นกัน [1]

เมื่อคุณให้ token แบบ "จำกัด scope" กับ agent agent จะทำงานภายใน scope ที่ API บังคับใช้จริง ไม่ใช่ scope ที่ป้ายกำกับอธิบาย หาก agent ถูกบุกรุก ไม่ว่าจะผ่าน prompt injection, ไฟล์ convention ที่ถูกวางยา, การโจมตี supply-chain หรือช่องทางใดก็ตามที่การป้องกันฝั่งข้อความปิดไม่หมด ผู้โจมตีจะไม่ได้แค่ vault เดียว แต่จะได้โครงสร้างองค์กร: ใครอยู่ในกลุ่มไหน ใครเข้าถึง vault ไหนได้บ้าง แต่ละคน authentication ครั้งล่าสุดเมื่อไร นั่นคือขั้น reconnaissance ของการบุกรุก ส่งมอบให้ในการเรียก API ครั้งเดียว [1]

ช่องว่างระหว่าง scope ที่เอกสารระบุ กับ scope ที่มีผลจริง ไม่ได้เป็นเรื่องเฉพาะของ 1Password ทุก API จัดการ credential ล้วนตัดสินใจเรื่อง authorization โดยปริยายที่ผู้ดูแลระบบไม่เคยเห็น สิ่งที่ Token Security พิสูจน์คือช่องว่างนี้มีอยู่จริง วัดได้ และนำไปใช้ประโยชน์ได้ด้วยงานสุดสัปดาห์เดียวกับ Frida hook ตัวเดียว [1]

สิ่งที่ vault ซึ่งออกแบบมาเพื่อสิ่งนี้ทำต่างออกไป

หน้าที่ของ credential คือการอยู่รอดในสภาพแวดล้อมที่มันอยู่ หาก token แบบ "จำกัด scope" สามารถทำแผนที่องค์กรของคุณได้โดยเงียบๆ scope นั้นก็ไม่เคยมีอยู่จริง มันเป็นแค่ป้ายกำกับ

Clavitor ไม่ได้ติดป้ายกำกับ credential แล้วหวังว่าจะเป็นไปตามนั้น agent ได้รับ credential หนึ่งรายการที่ระบุชื่อไว้อย่างชัดเจน ดึงมาแบบ live ในขณะเรียก ถูก inject เข้าไปใน request เดียว แล้วหายไป ไม่มี standing token ให้ผู้โจมตีนำไปใช้ซ้ำ ไม่มี endpoint ทำแผนที่องค์กรซ่อนอยู่หลังป้ายกำกับ scope ที่ไม่มีใครตรวจสอบ vault ไม่เปิดเผยการ enumeration ให้กับ agent agent เข้าถึงได้เฉพาะสิ่งที่มันถูกตั้งชื่อไว้ให้เข้าถึง และไม่มีอะไรมากกว่านั้น

การเข้าถึงทุกครั้งถูกบันทึกลงใน agent เฉพาะตัวที่ทำการเข้าถึงนั้น บน vault ไม่ใช่บน endpoint ที่ agent ทำงานอยู่ หาก token ถูกบุกรุก blast radius คือขอบเขตของ request นั้นเพียงครั้งเดียว ไม่ใช่โครงสร้างองค์กรที่อยู่เบื้องหลัง

หลักการเบื้องหลัง vault ที่บังคับใช้ scope ไม่ใช่แค่ติดป้ายกำกับ: กฎสิบข้อของการจัดการ credential

Clavitor (@clavitorai) คือ credential vault ที่สร้างขึ้นสำหรับ AI agent และเพื่อรับมือกับมัน clavitor.ai

แหล่งอ้างอิง

[1] Token Security (Gil Portnoy, Henry) — Reversing 1Password's Proprietary SRP Authentication Protocol — @TheTokenSec

[2] @TheTokenSec — X thread เรื่องข้อค้นพบ scope escalation วันที่ 16 กรกฎาคม 2026 — "1Password ยืนยันว่าพฤติกรรมนี้เป็นไปตามการออกแบบ เพื่อรองรับ workflow การจัดการ vault"