แก่นหลักของการโจมตีครั้งนี้ต่อ Kelp คือ: ผู้โจมตีใช้ข้อความข้ามโซ่ปลอม เพื่อให้สะพาน LayerZero OFT ปล่อย rsETH จริงจำนวน 116,500 หน่วยโดยตรงบน Ethereum Mainnet โดยไม่มีการเผาทำลายบนโซ่ต้นทาง จากนั้นนำ rsETH ที่เป็น “เปลือก” เหล่านี้ไปใช้เป็นหลักประกันในโปรโตคอลต่างๆ เช่น Aave เพื่อกู้ WETH/ETH จริงออกมาประมาณ 236 ล้านดอลลาร์สหรัฐ ช่องโหว่หลักไม่ได้อยู่ที่ Aave แต่อยู่ที่การตั้งค่าสะพานข้ามโซ่ LayerZero ของ Kelp DAO Kelp ใช้มาตรฐาน OFT (Omnichain Fungible Token) ของ LayerZero V2 สำหรับการข้ามโซ่ rsETH: บน Ethereum Mainnet, สัญญา OFTAdapter จะล็อก rsETH เป็นสินทรัพย์สำรองสุดท้ายสำหรับ rsETH ที่ถูกห่อหุ้มบน L2 ต่างๆ (เหมือนตู้เซฟของธนาคาร) บน L2, สัญญา OFT มาตรฐานจะใช้กลไก 1:1 แบบ “debit (เผา/หัก) → ส่งข้อความ → credit (สร้าง/ปล่อย)” เมื่อข้ามโซ่ ในกรณีปกติ กระบวนการจะเป็นดังนี้: ผู้ใช้บน L2 เผา rsETH → LayerZero ส่งข้อความ → OFTAdapter บน Mainnet รับข้อความแล้วปล่อย rsETH แต่ผู้โจมตีทำเพียงสิ่งเดียวเท่านั้น: เรียกใช้งานฟังก์ชัน lzReceive ของสัญญา EndpointV2 โดยตรงบน Ethereum Mainnet (แฮชธุรกรรมเปิดเผยแล้ว: 0x1ae232da…) พร้อมกับส่งแพ็กเกจข้อความข้ามโซ่ปลอม (origin packet) ที่อ้างว่ามาจากโซ่ต้นทางที่ถูกต้อง หลังจาก EndpointV2 ตรวจสอบผ่านแล้ว จะส่งข้อความนี้ไปยัง OFTAdapter ของ Kelp OFTAdapter เมื่อรับข้อความแล้ว จะปล่อย rsETH จำนวน 116,500 หน่วยโดยตรงจากสินทรัพย์สำรองบน Mainnet ไปยังที่อยู่ของผู้โจมตี ดังนั้นจึงไม่มีบันทึกการเผาหรือหักจากโซ่ต้นทาง แต่กลับมีการปล่อยและเพิ่มจำนวนบน Mainnet สมดุลของปริมาณ omnichain ถูกทำลาย สินทรัพย์สำรองบน Mainnet ถูกดึงออกหมด และ rsETH ทั้งหมดบน L2 กลายเป็น “กระดาษไร้ค่า” การโจมตีทั้งหมดเกิดขึ้นภายในหนึ่งธุรกรรม การโจมตีเพิ่มเติมสองครั้งต่อมา (ครั้งละ 40,000 หน่วย) ไม่สำเร็จ เพราะ Kelp ระงับการทำงานทันที ดังนั้นคำถามคือ: ทำไมสะพาน LayerZero ถึง “ยอมรับ” ข้อความปลอมนี้? ไม่ใช่เพราะโปรโตคอล LayerZero มีบั๊ก แต่เกิดจากการตั้งค่าความปลอดภัยของ OApp (ชั้นแอปพลิเคชัน) ของ Kelp อ่อนแอเกินไป LayerZero V2 อนุญาตให้นักพัฒนาปรับระดับความเข้มงวดของการตรวจสอบ โดยใช้ DVN (Distributed Validator Network) เพื่อยืนยันข้อความ Kelp ตั้งค่าเพียง DVN แบบ 1-of-1 (ต้องการลายเซ็นจากผู้ตรวจสอบเพียงคนเดียวเท่านั้น) — เป็นระดับความปลอดภัยต่ำสุด ตั้งแต่เดือนมกราคม 2025 มีการเตือนบนฟอรั่มการกำกับดูแลของ Aave ว่า Kelp ควรขยาย DVN เป็นแบบหลายลายเซ็น (อย่างน้อย 2-of-2 หรือมากกว่า) แต่ผ่านไปกว่า 15 เดือน ก็ยังไม่มีการเปลี่ยนแปลง และยังคงเลือกการตั้งค่า “ความเร็วเป็นหลัก” ที่อ่อนแอที่สุด จุดเดียวที่อ่อนแอเหล่านี้กลายเป็นจุดโจมตีหลักของเหตุการณ์ครั้งนี้: การโจมตีผู้ตรวจสอบ DVN เพียงคนเดียว การปลอมลายเซ็น หรือการสร้าง packet ที่ผ่านการตรวจสอบได้อย่างถูกต้อง เมื่อ EndpointV2 ได้รับข้อความที่ “ผ่านการตรวจสอบ” จะเรียกใช้งาน lzReceive โดยตรงของสัญญาเป้าหมาย OFTAdapter โดยสมบูรณ์เชื่อถือ packet จาก Endpoint โดยไม่มีการตรวจสอบเพิ่มเติมใดๆ หาก Kelp มิได้มุ่งเน้นแต่ความเร็วเท่านั้น หากพิจารณาสมดุลระหว่างความปลอดภัยด้วย การโจมตีครั้งนี้อาจไม่ประสบความสำเร็จ กล่าวคือ Kelp ได้วาง “ความถูกต้องของข้อความข้ามโซ่” เอาไว้ที่ DVN เพียงหนึ่งเดียวเท่านั้น สุดท้าย rsETH สามารถกู้ ETH จริงได้อย่างรวดเร็ว เพราะ rsETH เป็นสินทรัพย์หลักประกันที่อยู่ในรายการอนุญาตของ Aave และโปรโตคอลอื่นๆ ผู้โจมตีได้นำ rsETH เทียมไปฝากใน Aave และกู้ WETH จริงออกมาภายในเวลาเพียง 46 นาทีก่อนที่ Kelp จะระงับการทำงาน เมื่อ Kelp กัก冻结สะพานและโทเค็นแล้ว เงินกู้เสียหายได้เกิดขึ้นใน Aave แล้ว (Aave กัก冻结ตลาด rsETH และเปิดใช้งานโมดูลความปลอดภัย Umbrella เพื่อจัดการ) สรุป: แก่นหลักของการปลอมแปลงคือ “การตั้งค่า DVN เพียงหนึ่งเดียว + การเรียก lzReceive โดยตรงเพื่อส่ง packet เทียม” ความเสี่ยงจากการตรวจสอบแบบจุดเดียวรวมกับความสามารถในการรวมกันของ DeFi ส่งผลให้เกิดเหตุการณ์แฮกขนาดใหญ่ครั้งนี้ การตรวจสอบแบบจุดเดียวเป็นจุดอ่อน — ความเร็วสำคัญ แต่ความปลอดภัยสำคัญกว่า

