เงิน 293 ล้านดอลลาร์หายไปอย่างไร้ร่องรอย โค้ดที่ไม่มีช่องโหว่ใดๆ: การแฮ็กครั้งใหญ่ที่สุดของปี 2026 เผยให้เห็นจุดบอดด้านความปลอดภัยในการกำหนดค่า DVN

เมื่อวันที่ 18 เมษายน 2569 โปรโตคอลการวางเดิมพันสภาพคล่องของ Kelp DAO ถูกแฮ็กโดยผู้โจมตีที่ขโมย rsETH จำนวน 116,500 เหรียญจากสะพานเชื่อมระหว่างเชนภายในเวลาไม่กี่ชั่วโมง ซึ่งเทียบเท่ากับประมาณ 293 ล้านดอลลาร์สหรัฐในขณะนั้น กระบวนการทั้งหมดมีประสิทธิภาพอย่างผิดปกติ ตั้งแต่การปลอมแปลงข้อความข้ามเชนไปจนถึงการกระจายเงินที่ถูกขโมยไปยังโปรโตคอลการให้กู้ยืมสามแห่ง ได้แก่ Aave V3, Compound V3 และ Euler เพื่อยืมสินทรัพย์จริง ผู้โจมตีถอนเงิน WETH มูลค่า 236 ล้านดอลลาร์สหรัฐในวันเดียวกันนั้น ต่อมา Aave, SparkLend และ Fluid ได้ระงับตลาด rsETH

นี่คือการโจมตี DeFi ครั้งใหญ่ที่สุดเท่าที่เคยเกิดขึ้นในปี 2026

แต่สิ่งหนึ่งที่ทำให้การโจมตีครั้งนี้แตกต่างจากการแฮ็กส่วนใหญ่คือ โค้ดสัญญาอัจฉริยะของ Kelp DAO ไม่มีช่องโหว่ นักวิจัยด้านความปลอดภัย @0xQuit ซึ่งมีส่วนร่วมในการสืบสวน เขียนไว้ใน X ว่า "จากสิ่งที่ผมเข้าใจในตอนนี้ นี่เป็นปัญหาที่เกิดจากสองสาเหตุรวมกัน คือ การกำหนดค่า DVN แบบ 1 ใน 1 และตัวโหนด DVN เองถูกบุกรุก" แถลงการณ์อย่างเป็นทางการของ LayerZero ก็ไม่ได้กล่าวถึงโค้ดสัญญาเช่นกัน โดยระบุว่าเป็น "ช่องโหว่ของ rsETH" มากกว่า "ช่องโหว่ของ LayerZero"

เงินจำนวน 293 ล้านดอลลาร์นั้นไม่ได้อยู่ในโค้ดบรรทัดใด ๆ เลย มันซ่อนอยู่ในพารามิเตอร์การตั้งค่าที่ป้อนผิดพลาดระหว่างการติดตั้งใช้งาน

หลักการทั่วไปของการตรวจสอบความปลอดภัยของ DeFi คือ: ค้นหาสัญญา อ่านโค้ด และค้นหาช่องโหว่ หลักการนี้ทำงานได้อย่างราบรื่นเมื่อต้องรับมือกับช่องโหว่ในตรรกะของโค้ด เครื่องมืออย่าง Slither และ Mythril มีความสามารถที่ค่อนข้างสมบูรณ์ในการตรวจจับรูปแบบที่รู้จักกันดี เช่น การโจมตีแบบ reentrancy และ integer overflow การตรวจสอบโค้ดโดยใช้ LLM ซึ่งได้รับการส่งเสริมอย่างมากในช่วงสองปีที่ผ่านมา ก็มีความสามารถในการตรวจจับช่องโหว่ในตรรกะทางธุรกิจ (เช่น เส้นทางการเก็งกำไรจาก flash loan) ได้เช่นกัน

อย่างไรก็ตาม ในเมทริกซ์นี้มีสองแถวที่เป็นสีแดง

