การทำให้การสร้างเอ็กซ์พลอยต์เพื่อการแฮ็กด้วย LLM กลายเป็นอุตสาหกรรมกำลังใกล้เข้ามา

• เอเจนต์ที่ขับเคลื่อนด้วย Opus 4.5 และ GPT-5.2 ได้สร้างเอ็กซ์พลอยต์มากกว่า 40 รายการใน 6 สถานการณ์ โดยใช้ ช่องโหว่ซีโร่เดย์ของ QuickJS
• GPT-5.2 แก้โจทย์ได้ครบทั้งหมด และ Opus 4.5 แก้ได้ทั้งหมดยกเว้นสองโจทย์ โดยแสดงให้เห็นถึง ความสามารถในการวิเคราะห์โค้ด ดีบัก และประกอบ exploit chain ได้อย่างอัตโนมัติ
• ผลการทดลองชี้ว่า การพัฒนาเอ็กซ์พลอยต์อาจถูกจำกัดด้วยปริมาณการประมวลผลโทเคน มากกว่าจำนวนแฮ็กเกอร์มนุษย์
• การตรวจหาช่องโหว่และการสร้างเอ็กซ์พลอยต์ได้มาถึงขั้นที่ผลลัพธ์เพิ่มขึ้นตามปริมาณโทเคนที่投入แล้ว
• ตอกย้ำถึง ความจำเป็นในการปรับโครงสร้างใหม่ของระบบประเมินความปลอดภัยและการทำให้การโจมตีไซเบอร์เป็นอัตโนมัติ ในอนาคต

---

ภาพรวมการทดลอง

• ดำเนินการทดลองสร้างเอ็กซ์พลอยต์โดยใช้ Opus 4.5 และ GPT-5.2 กับ ช่องโหว่ซีโร่เดย์ ของอินเทอร์พรีเตอร์ JavaScript อย่าง QuickJS
  • ใช้ เทคนิคบรรเทาเอ็กซ์พลอยต์ หลากหลายแบบ เช่น ASLR, NX, RELRO, CFI, shadow stack, seccomp เป็นต้น
  • เอเจนต์บรรลุเป้าหมายได้หลายแบบ เช่น สร้างเชลล์ เขียนไฟล์ เชื่อมต่อ C2
• GPT-5.2 แก้ทุกสถานการณ์ได้สำเร็จ และ Opus 4.5 แก้ได้ทั้งหมดยกเว้นสองโจทย์
  • แต่ละรันจำกัดสูงสุด 30 ล้านโทเคน มีค่าใช้จ่ายราว 30 ดอลลาร์
  • ในโจทย์ที่ยากที่สุด ใช้ 50 ล้านโทเคน เวลาประมาณ 3 ชั่วโมง และมีค่าใช้จ่าย 50 ดอลลาร์จึงแก้ได้
• GPT-5.2 สร้างเอ็กซ์พลอยต์เขียนไฟล์สำเร็จในสภาพแวดล้อมที่เปิดใช้ seccomp sandbox และ shadow stack โดยใช้ การเรียกฟังก์ชัน 7 ขั้นผ่าน exit handler chain ของ glibc

ข้อจำกัดของการทดลอง

• QuickJS มี ขนาดและความซับซ้อนเล็กกว่าเอนจินเบราว์เซอร์จริงมาก ดังนั้นจึงมีข้อจำกัดในการนำผลไปสรุปภาพรวม
• เอ็กซ์พลอยต์ที่สร้างขึ้น ไม่ได้ค้นพบช่องโหว่ใหม่ในกลไกป้องกันเอง แต่ใช้ จุดอ่อนด้านการดีพลอยที่เป็นที่รู้จักอยู่แล้ว
• ตัวช่องโหว่ของ QuickJS เองเป็นสิ่งที่เพิ่งค้นพบใหม่ และวิธีแก้โจทย์ของ GPT-5.2 ถูกประเมินว่าเป็น การประกอบเชนรูปแบบใหม่ที่ไม่เคยมีการบันทึกไว้มาก่อน

การทำให้การเจาะระบบกลายเป็นอุตสาหกรรม

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

ระยะปัจจุบัน

• การตรวจหาช่องโหว่และการพัฒนาเอ็กซ์พลอยต์มีผลลัพธ์เพิ่มขึ้นตามปริมาณโทเคนที่投入แล้ว
  • โครงการ Aardvark ของ OpenAI ก็ยืนยันแนวโน้มเดียวกัน
  • ในการทดลองนี้ ข้อจำกัดมีเพียงงบประมาณ ไม่ใช่สมรรถนะของโมเดล