แชร์






แหล่งที่มา:แสดงต้นฉบับ
คำปฏิเสธความรับผิดชอบ: ข้อมูลในหน้านี้อาจได้รับจากบุคคลที่สาม และไม่จำเป็นต้องสะท้อนถึงมุมมองหรือความคิดเห็นของ KuCoin เนื้อหานี้จัดทำขึ้นเพื่อวัตถุประสงค์ในการให้ข้อมูลทั่วไปเท่านั้น โดยไม่มีการรับรองหรือการรับประกัน และจะไม่ถูกตีความว่าเป็นคำแนะนำทางการเงินหรือการลงทุน KuCoin จะไม่รับผิดชอบต่อความผิดพลาดหรือการละเว้นในเนื้อหา หรือผลลัพธ์ใดๆ ที่เกิดจากการใช้ข้อมูลนี้
การลงทุนในสินทรัพย์ดิจิทัลอาจมีความเสี่ยง โปรดประเมินความเสี่ยงของผลิตภัณฑ์และความเสี่ยงที่คุณยอมรับได้อย่างรอบคอบตามสถานการณ์ทางการเงินของคุณเอง โปรดดูข้อมูลเพิ่มเติมได้ที่ข้อกำหนดการใช้งานและเอกสารเปิดเผยข้อมูลความเสี่ยงของเรา
