คำเตือน 680 ล้านดอลลาร์: การโจมตี DeFi ส่วนใหญ่เกิดขึ้นนอกขอบเขตการตรวจสอบ

ผู้เขียน: Liam 'Akiba' Wright, cryptoslate

เรียบเรียง: Chopper, Foresight News

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

รายงานก่อนตีพิมพ์ฉบับใหม่ให้ตัวเลขที่ชัดเจนของช่องว่างนี้ นักวิจัยจากบริษัทความปลอดภัย ack3 และมหาวิทยาลัยเทคนิคเช็กแห่งปราก วิเคราะห์เหตุการณ์ความปลอดภัย 135 เหตุการณ์ที่รายงานในช่วงครึ่งแรกของปี 2025 ซึ่งสร้างความเสียหายรวม 939.86 ล้านดอลลาร์ พวกเขาพบว่า 68 เหตุการณ์มีบันทึกการตรวจสอบสาธารณะก่อนเกิดเหตุที่ระบุได้

ในกลุ่มตัวอย่าง 68 เหตุการณ์นี้ นักวิจัยจัดประเภทเส้นทางการโจมตี 46 เส้นทางว่าอยู่นอกขอบเขตการตรวจสอบใดๆ ที่ค้นหาได้ทั้งหมด 20 เหตุการณ์อยู่ในขอบเขตการตรวจสอบอย่างน้อยหนึ่งรายการ และอีก 2 เหตุการณ์ไม่สามารถระบุได้ เหตุการณ์นอกขอบเขตการตรวจสอบคิดเป็น 67.6% ของจำนวนเหตุการณ์ทั้งหมด แต่คิดเป็น 94.4% ของมูลค่าความเสียหายที่รายงานทั้งหมด

สัดส่วนที่น่าตกใจนี้ไม่ใช่การประเมินประสิทธิภาพของการตรวจสอบ และไม่ใช่หลักฐานว่าข้อจำกัดของขอบเขตการตรวจสอบเป็นสาเหตุของความเสียหาย แต่เป็นเพียงการแสดงการกระจายของความเสียหายในกลุ่มตัวอย่างเหตุการณ์ความปลอดภัยสาธารณะที่เลือกมา เหตุการณ์ใหญ่สองเหตุการณ์มีผลอย่างมากต่อข้อมูล: หากตัดความเสียหาย 292 ล้านดอลลาร์ของ Kelp DAO และ 285 ล้านดอลลาร์ของ Drift Protocol ออกไป สัดส่วนความเสียหายจากการโจมตีนอกขอบเขตการตรวจสอบในกลุ่มตัวอย่างที่ผ่านการตรวจสอบเดียวกันจะลดลงเหลือ 72.1%

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

ความหมายที่แท้จริงของข้อมูล

งานวิจัยของ ack3 นี้ครอบคลุมช่วงวันที่ 1 มกราคม ถึง 29 มิถุนายน 2025 รวมเหตุการณ์โจมตีที่ยืนยันแล้ว 122 เหตุการณ์ และเหตุการณ์ต้องสงสัย 13 เหตุการณ์ ในกลุ่มตัวอย่างทั้งหมด 35 เหตุการณ์ไม่พบบันทึกการตรวจสอบ และ 32 เหตุการณ์ไม่ทราบประวัติการตรวจสอบ ทั้งสองประเภทนี้ไม่นับรวมในสถิติ 68 เหตุการณ์ข้างต้น

ในกลุ่มตัวอย่าง 68 เหตุการณ์ ความเสียหายจากเหตุการณ์นอกขอบเขตการตรวจสอบคิดเป็น 680.97 ล้านดอลลาร์ จากความเสียหายรวม 721.24 ล้านดอลลาร์ จึงได้ตัวเลข 94.4% หลังจากตัด Kelp DAO และ Drift Protocol ออก ความเสียหายนอกขอบเขตการตรวจสอบอยู่ที่ 103.97 ล้านดอลลาร์ จากความเสียหายรวม 144.24 ล้านดอลลาร์ คิดเป็น 72.1% ไฟล์ json ของชุดข้อมูลสามารถใช้ทำซ้ำจำนวนการจัดประเภทเหตุการณ์และมูลค่าความเสียหายได้

