การเจาะระบบ Vercel: การโจมตี OAuth เปิดโปงความเสี่ยงที่ซ่อนอยู่ของตัวแปรสภาพแวดล้อมบนแพลตฟอร์ม

• การเจาะระบบซัพพลายเชน OAuth นำไปสู่การเข้าถึงระบบภายในของ Vercel และทำให้เกิดการ เปิดเผยตัวแปรสภาพแวดล้อม ของบางโปรเจ็กต์ลูกค้าที่มีขอบเขตจำกัด
• จุดเริ่มต้นคือการที่พนักงานของ Context.ai ติด Lumma Stealer และโทเค็น Google Workspace OAuth ที่รั่วไหลถูกใช้เพื่อเข้าถึงบัญชีพนักงาน Vercel และระบบภายใน
• ผู้โจมตีได้รับสิทธิ์เพียงพอที่จะไล่ดูตัวแปรสภาพแวดล้อมของโปรเจ็กต์ลูกค้า โดยเฉพาะ ตัวแปรที่ถูกระบุว่า non-sensitive ซึ่งเพิ่มโอกาสให้ข้อมูลรับรองของบริการปลายน้ำรั่วไหล
• จากข้อมูลที่เปิดเผย อย่างน้อยหนึ่งกรณีมี การตรวจพบ API key ที่รั่วไหลก่อน ที่ Vercel จะประกาศ และช่วงเวลาระหว่างการตรวจพบกับการแจ้งเตือนกลายเป็นปัจจัยเสี่ยงสำคัญ
• เหตุเจาะระบบครั้งนี้เผยให้เห็นว่า ความสัมพันธ์ความเชื่อถือแบบ OAuth และวิธีจัดเก็บตัวแปรสภาพแวดล้อมของแพลตฟอร์ม สามารถนำไปสู่การกระจายตัวของข้อมูลรับรองทั่วทั้งซัพพลายเชนได้

---

นัยสำคัญหลัก

• ยืนยันผลขยายวงของ OAuth
  • ความเสียหายของความสัมพันธ์ความเชื่อถือ OAuth เพียงจุดเดียว ขยายต่อเนื่องจากผู้ให้บริการไปถึงระบบภายในของ Vercel
  • แม้แต่ตัวแปรสภาพแวดล้อมของโปรเจ็กต์ลูกค้าที่ไม่มีความเกี่ยวข้องโดยตรงกับผู้ให้บริการที่ถูกเจาะก็ยังถูกเปิดเผยในวงจำกัด
• ตั้งข้อสังเกตถึงความเป็นไปได้ของการโจมตีแบบเร่งด้วย AI
  • CEO กล่าวต่อสาธารณะว่า ความเร็วที่ผิดปกติของผู้โจมตีอาจเชื่อมโยงกับการเสริมด้วย AI
  • อย่างไรก็ตาม การประเมินนี้ยังเป็นเพียงคำกล่าวสาธารณะ ไม่ใช่ข้อสรุปทางนิติวิทยาศาสตร์ดิจิทัลอย่างเป็นทางการ
• ชี้ให้เห็นความล่าช้าจากการตรวจพบถึงการเปิดเผย
  • ในรายงานสาธารณะจากลูกค้าอย่างน้อยหนึ่งกรณี มีข้อมูลบ่งชี้ว่ามีการตรวจพบคีย์ที่รั่วไหลก่อนการเปิดเผยของ Vercel 9 วัน
  • ในกรณีแพลตฟอร์มถูกเจาะ ความล่าช้าระหว่างการตรวจพบกับการแจ้งเตือนถูกชี้ว่าเป็นปัจจัยเสี่ยงสำคัญ
• เชื่อมโยงกับรูปแบบที่กว้างขึ้นในปี 2026
  • สอดคล้องกับแนวโน้มซัพพลายเชนที่มุ่งโจมตี ข้อมูลรับรองที่นักพัฒนาเก็บไว้ เช่นเดียวกับ LiteLLM, Axios, Codecov และ CircleCI

ไทม์ไลน์เหตุการณ์

• ราวเดือนกุมภาพันธ์ 2026 พนักงานของ Context.ai ติด Lumma Stealer ทำให้ข้อมูลรับรององค์กร โทเค็นเซสชัน และโทเค็น OAuth รั่วไหล
• ราวเดือนมีนาคม 2026 ผู้โจมตีเข้าถึงสภาพแวดล้อม AWS ของ Context.ai และขโมยโทเค็น OAuth ที่ใช้กับผู้ใช้ฝั่งผู้บริโภค
  • ในนี้รวมถึงโทเค็น Google Workspace ของพนักงาน Vercel
• เดือนมีนาคม 2026 มีการเข้าถึงบัญชี Google Workspace ของพนักงาน Vercel ด้วยโทเค็น OAuth ที่ถูกขโมย
• ตั้งแต่มีนาคมถึงเมษายน 2026 หลังย้ายเข้าสู่ระบบภายในของ Vercel แล้ว จึงเริ่มไล่ดูตัวแปรสภาพแวดล้อมของลูกค้า
• ราวเดือนเมษายน 2026 มีการอ้างว่ากลุ่มที่เชื่อมโยงกับ ShinyHunters เริ่มเสนอขายข้อมูลของ Vercel
• วันที่ 10 เมษายน 2026 ลูกค้า Vercel รายหนึ่งเปิดเผยต่อสาธารณะว่าได้รับการแจ้งเตือน API key รั่วไหลจาก OpenAI
• วันที่ 19 เมษายน 2026 Vercel เผยแพร่ประกาศด้านความปลอดภัยและเปิดเผยเธรดบน X
• หลังวันที่ 19 เมษายน 2026 มีการดำเนินการแจ้งลูกค้า แนะนำให้หมุนเวียนข้อมูลรับรอง และปล่อยการเปลี่ยนแปลงบนแดชบอร์ด
• แม้ผู้โจมตีจะอยู่ในระบบช่วงเวลาค่อนข้างสั้นเพียงราว 2 เดือน แต่ก็ยืนยันได้ถึงความเร็วจากการติดเชื้อในผู้ให้บริการภายนอกไปจนถึงการรั่วไหลของตัวแปรสภาพแวดล้อมลูกค้า
• ระยะเวลาการเก็บรักษาเริ่มต้นของ Google Workspace OAuth audit log คือ 6 เดือนในหลายแพ็กเกจ
  • ช่วงเวลาการอยู่ในระบบราว 2 เดือนครั้งนี้จึงมีแนวโน้มว่ายังอยู่ภายในหน้าต่างการเก็บรักษา
  • พร้อมกันนั้นก็มีการชี้ว่าเหตุเจาะระบบลักษณะคล้ายกันที่ยาวนานกว่านี้อาจเกินระยะเวลาการเก็บรักษาเริ่มต้นได้เช่นกัน

ห่วงโซ่การโจมตี

• ขั้นที่ 1: การเจาะ OAuth ของบุคคลที่สาม

  • Context.ai มีแอปพลิเคชัน Google Workspace OAuth ที่พนักงาน Vercel อนุมัติไว้
  • การถูกเจาะของแอปพลิเคชันนี้สืบย้อนไปได้ถึงการที่พนักงาน Context.ai ติด Lumma Stealer ราวเดือนกุมภาพันธ์ 2026
  • ตามรายงานของ Hudson Rock และ CyberScoop มีการรายงานว่าพนักงานคนนั้นติดมัลแวร์หลังดาวน์โหลดสคริปต์ exploit เกม Roblox
  • ด้วยข้อมูลรับรองที่ถูกขโมย ผู้โจมตีจึงเข้าถึงสภาพแวดล้อม AWS ของ Context.ai และทำให้โทเค็น OAuth สำหรับผู้ใช้ฝั่งผู้บริโภคของ Context AI Office Suite ที่เปิดตัวในเดือนมิถุนายน 2025 รั่วไหล
  • Context.ai ประกาศว่าตรวจพบและยับยั้งการเข้าถึงสภาพแวดล้อม AWS โดยไม่ได้รับอนุญาตในเดือนมีนาคม 2026
  • แต่ก็ระบุชัดว่าการรั่วไหลของโทเค็น OAuth เองยังไม่ถูกระบุได้จนกระทั่ง Vercel เริ่มการสอบสวน
  • แอปพลิเคชัน OAuth ที่ได้รับอนุมัติมีลักษณะดังต่อไปนี้
    • ไม่ต้องใช้รหัสผ่านของผู้ใช้
    • ยังใช้งานต่อได้แม้เปลี่ยนรหัสผ่านแล้ว
    • มักมีขอบเขตสิทธิ์กว้าง เช่น อีเมล ไดรฟ์ ปฏิทิน เป็นต้น
    • หลังการอนุมัติครั้งแรกมักแทบไม่ถูกตรวจสอบ

• ขั้นที่ 2: การยึดบัญชี Workspace

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

