EIP-7702 ไม่ใช่สาเหตุหลักของการถูกขโมยเงิน 6.3 พันล้านดอลลาร์จาก Binance วิธี获取ลายเซ็นต่างหากคือประเด็น

เวลา 04:24 น. ตามเวลาปักกิ่ง วันที่ 30 ตุลาคม 2026

ในบันทึกบนเชน เงินถูกส่งออกจาก 0x28C6…1d60 ที่อยู่นี้ชื่อ Binance 14 หนึ่งในกระเป๋าเงินร้อน Ethereum ที่ใหญ่ที่สุดของ Binance ซึ่งต้องส่งคำขอถอนเงินหลายพันรายการต่อวัน การโอนครั้งนี้ได้ย้าย 167,464 ETH, 1.615 พันล้าน USDT และโทเค็นอีกกว่า 60 ชนิด รวมมูลค่าประมาณ 2.5 พันล้านดอลลาร์ตามราคาขณะนั้น ในกระเป๋าเงินเหลือ ETH เพียง 1 เหรียญสุดท้าย

ค่าธรรมเนียม 0.0004 ETH ไม่ถึง 1 ดอลลาร์

สามนาทีก่อนหน้านั้น เวลา 04:21 น. มีคนส่งธุรกรรมประเภท EIP-7702 ให้กับมัน ซึ่งบรรจุการอนุญาต 50 รายการ โดยมี nonce เรียงจาก 18,914,775 ถึง 18,914,824 มี 49 รายการไม่ถูกต้อง และ 1 รายการตรงเป้า การตรงเป้าหมายหมายความว่า: จากวินาทีนี้เป็นต้นไป การเรียกใดๆ ต่อ Binance 14 จะดำเนินการตามสัญญาที่ผู้โจมตี déploy ไว้เมื่อคืนก่อนเวลา 23:59 น. — สัญญาที่ไม่ได้ผ่านการตรวจสอบและมีเพียงฟังก์ชัน sweep ตัวเดียวสำหรับกวาดเงิน

ดังนั้น Binance 14 จึงไม่ใช่กระเป๋าเงินอีกต่อไป มันกลายเป็นเปลือกที่บรรจุโปรแกรมของคนอื่นไว้ข้างใน

จนถึงเวลา 08:06 น. การมอบอำนาจนั้นยังคงอยู่ 3 ชั่วโมง 45 นาที ไม่มีใครเพิกถอนมัน

และการ "เพิกถอน" สิ่งนี้ ต้องการเพียงใช้กุญแจดอกเดียวกันเซ็นชื่ออีกครั้ง เช้าวันนั้นเวลา 06:55 น. Binance ยังคงใช้กุญแจนี้ในการโอนโทเค็นเศษเล็กเศษน้อยที่ไม่ได้ถูกกวาดกลับไปยังกระเป๋าเงินของตัวเอง

EIP-7702 เป็นสาเหตุหลักของการโจมตีหรือไม่

ตรรกะของ EIP-7702 มีดังนี้: ทำให้ที่อยู่ธรรมดา (EOA) สามารถเช่าโค้ดของสัญญาอัจฉริยะได้ โดยที่ที่อยู่ ยอดคงเหลือ และกุญแจส่วนตัวยังคงเดิมทั้งหมด วิธีการเช่าคือการเขียน 23 ไบต์ลงในฟิลด์ code ของที่อยู่นี้ — 0xef0100 บวกกับที่อยู่สัญญา 23 ไบต์นี้ไม่ใช่โค้ดที่สามารถเรียกใช้งานได้ แต่เป็นตัวชี้ จากนั้นใครก็ตามที่เรียกที่อยู่นี้ EVM จะไปโหลดโค้ดที่ตัวชี้ชี้ไป และดำเนินการในบริบทของที่อยู่นี้เอง: address(this) ยังคงเป็นตัวมันเอง ยอดคงเหลือยังคงเป็นยอดคงเหลือของมัน

มันไม่มีบั๊ก Derek Chiang ผู้ก่อตั้ง ZeroDev และผู้มีส่วนร่วมใน EIP-7702 กล่าวอย่างตรงไปตรงมาในวันเกิดเหตุว่า: EIP-7702 เองไม่มีช่องโหว่ ผู้ใช้กระเป๋าเงินที่สนับสนุนมาตรฐานนี้ไม่จำเป็นต้องตื่นตระหนก เขายังเสริมอีกว่า หากผู้โจมตีจะใช้ 7702 พวกเขาต้องควบคุมกุญแจส่วนตัว หรือล่อให้ Binance เซ็นการอนุญาต 7702 ออกมา

มันไม่ใช่ครั้งแรกที่ถูกใช้เป็นเครื่องมือโจมตี หลังการอัปเกรด Pectra ของ Ethereum Wintermute ค้นพบภายในไม่กี่สัปดาห์ว่ากว่า 97% ของการมอบอำนาจ 7702 บนเมนเน็ตชี้ไปยังสัญญา "ตัวกวาดเหรียญ" เกือบตัวเดียวกัน มีงานวิจัยที่นับธุรกรรมอนุมัติประมาณ 3.66 ล้านรายการ ซึ่งประมาณ 63% เกี่ยวข้องกับสัญญาอันตราย ยืนยันความเสียหาย 2.3 ล้านดอลลาร์ Blockaid ตรวจสอบเหตุการณ์ 7702 สี่ครั้งในช่วงครึ่งแรกของปี 2026 รวมประมาณ 1.08 ล้านดอลลาร์ และคาดการณ์ว่าจะมีคดีเจ็ดหลักครั้งแรกภายในปีนี้

