ค้นพบ WordPress RCE ด้วย GPT5.6 และเงิน 25 ดอลลาร์

 (slcyber.io)
2 คะแนน โดย GN⁺ 15 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • GPT5.6 Sol Ultra วิเคราะห์ WordPress รุ่นเสถียรล่าสุด และสร้างห่วงโซ่การโจมตีตั้งแต่ SQL injection ก่อนยืนยันตัวตน ไปจนถึงการสร้างบัญชีผู้ดูแลระบบและการรันโค้ดจากระยะไกล (RCE) ได้ภายในราว 10 ชั่วโมง
  • จุดเริ่มต้นคือ ความไม่ตรงกันของดัชนีอาร์เรย์ใน Batch API ที่มีมาตั้งแต่ WordPress 5.6 โดยผสานคำขอ Batch แบบเรียกซ้อนเพื่อข้ามข้อจำกัดของ GET และการตรวจสอบพารามิเตอร์
  • หลังทำให้เกิด UNION injection ผ่านสตริง author_exclude ที่ไม่ได้ตรวจสอบแล้ว ก็ใส่โพสต์ที่ถูกดัดแปลงลงในหน่วยความจำแคช และใช้ประโยชน์จาก oEmbed cache, changeset, การอ้างอิงวนซ้ำ, และ hook ต่อเนื่องกัน
  • ใช้ user_id: 1 ใน customize_changeset เพื่อยกระดับเป็นสิทธิ์ผู้ดูแลชั่วคราว แล้วเรียกคำขอ Batch ซ้ำผ่าน hook parse_request เพื่อสร้างผู้ดูแลใหม่ ก่อนอัปโหลด ZIP ของปลั๊กอินแบ็กดอร์เพื่อไปถึงการรันโค้ด
  • ค่าใช้จ่ายเมื่อคำนวณตามสัดส่วนจากการใช้โควตารายสัปดาห์ 50% ของแพ็กเกจสมาชิก 200 ดอลลาร์ต่อเดือนอยู่ที่ราว 25 ดอลลาร์ และบทบาทของมนุษย์มีแนวโน้มจะขยับไปสู่การกำกับงานวิจัยระดับสูง เช่น การเลือกผลิตภัณฑ์และพื้นผิวการโจมตี รวมถึงการปรับพรอมป์ต์

กระบวนการค้นพบและเงื่อนไขการทดลอง

  • นำ พรอมป์ต์ ที่ OpenAI เปิดเผยว่าใช้แก้ปัญหาสมมติฐาน Cycle Double Cover มาปรับสำหรับงานวิจัยด้านความปลอดภัย แล้วป้อนให้ GPT5.6 Sol Ultra
  • โคลน WordPress รุ่นเสถียรล่าสุดไว้ใน main/ และลบไดเรกทอรี .git ออก พร้อมเตรียมไดเรกทอรี third_party/ เปล่าไว้เพื่อให้ตรวจสอบโค้ด dependency ได้
  • พรอมป์ต์สั่งให้ใช้ เอเจนต์ได้สูงสุด 4 ตัว แบบขนาน และคงเส้นทางโจมตีที่หลากหลายไว้อย่างน้อย 6 ชั่วโมง
    • สำรวจการแยกวิเคราะห์อินพุต, ชุดอักขระ, การอัปโหลดไฟล์, การจัดการข้อผิดพลาด, เส้นทางภายใน, serialization, แคช, race condition, การเข้ารหัส, ชนิดข้อมูล, mass assignment เป็นต้น
    • ลงทะเบียนตระกูลของแนวทาง และถ้าเอเจนต์เริ่มกระจุกตัวกับกลยุทธ์ใดก็ย้ายไปยังพื้นที่ที่สำรวจน้อยกว่า
    • บั๊กที่เป็นรูปธรรมจะถูกตรวจยืนยันซ้ำโดยเอเจนต์ฝ่ายตรงข้าม และแม้เส้นทางที่ล้มเหลวก็จะถูกเปิดใหม่เมื่อมีกลไกใหม่เกิดขึ้น
  • จำกัดให้ค้นหาช่องโหว่ใหม่จาก ซอร์สโค้ดเอง โดยไม่ใช้อินเทอร์เน็ต เบาะแส ความต่างของประวัติการเปลี่ยนแปลง หรือเวอร์ชันแพตช์
  • เพื่อหลีกเลี่ยงการตั้งค่าที่ไม่สมจริงหรือเงื่อนไขที่ผู้โจมตีทำไม่ได้ จึงกำหนดเป้าหมายชัดเจนว่าเป็น “RCE ก่อนยืนยันตัวตนบนการติดตั้ง production ทั่วไปที่ใช้ MySQL”
  • ผ่านไปราว 6 ชั่วโมง โมเดลพบ SQL injection ก่อนยืนยันตัวตน และยืนยันซ้ำได้ภายในไม่กี่นาทีบนเซิร์ฟเวอร์ WordPress ระยะไกลเริ่มต้นด้วยการดึงอีเมลผู้ดูแลระบบ
  • เมื่อขอให้ยกระดับไปสู่ RCE เพิ่ม อีกประมาณ 4 ชั่วโมงต่อมา ก็สร้างห่วงโซ่จาก SQL injection แบบอ่านอย่างเดียวไปสู่สิทธิ์ผู้ดูแลได้สำเร็จ โดยไม่ต้องแคร็กรหัสผ่านหรือคำนวณออฟไลน์
  • เวลาทำงานรวมคือ มากกว่า 10 ชั่วโมงเล็กน้อย และใช้โควตารายสัปดาห์ไป 50% ค่าใช้จ่ายเมื่อเทียบสัดส่วนกับค่าสมาชิกรายเดือน 200 ดอลลาร์อยู่ที่ราว 25 ดอลลาร์
  • ก่อนเปิดเผยข้อมูล ได้เว้นช่วงสุดสัปดาห์ให้ผู้ดูแลอัปเกรด WordPress และระหว่างนั้น Calif กับ Hacktron ก็ยืนยันห่วงโซ่ทั้งหมดได้อย่างอิสระก่อน PoC อื่นบน GitHub
  • อินสแตนซ์ที่กำลังใช้งานสามารถตรวจสอบความเสี่ยงได้ที่ wp2shell.com