• ขั้นที่ 3: การเข้าถึงระบบภายใน

  • จากบัญชี Workspace ที่ถูกเจาะ มีการขยับต่อไปยังระบบภายในของ Vercel
  • Rauch กล่าวว่าการยกระดับสิทธิ์เกิดขึ้นผ่านชุดการดำเนินการที่เริ่มจากบัญชี Google Workspace ของเพื่อนร่วมงานใน Vercel ที่ถูกเจาะ
  • เทคนิค lateral movement ที่ใช้โดยเฉพาะไม่ได้ถูกเปิดเผย
    • การเชื่อมต่อ SSO
    • ข้อมูลรับรองที่รวบรวมจากอีเมลหรือ Drive
    • เครื่องมือภายในอื่นที่เชื่อมผ่าน OAuth
    • ไม่ได้เปิดเผยว่าเป็นข้อใดในรายการข้างต้น

• ขั้นที่ 4: การไล่ดูตัวแปรสภาพแวดล้อม

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

• ขั้นที่ 5: ความเป็นไปได้ในการนำไปใช้โจมตีบริการปลายน้ำ

  • ตัวแปรสภาพแวดล้อมที่เปิดเผยมักมีข้อมูลรับรองของบริการปลายน้ำรวมอยู่ด้วย
  • ตามรายงานสาธารณะของ Andrey Zagoruiko เมื่อวันที่ 19 เมษายน 2026 เขาระบุว่าได้รับคำเตือนเรื่องคีย์รั่วไหลจาก OpenAI เมื่อวันที่ 10 เมษายน
  • ตามคำกล่าวของผู้รายงาน คีย์ดังกล่าวไม่มีอยู่ที่อื่นนอกจากใน Vercel
  • ข้อมูลแวดล้อมนี้จึงทำให้เกิดความเป็นไปได้ว่า อย่างน้อยหนึ่งข้อมูลรับรองที่รั่วไหลถูกตรวจพบจากภายนอกก่อนที่ Vercel จะเปิดเผยเหตุการณ์

ช่องว่าง 9 วันก่อนการเปิดเผย

• ในคำตอบบนเธรด X ของ Guillermo Rauch เมื่อวันที่ 19 เมษายน ลูกค้า Andrey Zagoruiko เปิดเผยต่อสาธารณะว่าได้รับการแจ้งเตือนคีย์รั่วไหลจาก OpenAI เมื่อวันที่ 10 เมษายน 2026
• โดยทั่วไปการตรวจจับข้อมูลรับรองรั่วไหลของ OpenAI จะทำงานเมื่อพบในตำแหน่งสาธารณะ เช่น GitHub หรือเว็บไซต์ paste
• บทความประเมินว่าเส้นทางจากตัวแปรสภาพแวดล้อมของ Vercel ไปจนถึงการแจ้งเตือนจาก OpenAI ไม่ได้เป็นเส้นทางที่ตรงไปตรงมานัก
• หากพิจารณาตามวันที่ จะมี หน้าต่าง 9 วัน ระหว่างหลักฐานการเปิดเผยสู่สาธารณะครั้งแรกกับการเปิดเผยของ Vercel

• ช่องว่าง 9 วันนี้หมายถึงอะไร และไม่ได้หมายถึงอะไร

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

• นัยต่อผู้มีส่วนได้ส่วนเสียแต่ละกลุ่ม

  • หน่วยงานกำกับดูแล
    • ภายใต้ GDPR นาฬิกาแจ้งเตือน 72 ชั่วโมงจะเริ่มเมื่อผู้ควบคุมข้อมูลรับรู้ถึงเหตุละเมิด
    • ประเด็นว่า Vercel รับรู้เมื่อใดจึงกลายเป็นข้อถกเถียงสาธารณะ
  • ผู้ตรวจประเมิน
    • ผู้ประเมิน SOC 2 และ ISO 27001 อาจตรวจสอบ ความล่าช้าระหว่างการตรวจพบกับการแจ้งเตือน ว่าเป็นหลักฐานของการเฝ้าติดตามอย่างต่อเนื่องหรือไม่
  • ลูกค้า
    • ไม่อาจสมมติได้ว่าหน้าต่างการเปิดเผยเริ่มต้นในวันที่ 19 เมษายน
    • บทความชี้ว่ามีความเป็นไปได้ที่การนำไปใช้โจมตีจริงจะเริ่มตั้งแต่ก่อนหน้านั้น
  • การแจ้งเตือนข้อมูลรับรองรั่วไหลที่ส่งจากผู้ให้บริการจึงมีความสำคัญมากขึ้นในฐานะช่องทางเตือนล่วงหน้า
  • มีการยกตัวอย่าง OpenAI, Anthropic, GitHub, AWS และ Stripe

พฤติกรรมการโจมตีที่เร่งความเร็วด้วย AI

• Guillermo Rauch กล่าวบน X เมื่อวันที่ 19 เมษายน 2026 ว่าเขาสงสัยอย่างมากว่ากลุ่มผู้โจมตีมีความซับซ้อนสูงและได้รับการเร่งความเร็วอย่างมากด้วย AI
• บทความนี้ปฏิบัติต่อคำกล่าวดังกล่าวในฐานะ การประเมินตามบันทึกสาธารณะ ของ CEO ของแพลตฟอร์มที่ได้รับผลกระทบ และระบุว่าจำเป็นต้องพิจารณาอย่างรอบคอบ

• สัญญาณที่อาจคาดหวังได้จากหลักฐานนิติวิทยาศาสตร์ดิจิทัล

  • ความเร็วในการไล่รายการ ที่เกินกว่าความเร็วการทำงานด้วยมือ
    • อธิบายได้บางส่วนด้วยการทำสคริปต์เพียงอย่างเดียว
    • การลาดตระเวนที่ใช้ LLM สามารถทำการสำรวจสคีมา การทดสอบ endpoint และการจดจำรูปแบบข้อมูลรับรองแบบขนานได้
  • การสร้างคำขอแบบรับรู้บริบท
    • คำขอที่ดูเหมือนรู้ศัพท์เฉพาะของ Vercel, project slug, ชื่อ deployment target และกฎการตั้งชื่อตัวแปร env var แม้ไม่มีการลาดตระเวนล่วงหน้าที่ชัดเจน
  • ความสามารถในการปรับตัวต่อข้อผิดพลาด
    • หลังเกิด API error และ rate limit มีการเปลี่ยนกลยุทธ์ที่ยืดหยุ่นกว่าสคริปต์แบบคงที่
  • ผลลัพธ์ social engineering ที่ดูเหมือนปรับให้เข้ากับท้องถิ่น
    • ข้อความล่อฟิชชิง commit message และ support ticket มีคุณภาพใกล้เคียงบริบทท้องถิ่นมากกว่าข้อความแปลหรือเทมเพลต

• ความสำคัญที่ไปไกลกว่าเหตุการณ์ Vercel

  • ไม่ว่าการประเมินนี้จะยังคงอยู่ในการพิสูจน์หลักฐานอย่างเป็นทางการหรือไม่ หมวดหมู่ของ การปฏิบัติการโจมตีที่เสริมด้วย AI ก็ไม่ใช่เพียงการคาดเดาล้วนอีกต่อไป
  • ในประกาศของ Microsoft เดือนเมษายน 2026 มีการจัดทำเอกสารกรณีของ device-code phishing ที่ขับเคลื่อนด้วย AI, การสร้างโค้ดแบบไดนามิก, เหยื่อล่อแบบปรับให้เป็นรายบุคคลอย่างยิ่ง และการ orchestration ระบบอัตโนมัติฝั่ง backend
  • มีข้อชี้ว่าค่า telemetry baseline ที่ตั้งตามเกณฑ์ความเร็วของมนุษย์อาจก่อให้เกิด false negative ต่อผู้โจมตีที่ปฏิบัติการด้วยความเร็วระดับ AI

• นัยต่อวิศวกรรมการตรวจจับ

  • หากมีการบีบอัดระยะการไล่รายการและการเคลื่อนที่ด้านข้าง กฎเดิมที่อิง dwell time และ threshold ความเร็วอาจแจ้งเตือนต่ำกว่าความเป็นจริง
  • มีการเสนอให้ทบทวนรายการต่อไปนี้
    • ความเร็วในการไล่รายการทรัพยากรที่ไม่ซ้ำต่อเซสชัน
    • เส้นโค้งการฟื้นตัวจากความผิดพลาดเทียบกับความสำเร็จ
    • ความหลากหลายของรูปแบบคำขอภายในช่วงเวลาสั้น

จุดอ่อนสำคัญในงานออกแบบตัวแปรสภาพแวดล้อม

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

• วิธีการทำงานของตัวแปรสภาพแวดล้อมของ Vercel ในขณะนั้น

  • โปรเจ็กต์มีการฉีดตัวแปรสภาพแวดล้อมเข้าสู่ serverless function และกระบวนการ build
  • มี แฟล็ก sensitive แยกตามแต่ละตัวแปร
  • ค่าเริ่มต้นคือ non-sensitive
  • ต้องเปิด sensitive อย่างชัดเจน
  • ตัวแปร non-sensitive จะแสดงบนแดชบอร์ด
  • ตัวแปร sensitive จะถูก mask หลังสร้าง
  • การเข้าถึงผ่าน internal API ทำได้สำหรับ non-sensitive ส่วน sensitive ถูกจำกัด
  • จากคำกล่าวสาธารณะ การเก็บแบบเข้ารหัสไม่ได้ใช้กับ non-sensitive แต่ใช้กับ sensitive พร้อมข้อจำกัดเพิ่มเติม
  • ในเหตุการณ์เจาะระบบครั้งนี้ สิ่งที่ผู้โจมตีเข้าถึงได้ถูกทำเครื่องหมายเป็น non-sensitive