ผลลัพธ์ที่ออกมากลับเป็นสิบหลัก สูงกว่าที่พวกเขาประเมินไว้ถึงสามอันดับขนาด

สิ่งนี้ทำให้หลายคนโทษ EIP-7702 ว่าเป็นสาเหตุของเหตุการณ์แฮกครั้งใหญ่ที่สุดในประวัติศาสตร์มนุษย์มูลค่า 5.6 พันล้านครั้งนี้ของ Binance แต่เป็นปัญหาของ 7702 จริงหรือ?

ลายเซ็นได้มาอย่างไร

ก่อนจะไปต่อ ต้องพูดให้ชัดก่อน一件事: การมอบอำนาจ 50 ฉบับ ก็มี 50 ลายเซ็น แล้ว 50 ลายเซ็นนั้นเกิดขึ้นได้อย่างไร?

ถ้าแฮกเกอร์ได้ private key ครบ เขาจะยิงสุ่ม 50 nonce ทำไม? ถ้ากุญแจอยู่ในมือ Binance ตลอด ทำไมกระเป๋า 11 ใบถึงแตกพร้อมกันใน 12 นาที? ยังไม่มีคำอธิบาย

24 วินาทีหลังการกวาดครั้งหลัก Binance 16 โอนออก 28,005.6 ETH, 55.7 ล้าน USDT, 25.9 ล้าน RLUSD, 84.5 WBTC ไปยังที่อยู่รับเงินเดียวกัน

ภายใน 12 นาที กระเป๋าร้อนอีก 10 ใบของ Binance ทำแบบเดียวกันบนสี่เชน: Binance 55 บน Optimism โอนออก 44.2 ล้าน OP; กระเป๋าสี่ใบบน Arbitrum โอนออก 74.6 ล้าน ARB และ 8,426 ETH; กระเป๋าสี่ใบบน Avalanche โอนออก 1.81 ล้าน AVAX และ 8.41 ล้าน USDT

กระเป๋าเหล่านี้ไม่มีโค้ดเลย ทุกรายการเป็นการโอนธรรมดา เซ็นด้วย private key ของกระเป๋าเอง แทรกอยู่ระหว่างการถอนปกติ

คนที่มี private key ในมือ ไม่จำเป็นต้องยิงสุ่ม nonce แค่เช็ค eth_getTransactionCount ก็ใช้เวลาวินาทีเดียว

คนที่ต้องสร้าง 50 ฉบับครอบคลุม 50 nonce ติดกันในครั้งเดียว คือคนอีกประเภท: ได้ลายเซ็นมา แต่ไม่ได้สถานะเรียลไทม์ของกระเป๋า หรือส่งชุดการมอบอำนาจที่ประกอบไว้ล่วงหน้าครั้งเดียว ให้ระบบลองเอง

ที่น่าสังเกตยิ่งกว่าคือ 50 รายการที่ได้รับอนุญาตนี้ผ่านการตรวจสอบทั้งหมดในคราวเดียวภายในธุรกรรมเดียว

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

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

นี่แสดงว่ากุญแจดอกนี้ยังอยู่ภายใต้การควบคุมของไบแนนซ์ในช่วงเช้าของวันนั้น

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

วินาทีที่พ่ายแพ้ ไม่ได้อยู่บนเชน

ดังนั้นประเด็นหลักไม่ได้อยู่ที่ EIP-7702 แต่อยู่ในช่วงก่อนการลงนาม

กระเป๋าเงินร้อนลงนามหลายพันครั้งต่อวัน จึงจำเป็นต้องทำงานอัตโนมัติ; มันต้องปลอดภัย จึงต้องมี HSM, MPC, multi-sig, กระบวนการอนุมัติ ดังนั้นโมเดลความปลอดภัยทั้งหมดจึงถูกบีบให้เหลือประโยคเดียว: กระบวนการนี้สามารถตัดสินได้หรือไม่ก่อนการลงนามว่า "รายการนี้ไม่ควรลงนาม"

ปัญหาคือ เกณฑ์การตัดสินส่วนใหญ่มีเพียงสองช่อง: จำนวนเงิน และที่อยู่

การอนุญาต 7702 ไม่มีทั้งสองช่องนี้ มันไม่มีจำนวนเงิน สิ่งที่มันเปลี่ยนไม่ใช่ "โอนเท่าไหร่" แต่เป็น "ที่อยู่นี้คืออะไร"

ไบแนนซ์ไม่ได้ไม่ได้ป้องกัน

สามวันก่อนเกิดเหตุ คือวันที่ 27 ตุลาคม ได้เปิดเผยเรื่องหนึ่งที่ควรจดจำไว้: ในช่วงหนึ่งสัปดาห์ที่ผ่านมา ทีมความปลอดภัยได้สกัดกั้นการโจมตีที่เกี่ยวข้องกับเกาหลีเหนือหลายครั้ง วิธีการเรียกว่า Contagious Interview——ฝ่ายตรงข้ามปลอมตัวเป็นผู้รับสมัครงาน ใช้การสัมภาษณ์ การทดสอบโค้ด "ติดตั้งเครื่องมือพัฒนาก่อน" หลอกให้คนไปรันโปรแกรมอันตราย; เมื่อโปรแกรมทำงาน กุญแจ เครือข่ายภายใน และช่องทางสำหรับการเคลื่อนย้ายเงินทุนในภายหลังก็มีครบ

แต่ไม่สามารถป้องกัน "รายการนี้ ควรลงนามหรือไม่" ได้

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia