OAuth ของ AI ตัวเดียว ทำ Vercel แตก env vars ลูกค้าหลุดเป็นกอง
Vercel โดนเจาะผ่าน OAuth ของ AI tool ตัวหนึ่ง env vars ของลูกค้าหลุด ใครใช้ Vercel ต้องหมุน secret ด่วน
หากคุณนำโค้ดขึ้นระบบ (deploy) บน Vercel และไม่เคยตั้งค่า sensitive flag ให้กับ Environment Variables ข่าวความปลอดภัยรอบนี้ส่งผลกระทบถึงระบบของคุณโดยตรง
Vercel แถลงยอมรับอย่างเป็นทางการว่า ระบบภายในถูกผู้ไม่ประสงค์ดีเข้าถึง ส่งผลให้ Environment Variables ของลูกค้าบางส่วนรั่วไหล ซึ่งข้อมูลที่อาจหลุดออกไปมีตั้งแต่ API Key, รหัสผ่านฐานข้อมูล ไปจนถึง OAuth Token ของโปรเจกต์ต่างๆ บนแพลตฟอร์ม
สิ่งที่น่าสนใจคือ ต้นตอไม่ได้เกิดจากการแฮกระบบ Vercel โดยตรง แต่คนร้ายอาศัยสิทธิ์ OAuth ของเครื่องมือ AI ชื่อ Context.ai เพื่อเข้าถึงบัญชี Google Workspace ของพนักงาน Vercel ก่อนจะไต่ระดับสิทธิ์เข้าสู่ระบบ Production ภายใน
สรุปภาพรวมและผลกระทบ
Vercel ระบุว่าผู้ใช้ที่ได้รับผลกระทบเป็นเพียงส่วนน้อย (limited subset) และได้เริ่มแจ้งเตือนลูกค้ากลุ่มดังกล่าวโดยตรงแล้ว
อย่างไรก็ตาม รูปแบบการโจมตีลักษณะนี้เป็นกรณีศึกษาสำคัญสำหรับผู้พัฒนาโปรแกรมทุกคน ไม่ว่าจะใช้งาน Vercel หรือแพลตฟอร์มอื่นก็ตาม เนื่องจากเป็นช่องโหว่ที่เกิดจากการเชื่อมต่อสิทธิ์ OAuth ไปยังเครื่องมือภายนอก
ลำดับเหตุการณ์และเส้นทางการเจาะระบบ
การโจมตีครั้งนี้ไม่ได้ใช้ช่องโหว่ Zero-Day บนเซิร์ฟเวอร์ของ Vercel และไม่มีการทำฟิชชิงพนักงาน แต่เริ่มต้นจากการที่คนร้ายเข้ายึดระบบของ Context.ai ซึ่งเป็นแพลตฟอร์ม AI ที่ผู้ใช้สามารถเชื่อมต่อกับ Google Workspace ผ่าน OAuth
เมื่อ Context.ai ถูกแทรกแซง ผู้โจมตีจึงนำ Token สิทธิ์ที่พนักงาน Vercel เคยอนุมัติไว้ มาเปิดอ่านข้อมูลภายใน Google Workspace และทำการเคลื่อนย้ายสิทธิ์ภายในระบบ (lateral movement) ตามลำดับ
Guillermo Rauch ซีอีโอของ Vercel ระบุว่า ผู้โจมตีมีความชำนาญสูงมาก ทั้งในแง่ของความเร็วในการปฏิบัติการและความเข้าใจเชิงลึกเกี่ยวกับโครงสร้างระบบภายในของบริษัท
Sensitive Flag จุดตัดระหว่างความปลอดภัยและช่องโหว่
บนระบบของ Vercel ในการเพิ่ม Environment Variable จะมีตัวเลือกให้กำหนดว่าค่านั้นเป็นข้อมูลสำคัญ (Sensitive) หรือไม่ หากเปิดใช้งาน ระบบจะทำการเข้ารหัสขณะจัดเก็บ (Encryption at rest) แต่หากไม่เปิดใช้งาน ข้อมูลจะถูกจัดเก็บเป็นข้อความธรรมดา (Plaintext)
ก่อนหน้านี้ ค่าเริ่มต้นของระบบถูกตั้งไว้เป็นปิด (Off)
ผลลัพธ์คือ เมื่อผู้โจมตีเข้าถึงระบบภายในได้ ตัวแปรที่เปิด sensitive flag ไว้จะถูกล็อกด้วยการเข้ารหัส ซึ่ง Vercel ตรวจสอบแล้วไม่พบหลักฐานว่าข้อมูลส่วนนี้ถูกถอดรหัสได้ แต่ตัวแปรที่ไม่ได้เปิด sensitive flag ไว้ จะสามารถอ่านค่าได้ทันที
ส่วนประกอบของระบบที่ได้รับการยืนยันว่าปลอดภัย
Vercel ยืนยันความปลอดภัยในระบบสำคัญ 3 ด้าน
- NPM Packages แพ็กเกจที่ Vercel ดูแล เช่น Next.js ไม่มีการแก้ไขหรือแทรกโค้ดแปลกปลอม ห่วงโซ่การปล่อยแพ็กเกจยังคงปลอดภัย
- GitHub Repositories ซอร์สโค้ดของโครงการโอเพนซอร์สของ Vercel ไม่มีการเปลี่ยนแปลง
- Microsoft Integrations ระบบที่เชื่อมต่อร่วมกับ Microsoft ในระดับ Enterprise ไม่ได้รับผลกระทบ
- Deployments และ Runtime สภาพแวดล้อมการทำงานของโปรเจกต์ลูกค้ายังคงทำงานได้ตามปกติ ไม่พบหลักฐานว่าโค้ดที่รันอยู่ถูกแก้ไข
รายงานการอ้างสิทธิ์จากกลุ่มแฮกเกอร์
BleepingComputer รายงานว่า มีบุคคลโพสต์อ้างตัวเป็นเครือข่ายของกลุ่ม ShinyHunters เสนอขายข้อมูลและเรียกค่าไถ่ อย่างไรก็ตาม สมาชิกคนอื่นในกลุ่ม ShinyHunters ได้ออกมาปฏิเสธความเกี่ยวข้อง ทำให้การระบุตัวตนผู้โจมตีที่แน่ชัดยังอยู่ระหว่างการสืบสวน โดย Vercel ได้ดึงทีมผู้เชี่ยวชาญจาก Mandiant เข้ามาร่วมตรวจสอบร่วมกับหน่วยงานบังคับใช้กฎหมาย
4 ขั้นตอนที่นักพัฒนาควรทำทันที
- เปิดใช้งาน MFA ทุกบัญชี เปิดระบบยืนยันตัวตนสองชั้นบน Vercel, GitHub และบัญชีอีเมลทั้งหมดที่ใช้เข้าถึงระบบ
- ผลัดเปลี่ยน (Rotate) ค่า Environment Variables เข้าไปตรวจสอบโปรเจกต์บน Vercel และทำการรีเซ็ต API Key, Credential ฐานข้อมูล รวมถึง Secret ต่างๆ จากผู้ให้บริการต้นทาง (เช่น Stripe, Supabase หรือ OpenAI) จากนั้นนำค่าใหม่มากรอกพร้อมเปิด sensitive flag
- ตรวจสอบสิทธิ์ OAuth ภายนอก ตรวจสอบ Third-party Apps ที่ผูกไว้กับ Google Workspace หรือ GitHub หากมีแอปไหนไม่ได้ใช้งานแล้ว ให้เพิกถอนสิทธิ์ออกทันที
- ตรวจสอบ Audit Logs ดูบันทึกการทำงานย้อนหลังใน Vercel Team Settings เพื่อค้นหากิจกรรมที่ผิดปกติ เช่น การปรับแก้ตัวแปร หรือการสั่ง Deploy ที่ไม่ได้มาจากทีมงานจริง
บทเรียนเรื่อง Supply Chain Security
เหตุการณ์นี้ชี้ให้เห็นว่า สิทธิ์ OAuth คือหนึ่งในห่วงโซ่อุปทาน (Supply Chain) ที่มักถูกมองข้าม การมอบสิทธิ์ให้กับ Third-party App ใดๆ ก็เปรียบเสมือนการมอบกุญแจเข้าถึงข้อมูล หากผู้ให้บริการปลายทางถูกเจาะ ความเสี่ยงย่อมลามมาถึงระบบของเราทันที
การใช้หลักการ Least Privilege ในการให้สิทธิ์เท่าที่จำเป็น ควบคู่ไปกับการตั้งระบบหมุนเวียน Secret อัตโนมัติ (เช่น AWS Secrets Manager, Doppler หรือ Infisical) จะช่วยจำกัดขอบเขตความเสียหายได้อย่างมีประสิทธิภาพเมื่อเกิดเหตุการณ์ไม่คาดคิด
แหล่งอ้างอิง
ชอบเรื่องแนวนี้ มีอีบุ๊คฟรีให้อ่านต่อ
ChatGPT Work ฉบับเข้าใจง่าย มอบงานให้ AI ทำจนจบ ตั้งแต่งานแรกจนถึงงานอัตโนมัติ พร้อม workflow ใช้ได้จริง 8 แบบ
กดสมัครแล้วเราจะส่งเทคนิค AI และของแจกใหม่ๆ ให้ทางอีเมล เลิกรับได้ตลอด
Claude Cowork · The Business Playbook
ฉบับภาษาไทย 15 บท เรียนรู้ผ่านโปรเจกต์จำลองต่อเนื่องทั้งเล่ม ตั้งแต่ตั้งค่า Workspace จัดการไฟล์ เชื่อมแอป ตั้งระบบอัตโนมัติ จนถึงสร้าง Plugin