• ทางเลือกด้านการออกแบบที่เป็นจุดชี้ขาด

  • แฟล็ก sensitive ถูกปิดไว้เป็นค่าเริ่มต้น
  • DATABASE_URL, API_KEY, STRIPE_SECRET_KEY, AWS_SECRET_ACCESS_KEY ทั้งหมดที่นักพัฒนาไม่ได้เปิดอย่างชัดเจน จะถูกเก็บในรูปแบบที่ไม่เข้ารหัสภายใต้โมเดลการเข้าถึงภายในของ Vercel
  • มีการประเมินว่าการควบคุมด้านความปลอดภัยที่ต้องให้ผู้ใช้ opt-in อย่างชัดเจนกับแต่ละ secret โดยไม่มีการป้องกันพื้นฐานและ guardrail เป็นค่าเริ่มต้น จะมีอัตราการใช้งานจริงต่ำ

• การตอบสนองของ Vercel

  • มีการยืนยันการปรับปรุงหน้าภาพรวมตัวแปรสภาพแวดล้อมและ UI สำหรับการสร้าง/จัดการตัวแปรที่ละเอียดอ่อน
  • แม้มีการปรับปรุงด้านการมองเห็น แต่ ณ เวลาที่เขียน ยังไม่ได้เปลี่ยนค่าเริ่มต้น
  • ยังคงต้อง opt-in แยกเป็นรายตัวแปร
  • คำถามว่ามีการสลับค่าเริ่มต้นหรือไม่นั้นยังคงเปิดอยู่ในที่สาธารณะ

• การเปรียบเทียบในอุตสาหกรรม

  • อุตสาหกรรมกำลังเคลื่อนไปสู่ secret store โดยเฉพาะทาง เช่น Vault, AWS Secrets Manager, Doppler และ Infisical
  • มีการประเมินว่าเหตุการณ์นี้สนับสนุนการเลือกสถาปัตยกรรมจัดการความลับโดยเฉพาะทาง เมื่อเทียบกับแนวทางใช้ตัวแปรสภาพแวดล้อมของ Vercel
  • ตามตารางเปรียบเทียบ
    • Vercel ใช้ค่าเริ่มต้นเป็น non-sensitive และไม่มีการตรวจจับอัตโนมัติ
    • AWS SSM Parameter Store รองรับ SecureString
    • HashiCorp Vault มีการเข้ารหัส secret ทั้งหมดและมี ACL
    • GitHub Actions ทำ log masking ให้กับ secret ทั้งหมด
    • Netlify ใช้วิธีตัวแปรสภาพแวดล้อมที่มี secret toggle

Credential fan-out และความเสี่ยงปลายน้ำ

• Credential fan-out คือปรากฏการณ์ที่การเจาะระบบแพลตฟอร์มหนึ่งครั้งลุกลามเป็นการเปิดเผยแบบลูกโซ่ไปยังบริการปลายน้ำทั้งหมดที่ยืนยันตัวตนด้วยข้อมูลรับรองซึ่งเก็บอยู่บนแพลตฟอร์มนั้น
• รายการที่มักรวมอยู่ในตัวแปรสภาพแวดล้อมของโปรเจ็กต์ Vercel และผลกระทบปลายน้ำมีดังนี้
  • ฐานข้อมูล
    • DATABASE_URL, POSTGRES_PASSWORD
    • อาจเข้าถึงข้อมูลทั้งหมดได้
  • คลาวด์
    • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
    • อาจนำไปสู่การเจาะระบบบัญชีคลาวด์
  • การชำระเงิน
    • STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
    • เสี่ยงต่อข้อมูลการเงินและการฉ้อโกงการคืนเงิน
  • การยืนยันตัวตน
    • AUTH0_SECRET, NEXTAUTH_SECRET
    • อาจปลอมแปลงเซสชันและยึดบัญชี
  • การส่งอีเมล
    • SENDGRID_API_KEY, POSTMARK_TOKEN
    • อาจใช้ทำฟิชชิงผ่านโดเมนที่เชื่อถือได้
  • การมอนิเตอร์
    • DATADOG_API_KEY, SENTRY_DSN
    • อาจบิดเบือน telemetry ได้
  • ซอร์สโค้ดและแพ็กเกจ
    • GITHUB_TOKEN, NPM_TOKEN
    • อาจใช้ในการแทรกแซง supply chain
  • AI/ML
    • OPENAI_API_KEY, ANTHROPIC_API_KEY
    • อาจถูกนำไปใช้ API โดยมิชอบและก่อค่าใช้จ่าย
• โปรเจ็กต์ Vercel เดี่ยวมักมีตัวแปรสภาพแวดล้อม 10–30 รายการ
• ในระดับองค์กร หากมีพอร์ตโฟลิโอ 50 โปรเจ็กต์ อาจมีข้อมูลรับรอง 500–1,500 รายการอยู่บนแพลตฟอร์ม
• แม้เหตุการณ์ครั้งนี้จะระบุว่าเข้าถึงได้เพียงบางโปรเจ็กต์ของลูกค้าจำนวนจำกัด แต่ข้อมูลรับรองที่ถูกเปิดเผยแต่ละรายการอาจเป็นจุดย้ายต่อไปยังระบบอื่นได้
• บทความนี้นิยามประเด็นดังกล่าวว่าไม่ใช่เพียงเหตุการณ์ด้านการรักษาความลับของข้อมูลในระดับแพลตฟอร์ม แต่เป็น ผลคูณที่กระจายไปทั่วซอฟต์แวร์ซัพพลายเชน

ความสัมพันธ์เชิงความเชื่อถือของ OAuth และการข้ามการป้องกันตามขอบเขต

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

• OAuth governance คือความสามารถด้านความเสี่ยงจากผู้ขาย

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

คำกล่าวอ้างของผู้ไม่หวังดีและการระบุตัวผู้ก่อเหตุ

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

• คำกล่าวอ้างเรื่องความเชื่อมโยงกับ ShinyHunters

  • ผู้โพสต์ใน BreachForums อ้างว่ามีความเชื่อมโยงกับ ShinyHunters และอ้างว่าครอบครองข้อมูลของ Vercel
  • รายการข้อมูลที่อ้างว่ามี
    • บันทึกพนักงานประมาณ 580 รายการ
    • ที่เก็บซอร์สโค้ด
    • คีย์ API และโทเค็นภายใน
    • โทเค็น GitHub และ NPM
    • การสื่อสารภายใน
    • การเข้าถึง Linear workspace
  • จำนวนและขอบเขตข้างต้นทั้งหมด ยังไม่ได้รับการยืนยัน

• ปัจจัยที่ทำให้การระบุตัวผู้ก่อเหตุทำได้ยาก

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

• จุดยืนของ Vercel ต่อเส้นทางการปล่อยซัพพลายเชน

  • Rauch ระบุว่าได้วิเคราะห์ซัพพลายเชนของ Next.js, Turbopack และโอเพนซอร์สโปรเจ็กต์อีกจำนวนมาก และบอกกับชุมชนว่าปลอดภัย
  • ณ เวลาที่เขียน การตรวจสอบอิสระยังคงดำเนินอยู่
  • มีคำแนะนำให้องค์กรที่ใช้ Next.js, Turbopack และโอเพนซอร์สอื่น ๆ ของ Vercel ตรวจสอบสัญญาณด้านความสมบูรณ์ของแพ็กเกจอย่างต่อเนื่อง เช่น checksum, ลายเซ็น และ provenance attestation
  • เนื่องจากยังไม่มีการตรวจสอบอิสระต่อข้อมูลที่ถูกอ้างในฟอรัม จึงควรถือว่าเป็น ข้อมูลที่ยังไม่ได้รับการยืนยัน
  • มีการประเมินว่า ห่วงโซ่การโจมตีแบบ OAuth ที่ Vercel เปิดเผยนั้นเพียงพอให้เหตุการณ์นี้เกิดขึ้นได้ในทางเทคนิคอยู่แล้ว โดยไม่จำเป็นต้องมีระดับการเข้าถึงอย่างกว้างขวางตามที่ผู้โพสต์ในฟอรัมกล่าวอ้าง

การแมปกับ MITRE ATT&CK