ช่องโหว่ในระดับการกำหนดค่าเป็นจุดบอดเชิงโครงสร้างในการตรวจสอบด้วยเครื่องมือ ปัญหาของ Kelp DAO ไม่ได้อยู่ที่ไฟล์ .sol แต่Sอยู่ที่พารามิเตอร์ที่เขียนขึ้นระหว่างการปรับใช้โปรโตคอล นั่นคือเกณฑ์ DVN พารามิเตอร์นี้กำหนดจำนวนโหนดการตรวจสอบที่ข้อความข้ามเชนต้องได้รับการยืนยันเพื่อให้ถือว่าถูกต้อง พารามิเตอร์นี้ไม่ได้อยู่ในโค้ด ไม่ได้อยู่ในขอบเขตการสแกนของ Slither และไม่ได้อยู่ในเส้นทางการดำเนินการเชิงสัญลักษณ์ของ Mythril จากการศึกษาเปรียบเทียบโดย Dreamlab Technologies พบว่า Slither และ Mythril ตรวจพบช่องโหว่ 5/10 และ 6/10 ตามลำดับในสัญญาที่ทดสอบ แต่ความสำเร็จนี้ขึ้นอยู่กับสมมติฐานที่ว่า "ช่องโหว่อยู่ในโค้ด" จากการวิจัยของ IEEE พบว่าแม้ในระดับโค้ด เครื่องมือที่มีอยู่ก็สามารถตรวจพบช่องโหว่ที่สามารถใช้ประโยชน์ได้เพียง 8%-20% เท่านั้น

จากมุมมองของกระบวนการตรวจสอบที่มีอยู่ ไม่มีเครื่องมือใดที่สามารถ "ตรวจจับได้ว่าค่าเกณฑ์ DVN นั้นสมเหตุสมผลหรือไม่" ในการตรวจจับความเสี่ยงด้านการกำหนดค่าประเภทนี้ สิ่งที่จำเป็นไม่ใช่เครื่องมือวิเคราะห์โค้ด แต่เป็นรายการตรวจสอบการกำหนดค่าเฉพาะ เช่น "จำนวน DVN ที่ใช้ในโปรโตคอลข้ามเชน ≥ N หรือไม่" และ "มีข้อกำหนดเกณฑ์ขั้นต่ำหรือไม่" ปัจจุบันยังไม่มีเครื่องมือมาตรฐานใดที่ครอบคลุมคำถามเหล่านี้ และยังไม่มีมาตรฐานอุตสาหกรรมที่เป็นที่ยอมรับอย่างกว้างขวางด้วยซ้ำ

นอกจากนี้ ในพื้นที่สีแดงยังรวมถึงความปลอดภัยของคีย์และโหนดด้วย คำอธิบายของ @0xQuit กล่าวถึงโหนด DVN ที่ "ถูกเจาะ" ซึ่งจัดอยู่ในหมวดหมู่ความปลอดภัยในการปฏิบัติงาน (OpSec) และอยู่นอกเหนือความสามารถในการตรวจจับของเครื่องมือวิเคราะห์แบบคงที่ใดๆ บริษัทตรวจสอบชั้นนำหรือเครื่องมือสแกน AI ก็ไม่สามารถคาดการณ์ได้ว่าคีย์ส่วนตัวของผู้ดำเนินการโหนดจะรั่วไหลหรือไม่

การโจมตีครั้งนี้ทำให้เกิดพื้นที่สีแดงสองแห่งในเมทริกซ์พร้อมกัน

DVN คือกลไกการตรวจสอบข้อความข้ามเชนสำหรับ LayerZero V2 ซึ่งย่อมาจาก Decentralized Verifier Network หลักการออกแบบคือการมอบอำนาจการตัดสินใจด้านความปลอดภัยให้กับเลเยอร์แอปพลิเคชัน: แต่ละโปรโตคอลที่เชื่อมต่อกับ LayerZero สามารถเลือกได้ว่าต้องมีโหนด DVN กี่โหนดที่ต้องยืนยันพร้อมกันก่อนที่จะอนุญาตให้ข้อความข้ามเชนผ่านไปได้

"ระดับความเป็นอิสระ" นี้ก่อให้เกิดสเปกตรัม