ป้ายกำกับ "ใน/นอกขอบเขตการตรวจสอบ" เป็นการตัดสินของนักวิจัยจากหลักฐานสาธารณะ ทีมวิจัยตรวจสอบเอกสารเก็บถาวรของโปรเจกต์และบริษัทตรวจสอบ ค้นหารายงานการตรวจสอบก่อนเกิดการโจมตี แล้วเปรียบเทียบเส้นทางการโจมตีสุดท้ายกับโค้ดที่ตรวจสอบ เวอร์ชัน และข้อยกเว้นในการตรวจสอบ งานวิจัยนี้เป็นบทความก่อนตีพิมพ์ความยาว 6 หน้า จัดทำร่วมกับผู้เผยแพร่ชุดข้อมูล โดยผู้เขียนสองคนสังกัดบริษัทตรวจสอบความปลอดภัย ack3

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

ดังนั้น งานวิจัยนี้จึงได้ข้อสรุปที่จำกัดเพียงว่า: บันทึกการตรวจสอบและขอบเขตการตรวจสอบเป็นตัวชี้วัดสองตัวที่แยกจากกัน สัญญาอัจฉริยะที่ผ่านการตรวจสอบแล้ว ไม่ได้หมายความว่าการอัปเกรดสัญญา คีย์สิทธิพิเศษ ฟรอนต์เอนด์ รีเลย์ ออราเคิล บริการคลาวด์ หรือกระบวนการตอบสนองเหตุฉุกเฉิน จะได้รับการรับประกันความปลอดภัยในระดับเดียวกัน

เหตุการณ์สองเหตุการณ์ในเดือนสิงหาคม ยืนยันความแตกต่างนี้จากมุมมองที่ต่างกัน กรณี ICON Network แสดงให้เห็นอย่างชัดเจนว่าโค้ดสองส่วนที่ผ่านการตรวจสอบแล้วเกิดความผิดพลาดที่รอยต่อระหว่างจุดตรวจสอบสองจุด ส่วนเหตุการณ์ความปลอดภัยของ aelf ในเดือนสิงหาคมเป็นอีกกรณีหนึ่ง หลักฐานการตรวจสอบที่มีอยู่ยังไม่สามารถจับคู่เส้นทางการโจมตีกับขอบเขตการตรวจสอบก่อนเกิดเหตุได้

ICON Network: ตัวอย่างความล้มเหลวที่รอยต่อของการตรวจสอบ

ในการโจมตีแบบรีเพลย์ของ ICON Network เมื่อวันที่ 27 สิงหาคม โมดูลสองตัวในเส้นทางการถอนเงินตีความข้อความเดียวกันแตกต่างกัน

ตามรายงานหลังเหตุการณ์ของมูลนิธิ ICON: สัญญาการย้ายข้อมูลอาศัยบิตสูงของหมายเลขลำดับข้อความถอนเงินเพื่อตัดสินว่าข้อความไม่ซ้ำกันหรือไม่ แต่ลายเซ็นเข้ารหัสครอบคลุมเฉพาะ 256 บิตล่างของหมายเลขลำดับ ผู้โจมตีแก้ไขบิตสูงที่ไม่ได้รวมอยู่ในการตรวจสอบลายเซ็น แล้วส่งข้อความถอนเงินที่มีลายเซ็นถูกต้องสองข้อความซ้ำ 1,492 ครั้งภายในเวลาประมาณ 20 นาที โดย 1,490 ครั้งทำสำเร็จ

การโจมตีแบบรีเพลย์นี้ปล่อย ICX 119.866 ล้านเหรียญ และ bnUSD 531,600 เหรียญ ณ เวลาที่เผยแพร่รายงาน ICON ยืนยันความเสียหายสุทธิประมาณ 150.2 ETH บวก USDC 31,204 เหรียญ มูลนิธิระบุว่า bnUSD 531,600 เหรียญ และ SODA 1.366 ล้านเหรียญถูกกู้คืนแล้ว เงินฝากผู้ใช้ ยอดคงเหลือในบัญชี และสถานะการถือครองไม่ได้รับผลกระทบ