• ห่วงโซ่การโจมตีที่ได้รับการยืนยันสามารถแมปเข้ากับ เทคนิค MITRE ATT&CK ที่มีอยู่ได้อย่างเป็นธรรมชาติ
• รายการการแมป
  • Initial Access / Trusted Relationship / T1199
    • ใช้แอป OAuth ของ Context.ai เป็นบุคคลที่สามที่ได้รับความไว้วางใจ
  • Persistence / Application Access Token / T1550.001
    • โทเค็น OAuth ยังคงใช้งานได้แม้หลังเปลี่ยนรหัสผ่าน
  • Credential Access / Valid Accounts / T1078
    • ข้อมูลรับรอง Workspace ของพนักงานที่ถูกเจาะ
  • Discovery / Account Discovery / T1087
    • การไล่ตรวจระบบภายในและโปรเจ็กต์ต่าง ๆ
  • Credential Access / Unsecured Credentials: Credentials in Files / T1552.001
    • สามารถเข้าถึงตัวแปรสภาพแวดล้อมที่ไม่ถูกจัดเป็นข้อมูลอ่อนไหวได้
  • Lateral Movement / Valid Accounts: Cloud Accounts / T1078.004
    • ความเป็นไปได้ในการใช้ข้อมูลรับรองคลาวด์ที่ถูกเปิดเผย
  • Collection / Data from Information Repositories / T1213
    • การไล่ดูตัวแปรสภาพแวดล้อมทั่วทั้งโปรเจ็กต์
• ในการแมปนี้ จุดตรวจจับที่มีคุณค่าสูงที่สุดคือ ช่วงที่เปลี่ยนผ่านจากการเข้าถึงผ่านแอปพลิเคชัน OAuth ไปสู่การเข้าถึงระบบภายใน
• องค์กรจำเป็นต้องเฝ้าติดตามพฤติกรรมผิดปกติของแอป OAuth ที่เข้าถึงทรัพยากรนอกเหนือจากขอบเขตที่คาดไว้ หรือจากช่วง IP ที่ไม่คาดคิด

การปิดล้อมซัพพลายเชน: LiteLLM, Axios, Vercel

• เหตุการณ์ของ Vercel ไม่ใช่กรณีเดี่ยว แต่เป็นส่วนหนึ่งของกระแสการโจมตีซัพพลายเชนที่กระจุกตัวในช่วงมีนาคม-เมษายน 2026
• บทความระบุว่านี่อาจเป็นแคมเปญที่มีการประสานงานกัน หรืออีกคำอธิบายที่มีแนวโน้มมากกว่าคือ ผู้โจมตีหลายรายค้นพบจุดอ่อนเชิงโครงสร้างเดียวกันพร้อมกัน ได้แก่ ขอบเขตความไว้วางใจระหว่าง package repository, CI/CD, ผู้ให้บริการ OAuth และแพลตฟอร์ม deployment

• 24 มีนาคม 2026: การเจาะซัพพลายเชน LiteLLM บน PyPI

  • มีการเผยแพร่แพ็กเกจ PyPI ที่เป็นอันตราย litellm 1.82.7 และ 1.82.8
  • ใช้ข้อมูลรับรองการ deploy ของ CI/CD ที่ขโมยมาจาก Trivy เครื่องสแกนช่องโหว่ของ Aqua Security
  • LiteLLM เป็น LLM proxy ที่มียอดดาวน์โหลดราว 3.4 ล้านครั้งต่อวัน
  • แบ็กดอร์ 3 ขั้นตอนมุ่งเป้าข้อมูลรับรองมากกว่า 50 ประเภท ครอบคลุมผู้ให้บริการคลาวด์รายใหญ่
  • รวมถึงความคงอยู่แบบ Kubernetes DaemonSet
  • ระยะเวลาที่แฝงตัวก่อนถูกตรวจพบและนำออกอยู่ที่ประมาณ 40 นาทีถึง 3 ชั่วโมง
  • CVE ที่เกี่ยวข้องคือ CVE-2026-33634

• 31 มีนาคม 2026: การเจาะซัพพลายเชน Axios บน npm

  • แพ็กเกจ npm axios มียอดดาวน์โหลดราว 70 ล้านถึง 100 ล้านครั้งต่อสัปดาห์
  • มีการปล่อยเวอร์ชันอันตราย 1.14.1 และ 0.30.4 จากการยึดบัญชีผู้ดูแลรักษา
  • มีการฉีด dependency plain-crypto-js@4.2.1 ซึ่งมี RAT ข้ามแพลตฟอร์มรวมอยู่ด้วย
  • ตรวจพบว่า endpoint ที่ติดเชื้อ 135 แห่งสื่อสารกับ C2 ของผู้โจมตี
  • ระยะเวลาการแฝงตัวอยู่ที่ 2-3 ชั่วโมง
  • Microsoft ระบุว่าการโจมตีนี้เป็นฝีมือของผู้ไม่หวังดีที่ได้รับการสนับสนุนจากเกาหลีเหนือชื่อ Sapphire Sleet

• รูปแบบที่มาบรรจบกัน

  • การโจมตี 3 ครั้งในช่วง 3 สัปดาห์
  • ใช้เวกเตอร์ต่างกัน
  • เป้าหมายร่วมกันคือ ข้อมูลรับรองและความลับ ที่นักพัฒนาเก็บไว้ใน toolchain
  • สรุปในตารางมีดังนี้
    • LiteLLM: ขโมยข้อมูลรับรอง CI/CD → PyPI, ข้อมูลรับรองนักพัฒนาและคีย์ API, 40 นาทีถึง 3 ชั่วโมง
    • Axios: ยึดบัญชีผู้ดูแลรักษา → npm, RAT บนเวิร์กสเตชันนักพัฒนา, 2-3 ชั่วโมง
    • Vercel: เจาะผ่านแอป OAuth → แพลตฟอร์ม, ตัวแปรสภาพแวดล้อมของลูกค้า, ในตารางระบุประมาณ 22 เดือน แต่มีการแก้ไขในส่วนต้นและเนื้อหาเป็นประมาณ 2 เดือน

รูปแบบร่วมกับการเจาะแพลตฟอร์มก่อนหน้า

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

• การเจาะ Codecov Bash Uploader, มกราคม-เมษายน 2021

  • ผู้โจมตีแก้ไขสคริปต์ Bash Uploader เพื่อทำให้ตัวแปรสภาพแวดล้อมในสภาพแวดล้อม CI ของลูกค้ารั่วไหล
  • ไม่ถูกตรวจพบเป็นเวลาประมาณ 2 เดือน
  • อาจกระทบลูกค้ามากกว่า 29,000 ราย รวมถึง Twitch, HashiCorp และ Confluent
  • จุดร่วมกับ Vercel คือ การเปิดเผยตัวแปรสภาพแวดล้อมของลูกค้าผ่านการเจาะแพลตฟอร์ม

• เหตุการณ์ด้านความปลอดภัยของ CircleCI, มกราคม 2023

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

• การโจมตีข้อมูลรับรองลูกค้า Snowflake, พฤษภาคม-มิถุนายน 2024

  • UNC5537 ใช้ข้อมูลรับรองที่ได้จาก infostealer และบัญชีที่ไม่มี MFA
  • กระทบองค์กรมากกว่า 165 แห่ง
  • รวมถึง Ticketmaster, Santander Bank และ AT&T

• การเจาะระบบสนับสนุนของ Okta, ตุลาคม 2023

  • ใช้ข้อมูลรับรองที่ขโมยมาเพื่อเข้าถึงระบบจัดการเคสสนับสนุนลูกค้า
  • อ่านโทเค็นเซสชันในไฟล์ HAR
  • กระทบลูกค้าอย่าง Cloudflare, 1Password และ BeyondTrust

• สรุปรูปแบบ

  • การเข้าถึงเริ่มต้นผ่านความสัมพันธ์ที่เชื่อถือได้หรือข้อมูลรับรอง
  • เคลื่อนที่ด้านข้างเข้าสู่ระบบภายใน
  • ความลับของลูกค้ารั่วไหล
  • ขอบเขตของเป้าหมายมีตั้งแต่บางเป้าหมายไปจนถึงทั้งแพลตฟอร์ม
  • ในตารางมีการสรุปเวกเตอร์เริ่มต้น ทรัพย์สินที่ถูกเปิดเผย และความล่าช้าในการตรวจจับของแต่ละเหตุการณ์
    • Codecov ประมาณ 2 เดือน
    • Okta หลายสัปดาห์
    • CircleCI หลายสัปดาห์
    • Snowflake หลายเดือน
    • Vercel ประมาณ 2 เดือน

สิ่งที่ยังไม่ได้เปิดเผย

• แม้จะมีรายงานสาธารณะและคำกล่าวของผู้บริหารจำนวนมาก แต่ก็ยังมีช่องว่างสำคัญอยู่
• คำถามที่ยังไม่ได้รับคำตอบจากบันทึกสาธารณะ
  • เวลาที่ Vercel ตรวจพบกิจกรรมผิดปกติเป็นครั้งแรก
  • เหตุผลของ ช่องว่าง 9 วัน ระหว่างหลักฐานการใช้ข้อมูลรับรองในทางมิชอบที่เก่าที่สุดซึ่งเปิดเผยต่อสาธารณะ กับการเปิดเผยข้อมูล
  • จำนวนลูกค้าที่ได้รับผลกระทบ
    • Rauch ใช้คำว่า “quite limited” แต่ไม่ได้เปิดเผยตัวเลขที่ชัดเจน
  • คำกล่าวอ้างในฟอรัมของ ShinyHunters มาจากผู้โจมตีรายเดียวกันหรือไม่
  • สถานะปัจจุบันของ Context.ai และมีการแจ้งลูกค้าปลายน้ำหรือไม่
  • ขอบเขตทั้งหมดของการเข้าถึงภายใน Vercel
    • ยังไม่เปิดเผยจำนวนทีมที่ได้รับผลกระทบ จำนวนโปรเจ็กต์ และจำนวนตัวแปรสภาพแวดล้อม
    • ยังไม่ยืนยันด้วยว่ามีการเข้าถึงระบบภายในอื่นนอกเหนือจากตัวแปรสภาพแวดล้อมของลูกค้าหรือไม่