ความไม่สอดคล้องในการตรวจสอบของ Batch API

  • Batch API ที่เพิ่มเข้ามาใน WordPress 5.6 ประมวลผลคำขอ API เสมือนหลายรายการในคำขอเดียว แม้จะเข้าถึง endpoint เองได้โดยไม่ต้องยืนยันตัวตน แต่ข้อมูลยืนยันตัวตนจะถูกส่งต่อให้กับคำขอย่อยแต่ละรายการ
  • โดยปกติคำขอ REST จะถูกประมวลผลตามลำดับดังนี้
    • ตรวจสอบค่าที่จำเป็นและความถูกต้องด้วย has_valid_params()
    • ทำความสะอาดค่าด้วย sanitize_params()
    • เรียก permission callback
    • เรียก endpoint callback
  • Batch API แยกการตรวจสอบกับการประมวลผลออกเป็นสองลูปเพื่อประสิทธิภาพ
    • ลูปแรกตรวจสอบและทำความสะอาดทุกคำขอ
    • ลูปที่สองตรวจผลการตรวจสอบ แล้วเรียก permission และ endpoint callback
  • การติดตั้งใช้งานสมมติว่าอินเด็กซ์เดียวกันในผลการจับคู่ route คือ $matches และผลการตรวจสอบคือ $validation จะสอดคล้องกัน
  • หากคำขอที่ไม่ถูกต้องเข้าไปในกิ่ง is_wp_error($single_request) ระบบจะเพิ่มรายการเข้า $validation แต่จะไม่เพิ่มเข้า $matches เพราะ continue
    • หลังจากนั้น รายการทั้งหมดใน $matches จะเลื่อนไปหนึ่งตำแหน่ง
    • พารามิเตอร์ของคำขอหนึ่งจึงอาจถูกตรวจสอบด้วยกฎของอีกคำขอ แล้วนำไปรันใน handler ของ endpoint ที่เดิมไม่ได้ตั้งใจ
  • เมื่อใช้ ความไม่ตรงกันของดัชนี นี้ ก็สามารถนำผลการตรวจสอบจาก endpoint อื่นที่ไม่ทำความสะอาดพารามิเตอร์มาใช้กับ endpoint ที่รองรับ Batch ได้