ICON ระบุว่าสัญญาการย้ายข้อมูลนี้ผ่านการตรวจสอบภายนอกแล้ว และได้ปฏิบัติตามคำแนะนำจากการตรวจสอบ รวมถึงการแก้ไขที่เกี่ยวข้องในบริเวณโมดูลเดียวกัน ลอจิกของรีเลย์ที่เกี่ยวข้องก็ได้รับการตรวจสอบเฉพาะทางแยกต่างหาก รายการตรวจสอบในเอกสารนักพัฒนาของ Sodax มีรายงาน 8 ฉบับครอบคลุมส่วนประกอบต่างๆ รวมถึงรายงานการตรวจสอบรีเลย์ Sodax เดือนพฤศจิกายน 2025

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

ไทม์ไลน์การตอบสนองยังเผยให้เห็นปัญหาขอบเขตอีกประเภทหนึ่ง สัญญาณเตือนอัตโนมัติแรกของ ICON ทำงานเมื่อเวลา UTC 02:08 ประมาณ 7 นาทีหลังการโจมตีเริ่มขึ้น เจ้าหน้าที่เริ่มการสอบสวนประมาณ 03:40 น. หยุดสัญญาที่ได้รับผลกระทบเมื่อ 03:53 น. และหยุดเครือข่ายทั้งหมดเมื่อ 06:18:54 น.

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

กลไกการควบคุมความเสี่ยงประเภทนี้ไม่สามารถแทนที่การตรวจสอบได้ แต่ตอบคำถามสำคัญอีกข้อหนึ่ง: เมื่อมาตรการป้องกันล้มเหลว ระบบสามารถตรวจจับและแยกความเสี่ยงได้อย่างรวดเร็วหรือไม่

aelf: การรับประกันความปลอดภัยต้องอัปเดตอย่างต่อเนื่อง

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

ประกาศอย่างเป็นทางการของโปรเจกต์อธิบายว่า: มีสัญญาอัจฉริยะที่ไม่ได้รับอนุญาต ซึ่งสามารถใช้พารามิเตอร์ธุรกรรมเพื่อแทรก .NET assembly และคำสั่งที่เข้ารหัสเข้าไปในเส้นทางการทำงานของโหนด

รายงานการสอบสวนเบื้องต้นระบุสาเหตุของเหตุการณ์ว่าเป็นข้อบกพร่องในการตรวจสอบการสะท้อนขณะรันไทม์และการโหลดแบบไดนามิก รวมถึงการแยกที่ไม่เพียงพอระหว่างสภาพแวดล้อมการทำงานของสัญญากับโหนดที่ละเอียดอ่อนและทรัพยากรโครงสร้างพื้นฐาน aelf ระบุธุรกรรมที่เกี่ยวข้อง 155 รายการ และ payload assembly อิสระ 5 ชุด ซึ่งมีความสามารถในการรันคำสั่งโฮสต์ พยายามสื่อสารภายนอก เข้าถึงคีย์โหนด และสำรวจโครงสร้างพื้นฐาน

การมีความสามารถไม่ได้หมายความว่า payload ทั้งหมดทำงานสำเร็จ หรือผู้โจมตีได้ข้อมูลรับรองเป้าหมายทั้งหมดและข้อมูลละเอียดอ่อนรั่วไหล aelf ระบุว่าได้หมุนเวียนคีย์ลายเซ็นและข้อมูลรับรองโครงสร้างพื้นฐานตามมาตรฐานการรั่วไหลที่อาจเกิดขึ้น

ณ วันที่ 11 กันยายน ข้อสรุปนี้ยังเป็นเพียงการตัดสินชั่วคราว บล็อกทางการของ aelf ไม่ได้เผยแพร่การอัปเดตเฉพาะเกี่ยวกับเหตุการณ์นี้หลังจากวันที่ 26 สิงหาคม ประกาศวันที่ 26 สิงหาคมสัญญาว่าจะเผยแพร่การอัปเดตและรายงานหลังเหตุการณ์ฉบับสมบูรณ์ในภายหลัง

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

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

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

นี่ไม่ใช่การปฏิเสธคุณค่าของการตรวจสอบ แต่เป็นการทำให้การโฆษณาการตรวจสอบสอดคล้องกับเนื้อหางานจริง และเชื่อมโยงกับระบบที่กำลังทำงานอยู่ในปัจจุบัน

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