• บทความเน้นว่า การยอมรับอย่างชัดเจนถึง สิ่งที่ยังไม่ได้เปิดเผย ควบคู่ไปกับข้อเท็จจริงที่ทราบแล้ว เป็นท่าทีที่จำเป็นต่อการวิเคราะห์อย่างเข้มงวด

คู่มือการตรวจจับและการล่า

• มาตรการเร่งด่วนสำหรับลูกค้า Vercel

  • จำเป็นต้องตรวจสอบตัวแปรสภาพแวดล้อมของทุกโปรเจ็กต์
  • ในบทความมีตัวอย่าง CLI ต่อไปนี้
    • vercel env ls --environment production
    • vercel env ls --environment preview
    • vercel env ls --environment development
  • ปัจจุบัน CLI ยังไม่แสดงแฟลก sensitive โดยตรง จึงต้องตรวจสอบผ่านแดชบอร์ดหรือ API

• ค้นหาการใช้งานข้อมูลรับรองที่รั่วไหลโดยไม่ได้รับอนุญาต

  • ค้นหา audit log ของผู้ให้บริการคลาวด์
    • AWS CloudTrail
      • ตัวกรอง eventSource ที่มี sts.amazonaws.com, iam.amazonaws.com, s3.amazonaws.com
      • ค้นหา userIdentity.accessKeyId ที่ตรงกับ access key ที่เก็บใน Vercel และถูกหมุนแล้ว
      • ตรวจจับ sourceIPAddress ที่อยู่นอก CIDR ที่องค์กรรู้จัก, userAgent เช่น python-requests, curl, Go-http-client และสตริง automation ที่ไม่คุ้นเคย
      • ช่วงเวลาคือตั้งแต่กุมภาพันธ์ 2026 ถึงปัจจุบัน
    • GCP Audit Logs
      • ค้นหา protoPayload.authenticationInfo.principalEmail ของ service account ที่ใช้คีย์ซึ่งเก็บไว้ใน Vercel
      • callerIp ที่อยู่นอกช่วงที่รู้จัก
      • ตรวจสอบเมธอดอย่าง storage.objects.get, compute.instances.list, iam.serviceAccountKeys.create
    • Azure Activity Logs
      • กรองตาม application ID หรือ service principal ที่เคยอยู่ใน Vercel env vars
      • callerIpAddress ที่อยู่นอกช่วงที่คาดไว้
      • ตรวจสอบ Microsoft.Storage/storageAccounts/listKeys, Microsoft.Compute/virtualMachines/write, Microsoft.Authorization/roleAssignments/write เป็นลำดับแรก
  • ค้นหา log การเข้าถึงฐานข้อมูล
    • ฐานข้อมูลทุกตัวที่มี connection string อยู่ในตัวแปรสภาพแวดล้อมของ Vercel
    • วิเคราะห์ทั้งช่วงตั้งแต่กุมภาพันธ์ถึงเมษายน 2026
    • ตรวจสอบ IP ที่อยู่นอกช่วง egress ที่รู้จัก เช่น Vercel edge IP, VPN, สำนักงาน
    • ตรวจจับการเชื่อมต่อที่ใช้ข้อมูลรับรองที่รั่วไหลนอกช่วงเวลาการ deploy ปกติ
    • PostgreSQL ใช้ pg_stat_activity, log_connections
    • MySQL ใช้ general log หรือ audit plugin
    • MongoDB Atlas ใช้เหตุการณ์ DATA_EXPLORER, CONNECT ใน Project Activity Feed
  • ค้นหา log ของระบบประมวลผลการชำระเงิน
    • Stripe Dashboard → Developers → Logs
    • source_ip ที่ไม่ได้มาจากเซิร์ฟเวอร์ที่คาดไว้
    • /v1/charges, /v1/transfers, /v1/payouts, /v1/customers
    • ตรวจสอบ log ที่เทียบเท่ากันของ Braintree และ Adyen
    • ให้ความสำคัญก่อนกับ API key ที่เก็บไว้ใน non-sensitive env var และยังไม่ได้หมุน
    • ตรวจสอบการส่งอีเมลที่ไม่คาดคิดใน log ของบริการส่งอีเมลด้วย
  • จำเป็นต้องตรวจสอบ การแจ้งเตือนข้อมูลรับรองรั่วไหลโดยไม่สมัครใจ จาก OpenAI, Anthropic, GitHub, AWS, Stripe เป็นต้น

• ต้องหมุนและ redeploy พร้อมกัน

  • ตามเอกสารของ Vercel การหมุนตัวแปรสภาพแวดล้อมเพียงอย่างเดียวไม่ได้ทำให้ค่าข้อมูลรับรองเดิมใน deployment เก่าหมดผล
  • deployment ก่อนหน้ายังคงใช้ข้อมูลรับรองเดิมต่อไปจนกว่าจะ redeploy
  • ดังนั้นการหมุนทุกครั้งจึงต้องมี การ redeploy ทุก environment ที่ใช้ตัวแปรนั้น หรือปิดใช้งาน deployment เก่าอย่างชัดเจน
  • ลำดับความสำคัญมีดังนี้
    • ข้อมูลรับรองของผู้ให้บริการคลาวด์
    • connection string ของฐานข้อมูล
    • คีย์ประมวลผลการชำระเงิน
    • secret สำหรับการยืนยันตัวตน
    • คีย์ API ของบุคคลที่สาม
    • โทเค็น monitoring และ logging

• มาตรการเชิงรุกสำหรับทีมความปลอดภัย

  • ตรวจสอบ OAuth app ที่ได้รับอนุมัติทั้งหมดใน Google Workspace Admin Console → Security → API Controls → Third-party app access
  • แสดงแอปที่มีสโคปกว้าง เช่น Drive, Gmail, Calendar
  • ตรวจสอบ vendor app ที่ไม่มีความสัมพันธ์ทางธุรกิจที่ยังใช้งานอยู่
  • เฝ้าระวังการใช้ OAuth token จากช่วง IP ที่ไม่คาดคิด
  • จำเป็นต้องค้นหา OAuth Client ID ที่เป็นอันตรายที่ทราบแล้ว
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

ตรรกะการตรวจจับใน SIEM

• สัญญาณผิดปกติของแอป OAuth, ขั้นที่ 1~2

  • แจ้งเตือนทันทีเมื่อพบเหตุการณ์ refresh token หรือ authorization ที่เกี่ยวข้องกับ OAuth Client ID อันตรายที่ทราบแล้ว
  • นำเหตุการณ์การให้สิทธิ์สโคปกว้าง เช่น เข้าถึงอีเมลทั้งหมด, อ่าน/เขียน Drive, เข้าถึง Calendar ไปเทียบกับรายการ vendor ปัจจุบัน
  • แอปที่ไม่ได้ใช้งานทางธุรกิจแล้วควรถูกเพิกถอน
  • หากพบการใช้โทเค็นของ OAuth app ที่อนุมัติแล้วจาก IP นอกช่วง CIDR ที่คาดไว้ขององค์กรและ vendor ต้องตรวจสอบ

• การเข้าถึงระบบภายในและการเคลื่อนที่ด้านข้าง, ขั้นที่ 3

  • เหตุการณ์ยืนยันตัวตน SSO/SAML ที่ผิดปกติ
    • กรณีบัญชี Workspace ที่ถูก compromise ล็อกอินเข้าแอปภายในจาก IP, ภูมิภาค หรือ device fingerprint ที่ไม่เคยเห็นมาก่อน
  • การรวบรวมข้อมูลรับรองผ่านอีเมลและ Drive
    • ค้นหาปริมาณมากด้วยคีย์เวิร์ดอย่าง API key, secret, token, password, .env
    • เข้าถึงที่เก็บข้อมูลรับรองที่ใช้ร่วมกัน, runbook ของวิศวกรรม, เอกสารโครงสร้างพื้นฐาน
    • สร้างกฎการส่งต่ออีเมล
  • การเข้าถึงเครื่องมือภายในผ่านการเชื่อมต่อ OAuth
    • มีการสร้างเซสชันหรือกิจกรรม API ใน Slack, Jira, GitHub, แดชบอร์ดภายใน ฯลฯ จากช่วงเวลาหรือโครงสร้างพื้นฐานที่ต่างจากปกติ
  • ความพยายามยกระดับสิทธิ์
    • เข้าร่วมกลุ่มหรือบทบาทใหม่
    • เข้าถึง admin console ที่ไม่เคยใช้
    • เฝ้าระวังการเรียกใช้ Directory API ของ Google Workspace, การเปลี่ยน delegation, ความพยายาม enumerate OAuth token ของผู้ใช้รายอื่น