Kelp DAO เลือกการกำหนดค่าแบบ 1 ใน 1 ทางซ้ายสุดบนสเปกตรัม ซึ่งต้องการเพียงโหนด DVN เดียวสำหรับการยืนยัน นั่นหมายความว่าไม่มีความทนทานต่อความผิดพลาดเลย ผู้โจมตีเพียงแค่เจาะโหนดนั้นโหนดเดียวก็สามารถปลอมแปลงข้อความข้ามเชนได้ตามอำเภอใจ ในทางตรงกันข้าม Apechain ซึ่งก็ผสานรวมกับ LayerZero เช่นกัน แต่กำหนดค่า DVN มากกว่าสองโหนด กลับไม่ได้รับผลกระทบจากเหตุการณ์นี้ คำแถลงอย่างเป็นทางการของ LayerZero ระบุว่า "แอปพลิเคชันอื่นๆ ทั้งหมดยังคงปลอดภัย" ซึ่งหมายความว่าความปลอดภัยขึ้นอยู่กับการกำหนดค่าที่คุณเลือก

ข้อแนะนำมาตรฐานในอุตสาหกรรมคืออย่างน้อย 2 ใน 3 ซึ่งหมายความว่าผู้โจมตีจะต้องเจาะระบบโหนด DVN อิสระสองโหนดพร้อมกันเพื่อปลอมแปลงข้อความ ทำให้ความทนทานต่อความผิดพลาดเพิ่มขึ้นเป็น 33% การกำหนดค่าความปลอดภัยสูง เช่น 5 ใน 9 สามารถบรรลุความทนทานต่อความผิดพลาดได้ถึง 55%

ปัญหาคือผู้สังเกตการณ์และผู้ใช้ภายนอกไม่สามารถมองเห็นการกำหนดค่านี้ได้ ทั้งสองอย่างมีป้ายกำกับว่า "Powered by LayerZero" แต่ความทนทานต่อข้อผิดพลาดที่อยู่เบื้องหลังอาจเป็น 0% หรือ 55% ทั้งสองอย่างถูกอ้างถึงในเอกสารว่าเป็น DVN

Dovey Wan นักลงทุนคริปโตผู้มากประสบการณ์ซึ่งเคยประสบเหตุการณ์ Anyswap ได้เขียนข้อความโดยตรงบน X ว่า "DVN ของ LayerZero เป็นตัวตรวจสอบความถูกต้องแบบ 1/1... สะพานเชื่อมระหว่างเชนทั้งหมดควรได้รับการตรวจสอบความปลอดภัยอย่างเต็มรูปแบบโดยทันที"

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

การวิเคราะห์หลังเกิดเหตุการณ์ของ Nomad ระบุว่าช่องโหว่ดังกล่าวมีต้นกำเนิดมาจาก "การกำหนดค่าเริ่มต้นของรูทที่เชื่อถือได้เป็น 0x00 ระหว่างการอัปเกรดตามปกติ" ซึ่งเป็นข้อผิดพลาดในการกำหนดค่าที่เกิดขึ้นในระหว่างขั้นตอนการติดตั้งใช้งาน Merkle พิสูจน์แล้วว่าตรรกะการตรวจสอบถูกต้อง โค้ดเองไม่ได้มีข้อบกพร่อง ปัญหาอยู่ที่ค่าเริ่มต้นที่ไม่ถูกต้อง

เมื่อรวมกับ Nomad แล้ว ช่องโหว่ในการกำหนดค่า/การเริ่มต้นใช้งานทำให้เกิดความเสียหายประมาณ 482 ล้านดอลลาร์ ในประวัติศาสตร์ทั้งหมดของการโจรกรรมสะพานเชื่อมข้ามเชน หมวดหมู่นี้มีขนาดเทียบได้กับการรั่วไหลของคีย์ (624 ล้านดอลลาร์สำหรับ Ronin, 100 ล้านดอลลาร์สำหรับ Harmony และ 126 ล้านดอลลาร์สำหรับ Multichain รวมเป็นประมาณ 850 ล้านดอลลาร์)

อย่างไรก็ตาม การออกแบบผลิตภัณฑ์ในอุตสาหกรรมการตรวจสอบโค้ดไม่เคยถูกมุ่งเน้นไปที่หมวดหมู่นี้มาก่อน

