Vercel ยืนยันเหตุละเมิดความปลอดภัย แฮกเกอร์อ้างว่ากำลังขายข้อมูลที่ขโมยมา
(bleepingcomputer.com)- Vercel ยืนยันอย่างเป็นทางการว่าเกิดเหตุความปลอดภัยจากการเข้าถึงระบบภายในโดยไม่ได้รับอนุญาต และขณะนี้กำลังร่วมมือกับผู้เชี่ยวชาญด้านการรับมือเหตุการณ์และหน่วยงานบังคับใช้กฎหมาย
- สาเหตุของการเจาะระบบมาจากแอป Google Workspace OAuth ของเครื่องมือ AI ฝั่งที่สาม Context.ai ถูกบุกรุก จนนำไปสู่การยึดบัญชีพนักงานของ Vercel
- ผู้โจมตีได้ไล่ดู ตัวแปรสภาพแวดล้อมที่ไม่ใช่ข้อมูลอ่อนไหว (non-sensitive) เพื่อให้ได้สิทธิ์เข้าถึงเพิ่มเติม โดยตัวแปรเหล่านี้ถูกเก็บไว้ในสถานะที่ไม่เข้ารหัส
- แฮกเกอร์ที่อ้างตัวว่าเป็น ShinyHunters โพสต์ในฟอรัมแฮกกิ้งว่ากำลังขายคีย์เข้าถึง ซอร์สโค้ด ข้อมูลฐานข้อมูล API key และอื่น ๆ พร้อมเรียก ค่าไถ่ 2 ล้านดอลลาร์
- Vercel ยืนยันแล้วว่า ความปลอดภัยของโครงการโอเพนซอร์ส เช่น Next.js และ Turbopack ไม่ได้รับผลกระทบ พร้อมแนะนำให้ลูกค้าตรวจสอบตัวแปรสภาพแวดล้อมและเปิดใช้ฟีเจอร์ตัวแปรที่ละเอียดอ่อน
ภาพรวมของเหตุการณ์ความปลอดภัย
- Vercel เป็นแพลตฟอร์มโครงสร้างพื้นฐานสำหรับโฮสต์และดีพลอยบนคลาวด์ที่เน้น JavaScript framework โดยเป็นผู้พัฒนา Next.js และให้บริการ serverless functions, edge computing และ CI/CD pipeline
- บริษัทได้ยืนยันอย่างเป็นทางการผ่านประกาศด้านความปลอดภัยว่าเกิด การเข้าถึงโดยไม่ได้รับอนุญาต (unauthorized access) ต่อระบบภายใน
- ระบุว่ามีลูกค้าเพียงบางส่วนเท่านั้นที่ได้รับผลกระทบ และตัวบริการเองไม่ได้รับผลกระทบ
- บริษัทได้ว่าจ้างผู้เชี่ยวชาญด้านการรับมือเหตุการณ์และ แจ้งหน่วยงานบังคับใช้กฎหมาย แล้ว และกำลังดำเนินการสอบสวน
เส้นทางการเจาะระบบและรายละเอียดทางเทคนิค
- ต้นตอหลักของการเจาะระบบคือ Google Workspace OAuth app ของแพลตฟอร์ม AI บุคคลที่สาม Context.ai ถูกบุกรุก
- Guillermo Rauch ซีอีโอของ Vercel เปิดเผยรายละเอียดเพิ่มเติมบน X (ชื่อเดิม Twitter)
- ผู้โจมตีเข้ายึดบัญชี Google Workspace ของพนักงาน Vercel ผ่านการเจาะระบบ Context.ai
- จากนั้นจึง ยกระดับสิทธิ์การเข้าถึง (escalate) จากบัญชีนั้นเข้าสู่สภาพแวดล้อมของ Vercel
- ผู้โจมตีเข้าถึง ตัวแปรสภาพแวดล้อมที่ถูกระบุว่า "ไม่ใช่ข้อมูลอ่อนไหว (non-sensitive)" ซึ่งตัวแปรเหล่านี้ถูกเก็บไว้แบบไม่เข้ารหัสขณะพักข้อมูล (not encrypted at rest)
- Vercel ระบุว่าตัวแปรสภาพแวดล้อมของลูกค้าทั้งหมดถูกเก็บแบบ เข้ารหัสเต็มรูปแบบขณะพักข้อมูล (fully encrypted at rest) และมีระบบป้องกันหลายชั้น แต่ตัวแปรที่ถูกตั้งค่าเป็น "non-sensitive" กลับกลายเป็นจุดอ่อน
- Vercel แนะนำให้ผู้ดูแล Google Workspace ตรวจสอบ OAuth app ต่อไปนี้:
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
แฮกเกอร์อ้างว่ากำลังขายข้อมูล
- ผู้ไม่หวังดีที่อ้างตัวว่าเป็น ShinyHunters ได้โพสต์ในฟอรัมแฮกกิ้งเกี่ยวกับการเจาะ Vercel และการขายข้อมูล
- รายการที่อ้างว่าขาย: คีย์เข้าถึง, ซอร์สโค้ด, ข้อมูลฐานข้อมูล, สิทธิ์เข้าถึงการดีพลอยภายใน และ API key (รวมถึง NPM token และ GitHub token)
- อ้างว่ามีสิทธิ์เข้าถึงบัญชีพนักงานจำนวนมาก พร้อมยกข้อมูลของ Linear มาเป็นหลักฐาน
- ผู้ไม่หวังดีรายอื่นที่เคยถูกเชื่อมโยงกับกลุ่ม ShinyHunters ปฏิเสธกับ BleepingComputer ว่า ไม่เกี่ยวข้อง กับเหตุการณ์ครั้งนี้
- ไฟล์ข้อความที่ผู้โจมตีแชร์มีข้อมูลพนักงาน Vercel 580 รายการ ประกอบด้วยชื่อ อีเมล Vercel สถานะบัญชี และ timestamp ของกิจกรรม
- มีการแชร์ภาพหน้าจอที่ดูเหมือนจะเป็น แดชบอร์ด Vercel Enterprise ภายในด้วย
- BleepingComputer ระบุว่า ไม่สามารถยืนยันความถูกต้องได้อย่างอิสระ ของข้อมูลและภาพหน้าจอเหล่านั้น
- ในข้อความ Telegram ผู้ไม่หวังดีอ้างว่ากำลังติดต่อกับ Vercel และได้เรียก ค่าไถ่ (ransom) 2 ล้านดอลลาร์
การตอบสนองของ Vercel และคำแนะนำต่อลูกค้า
- Vercel ยืนยันว่า Next.js, Turbopack และโครงการโอเพนซอร์สอื่น ๆ ยังคงปลอดภัย
- บริษัทได้ปล่อย หน้าภาพรวม ของตัวแปรสภาพแวดล้อมบนแดชบอร์ด และ อินเทอร์เฟซที่ปรับปรุงใหม่ สำหรับจัดการตัวแปรสภาพแวดล้อมที่ละเอียดอ่อน
- มาตรการที่แนะนำให้ลูกค้าดำเนินการ:
- ตรวจสอบตัวแปรสภาพแวดล้อม (environment variables)
- เปิดใช้ ฟีเจอร์ตัวแปรสภาพแวดล้อมที่ละเอียดอ่อน (sensitive environment variable feature) เพื่อรับประกันการเข้ารหัสเมื่อไม่ได้ใช้งาน
- ดำเนินการ หมุนเวียนซีเคร็ต (secret rotation) หากจำเป็น
3 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เพิ่งมีการอัปเดตประกาศ และจุดสำคัญคือมีการระบุว่าการละเมิดเริ่มต้นจากการที่ Google Workspace OAuth app ของ เครื่องมือ AI ฝั่งที่สาม ถูกเจาะ
มีการเปิดเผย IOC เพื่อช่วยในการตรวจสอบด้วย และบอกว่าถ้าเป็นผู้ดูแลระบบควรตรวจสอบทันทีว่าใช้แอปนี้อยู่หรือไม่
OAuth App คือ
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.comและอ่านต้นฉบับได้ที่ ประกาศด้านความปลอดภัยของ Vercelโดยเฉพาะคำอธิบายที่บอกว่าสามารถเข้าถึงเพิ่มเติมได้ผ่านการไล่ดู ตัวแปรสภาพแวดล้อมที่ไม่ sensitive นั้นสะดุดตามาก และยังมีการคาดเดาด้วยว่าผู้โจมตีอาจเป็นกลุ่มที่มีความซับซ้อนสูงซึ่งถูกเร่งความเร็วอย่างมากด้วย AI
ถึงอย่างนั้น การที่ยังไม่มี อีเมลแจ้งเตือน ถึงผู้ใช้ก็ยังน่ากังวลมาก
เข้าใจได้ว่าอาจไม่อยากระบุตัวอีกฝ่ายตรง ๆ แต่การซ่อนชื่อบริการกลับให้ความรู้สึกว่าทำให้การรับมือช้าลง
ทุกวันนี้แทนที่จะสร้างบนฐานที่มั่นคง การเอา บริการฝั่งที่สามหลายตัวมาประกอบกัน กลายเป็นเรื่องปกติเกินไป และยิ่งทำให้มีจุดล้มเหลวมากขึ้น
สุดท้ายก็ย้ำอีกครั้งว่าความปลอดภัยแข็งแกร่งได้เท่ากับห่วงโซ่ที่อ่อนแอที่สุดเท่านั้น และโดยเฉพาะการเอาธุรกิจไปวางบนเครื่องมือ AI ที่ให้ความรู้สึกแบบ vibe-coded นั้นเป็นความเสี่ยงชัดเจน
เลยทำให้ต้องถามตัวเองว่าควรผลักดันแนวทางนี้ต่อไปจริงหรือ และความซับซ้อนต้องเพิ่มอีกแค่ไหนถึงจะย้อนกลับมาทบทวนกัน
จาก การวิเคราะห์สแต็กแนะนำของ Claude Code รู้สึกว่า Claude Code กำลังทำให้เว็บ เป็นแบบเดียวกันมากขึ้น โดยแนะนำผู้ให้บริการและเฟรมเวิร์กบางรายเป็นค่าเริ่มต้น
การขาดความหลากหลายแบบนี้ดูเหมือนจะยิ่งทำให้ รัศมีผลกระทบ ใหญ่ขึ้นเมื่อเกิดปัญหา
ให้ความรู้สึกว่าแทบจะกลายเป็นตัวเลือกตั้งต้นไปแล้ว
พอบอกว่าเอาแบบ ไม่มี Node มันก็เขียนใหม่เป็น Python backend ให้ทันที และยังอธิบายเองด้วยว่าปรับไปทางลด dependency
อ้างอิงไว้ก่อนว่านี่เป็นแค่การทดลองเพื่อให้ได้ผลลัพธ์ที่ตั้งใจจะทิ้งอยู่แล้ว ไม่ได้จะมาแนะนำ vibe coding
ท้ายที่สุดมันเป็นปัญหาเรื่อง วิธีใช้งาน และควรช่วยชี้นำให้นักพัฒนาไม่ปล่อยให้ Claude เป็นคนตัดสินใจแทน
รับคำแนะนำได้ แต่สุดท้ายมนุษย์ต้องตรวจทานอย่างมีวิจารณญาณ และในแง่นี้ก็รู้สึกว่าไม่ได้ต่างจากการทำงานร่วมกับเพื่อนร่วมทีมคนอื่นมากนัก
อินเทอร์เน็ตเดิมทีก็มีแนวโน้มแบบนั้นอยู่แล้ว แต่ครั้งนี้ให้ความรู้สึกต่างออกไปเล็กน้อย
ในฐานะคนที่เคยอยู่ทีมรับมือเหตุการณ์ด้านความปลอดภัยมาก่อน ก็เข้าใจได้ว่าทีมรับมือครั้งนี้คงลำบากแค่ไหน
ถึงอย่างนั้น ประกาศแรกก็ดูเป็น การสื่อสารที่แย่มาก จริง ๆ
ไม่บอกว่าเกิดอะไรขึ้น แต่ใช้ถ้อยคำทำนองว่าร้ายแรงถึงขั้นต้องแจ้งหน่วยงานบังคับใช้กฎหมาย ขณะที่คำแนะนำให้ลูกค้ามีแค่ประมาณว่า "ให้ตรวจสอบตัวแปรสภาพแวดล้อม"
แต่จากมุมลูกค้า มันคลุมเครือเกินไปว่าจะต้องทำอะไรกับข้อมูลนั้น จะให้ดูว่ายังคงมีค่าอยู่หรือไม่ หรือจะให้ตัดสินอย่างไรว่าเคยรั่วไหลไปแล้วหรือยัง
สำหรับผม ควรบอกไปเลยให้หมุนเปลี่ยนรหัสผ่าน access token และข้อมูลลับทั้งหมดที่ฝากไว้กับ Vercel ทันที แล้วตามด้วยคำแนะนำให้ตรวจสอบ access log และ audit ความผิดปกติของข้อมูลลูกค้า
เหตุผลที่ยอมจ่ายค่าโฮสติ้งแพง ๆ ก็เพราะคาดหวังว่าจะมีการ ดูแลความปลอดภัยและความเสถียรอย่างมืออาชีพ แต่ตอนนี้แม้จะเผื่อความไม่แน่นอนในช่วงแรกไว้แล้ว ก็ยังดูคลุมเครือแบบตั้งใจเกินไป
แต่ถ้าค่าลับอย่าง API key, token, credential ของฐานข้อมูล หรือ signing key ไม่ได้ถูกทำเครื่องหมายว่า sensitive ก็ควรมองว่ามีโอกาสถูกเปิดเผยและควรเปลี่ยนก่อนเป็นลำดับแรก
แหล่งข้อมูลคือ incident page และตอนที่ผมดูคือ 16:22 น. ตามเวลาฝั่งตะวันออก
เป็นลูกค้าที่จ่ายเงินมานานกว่าปีแล้ว แต่กลับได้ข่าวจาก news aggregator ก่อน อีเมลจากบริษัท เอง มันชวนงงมาก
ดูบริบทได้จาก HN thread และ ปฏิกิริยาตอนนั้น
นอกนั้นส่วนใหญ่ให้ความรู้สึกว่าเป็นการเลือกที่ ชวนปัญหาเข้ามาเอง
แต่ตอนนี้ผมตัดสินใจแล้วว่าจะไม่พึ่งความสะดวกนั้นอีก และย้ายทั้งหมดจาก Render ไป linode แล้ว
เมื่อก่อนเคยจ่าย Render เกิน 50 ดอลลาร์ต่อเดือน ตอนนี้เหลือแค่ระดับ 3–5 ดอลลาร์ ดังนั้นแทบไม่คิดจะกลับไปใช้ผู้ให้บริการโฮสติ้งแบบนั้นอีกแล้ว
พอเห็นประโยคที่ว่า “Vercel ไม่ได้เปิดเผยว่าระบบใดถูกเจาะ” ก็รู้สึกว่าแม้ไม่ใช่ผู้เชี่ยวชาญด้านความปลอดภัย ท่าทีแบบนี้ก็ยัง ยอมรับได้ยาก พอสมควร
มันยังให้ความรู้สึกว่าพวกเขาเน้นป้องกันตัวเองมากกว่าช่วยให้ลูกค้าเข้าใจผลกระทบด้วย
ตัวอย่างเช่น ถ้าบอกว่า subsystem ย่อย X ที่ไม่ค่อยมีใครรู้จักใน GitHub ถูกเจาะ มันอาจไม่ได้ช่วยอะไรในทางปฏิบัติมากไปกว่าข้อมูลที่มีอยู่แล้วอย่าง “สภาพแวดล้อมของลูกค้าบางส่วนถูกกระทบ” ก็ได้
พอกลับไปดูว่ามีการเพิ่ม IOC ในประกาศ ก็ชัดเจนว่าจุดเริ่มของเหตุการณ์นี้คือการที่ Google Workspace OAuth app ถูกเจาะ และนี่เป็นข้อมูลสำคัญต่อชุมชนโดยรวมมาก
รู้สึกว่าผู้ดูแลระบบและเจ้าของบัญชีควรรีบตรวจสอบตัวระบุของแอปนั้นทันที และรายละเอียดเพิ่มเติมอยู่ใน ประกาศของ Vercel
ผมใช้ MacBook Pro กับ Chrome 147.0.7727.56 แล้วพอกดโลโก้ Vercel ที่มุมซ้ายบนของหน้า หน้าแอป Chrome ก็ crash ทันที
รู้สึกว่าเป็นบั๊กที่น่าสนใจทีเดียว
สถานการณ์ที่ทุกคนกำลังอ่านเรื่องที่ว่า Vercel อาจโดนเจาะอะไรบางอย่างอยู่ แล้วก็มาลองไล่ reproduce การ crash ของหน้าเว็บต่อ มันตลกดีแบบแปลก ๆ
แน่นอนว่าก็อดคิดไม่ได้ว่าการเล่นช่วยกัน reproduce แบบนี้ ไม่มีทางไม่ส่งผลเสีย
ผมอัดวิดีโอไว้ด้วย และใช้ uBlock Origin Lite เลยสงสัยว่าอาจเป็นสาเหตุ แต่พอปิดแล้วก็ยังไม่ crash อยู่ดี
ถ้ามัน reproduce ได้ก็คง น่าสนุกอยู่เหมือนกัน
จำได้ว่ามันเป็นอยู่พักหนึ่งก่อนจะถูกแก้ไขในที่สุด
แต่หลังจากเปิดหน้าแรกของ Vercel ผ่าน URL โดยตรงหนึ่งครั้งแล้ว กดโลโก้อีกก็ไม่ crash แล้ว
แต่ตอนนี้ก็เริ่มไม่ค่อยอยากกดปุ่ม Finish update แล้ว
กำลังดูข้อมูลที่เกี่ยวข้องอยู่ ทั้ง HN อีกเธรดหนึ่ง และโพสต์บน X หลายอัน
โพสต์แรกของ Theo บอกว่าดูน่าเชื่อถือ ส่วน โพสต์ถัดมา บอกว่า env var ที่ทำเครื่องหมายเป็น sensitive นั้นปลอดภัย และค่าที่ไม่ได้ทำเครื่องหมายก็ควรเปลี่ยนเพื่อความป้องกันไว้ก่อน
อีกทั้ง อีกโพสต์หนึ่ง ยังบอกว่าการแฮ็กประเภทนี้เกิดขึ้นได้กับโฮสต์ไหนก็ได้ และ อีกความเห็นหนึ่ง ก็พูดถึงความเป็นไปได้ว่าอาจเกี่ยวข้องกับ ShinyHunters
ถ้าต้องเปลี่ยนมันจริง ๆ แปลว่าเดิมทีมันก็เป็นข้อมูลลับอยู่แล้ว และควรถูกทำเครื่องหมายเป็น sensitive ตั้งแต่แรกไม่ใช่หรือ
ณ ตอนนี้ยังดูเหมือนไม่ได้มีเนื้อหาสาระที่จับต้องได้มากนัก
เหตุการณ์แบบนี้ทำให้นึกอีกครั้งว่า ecosystem เว็บยุคใหม่กระจุกตัวอยู่กับ single point of failure มากแค่ไหน
สิ่งที่เปิดเผยมาจนถึงตอนนี้ถือว่าค่อนข้างโปร่งใส แต่ก็ทำให้ต้องกลับมาคำนวณ โปรไฟล์ความเสี่ยง ใหม่ สำหรับการเลือกพึ่งพา fully managed PaaS แบบเต็มตัว
คำว่า “ลูกค้าจำนวนจำกัดบางส่วน” นั้นในเชิงเทคนิคจะหมายถึง 99% ก็ยังได้ เลยฟังดูเป็น ถ้อยคำที่คลุมเครือ มาก
ก็อดสงสัยไม่ได้ว่านี่อาจเป็นกรณีที่จริง ๆ แล้วลูกค้าจำนวนมากได้รับผลกระทบ แต่เรียกว่าเป็น subset เพียงเพราะเป็นกลุ่มลูกค้ารายใหญ่ที่เสียไปไม่ได้หรือเปล่า
ปกติถ้าปลอบใจได้จริงก็มักจะบอกเป็น ตัวเลขชัดเจน เช่น “น้อยกว่า 1% ของผู้ใช้” แต่ครั้งนี้ไม่ได้ทำแบบนั้น
เลยเดาว่าอาจยังมองภาพรวมไม่ออกดีพอ หรือไม่ก็ตัวเลขที่ได้ไม่น่าพอใจ
ถึงอย่างนั้นก็เข้าใจว่าทีมรับมือคงกำลังลำบากมาก และหวังว่าหลังจากนี้จะสื่อสารกันอย่างเปิดเผยและโปร่งใสมากขึ้น
ที่นี่ยังเห็นตัวอักษรภาษาฮินดีอีกนะครับ ช่วงหลังมานี้ไม่ว่าจะเป็น openai, claude, google ก็มักเกิดกรณีที่ output ภาษาเกาหลีมีภาษาฮินดีปนออกมาค่อนข้างบ่อย เลยสงสัยว่าการทำลาเบลชุดข้อมูลภาษาเกาหลีมีคนอินเดียเป็นคนช่วยทำหรือเปล่า?
เดิมทีผมไม่ชอบที่โมเดลจีนมักมีภาษาจีนปนมาในคำตอบภาษาเกาหลี แต่ช่วงหลังพอพวก frontier model ชอบปนภาษาฮินดีเข้ามาบ่อย ๆ กลับทำให้ความรู้สึกต่อต้านโมเดลจีนลดลงไปเสียอีก
ตอนฉันใช้ Claude ก่อนหน้านี้ มักจะมีภาษาญี่ปุ่นโผล่มาบ่อย ๆ เมื่อวานก็เป็นเหมือนกัน