• การ enumerate ตัวแปรสภาพแวดล้อม, ขั้นที่ 4

  • ตรวจจับรูปแบบปริมาณและความถี่ที่ผิดปกติของการเรียกแบบ env read, list, decrypt ใน Vercel team audit log
  • ก่อนอื่นต้องตั้งค่า baseline ของช่วงเวลาการ build ใน CI/CD ปกติ
  • จากนั้นแจ้งเตือนเมื่อการเข้าถึงในด้านปริมาณ เวลา และตัวตนต้นทางเบี่ยงเบนจาก baseline
  • ให้ความสำคัญกับการเข้าถึงจากบัญชีผู้ใช้ที่ไม่ใช่ service account และบัญชีที่ปกติไม่เคยโต้ตอบกับโปรเจ็กต์นั้น

• การใช้ข้อมูลรับรองปลายน้ำในทางที่ผิด, ขั้นที่ 5

  • ตรวจสอบ log ของบริการปลายทางทุกตัวสำหรับข้อมูลรับรองทั้งหมดที่เคยเก็บเป็น non-sensitive Vercel environment variables ในช่วงกุมภาพันธ์ถึงเมษายน 2026
  • สำหรับ AWS ให้ค้นหา CloudTrail ด้วย access key ID ที่เฉพาะเจาะจง
  • สำหรับ GCP และ Azure ให้ค้นหา audit log ด้วย service account หรือ application ID
  • สำหรับ SaaS API เช่น Stripe, OpenAI, Anthropic, SendGrid, Twilio ให้ตรวจสอบในแดชบอร์ดหรือ API log ว่ามีการใช้งานจาก IP ที่ไม่รู้จักหรือในช่วงเวลาที่ไม่ได้ใช้งานหรือไม่
  • หากไม่สามารถระบุได้ว่าเป็นการใช้งานจากโครงสร้างพื้นฐานของตนเอง ให้ถือเป็นข้อมูลรับรองที่ถูก compromise ทันที และต้องหมุนพร้อมตรวจสอบพฤติกรรม

• การแจ้งเตือนการรั่วไหลของข้อมูลรับรองจากบุคคลที่สาม

  • จำเป็นต้องเฝ้าติดตามการแจ้งเตือนการสแกน secret อัตโนมัติ เช่น GitHub secret scanning partner program, AWS compromised key detection, OpenAI, Anthropic, Stripe, Google Cloud
  • การแจ้งเตือนเกี่ยวกับคีย์ที่มีอยู่เฉพาะบนแพลตฟอร์ม deployment ไม่ควรถูกมองเป็นเพียงคำเตือนด้านสุขอนามัย แต่ต้องถือเป็น ตัวบ่งชี้การถูกเจาะระบบของแพลตฟอร์ม

ขั้นตอนการล่าภัยคุกคามแบบแมนนวล

• การค้นหาด้วยตนเองใน Google Workspace Admin Console

  • Admin Console → Reports → Audit and Investigation → OAuth Log Events
  • Application Name = Context.ai หรือ Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
  • ช่วงเวลาตั้งแต่เดือนกุมภาพันธ์ 2026 ถึงปัจจุบัน
  • หากพบผลลัพธ์ ต้องเพิกถอนสิทธิ์และตรวจสอบเหตุการณ์ทันที

• ตรวจสอบแอป OAuth ของบุคคลที่สามที่มีสโคปกว้าง

  • Admin Console → Security → API Controls → Third-party app access → Manage Google Services
  • จัดเรียงแอปที่ App access เป็น Unrestricted
  • รายการตรวจสอบสำหรับแต่ละแอป
    • มีความสัมพันธ์กับผู้ให้บริการอยู่จริงหรือไม่
    • สโคปมีความชอบธรรมทางธุรกิจหรือไม่
    • วันที่ใช้งานล่าสุด
  • แอปที่ไม่ได้ใช้งานเกิน 90 วันควรถูกเพิกถอน

คำแนะนำด้านการป้องกัน

• การดำเนินการทันที ภายใน 0~48 ชั่วโมง

  • หมุนเวียนตัวแปรสภาพแวดล้อม Vercel ทั้งหมดที่ไม่ได้ทำเครื่องหมายเป็น sensitive
  • หลังการหมุนเวียน ให้ redeploy ทุกสภาพแวดล้อม
  • เปิดใช้แฟล็ก sensitive กับตัวแปรสภาพแวดล้อมทั้งหมดที่มีข้อมูลรับรอง โทเค็น คีย์ หรือซีเคร็ต
  • ตรวจสอบการอนุมัติแอป OAuth ในคอนโซลผู้ดูแลระบบ Google Workspace หรือ Microsoft Entra
  • เพิกถอนการเข้าถึงของแอปที่ไม่ได้ใช้งานอย่างต่อเนื่องแล้ว
  • ตรวจสอบ access log ของทุกบริการที่ใช้ข้อมูลรับรองซึ่งเคยเก็บไว้ในตัวแปรสภาพแวดล้อม Vercel ตั้งแต่เดือนกุมภาพันธ์ 2026 ถึงปัจจุบัน

• การเสริมความแข็งแกร่งระยะสั้น ภายใน 1~4 สัปดาห์

  • ย้ายไปใช้ตัวจัดการซีเคร็ตโดยเฉพาะ เช่น HashiCorp Vault, AWS Secrets Manager, Doppler และ Infisical
  • ใช้วิธี inject ตอนรันไทม์แทนการจัดเก็บในตัวแปรสภาพแวดล้อมของแพลตฟอร์ม
  • ใช้ การยืนยันตัวตนแบบ OIDC เพื่อตัดข้อมูลรับรองระยะยาวในจุดที่รองรับ
  • นำการมอนิเตอร์แอป OAuth มาใช้
    • Nudge Security, Grip Security, Valence Security หรือความสามารถด้านการจัดการพื้นฐานของ Google Workspace
  • สร้างระบบอัตโนมัติสำหรับการหมุนเวียนข้อมูลรับรอง
    • แนะนำรอบเวลา 30~90 วัน
  • รวมการอนุมัติ OAuth ไว้ใน บัญชีรายการความเสี่ยงของบุคคลที่สาม เช่นเดียวกับผู้ให้บริการตามสัญญา

• การเปลี่ยนแปลงเชิงโครงสร้าง ภายใน 1~6 เดือน

  • ใช้แนวทาง Zero Trust กับตัวแปรสภาพแวดล้อม
    • ให้ถือว่าซีเคร็ตทั้งหมดที่เก็บไว้บนแพลตฟอร์ม deploy อาจถูกเปิดเผยได้หากแพลตฟอร์มถูกเจาะ
  • ใช้ขอบเขตสิทธิ์ให้น้อยที่สุด
    • บัญชี DB ให้มีสิทธิ์ขั้นต่ำ
    • จำกัดขอบเขตการดำเนินการของ API key
    • สำหรับข้อมูลรับรองคลาวด์ ให้ใช้ข้อมูลรับรองชั่วคราวแบบอิงบทบาทแทน access key ระยะยาว
  • ดำเนินการตรวจสอบความปลอดภัยของบุคคลที่สามและการทบทวนเป็นระยะ สำหรับแอป OAuth และการผสานรวมทั้งหมดที่เข้าถึงระบบยืนยันตัวตนขององค์กร
  • รวมแพลตฟอร์ม PaaS ไว้ในบัญชีรายการ SBOM/ASPM
    • ต้องปฏิบัติต่อมันไม่ใช่เป็นเพียงบริการภายนอก แต่เป็น การพึ่งพาห่วงโซ่อุปทานชั้นหนึ่ง

• การมอนิเตอร์ที่แนะนำ

  • ตรวจสอบ OAuth Client ID ข้างต้นใน Google Workspace Admin Console
  • มอนิเตอร์การเรียก API env.read, env.list ที่ไม่คาดคิดในบันทึกการตรวจสอบของ Vercel
  • ตรวจสอบใน CloudTrail, GCP Audit Logs และ Azure Activity Logs ว่ามีการใช้ข้อมูลรับรองที่เก็บใน Vercel env vars ช่วงเดือนกุมภาพันธ์~เมษายน 2026 จาก IP หรือ user agent ที่ไม่คาดคิดหรือไม่
  • หากใน dependency tree มี LiteLLM หรือ Axios ให้มอนิเตอร์ IOC ที่ระบุไว้ในคำแนะนำแต่ละฉบับด้วย
  • เฝ้าระวังการแจ้งเตือนข้อมูลรับรองรั่วไหลโดยไม่สมัครใจจากผู้ให้บริการ API รายสำคัญในช่วงเวลาที่มีการเปิดเผย

ผลกระทบด้านกฎระเบียบและการปฏิบัติตามข้อกำหนด

• องค์กรที่อาจประสบกับการเปิดเผยข้อมูลรับรองจากการเจาะครั้งนี้ จำเป็นต้องประเมินภาระผูกพันต่อไปนี้

