วิเคราะห์และรีวิว: นักวิจัยใช้ Claude ของ Anthropic แฮ็กเข้าสู่ OpenAI

ทีมนักวิจัยความปลอดภัยสามคนจากสตาร์ทอัพ Hacktron AI ใช้ Claude ช่วยไล่หาและประกอบช่องโหว่จนเจาะเข้าไปถึงระบบของ OpenAI ได้จริง ผ่านโครงการ bug bounty ที่ OpenAI เปิดให้นักวิจัยภายนอกทดสอบ เหตุการณ์นี้ไม่ใช่แค่ข่าวความปลอดภัยทั่วไป แต่ชี้ให้เห็นว่า AI กำลังลดระดับความเชี่ยวชาญที่จำเป็นสำหรับการสร้าง exploit ลงอย่างชัดเจน

Hacktron ทีมสามคนที่ใช้ Claude เจาะระบบ OpenAI ได้จริง

Hacktron AI เป็นทีมวิจัยความปลอดภัยขนาดเล็กเพียงสามคน ที่เข้าร่วมโครงการ bug bounty ของ OpenAI ด้วยเป้าหมายเดียวกับนักวิจัยด้านความปลอดภัยทั่วไป คือหาช่องโหว่ในระบบก่อนที่คนร้ายจะเจอ สิ่งที่ต่างออกไปคือทีมนี้ใช้ Claude เป็นเครื่องมือหลักในการไล่วิเคราะห์โค้ด ประกอบช่องโหว่ และเขียน exploit แทนที่จะทำเองทั้งหมดด้วยมือ

จากไฟล์ภาพ HEIC ธรรมดา สู่ช่องโหว่ในระบบของ OpenAI

จุดเริ่มต้นของการเจาะระบบอยู่ที่ฟอรัมชุมชนของ OpenAI ซึ่งใช้ซอฟต์แวร์ third-party อย่าง Discourse เป็นฐาน ระบบนี้รองรับการอัปโหลดไฟล์ภาพ HEIF/HEIC ซึ่งเป็นฟอร์แมตเริ่มต้นของกล้อง iPhone โดยใช้ไลบรารี ImageMagick ร่วมกับ libheif ในการแปลงไฟล์เบื้องหลัง

ทีม Hacktron พบว่า libheif มีบั๊กด้านหน่วยความจำที่เปิดทางให้ผู้โจมตีเข้าควบคุมเซิร์ฟเวอร์ได้ผ่านไฟล์ภาพที่สร้างขึ้นมาเฉพาะ พวกเขาใช้ช่องโหว่นี้เจาะเข้าระบบได้สำเร็จในวันที่ 25 กรกฎาคม และ Discourse ออกแพตช์ปิดช่องโหว่ตามมาในวันที่ 27 กรกฎาคม

จากช่องโหว่ไฟล์ภาพ สู่การเข้าควบคุมบัญชีพนักงาน OpenAI

ช่องโหว่ในระบบอัปโหลดภาพเป็นแค่จุดเริ่มต้น ทีมวิจัยยังพบช่องโหว่ที่สองซึ่งต่อยอดจากจุดแรก จนสามารถเข้าควบคุมบัญชี ChatGPT และ Codex ของพนักงาน OpenAI ได้ และเมื่อเข้าถึงบัญชีเหล่านี้ ก็เปิดทางไปสู่ repository บน GitHub ที่พนักงานคนนั้นมีสิทธิ์เข้าถึงด้วย

ลำดับนี้แสดงให้เห็นว่าช่องโหว่เดี่ยวๆ ที่ดูไม่ร้ายแรง อย่างบั๊กในการแปลงไฟล์ภาพ สามารถกลายเป็นจุดเริ่มต้นของการเข้าถึงระบบภายในทั้งหมดได้ หากไม่มีการตัดขอบเขตสิทธิ์ระหว่างระบบย่อยแต่ละส่วน

ทำไม Claude Opus 4.8 ทำไม่สำเร็จ แต่ Opus 5 ทำสำเร็จภายในไม่กี่ชั่วโมง

รายละเอียดที่น่าสนใจที่สุดของเคสนี้คือความแตกต่างระหว่างรุ่นโมเดล ทีม Hacktron ลองให้ Claude Opus 4.8 สร้าง exploit จากบั๊ก libheif ก่อน แต่โมเดลทำไม่สำเร็จ กระทั่ง Anthropic เปิดตัว Claude Opus 5 ทีมจึงลองใหม่อีกครั้งด้วยโมเดลรุ่นนี้ และได้ exploit ที่ใช้งานได้จริงภายในไม่กี่ชั่วโมงหลังเปิดตัว