SQL injection ที่เกิดใน author__not_in

  • GET /wp/v2/posts ใช้ตัวแปร query ภายใน author__not_in เพื่อยกเว้นผู้เขียนบางรายออกจากผลลัพธ์
  • หากค่าเป็นอาร์เรย์ จะใช้ absint กับแต่ละสมาชิกเพื่อแปลงเป็นจำนวนเต็ม แต่ถ้าเป็นค่า scalar จะนำไป implode ตรง ๆ แล้วแทรกเข้าเงื่อนไข NOT IN ของ SQL
  • ในการเรียกใช้งานปกติ พารามิเตอร์สาธารณะ author_exclude ต้องเป็นอาร์เรย์ของจำนวนเต็ม จึงไม่เห็นปัญหานี้
  • แต่เมื่ออาศัยความไม่ตรงกันของดัชนีใน Batch ก็สามารถตรวจสอบสตริง author_exclude ด้วยกฎของ DELETE /wp/v2/posts/1 ซึ่งไม่รู้จักพารามิเตอร์นี้ แล้วส่งต่อไปยัง GET /wp/v2/posts ได้
  • ข้อจำกัดที่ Batch API ไม่ยอมให้มีคำขอย่อยแบบ GET ก็ถูกข้ามด้วย คำขอ Batch แบบเรียกซ้อน
    • Batch ชั้นนอกทำให้เกิดความไม่ตรงกันของดัชนีเพื่อข้ามการตรวจสอบ method ของคำขอชั้นใน
    • Batch ชั้นในทำให้เกิดความไม่ตรงกันของดัชนีอีกครั้งเพื่อข้ามการตรวจสอบ author_exclude
  • เมื่อนำค่าอย่าง 0) OR 1=1 -- ไปใส่ ก็จะได้แถวโพสต์ทั้งหมดกลับมา ใช้ยืนยันการฉีดได้
  • จากนั้นสามารถใช้ UNION-based injection เพื่อสร้างแถวที่มีรูปแบบเหมือน wp_posts และรั่วค่าฐานข้อมูลตามต้องการ
  • เนื่องจากรหัสผ่าน โทเค็นรีเซ็ต และ API key ถูกแฮชในฐานข้อมูล การรั่วข้อมูลเพียงอย่างเดียวจึงยังไม่พอให้ยึดบัญชีได้ หากรหัสผ่านผู้ดูแลไม่ได้อ่อนแอ

การดัดแปลงแคชโพสต์ภายในคำขอ

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

การสร้างแถวฐานข้อมูลด้วย oEmbed cache

  • ฟีเจอร์ embeds ของ WordPress ใช้ไวยากรณ์ [embed]...[/embed] ในเนื้อหาโพสต์เพื่อฝังเนื้อหาระยะไกลที่รองรับ
  • เพื่อไม่ต้องส่งคำขอ HTTP ทุกครั้ง ผลลัพธ์จะถูก เก็บลงฐานข้อมูล เป็นโพสต์ชนิด oembed_cache ใน wp_posts
  • ถ้าฝังโพสต์ WordPress ภายในเครื่องด้วยเส้นทางสัมพัทธ์ ระบบจะข้ามคำขอ HTTP และไม่ตรวจว่า ID ของโพสต์ที่อ้างอิงมีอยู่จริงหรือไม่
  • แม้จะฝังโพสต์ภายในเครื่องที่ไม่มีอยู่จริง เช่น /?p=10 ก็ยังอาจสร้างแถว oembed_cache สำหรับข้อมูลนั้นได้
  • เมื่อดึงแถวที่สร้างขึ้นกลับมาด้วย SQL injection อีกครั้ง พร้อมดัดแปลงชนิดโพสต์ในหน่วยความจำให้เป็น post เป็นต้น การแสดงผลในฐานข้อมูลกับในแคชก็จะต่างกัน
  • WordPress จะปรับสองการแสดงผลนี้ให้สอดคล้องกันด้วยการเรียก wp_update_post() และนอกจากฟิลด์ ID กับ post_content ที่ระบุอย่างชัดเจนแล้ว จะให้ความสำคัญกับค่าหน่วยความจำที่ผู้โจมตีสร้างขึ้น
  • ด้วยเหตุนี้ จึงเปลี่ยนแถว oembed_cache ให้เป็นโพสต์ปกติได้ แต่ในการเรียกนี้ post_content จะถูกเขียนทับด้วยผลลัพธ์จากการฝัง ทำให้ผู้โจมตีควบคุมเนื้อหาไม่ได้