• GDPR

  • หากข้อมูลรับรองที่ถูกเปิดเผยทำให้เข้าถึงระบบที่มีข้อมูลส่วนบุคคลของสหภาพยุโรปได้ นาฬิกาการแจ้งเตือนภายใน 72 ชั่วโมงอาจเริ่มนับจากเวลาที่ยืนยันการเปิดเผย
  • การแจ้งเตือนของ OpenAI เมื่อวันที่ 10 เมษายน ทำให้เกิดคำถามว่าบางองค์กรอาจรับรู้เหตุการณ์ก่อนการเปิดเผยสาธารณะในวันที่ 19 เมษายนหรือไม่

• CCPA/CPRA

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

• PCI DSS

  • หากมีการเปิดเผยข้อมูลรับรองที่ใช้ประมวลผลการชำระเงิน เช่น Stripe, Braintree, Adyen อาจต้องใช้กระบวนการตอบสนองต่อเหตุการณ์และการตรวจสอบทางนิติวิทยาศาสตร์

• SOC 2

  • ต้องสะท้อนบันทึกเหตุการณ์ มาตรการหมุนเวียนข้อมูลรับรอง และการควบคุมที่อัปเดตแล้ว ไว้ในหลักฐานการมอนิเตอร์อย่างต่อเนื่อง

• SEC Cybersecurity Rules 8-K

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

ตัวบ่งชี้การเจาะระบบ

• IoC ที่ยืนยันแล้ว

  • OAuth Client ID
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
    • ค่าที่เชื่อมโยงกับแอปพลิเคชัน OAuth ของ Context.ai ที่ถูกเจาะ

[GN⁺]

ความเห็นจาก Hacker News

• ทำให้นึกขึ้นได้ว่าตอนที่ Vercel เปิดตัว UI สำหรับ environment variables ครั้งแรกนั้นยังไม่มี ตัวเลือก sensitive เลย กว่าจะเพิ่มฟีเจอร์นี้เข้ามาก็กินเวลาเกือบเกิน 2 ปีแล้ว การพูดคุยที่เกี่ยวข้องยังอยู่ใน GitHub discussion และ Vercel changelog

  • ต่อให้ติด sensitive flag ไว้ใน UI ก็ไม่ได้หมายความว่า runtime จะเปลี่ยนไป พอค่าถูกใส่เข้า process.env ตอน build แล้ว ถ้ามี dependency ที่พยายามส่องดูก็อ่านได้อยู่ดี ปัญหาจริงคือการเอาค่าลับทั้งหมดไปกองไว้ในถุง env ใบเดียวแล้วส่งทั้งก้อนให้ build tool มากกว่า Cloudflare แบบ scoped bindings หรือ Fly แยกส่วนนี้ไปแล้ว และมองว่าแพลตฟอร์มอื่นช้ากว่า
  • มองว่า sensitive ไม่ได้แปลว่าอ่านไม่ได้ แต่หมายถึงแค่ ไม่แสดงใน UI เท่านั้น ถ้า action function หรือ route คืน props มากเกินนิดเดียวก็รั่วได้ง่ายอยู่ดี ถ้าจะกันปัญหาประเภทนี้จริง ๆ สุดท้ายก็คงต้องเข้ารหัสค่า environment ด้วยคีย์ของตัวเอง และเพราะไม่มีวิธีแยกที่เหมาะนัก ก็อาจใช้ทางอ้อมด้วยการ bake-in ความลับบางส่วนไว้ในซอร์สแทนได้ ผู้โจมตีจะไม่ได้แค่อ่านค่า env แต่ต้องดาวน์โหลดผลลัพธ์จากการ build แล้วหาคีย์ถอดรหัสอีกที ทำให้กำแพงสูงขึ้นเล็กน้อย ไม่ใช่วิธีที่ ideal แต่ดูเหมือนใช้เป็นมาตรการชั่วคราวได้

• เหตุการณ์ที่โดนด้วยวิธีนี้ให้ความรู้สึกว่าเป็น อุบัติเหตุที่น่าอายมาก ตามข้อความที่อ้างมา จุดที่ชวนอึดอัดเป็นพิเศษคือดูเหมือนการติด Lumma Stealer จะเริ่มจากพนักงาน Context.ai ดาวน์โหลด Roblox exploit script

• ตอนที่ CEO ออกมาบอกต่อสาธารณะว่าการเคลื่อนไหวอย่างรวดเร็วของผู้โจมตีเกิดจาก เทคนิคการโจมตีที่เร่งด้วย AI นั้น ในมุมผมแทบไม่เห็นหลักฐานรองรับเลย จึงให้ความรู้สึกว่าแทบไม่มีข้อมูลที่เป็นรูปธรรมถูกเปิดเผยจริง ๆ

  • ทุกวันนี้ AI ดูเหมือนกำลังปั่นป่วนแม้แต่ ตลาดข้อแก้ตัวเหลวไหล และสื่อก็ดูเหมือนจะเอาไปทวนซ้ำโดยไม่ตรวจสอบอย่างเย็นชา
  • อีกด้านหนึ่งมันก็ทำให้นึกถึงแนวโน้มที่โซลูชันแบบ vibe coded มักแนะนำ Vercel บ่อย ๆ คล้ายกับกระแสแนะนำ Axios ในอดีต

• ผมไม่ค่อยเข้าใจคำอธิบายของ Stage 2 ถ้าแอป ContextAI ขอสิทธิ์ Google mail, drive, calendar ครบหมด ก็มองว่าเกินความจำเป็นมาก ไม่ใช่บริษัทเล็ก ๆ ด้วย เลยยากจะเชื่อว่ามีคนยอมให้รันสิ่งนี้นอกสภาพแวดล้อมของตัวเอง แต่พอไปอ่าน โพสต์อัปเดตความปลอดภัย ของ Context.ai ก็เหมือนจะสื่อว่าพนักงาน Vercel คนหนึ่งเป็นคนตัดสินใจอนุญาตให้เข้าถึง Google Workspace ทั้งชุดของตัวเองเป็นการส่วนตัว

• ผมยังจับภาพไม่ค่อยออกว่ากระบวนการนี้ทำงานอย่างไรกันแน่ OAuth token ที่พูดถึงตรงนี้คือโทเคนที่ได้หลัง Sign in with Google หรือเปล่า ปกติมันไม่ได้ถูกผูกกับ client id และ client secret ของ Google App ตัวใดตัวหนึ่งหรอกหรือ ต่อให้ผู้โจมตีรู้ทั้ง OAuth token ของผู้ใช้และข้อมูล client ก็ยังพอเข้าใจได้แค่ว่าใช้เข้าถึง Drive อะไรพวกนั้นได้ แต่จากตรงนั้นมันไปสู่การล็อกอินเข้า control plane ของ Vercel ได้อย่างไรยังไม่ค่อยสมเหตุสมผล สุดท้ายคือไปเจอข้อมูลรับรองอยู่ใน Google Drive หรือไม่

  • รู้สึกว่ารายงานไม่ได้พูดส่วนนั้นให้ชัด จนยิ่งทำให้เดาว่าอาจมี ความผิดพลาดที่น่าอายกว่าเดิม และกำลังถูกปกปิดอยู่ อาจเป็นรหัสผ่านใน Drive หรือ Gmail หรืออาจเป็น passwordless login link อย่างที่คอมเมนต์อื่นว่าไว้
  • พอจบกระบวนการ OAuth แล้ว สุดท้ายก็จะได้ session token มา และใช้มันยิง API request ได้ ดูเหมือนนี่จะเป็นแกนหลักของคำอธิบาย มีความเป็นไปได้สูงว่าโทเคนที่ออกให้มีสิทธิ์เข้าถึง inbox ของเหยื่อด้วย ผู้โจมตีจึงอ่านอีเมลเพื่อเอารหัสผ่านใช้ครั้งเดียว magic link หรือข้อมูลอ่อนไหวอื่น ๆ ได้
  • ผมก็ยังงงเหมือนกัน สรุปแล้วคือแอป OAuth ของ Context.ai ถูกเจาะจริงหรือเปล่า แล้วถ้าใช่ ผู้โจมตีก็ได้การมองเห็น workspace ของลูกค้าทั้งหมดที่ Context.ai เคยเห็นไปด้วยใช่ไหม แต่ก็ยังสงสัยว่าทำไมความรับผิดถึงไปกองอยู่ที่พนักงานคนเดียว สุดท้ายประเด็นหลักน่าจะอยู่ที่ว่าพนักงาน Vercel คนนั้นไปอนุมัติให้ Context.ai อ่าน workspace ทั้งหมดของ Vercel หรือไม่