หัวข้อที่ถูกพูดถึงมากที่สุดในอุตสาหกรรมยังคงเป็นช่องโหว่ด้านตรรกะของโค้ด ตัวอย่างเช่น การสูญเสีย 326 ล้านดอลลาร์ของ Wormhole เนื่องจากการหลีกเลี่ยงการตรวจสอบลายเซ็น และการโจรกรรม 80 ล้านดอลลาร์ของ Qubit Finance เนื่องจากการฝากเงินที่ฉ้อโกง กรณีเหล่านี้มีรายงานการวิเคราะห์ช่องโหว่ที่สมบูรณ์ การเปรียบเทียบหมายเลข CVE และ PoC ที่สามารถทำซ้ำได้ ทำให้เหมาะสำหรับการฝึกอบรมและเพิ่มประสิทธิภาพเครื่องมือตรวจสอบ ปัญหาในระดับการกำหนดค่า หากไม่ได้รับการแก้ไขในโค้ด ก็ไม่น่าจะถูกนำไปใช้ในวงจรการผลิต

รายละเอียดที่น่าสนใจอย่างหนึ่งคือ เหตุการณ์การกำหนดค่าทั้งสองเกิดขึ้นในลักษณะที่แตกต่างกันอย่างสิ้นเชิง Nomad ป้อนค่าเริ่มต้นที่ไม่ถูกต้องโดยไม่ได้ตั้งใจระหว่างการอัปเกรดตามปกติ ซึ่งเป็นความผิดพลาด ในทางกลับกัน การตั้งค่า 1-of-1 ของ Kelp DAO เป็นการเลือกการกำหนดค่าเชิงรุก โปรโตคอล LayerZero ไม่ได้ห้ามตัวเลือกนี้ และ Kelp DAO ไม่ได้ละเมิดกฎของโปรโตคอลใดๆ การเลือกการกำหนดค่าที่ "สอดคล้อง" และค่าเริ่มต้นที่ "ผิดพลาด" ในท้ายที่สุดแล้วชี้ไปสู่ผลลัพธ์เดียวกัน

หลักการทำงานของการโจมตีนี้เรียบง่าย: ข้อความข้ามเชนปลอมจะแจ้งให้เครือข่ายหลักของ Ethereum ทราบว่า "มีคนในเชนอื่นล็อกสินทรัพย์ที่มีมูลค่าเท่ากันไว้" ซึ่งจะกระตุ้นให้เครือข่ายหลักสร้าง rsETH ขึ้นมา rsETH ที่สร้างขึ้นมานั้นไม่มีสินทรัพย์รองรับที่แท้จริง แต่บันทึกในเชนของมัน "ถูกต้องตามกฎหมาย" และสามารถใช้เป็นหลักประกันได้โดยโปรโตคอลการให้กู้ยืม

จากนั้นผู้โจมตีได้กระจาย rsETH จำนวน 116,500 เหรียญไปยัง Aave V3 (Ethereum และ Arbitrum), Compound V3 และ Euler โดยปล่อยกู้สินทรัพย์จริงรวมมูลค่ากว่า 236 ล้านดอลลาร์สหรัฐ จากรายงานหลายฉบับ พบว่า Aave V3 เพียงแห่งเดียวเผชิญกับหนี้เสียประมาณ 177 ล้านดอลลาร์สหรัฐ โมดูลรักษาความปลอดภัยของ Aave ที่ชื่อ Umbrella มีเงินสำรอง WETH ประมาณ 50 ล้านดอลลาร์สหรัฐที่พร้อมรองรับหนี้เสีย ซึ่งครอบคลุมได้น้อยกว่า 30% ของยอดรวมทั้งหมด ส่วนที่เหลือจะได้รับการคุ้มครองโดยผู้ถือครอง aWETH

ท้ายที่สุดแล้ว ภาระนี้ตกอยู่กับผู้ที่แค่ต้องการหารายได้เล็กน้อยจากดอกเบี้ยของ WETH เท่านั้น

ณ เวลาที่รายงานข่าวนี้เผยแพร่ LayerZero ยังคงดำเนินการสอบสวนร่วมกับองค์กรรับมือเหตุการณ์ด้านความปลอดภัย SEAL Org และระบุว่าจะเผยแพร่รายงานการวิเคราะห์หลังเกิดเหตุร่วมกับ Kelp DAO หลังจากได้รับข้อมูลทั้งหมดแล้ว Kelp DAO ระบุว่ากำลังดำเนินการ "แก้ไขเชิงรุก"

ช่องโหว่มูลค่า 293 ล้านดอลลาร์ไม่ได้อยู่ในโค้ด วลี "การตรวจสอบผ่านแล้ว" ไม่ได้ระบุตำแหน่งของพารามิเตอร์นั้น