สิทธิ์ผู้ดูแลชั่วคราวผ่าน customize_changeset

  • ร่างการปรับแต่งธีมจะถูกเก็บเป็นโพสต์พิเศษชนิด customize_changeset ใน wp_posts
  • ใน post_content จะเก็บ JSON ที่มีค่าการเปลี่ยนแปลงตามคีย์การตั้งค่า ชนิดของค่า และ ID ผู้ใช้ที่ทำการเปลี่ยนแปลง
  • เมื่อมีการใช้ changeset นั้น WordPress จะอ่าน user_id ของแต่ละรายการและสลับผู้ใช้ปัจจุบันชั่วคราวด้วย wp_set_current_user()
  • หากผู้โจมตีใช้ changeset ที่มี user_id: 1 ก็จะยืมตัวตนของผู้ดูแลได้ชั่วคราว แม้จะเป็นคำขอแบบไม่ระบุตัวตน
  • แต่เส้นทาง wp_update_post() จากการปรับ oEmbed ก่อนหน้านี้จะเขียนทับ post_content จึงต้องมีเส้นทางเรียก wp_update_post() อื่นที่รักษา JSON changeset อันตรายนี้ไว้

การคงเนื้อหาด้วยวงจรของโพสต์แม่

  • โพสต์ใน WordPress มีโพสต์แม่ได้หนึ่งรายการ แต่จะไม่ยอมให้มี โครงสร้างวนซ้ำ เช่น ตั้งตัวเองหรือโพสต์ลูกเป็นโพสต์แม่
  • ฟิลเตอร์ wp_insert_post_parent จะไล่ตามลำดับชั้นของโพสต์แม่เพื่อตรวจหาวงจร และถ้าพบก็จะเรียก wp_update_post() เพื่อเปลี่ยน post_parent ของโพสต์นั้นเป็น 0
  • การเรียกครั้งที่สองนี้ระบุแค่ ID กับ post_parent โดยไม่เขียนทับ post_content
  • ถ้าด้วย SQL injection ทำให้โพสต์ในหน่วยความจำกลายเป็น customize_changeset ที่มีตัวเองเป็นโพสต์แม่ กระบวนการแก้วงจรนี้ก็จะเขียน JSON changeset อันตราย ที่ผู้โจมตีกำหนดลงฐานข้อมูล
  • เมื่อสร้าง changeset ที่มีวันที่อยู่ในอดีตแต่สถานะเป็น future WordPress ก็จะนำไปใช้ และทำการเปลี่ยนการตั้งค่าตามที่ระบุด้วยสิทธิ์ผู้ดูแลจาก user_id: 1
  • สิทธิ์ผู้ดูแลจะคงอยู่เฉพาะระหว่างการประมวลผล changeset และจะกลับเป็นสิทธิ์ guest เมื่อเสร็จ

การรันคำขอทั้งหมดซ้ำผ่าน hook แบบไดนามิก

  • Hook ของ WordPress แบ่งเป็น action และ filter เพื่อให้ปลั๊กอินเข้ามาแทรกในจุดต่าง ๆ ของวงจรชีวิต เช่น การล็อกอิน การโพสต์ หรือการลงทะเบียนสคริปต์
  • เมื่อสถานะของโพสต์เปลี่ยน WordPress จะเรียก action แบบไดนามิกในรูป "{$new_status}_{$post->post_type}"
    • สำหรับโพสต์ปกติ ชื่อจะเป็นอย่าง publish_post
    • โพสต์ปลอมในหน่วยความจำสามารถกำหนดสถานะและชนิดได้ตามใจ จึงประกอบเป็นชื่อ action ที่ต้องการซึ่งมีขีดล่างหนึ่งตัวขึ้นไปได้
  • แม้อาร์กิวเมนต์ของ hook จะถูกจำกัดไว้ที่ ID ของโพสต์และอ็อบเจ็กต์ WP_Post ที่ผู้โจมตีกำหนด จึงเรียกใช้ action ใด ๆ ให้เกิดประโยชน์โดยตรงได้ยาก
  • ห่วงโซ่การโจมตีนี้จึงดัดแปลงสถานะเป็น parse และชนิดเป็น request เพื่อเรียก hook parse_request
  • เนื่องจาก parse_request เป็น hook ที่รันในช่วงต้นของวงจรคำขอ การเรียกมันซ้ำจึงทำให้คำขอ Batch เดิมทั้งก้อนถูกประมวลผลใหม่ตั้งแต่ต้น
  • การประมวลผลใหม่นี้เกิดขึ้นขณะตัวตนผู้ดูแลชั่วคราวจาก changeset ยังมีผลอยู่ ทำให้คำขอสำหรับผู้ดูแลที่ล้มเหลวเพราะสิทธิ์ไม่พอในการรันครั้งแรก กลับสำเร็จในการรันครั้งที่สอง