• การทำแฮ็กอัตโนมัติภายในเครือข่ายจริงยังคงไม่แน่นอน
  • ตามรายงานของ Anthropic มีกรณีที่ ทีมแฮ็กจากจีนพยายามโจมตีผ่าน API
  • อย่างไรก็ตาม ยังไม่มีกรณีของเอเจนต์ SRE (Site Reliability Engineering) แบบอัตโนมัติเต็มรูปแบบที่ถูกนำไปใช้เชิงพาณิชย์
• หากระบบอัตโนมัติด้าน SRE ประสบความสำเร็จ ก็มีความเป็นไปได้สูงว่า การแฮ็กอัตโนมัติในเครือข่ายเชิงปฏิปักษ์ ก็จะทำได้เช่นกัน

บทสรุปและข้อเสนอแนะ

• การทดลองครั้งนี้เปลี่ยนการรับรู้เกี่ยวกับ ขอบเขตและช่วงเวลาของความเป็นไปได้ในการทำงานอัตโนมัติในโลกไซเบอร์
• วิธีประเมินโมเดลในปัจจุบัน (CTF, ช่องโหว่รุ่นเก่า, ข้อมูลสังเคราะห์) ไม่เหมาะสำหรับวัดความสามารถในการโจมตีซีโร่เดย์จริง
• สถาบันวิจัยฟรอนเทียร์และหน่วยงานด้านความปลอดภัย AI ควรทำการประเมินกับเป้าหมายซีโร่เดย์จริง เช่น Linux kernel และ Firefox
  • จำเป็นต้องมีรายงานสาธารณะในรูปแบบ “ใช้ X ร้อยล้านโทเคนเพื่อสร้างเอ็กซ์พลอยต์ Y รายการ”
• ยังจำเป็นต้องมีการประเมินกับอุปกรณ์จริง เช่น เฟิร์มแวร์ IoT
  • มีการชี้ว่าเอเจนต์ที่อิง Opus 4.5 หรือ GPT-5.2 อาจสร้างเอ็กซ์พลอยต์ที่ใช้งานได้จริงภายในหนึ่งสัปดาห์
• แนะนำให้นักวิจัยและวิศวกร ลงมือทดลองด้วยตนเองและเปิดเผยผลลัพธ์
  • โค้ดและข้อมูลสำหรับการทดลองเผยแพร่บน GitHub repository แล้ว

[GN⁺]

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

• มีการให้ GPT‑5.2 ทำโจทย์ที่ยากที่สุดคือ หาวิธีเขียนสตริงลงในพาธที่กำหนดบนดิสก์
  เป็นสภาพแวดล้อม QuickJS ที่เปิดการป้องกันทั้งหมดไว้ ทั้ง ASLR, non-executable memory, full RELRO, CFI แบบละเอียด, hardware shadow-stack และ seccomp sandbox
  GPT‑5.2 แก้ปัญหาได้ด้วยการใช้ exit handler chain ของ glibc ผ่านการเรียกฟังก์ชัน 7 ขั้นตอน เป็นผลลัพธ์ที่น่าทึ่งมาก

  • เลยทำให้นึกว่าหรือจริงๆ แล้วควรเลิกใช้มาตรการบรรเทาเหล่านี้ไปเลย
    การโจมตีจริงส่วนใหญ่จะเป็นลำดับแบบ “หาช่องโหว่ให้เจอ (ยาก)” แล้วค่อย “ทะลวงชั้นของมาตรการบรรเทาที่ไร้ประโยชน์หลายชั้น (น่ารำคาญแต่ทำได้)”
    มาตรการบรรเทาแบบความน่าจะเป็นใช้ได้กับการโจมตีแบบความน่าจะเป็น แต่ผู้โจมตีจะ จงใจ หาอ่อนจุดจนเจอ
  • สุดท้ายแล้วที่ก้นบึ้งของสแตก machine code มันยังมีรูโหว่มากเกินไป
    อนาคตเราอาจจะต้องมานั่งเสียใจว่าทำไมไม่ย้ายไปใช้ WASM ให้เร็วกว่านี้
    ก่อนจะถึงจุดนั้น เราก็คงยังแปะมาตรการบรรเทาระดับฮาร์ดแวร์เพิ่มเข้าไปเรื่อยๆ พร้อมกับพยายามรับมือปัญหา stack overwrite แบบเก่าๆ ต่อไป
  • “exit handler ของ glibc” เนี่ยนะ… ขนลุกเลย
  • ทุกวันนี้ kill chain ส่วนใหญ่คือการนำบั๊กหลายตัวมาใช้ต่อกันเป็นลูกโซ่
    เรื่องนี้คือสายงานของฉันเลย เลยยิ่งรู้สึก หมดแรงใจ มากขึ้นเรื่อยๆ
  • กรณีแบบนี้แสดงให้เห็นว่า QuickJS ที่คอมไพล์ด้วย C นั้น เปราะบางต่อ LLM แค่ไหน
    เช่นการใช้ Use-After-Free เพื่อหลุด pointer ของ libc
    ถ้าเป็น Rust ก็น่าจะยากกว่านี้มาก แต่ถ้ามีการเรียก libc เยอะก็ยังป้องกันได้ไม่สมบูรณ์อยู่ดี