ข้อมูลจุดนี้มาจากคำบอกเล่าของทีม Hacktron เอง ไม่ใช่ผล benchmark อย่างเป็นทางการ จึงบอกได้แค่ว่ารุ่นใหม่ทำสำเร็จในเคสนี้ ไม่ได้แปลว่า Opus 5 เก่งกว่า Opus 4.8 ในทุกงานด้านความปลอดภัย

ทำไมช่องโหว่นี้ถึงไม่มีใครจับได้มานานหลายเดือน

บั๊กใน libheif ที่ทีม Hacktron ใช้นั้น อันที่จริงเคยถูกแพตช์แก้ไปแล้วตั้งแต่หลายเดือนก่อนหน้า แต่ไม่เคยมีการออกหมายเลข CVE ให้กับช่องโหว่นี้ ทำให้เครื่องมือสแกนความปลอดภัยที่อ้างอิงฐานข้อมูล CVE ไม่รู้จักและไม่แจ้งเตือนว่าระบบที่ยังไม่อัปเดตมีความเสี่ยง นี่คือช่องว่างที่ทำให้บั๊กเก่าที่ “แก้แล้ว” ยังใช้โจมตีได้จริงในระบบของ OpenAI

ผลจากการทดสอบ OpenAI จ่ายค่า bug bounty และปิดช่องโหว่ทั้งสองจุด

OpenAI จ่ายค่าตอบแทนผ่านโครงการ bug bounty ให้ทีม Hacktron เป็นเงิน 6,500 ดอลลาร์สหรัฐ และปิดช่องโหว่ทั้งสองจุดหลังได้รับรายงาน ทีม Hacktron เผยแพร่รายละเอียดการค้นพบต่อสาธารณะ พร้อมย้ำว่า AI กำลังลดปริมาณความเชี่ยวชาญเฉพาะทางที่จำเป็นสำหรับการสร้าง exploit ลงอย่างมีนัยสำคัญ

ความหมายที่แท้จริงคือขอบเขตความเชี่ยวชาญที่ AI ช่วยลดลง

พูดตรงๆ ประเด็นที่น่ากังวลของเคสนี้ไม่ใช่ว่า Claude “แฮ็กเก่ง” กว่ามนุษย์ แต่คือทีมแค่สามคนใช้เวลาไม่กี่ชั่วโมงหลัง Opus 5 เปิดตัว ก็ต่อยอด exploit ที่เคยทำไม่สำเร็จให้ใช้งานได้จริง งานที่เคยต้องใช้ผู้เชี่ยวชาญด้าน memory corruption โดยเฉพาะ ตอนนี้ AI ช่วยร่นระยะเวลาและลดกำแพงทักษะลงไปมากครับ

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

ต้นทุนจริงไม่ได้อยู่แค่ค่าบริการโมเดล AI

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

สำหรับฝั่งองค์กรอย่าง OpenAI ต้นทุนที่มองไม่เห็นคือความเสียหายที่หลีกเลี่ยงได้จากการจ่ายค่า bug bounty หลักพันดอลลาร์ เทียบกับความเสียหายที่อาจเกิดขึ้นจริงหากช่องโหว่เดียวกันตกไปอยู่ในมือผู้ไม่หวังดีก่อน ทั้งข้อมูลรั่วไหล การหยุดให้บริการ และความเสียหายด้านชื่อเสียง

สิ่งที่องค์กรควรเปลี่ยนหลังเห็นขีดจำกัดของการกำกับ AI

องค์กรที่เปิดให้ AI เข้าถึงโค้ดหรือระบบภายในควรตัดขอบเขตสิทธิ์ระหว่างระบบย่อยให้ชัดเจน เพื่อไม่ให้ช่องโหว่เล็กๆ จุดเดียวลุกลามไปถึงบัญชีพนักงานหรือ repository สำคัญได้ง่ายเหมือนในเคสนี้

ระบบที่พึ่งพาซอฟต์แวร์ third-party อย่าง Discourse ก็ควรมีกระบวนการตรวจสอบ dependency สม่ำเสมอ ไม่พึ่งพาฐานข้อมูล CVE เพียงอย่างเดียว เพราะบั๊กที่แพตช์แล้วแต่ไม่มีหมายเลข CVE อย่างที่เกิดขึ้นกับ libheif ก็ยังหลุดรอดสายตาเครื่องมือสแกนอัตโนมัติได้

บทสรุป คำถามสำคัญไม่ใช่ AI ทำได้แค่ไหน แต่ใครกำลังควบคุมมัน

เคสของ Hacktron และ OpenAI ไม่ได้พิสูจน์แค่ว่า Claude ช่วยแฮ็กได้ แต่ชี้ว่า AI กำลังลดระยะเวลาและความเชี่ยวชาญที่จำเป็นสำหรับการสร้าง exploit ลงจริง ในทีมขนาดเพียงสามคน

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