• เห็นด้วยกับประโยคที่ว่า “ควรปฏิบัติต่อแอป OAuth เหมือน vendor ภายนอก ตัดความลับระยะยาวของแพลตฟอร์มทิ้ง และออกแบบโดยสมมติว่ามี provider-side compromise ได้” แต่ก็รู้สึกว่าการออกแบบโดยตั้งต้นว่าฝั่งผู้ให้บริการอาจถูกเจาะได้เป็นเรื่องยากมาก เพราะสุดท้ายความเชื่อใจก็คือจุดตั้งต้นของระบบอยู่ดี

  • ยิ่งทำ SaaS และต้องคิดเรื่องแอป OAuth ด้วย ก็ยิ่งรู้สึกว่าเป็น ปัญหาที่ยากมาก อยากรู้เหมือนกันว่ามี marketplace ไหนแก้เรื่องนี้ได้ดี Cloudflare เคยเสนอหลังเหตุ Salesloft ว่าให้ proxy OAuth และ API traffic จาก third party ทั้งหมดผ่านตัวเอง แต่ก็ให้ความรู้สึกเหมือนย้าย threat vector ไปอีกที่หนึ่ง นอกจากหลักพื้นฐานอย่างลด scope ให้แคบที่สุด ลดอายุการใช้งาน และ rotate client secret แล้ว ก็ยังนึกไม่ออกว่าทำอะไรได้อีก อาจพอนึกถึง allowlist IP ต้นทางของ request แยกตาม client
  • พอเห็นกรณีแบบนี้ก็ทำให้นึกว่า zero-trust ที่พูดกันมาจนถึงตอนนี้ ส่วนหนึ่งอาจเป็นแค่ภาษาการตลาด ถ้าจะเป็น security by design จริง ก็ต้องใส่สมมติฐานตั้งแต่แรกว่าการโจมตีแบบ supply chain อาจทำให้ผู้ให้บริการต้นน้ำถูกเจาะจนหมดได้

• มองว่าเหตุการณ์แบบนี้ต่อจากนี้จะเกิดอีกเยอะมาก ไม่ว่าจะเป็นบริษัทใหญ่หรือเล็ก เพราะตอนนี้ทั้งเศรษฐกิจ IT กำลังทยอยเจอ หนี้ความเสี่ยง จากการทดลองใช้เครื่องมือ AI อย่างกว้างขวางแบบล่าช้า เลยอ่านเรื่องนี้ว่าไม่ใช่ “AI-enabled tradecraft” เท่าไร แต่เป็นผลจากผู้นำองค์กรกดดันให้ติดตั้งและทดลองเครื่องมือ AI ทั้งบริษัทโดยอ้างเรื่องความเร็ว การโจมตีแบบนี้ธรรมดามาก และถ้าบริษัทไหนไม่มี allowlist สำหรับการติดตั้ง AI ที่บังคับใช้ได้ ก็แทบเปิดช่องไว้เหมือนกัน ถ้าไปถามทีม IT ว่าเครื่องมืออย่าง Context ถูกติดตั้งไว้แค่ไหนทั้งบนเครื่อง local และใน SaaS ต่าง ๆ ก็มีโอกาสสูงว่าจะเยอะพอสมควร ปัญหาคือเครื่องมือพวกนี้แทบเข้าถึงได้ทุกอย่าง และ ecosystem ของ security vendor หรือ RBAC ที่จะมาคุมเรื่องนี้จริงจังน่าจะต้องรออีก 18~24 เดือน Vercel ดูเหมือน นกคีรีบูนในเหมืองถ่านหิน และไม่น่าใช่ว่า Context จะเป็นเป้าหมายเดียว ถ้าที่หนึ่งแตก ที่อื่นก็น่าจะทยอยโผล่ตามมาได้ เพราะมันเป็น threat vector ที่รู้กันอยู่แล้วแต่ถูกเมินมาตลอด อีก 6 เดือนข้างหน้าอาจยากเป็นพิเศษ และทุกคนน่าจะกำลัง audit หรือควรจะ audit การติดตั้ง AI ของตัวเองอยู่ตอนนี้ ขณะที่ผู้โจมตีก็จะรีบเคลื่อนไหวด้วยสิทธิ์ที่มีอยู่ก่อนจะถูกตัดทิ้ง อ้างอิงไว้ก่อนว่าผมเป็นหัวหน้าฝ่ายความปลอดภัยในวงการ tech

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

• พออ่านสรุปที่ว่า “ความสัมพันธ์ความเชื่อใจของ OAuth ลามจนเปิดทั้งแพลตฟอร์ม, CEO โยนความเร็วของการโจมตีให้ AI, และความล่าช้าตั้งแต่การตรวจพบจนถึงการเปิดเผยก็ยังน่ากังขา” ก็รู้สึกว่าแกนของความล้มเหลวที่เห็นเป็นเรื่องคลาสสิกมาก มีบัญชีผู้ใช้ที่ มีสิทธิ์มากเกินไป และอาจมีบัญชีลักษณะเดียวกันอีก อาจไม่มี 2FA หรือ ZeroTrust เลย หรือมีอย่างจำกัดมาก สุขอนามัยด้านความปลอดภัยโดยรวมก็ดูไม่ดีนัก

  • ต่อไปการโทษ AI คงกลายเป็นข้ออ้างสารพัดประโยชน์เวลาเกิดเหตุความปลอดภัย คล้ายกับสมัยที่เว็บล่มแล้วโทษ DDoS ไว้ก่อนทุกครั้ง

• มีจุดหนึ่งที่คนมักมองข้าม ต่อให้ rotate environment variables บน Vercel แล้ว deployment เก่าไม่ได้ถูกทำให้ใช้ไม่ได้อัตโนมัติ ดังนั้น deploy ก่อนหน้าจะยังรันด้วยข้อมูลรับรองเก่าต่อไปจนกว่าจะ redeploy หรือลบทิ้ง เพราะฉะนั้นถึงจะเปลี่ยนคีย์หลังมีประกาศแล้ว ถ้ายังไม่ได้ปล่อยทุก deployment ใหม่ ค่าเดิมที่รั่วก็อาจยังมีผลอยู่ และคิดว่าควรตรวจสอบรายการ OAuth approvals ใน Google Workspace ด้วย ที่ Admin Console > Security > API Controls > Third-party app access มีโอกาสสูงว่าแอปที่เคยอนุมัติไว้เพราะเดโมเมื่อ 2 ปีก่อน ยังถือสิทธิ์เข้าถึง Mail และ Drive ทั้งหมดอยู่

  • เราเลยแยกใช้ หลายบัญชี Google ด้วยเหตุผลนี้ แต่หลายองค์กรก็ทำแบบนั้นไม่ได้เพราะค่าใช้จ่ายต่อผู้ใช้ของ Google Workspace ผมเองก็เคยพยายามเสนอที่ทำงานเก่าว่าควรให้ OAuth approval แบบนี้ผ่านบัญชีแยก ไม่ใช่บัญชีหลัก แต่ไม่สำเร็จ
  • ปกติถ้าพูดถึง credential rotation ก็จะนึกว่าต้องรวม การทำให้ข้อมูลรับรองเดิมใช้ไม่ได้ ด้วย วิธีที่แค่สร้างของใหม่แล้วปล่อยของเก่าไว้ต่อแทบไม่ค่อยได้ยิน
  • ประโยคในรายงานตรงนั้นทำให้ผมสับสนมากเหมือนกัน เพราะการที่ deployment เก่ายังใช้ env var เดิมอยู่ ไม่ได้เป็นตัวตัดสินว่าข้อมูลรับรองนั้นยังใช้ได้อยู่หรือไม่ มันเลยดูเป็น footgun ที่กระทบด้านความพร้อมใช้งานมากกว่าความลับ ส่วน “Environment variable enumeration (Stage 4)” ในรายงานก็อ่านแล้วแปลก โดยเฉพาะตรงที่บอกว่า “ให้ดูว่ามีการเข้าถึง environment variables จาก service account หรือจากบัญชีที่ปกติไม่เคยโต้ตอบกับโปรเจกต์นั้นหรือไม่” ทำให้รู้สึกแปลกว่าคนจำนวนมากกำลังดึงข้อมูลรับรองจาก Vercel env var ไปใช้ในระบบอื่นจริงหรือ
  • Preview deploy ดูหนักกว่าอีก เพราะทุก PR จะมีตัวหนึ่งขึ้นมาพร้อม env var ชุดเดิม และไม่มีใครเก็บกวาด ต่อให้ rotate คีย์แล้ว redeploy prod ก็ยังอาจมี preview ซอมบี้หลายร้อยตัวที่ฝังค่าเก่าไว้
  • เวลาทำ rotation ก็ควรต้องรวม การหมดอายุของตัวแปรเดิม ไว้ด้วยอยู่แล้ว

• รายละเอียดบางส่วนในรายงานนี้ โดยเฉพาะ ไทม์ไลน์ ที่เริ่มตั้งแต่ 2024~2025 ให้ความรู้สึกเหมือนเป็นข้อมูลที่ไม่ได้ถูกสื่ออื่นรายงานอย่างแพร่หลาย เช่น “ปลายปี 2024~ต้นปี 2025 ผู้โจมตี pivot จากการเข้าถึง OAuth ของ Context.ai ไปยังบัญชี Google Workspace ของพนักงาน Vercel” หรือ “ต้น~กลางปี 2025 เริ่มเข้าถึงระบบภายในของ Vercel และ enumerate environment variables ของลูกค้า” เลยสงสัยว่าวันที่พวกนั้นมาจากไหน

  • ในมุมผม วันที่เหล่านั้นน่าจะเป็น ข้อมูลที่แต่งขึ้นทั้งหมด และมีโอกาสสูงว่าเป็น hallucination