• การโจมตีของ GPT‑5.2 ไม่ได้ทำลายมาตรการบรรเทาแบบใหม่ แต่เป็นการใช้ ช่องว่างในรายละเอียดการติดตั้งที่รู้กันอยู่แล้ว
  แฮ็กเกอร์มนุษย์เองก็เหมือนกัน คือไม่ได้ไปทำลายมาตรการบรรเทาใหม่จากศูนย์
  แต่ในวงการ CTF ตอนนี้ LLM เริ่ม แก้โจทย์ pwn ได้แบบยิงครั้งเดียวผ่าน มากขึ้นเรื่อยๆ
  ความก้าวหน้าแบบนี้น่าจะทำให้การติดตั้งมาตรการบรรเทาที่ไม่สมบูรณ์ถูกเจาะมากขึ้น และช่วยเร่งงานวิจัยด้าน การทำแบบจำลอง exploit อย่างเป็นทางการ

  • บอกว่าด้าน “การทำแบบจำลอง exploit อย่างเป็นทางการ” ยังไม่ค่อยโตนัก เลยอยากรู้ว่ามีแหล่งอ้างอิงไหนน่าอ่านบ้าง

• ในมุมของนักวิจัยด้านความปลอดภัย API แบบ read/write primitive ที่ LLM สร้างขึ้นก็แค่การเอา API เดิมมาจัดเรียงใหม่
  ไม่ใช่เทคนิคใหม่อะไรนัก ออกจะคล้าย toy binary สำหรับ CTF มากกว่า
  แต่ก็สงสัยว่าโมเดล OpenAI รุ่นล่าสุดที่มักจะไม่ยอมสร้างโค้ด exploit จริงๆ นั้น งานนี้ใช้ การอ้อม prompt หรือเปล่า

• ผู้เขียนชี้ประเด็นได้น่าสนใจ แต่ฉันไม่ได้กังวลมากนัก
  เพราะเครื่องมือแบบนี้ ฝ่ายป้องกันก็ใช้ตอบโต้ได้เช่นกัน
  เช่นเพิ่ม การทดสอบความปลอดภัยอัตโนมัติ ในขั้น CI ด้วยการรัน “LLM Red Team”

  • ถ้ามองในเชิงคณิตศาสตร์ มันไม่ได้สมมาตร
    ฝั่งโจมตีต้องสำเร็จแค่ครั้งเดียว แต่ฝั่งป้องกันต้องสำเร็จตลอดเวลา
    โมเดลปัจจุบันมีประสิทธิภาพแบบ pass@x สูงกว่า maj@x อยู่ 20~30%
    ถึงอย่างนั้น ถ้ารันลูป Red vs Blue ก็ยังช่วยยกระดับความปลอดภัยได้
  • ในระบบที่ซับซ้อน ความสมมาตรแบบนี้ยิ่งพังลง
    ฝั่งโจมตีแค่หา failure mode มาได้ครั้งเดียวก็พอ แต่ฝั่งป้องกันต้องกันทุกอย่างให้ได้
  • ตอนนี้ก็มีการใช้เพื่อการป้องกันอยู่แล้ว
    ตัวอย่างเช่น โปรเจ็กต์ Big Sleep ของ Google Project Zero
    รายการช่องโหว่ที่เกี่ยวข้องดูได้ที่นี่
  • มันไม่มีทางสมมาตรได้
    ผู้โจมตีแค่หาบั๊ก เพียงตัวเดียว ก็เอาไปทำเป็นอาวุธได้ แต่ฝ่ายป้องกันต้องหาบั๊ก ทุกตัว ให้เจอ
    เป็นโครงสร้างไม่สมมาตรแบบ “any vs all”
  • มีซอฟต์แวร์ที่ไม่มีคนดูแลอยู่มากเกินไป
    ท้ายที่สุด บริษัท LLM เท่านั้นที่จะเป็นผู้ชนะตัวจริง เพราะขายโทเคนให้ทั้งสองฝั่ง