ห่วงโซ่ RCE ที่เสร็จสมบูรณ์ด้วยสองคำขอ

  • เอ็กซ์พลอยต์สุดท้ายใช้คำขอ HTTP สองครั้ง และกำหนด ID ให้โพสต์ปลอมเป็นค่าที่สูงพอจะไม่ชนกับโพสต์จริง

  • คำขอแรก: เตรียมแถวถาวร

    • ใช้ SQL injection ให้คืนโพสต์ปลอมที่มี local embed สามรายการ เพื่อสร้าง แถว oembed_cache 3 แถว ที่สอดคล้องกับ O, C, D
    • embed ทั้งสามอ้างถึงโพสต์เดียวกันคือ S แต่ใช้ query string ต่างกันเพื่อให้ได้แฮช oEmbed cache แยกกัน

  • คำขอที่สอง: ประกอบโพสต์หกรายการ

    • สร้างโพสต์ปลอม 6 รายการต่อไปนี้ในแคชหน่วยความจำ
    • O: แคชเก่าที่มีสถานะ/ชนิดเป็น publish/oembed_cache และมีโพสต์แม่คือ C
    • C: มีสถานะ/ชนิดเป็น future/customize_changeset มีตัวเองเป็นโพสต์แม่ และมี JSON changeset อันตราย
    • P: draft/page ที่มีโพสต์แม่คือ D
    • D: มีสถานะ/ชนิดเป็น parse/request และมีตัวเองเป็นโพสต์แม่
    • S: publish/post ที่ให้ข้อมูล embed
    • T: publish/post ที่บรรจุ embed ชั้นนอก
    • embed ของ T จะไปดึง O และเพราะเวลาแก้ไขเก่า จึงทำให้แคชของ S ถูกรีเฟรช
    • ระหว่างรีเฟรช O หากตรวจพบวงจรของโพสต์แม่ C ก็จะเปลี่ยนโพสต์แม่ของ C เป็น 0 พร้อมเขียน customize_changeset และ JSON อันตรายในหน่วยความจำลงฐานข้อมูล
    • เมื่อ future changeset ที่มีวันที่ในอดีตถูกนำไปใช้ ก็จะเผยแพร่ P ด้วยตัวตนผู้ดูแลจาก user_id: 1
    • การอัปเดต P จะพบวงจรของโพสต์แม่ D จึงเขียน D ลงฐานข้อมูลและเรียก action parse_request จากสถานะและชนิดที่ถูกดัดแปลง
    • คำขอ Batch มี คำขอสร้างผู้ดูแลใหม่ รวมอยู่ตั้งแต่ต้น
    • ในการประมวลผลครั้งแรก คำขอนี้ล้มเหลวเพราะยังเป็นสิทธิ์ guest
    • แต่เมื่อถูกรันซ้ำผ่าน parse_request ขณะยังมีสิทธิ์ผู้ดูแลชั่วคราวอยู่ ก็จะสำเร็จ
    • หลังล็อกอินด้วยบัญชีผู้ดูแลใหม่แล้ว การอัปโหลด ZIP ของปลั๊กอินแบ็กดอร์จะนำไปสู่การรันโค้ดจากระยะไกลในที่สุด

บทบาทที่เปลี่ยนไปในงานวิจัยความปลอดภัยด้วย AI

  • ขั้นตอนที่สร้างสรรค์เป็นพิเศษในห่วงโซ่นี้ ได้แก่ การข้ามข้อจำกัด GET ด้วยคำขอ Batch แบบเรียกซ้อน การรวมแคชกับ changeset เพื่อได้สิทธิ์ผู้ดูแล และการเรียก parse_request ด้วยโพสต์ปลอมเพื่อรันคำขอซ้ำทั้งชุด
  • แม้จะยังสรุปความเหนือกว่าโดยทั่วไปไม่ได้ แต่ก็ประเมินว่า หากไม่มี AI นักวิจัยความปลอดภัยคง ไม่สามารถค้นพบและต่อห่วงโซ่นี้จนเสร็จภายใน 10 ชั่วโมงได้
  • ต่อให้บอกบั๊ก Batch เดิมไว้ล่วงหน้า ก็ยังไม่มั่นใจว่าจะต่อไปถึง RCE ได้ทันในเวลานั้น
  • ผู้เขียนมองว่า GPT5.6 Sol Ultra พัฒนาขึ้นมากจาก GPT5.5 ในความสามารถในการค้นหา code gadget หลายจุดที่กระจัดกระจายและเชื่อมเป็นห่วงโซ่เดียว
  • ยิ่งโมเดลรับหน้าที่พัฒนา technical exploit มากขึ้น มนุษย์ก็จะยิ่งไปโฟกัสกับการเลือกผลิตภัณฑ์ พื้นผิวการโจมตี เวลา投入 และทิศทางการวิจัย รวมถึงการแก้ทิศเมื่อโมเดลหลงทาง
  • ความสามารถด้าน meta-research แบบนี้ AI ยังทำได้ไม่ดี และคาดว่าจะยิ่งสำคัญมากขึ้นเมื่อความสามารถทางเทคนิคของโมเดลสูงขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 15 시간 전