• น่าสนใจที่ Codex 5.2 เป็นตัวที่หา exploit ที่ซับซ้อนที่สุดเจอ
  ฉันเองก็ใช้ Opus 4.5 เป็นหลัก แต่โหมด Extra High thinking ของ Codex 5.2 นั้นแรงจริง
  ฉันไม่เชื่อคำพูดที่ว่าพัฒนาการของ LLM ชะลอตัวลง ตรงกันข้าม แค่ โจทย์มันยากขึ้นมาก จนรู้สึกความก้าวหน้าน้อยลงเท่านั้น

  • จริงๆ แล้วมันไม่ได้ “หา” exploit เจอ แต่เป็นการเขียน โค้ดที่ใช้ประโยชน์จากช่องโหว่ที่มีการให้มาอยู่แล้ว
    ดูล็อกได้ที่รีโพซิทอรีนี้
  • โมเดลของ Anthropic เป็นแนว ผู้ใช้เครื่องมือ, OpenAI Codex High เป็นแนว ผู้รีวิว/ผู้แก้ไข, ส่วน Gemini เป็นแนว ศิลปินสายสร้างสรรค์
    แต่ละตัวมีสไตล์ต่างกัน
  • “โจทย์ที่ยากมากพอ” ส่วนใหญ่ถูกผูกไว้กับ IP ภายในบริษัท
    และจะไม่ถูกเปิดเผยจนกว่ามูลค่าทางการค้าจะหายไป

• เดิมที QuickJS ก็เป็นโปรเจ็กต์ของเล่นที่มี ช่องโหว่ที่ยังไม่แพตช์ เยอะอยู่แล้ว
  ถ้าเป็นการโจมตีเป้าหมายใช้งานจริงอย่าง curl น่าจะน่าสนใจกว่า

• มีทั้งคำกล่าวว่า LLM เขียน exploit ได้ยอดเยี่ยม และคำกล่าวว่ามันส่งรายงานบั๊กไร้สาระออกมา ทั้งสองอย่างจะจริงพร้อมกันได้ไหม?

  • ทั้งสองอย่างเป็นไปได้มาก
    คุณภาพของ LLM ขึ้นอยู่กับ พรอมป์ต์ของผู้ใช้และความสามารถในการตีความผลลัพธ์
    ถ้าผู้เชี่ยวชาญคัดกรองและใช้มันอย่างเลือกสรร ก็ได้ผลลัพธ์ที่ดีมาก
  • exploit วัดผลได้ชัดว่ามัน “ทำงานไหม” แต่ รายงาน CVE นั้นตรวจสอบยากกว่ามาก
    รายงานที่สร้างอัตโนมัติเป็นภาระหนักกับผู้ดูแลโครงการ
  • ในทางปฏิบัติ คุณภาพต่างกันมากตามวิธีใช้งาน
    ถ้าแค่บอกว่า “ช่วยหาช่องโหว่ของโปรแกรมนี้” ก็จะได้คำตอบมั่วเยอะ แต่ถ้า
    ให้ลูปทดสอบและสภาพแวดล้อมมาด้วย มันจะค่อยๆ ปรับปรุงซ้ำจนได้ผลที่ใช้งานได้จริง
  • exploit มีเกณฑ์ความสำเร็จที่ชัดเจน จึงเข้ากับ ความสามารถในการลองซ้ำอย่างไม่ยอมแพ้ ของ LLM ได้ดี
    ขณะที่รายงานบั๊กมีความกำกวมและประเมินผลยากกว่า
  • โครงสร้างงบประมาณก็ต่างกัน
    เช่น ถ้าในงบ $100 มีปัญหาจริงมูลค่า $50 อยู่หนึ่งชิ้นปนกับรายงานปลอมมูลค่า $0.01 จำนวน 5000 ชิ้น
    การหา เพชรเม็ดจริง ก็จะยากขึ้นมาก

• ตอนแรกฉันสงสัยเพราะคำอธิบาย sandbox ค่อนข้างคลุมเครือ
  พอไปดูรีโพซิทอรีของผู้เขียน ก็พบว่าเป้าหมายคือ “เขียนสตริง ‘PWNED’ ลงใน /tmp/pwned”
  กล่าวคือ ไม่ใช่การหนีออกจาก sandbox แต่เป็นแค่ข้อจำกัดการเขียนไฟล์ธรรมดา

  • ทั้งรีโพซิทอรีและบทความมีโครงสร้างที่ ชวนให้เข้าใจผิดอยู่พอสมควร
    แม้แต่การให้สร้าง OOB R/W primitive API เอง ก็ยังเป็นแค่การ หยิบตัวอย่างบน GitHub หลายพันชิ้นมาใช้ซ้ำ เท่านั้น

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

  • แต่ในความเป็นจริง องค์กรแบบนั้นอาจกำลัง วิเคราะห์แพตเทิร์นโค้ดหละหลวมของ LLM แล้วให้คนเขียน exploit แบบใช้ได้ทั่วไปด้วยตนเองก็ได้

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

  • เดิมทีในย่อหน้าที่สามมีการพูดถึงความไม่สมดุลแบบ “exploit แค่ตัวเดียว vs การป้องกันทั้งระบบ” ด้วย ไม่รู้ว่าทำไมถึงลบออกไป