ความเห็นจาก Hacker News

  • ไม่มีหลักฐานว่าเอ็กซ์พลอยต์แบบนี้เคยได้รับหรือจะได้รับ 500,000 ดอลลาร์ ผู้เขียนบอกว่าปรับพรอมป์ตอย่างระมัดระวังราวกับคัมภีร์ ดังนั้นน่าจะขายพรอมป์ตนั้นในราคา 500,000 ดอลลาร์ไปเลยมากกว่า
    ผู้เขียนทำงานที่ https://www.assetnote.io/ ซึ่งขายผลิตภัณฑ์ AI สำหรับสแกนอัตโนมัติ

    • น่าจะหมายถึง https://www.crowdfense.com/exploit-acquisition-program/ ส่วน Zerodium ก็เคยเสนอสูงสุด 300,000 ดอลลาร์ในปี 2021: https://www.securityweek.com/sites/default/files/images/Zero...
      นายหน้าพวกนี้มักไม่จ่ายเงินก้อนใหญ่ทั้งหมดในครั้งเดียว แต่จะขายสิทธิ์การเข้าถึงให้ผู้กระทำการระดับรัฐ แล้วทยอยจ่ายตราบใดที่บั๊กยังไม่ถูกแพตช์ โครงสร้างแบบนี้มีไว้เพื่อกันการขายต่อหรือการใช้จนหมดเร็ว จึงแทบไม่มีใครยืนยันได้ว่าเคยมีคนได้รับเงินเต็มจำนวนจริงสำหรับช่องโหว่ลักษณะใกล้เคียงกัน
    • ลบ 500,000 ดอลลาร์ ออกจากพาดหัวแล้ว
    • แม้ก่อนยุค LLM ก็แทบไม่มีคนที่ทั้งมีความสามารถพอจะหาช่องโหว่แบบนี้และตั้งใจจะขายให้นายหน้า แถมยังโง่พอจะเอา ป้ายเชิญมาจับฉันสิ ไปชูบนโซเชียลมีเดีย
      ตัวอย่างที่ใกล้สุดคือวัยรุ่นจากฟลอริดาที่ฝังมัลแวร์ในเกมบน Steam เพื่อขโมยบัญชีแล้วโดนจับ พวกเขาคงโดนจับอยู่ดี แต่ถ้าไม่เอาไปอวดบนโซเชียล การสืบสวนก็น่าจะใช้เวลานานกว่านี้มาก
    • การที่มีคนซื้อ Macintosh ที่เคยราคา 5,000 ดอลลาร์ตอนออกใหม่ได้ในตลาดมือสองในราคา 25 ดอลลาร์ ไม่ได้แปลว่าจะเทียบมูลค่าแบบเดียวกันได้
    • คำว่าปรับเหมือนคัมภีร์ ฟังดูเหมือนหมายถึงไม่แก้อะไรเลย แม้มันจะขัดแย้งกันชัดเจนหรือเสื่อมทรามทางศีลธรรมก็ตาม

  • ดูจาก https://github.com/WordPress/WordPress/commit/3a640e1c5e39aa... ก็ยังมี SQL injection จากการต่อสตริง โผล่มาในปี 2026

    • สิ่งที่หนักกว่านั้นอยู่ใน https://developer.wordpress.org/plugins/creating-tables-with...
      เขาบอกให้ใช้ dbDelta แทนการรัน SQL ตรง ๆ แต่กลับบังคับกฎรูปแบบที่จุกจิกสุดขีด เช่น ต้องขึ้นบรรทัดใหม่ทุกฟิลด์ ต้องเว้นวรรคสองช่องระหว่าง PRIMARY KEY และต้องใช้ KEY แทน INDEX ห้ามใส่เครื่องหมายคำพูดหรือแบ็กทิกกับชื่อฟิลด์ ชนิดข้อมูลต้องเป็นตัวพิมพ์เล็ก คีย์เวิร์ด SQL ต้องเป็นตัวพิมพ์ใหญ่ และพารามิเตอร์ความยาวก็ต้องระบุทั้งหมด
    • โค้ดเบสของ WordPress น่าอับอายมาก PHP ตอนนี้กลายเป็นภาษาที่ดีมากแล้ว แต่ WordPress กลับเอาไปใช้แบบเสียของหนักและยังปฏิเสธจะปรับปรุง
    • วิธีแก้ก็แย่มากเหมือนกัน สงสัยว่า WordPress ยังประกอบคำสั่ง SQL ด้วย การต่อสตริงพื้นฐานกับ sprintf อยู่จริงหรือ
    • สุดสัปดาห์นี้เห็นการโจมตีที่ใช้งานเอ็กซ์พลอยต์นี้กับเว็บไซต์ที่เปิดใช้งานจริงแห่งหนึ่ง
      ในคำขอ POST และ GET มีเพย์โหลดลักษณะ /wp/v2/widgets?author_exclude=1%29+AND+1%3D0+UNION+ALL+SELECT...
    • ในโปรไฟล์เขียนว่า Principal Software Engineer @ Bluehost, WordPress Core Committer แต่พอเห็นโค้ดแบบนี้ คำว่า ‘principal’ ก็ฟังดูประหลาดดี

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

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

  • ส่วนที่น่าทึ่งคือราคาสูงของช่องโหว่ที่รู้กันอยู่แล้ว ซึ่งก็อาจไม่จริงด้วยซ้ำ WordPress มักถูกเรียกว่า remote root shell ที่แถมฟังก์ชันบล็อกมาด้วย

    • ยังเข้าใจยากว่าทำไมบล็อกถึงไม่ใช้แค่หน้า static ก็พอ โดยเฉพาะเมื่อปัญหาส่วนใหญ่ของ WordPress ถูก ‘แก้’ ด้วยการเพิ่มแคช
      เข้าใจได้ว่าการบอกให้ผู้ใช้ทั่วไปลากแล้ววางย่อมง่ายกว่าการให้ไปคอมมิตลง GitHub repository แล้ว build ด้วย Hugo แต่ในมุมความปลอดภัย มันคือโครงสร้างที่รอวันให้โค้ดแกนกลางหรือปลั๊กอินนับพันตัวตัวใดตัวหนึ่งมีช่องโหว่ แล้วเปิด remote code execution แบบ as-a-service
    • ถ้าอยากรู้ว่าเป็นเรื่องจริงไหม คงต้องทำ threat intelligence และแฝงตัวเข้าไปในกลุ่ม Telegram ที่นายหน้าพวกนี้ใช้งาน ซึ่งผู้เขียนไม่น่าจะทำแบบนั้น อาจเป็นไปได้ว่าเขาสับสนระหว่างช่องโหว่ทั่วไปกับ zero-day
    • WordPress เป็นหนึ่งในเป้าหมายที่ได้รับการ harden ด้านความปลอดภัยมากที่สุดเท่าที่เคยมีมา โค้ดเก่าหลายส่วนแทบไม่เปลี่ยนมาเป็นสิบ ๆ ปี จึงอาจมองได้ว่าบั๊กส่วนใหญ่ถูกค้นพบและแพตช์ไปหมดแล้ว
    • ยังมีสถิติอีกว่าเกือบ 50% ของเว็บไซต์บนอินเทอร์เน็ตใช้ WordPress ดังนั้นการที่ zero-day remote code execution แบบไม่ต้องยืนยันตัวตน ที่ยังไม่ถูกเปิดเผยจะมีราคา 500,000 ดอลลาร์ ก็ไม่ถึงกับเหนือจริงมากนัก

  • เป็นบทความที่น่าสนใจ และ การค้นหาเอ็กซ์พลอยต์ด้วย LLM และการเปิดเผยต่อสาธารณะ เป็นเรื่องที่ควรกังวลจริง ๆ ผมเองก็เคยทำให้โมเดลสร้างโค้ดหนีออกจากคอนเทนเนอร์จากช่องโหว่ยกระดับสิทธิ์เฉพาะเครื่องบน Linux ได้ค่อนข้างเร็ว
    แต่สิ่งที่น่าแปลกคือ GPT-5.6 ไม่ได้บล็อกพรอมป์ตด้วยมาตรการความปลอดภัย GPT-5.5 ขึ้นไปมักไม่ค่อยยอมทำงานด้าน offensive security คล้าย Opus 4.7+/Fable ดังนั้นจึงดูเป็นไปได้ว่าผู้เขียนอาจได้รับการอนุมัติด้านความปลอดภัยไซเบอร์จาก OpenAI เพื่อผ่อนคลายมาตรการป้องกัน

    • https://chatgpt.com/cyber อาจช่วยเรื่อง การผ่อนคลายมาตรการป้องกัน ได้

  • แม้แต่เครื่องมือ Static Application Security Testing (SAST) แบบไม่ใช้ AI ก่อนปี 2020 ก็จับ SQL injection แบบนี้ได้บ่อย และอย่างน้อยก็ควรเจอในการรีวิวโค้ด จึงน่าสงสัยว่า WordPress ไม่ใช้การรีวิวโค้ดหรือ SAST หรือไม่

    • การโจมตีนี้ต้อง เชื่อมหลายช่องโหว่เข้าด้วยกัน จึงน่าจะจับไม่ได้ด้วยเครื่องมือแบบนั้นเพียงอย่างเดียว

  • เว็บไซต์หนึ่งของฉันถูกแฮ็กด้วยช่องโหว่นี้ แต่โชคดีที่เป็นที่ที่ไม่มีผู้ใช้
    ผู้โจมตีสร้างบัญชีแอดมินสองบัญชีในฐานข้อมูล และติดตั้งเว็บเชลล์รันคำสั่งระยะไกล wp-core-[อักขระสุ่ม 12 ตัว].php ไว้ที่ wp-content/plugins/wp-core ใน mu-plugins ยังมีแบ็กดอร์ firewall.php ที่สร้างแอดมินผ่าน GET ?sergei และเพิ่มแบ็กดอร์ cache-seo-helper.php ด้วย รวมทั้งใช้ fixer.php เปลี่ยนหมายเลขเวอร์ชัน WordPress ให้ดูเหมือนเป็นเวอร์ชันที่แพตช์แล้ว สุดท้ายจึงตัดสินใจ เลิกใช้ WordPress

  • ช่วงท้ายบทความเริ่มเรียกโพสต์ด้วยชื่อแปลก ๆ จนเข้าใจยาก มี ID หนึ่งเป็น O อีกอันเป็น 0 และสงสัยว่าทำไมถึงใช้ตัวอักษรเดี่ยวกับ OCPDST ที่ดูเหมือนสุ่ม แทน EMBED_01 หรือ ABCDEF

    • ทั้งหมดเป็นตัวแทนชื่อชั่วคราว และความหมายเขียนไว้ในเนื้อหาแล้ว O คือ publish/oembed_cache, C คือ future/customize_changeset, P คือ draft/page, D คือ parse/request, S คือ publish/post ที่ให้ข้อมูล embed และ T คือ publish/post ที่มี external embed

  • สงสัยว่านี่กำลังสมมติว่าคนที่ยอมจ่าย 500,000 ดอลลาร์ ไม่มีความสามารถพอจะ ใช้ GPT-5.6 โดยตรง หรือไม่

    • ถ้าอย่างนั้นก็ควรถามว่าทำไมบทวิเคราะห์แบบเดียวกันนี้ถึงไม่ออกมาตั้งแต่ก่อนหน้านี้ การตรวจทานผลลัพธ์จาก LLM และทำให้มันกลายเป็น proof of concept ที่ใช้ได้จริงยังต้องอาศัยความเชี่ยวชาญอยู่มาก
      ฉันเองก็ใช้ LLM หาช่องโหว่ด้านความปลอดภัย แต่ไม่สามารถส่งผลลัพธ์ที่ได้ตรง ๆ แล้วจบได้ และก็มีคนมากมายที่พยายามทำแบบนั้น
    • มีข่าวออกมาเรื่อย ๆ ว่าหน่วยงานสืบสวนได้บันทึกการใช้งานคลาวด์ LLM ไปใช้เป็นหลักฐานในการดำเนินคดีอาญา ดังนั้นถ้าเป็นอาชญากรมืออาชีพ ก็น่าจะมีโอกาสสูงที่จะ ฟอก การกระทำผ่านคนกลางที่ผิดจริยธรรมแต่ถูกกฎหมาย
    • คนที่หาเงินเก่งกับคนที่เขียนโค้ดเก่งที่สุดไม่จำเป็นต้องเป็นคนเดียวกันเสมอไป Elon Musk ก็ไม่ได้เขียนโค้ดจรวดด้วยตัวเอง แต่จ้างคนมาเขียน

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

    • ในการคำนวณเลขคณิตนั้นเหนือกว่ามนุษย์มานานยิ่งกว่านั้นมาก