กลับ

2026/11/03

ลายเซ็นเดียวที่ดูดเงินจาก Hot Wallet ของ Binance ซ้ำแล้วซ้ำเล่า: การมอบสิทธิ์ EIP-7702 เบื้องหลังการเจาะระบบ

การอนุญาต EIP-7702 ที่ลงนามล่วงหน้า 50 รายการ ตรงกันเพียงหนึ่ง และการมอบสิทธิ์ที่อยู่ต่อแม้กระเป๋าว่าง กลไกนี้ทำงานอย่างไร และผู้ดูแล hot wallet ควรเฝ้าระวังอะไร

ในบทความแรกเกี่ยวกับการเจาะระบบ Binance เราได้ดูว่าการโจมตีน่าจะเริ่มต้นอย่างไร: แล็ปท็อปของทีม DevOps ที่ถูกเจาะ และผู้โจมตีที่เข้าถึงระบบซึ่งใช้อนุมัติการดำเนินการที่มีความสำคัญได้ ต่อมาการวิเคราะห์บนเชนโดยบริษัทด้านความปลอดภัย Blockaid ได้แสดงให้เห็นว่าขั้นตอนสุดท้ายบน Ethereum ทำงานอย่างไร โดยใช้ EIP-7702 ซึ่งเป็นฟีเจอร์ที่เพิ่มเข้ามาใน Ethereum เมื่อเดือนพฤษภาคม 2025 และสะท้อนความเสี่ยงที่ผู้ดูแล hot wallet จำนวนมากยังไม่ได้วางแผนรับมือ

สรุปสั้น ๆ คือ การอนุญาตที่ลงนามเพียงรายการเดียวได้เปลี่ยน hot wallet บน Ethereum ที่ใหญ่ที่สุดของ Binance ให้กลายเป็นบัญชีที่ผู้โจมตีควบคุมได้ การควบคุมนั้นไม่ได้สิ้นสุดลงเมื่อกระเป๋าว่างเปล่า และก็จะไม่สิ้นสุดแม้จะหมุนเวียนคีย์ (key rotation) ก็ตาม

ประเด็นสำคัญ

  • ผู้โจมตีรวมการอนุญาต EIP-7702 ที่ลงนามไว้ล่วงหน้า 50 รายการ ครอบคลุม nonce ต่อเนื่องกัน 50 ค่า ไว้ในธุรกรรมเดียว มีเพียงรายการเดียวที่ตรงกัน และส่งมอบการทำงานของกระเป๋าให้กับสัญญาของผู้โจมตี
  • การมอบสิทธิ์แบบ EIP-7702 จะคงอยู่จนกว่าบัญชีจะแทนที่หรือล้างมัน เงินฝากที่เข้ามาหลังการกวาดครั้งแรก ซึ่งในช่วงหนึ่งมีมากกว่า 200 ล้านดอลลาร์ ถูกนำไปโดยไม่ต้องมีลายเซ็นใหม่เลย
  • การหมุนเวียน private key ไม่ได้ลบการมอบสิทธิ์ เพราะการมอบสิทธิ์ผูกอยู่กับแอดเดรส มีเพียงการเพิกถอนอย่างชัดแจ้งเท่านั้นที่จะล้างมันได้
  • ยังไม่มีคำตอบว่าผู้โจมตีได้ลายเซ็นที่ถูกต้อง 50 รายการมาอย่างไร Binance ระบุว่ายังไม่พบหลักฐานว่า private key รั่วไหล
  • ผู้ดูแล hot wallet ควรเฝ้าติดตามสถานะการมอบสิทธิ์ ปฏิเสธการลงนามการอนุญาตที่ตนไม่ได้ตั้งใจ และใส่ขั้นตอนการเพิกถอนอย่างชัดแจ้งไว้ในคู่มือรับมือเหตุการณ์

ทำความรู้จัก EIP-7702 แบบสั้น ๆ

EIP-7702 ช่วยให้บัญชี Ethereum ทั่วไป (externally owned account หรือ EOA) มอบการทำงานของตนให้กับสมาร์ตคอนแทรกต์ได้ เจ้าของบัญชีลงนามการอนุญาตที่ระบุแอดเดรสของสัญญา เชน และ nonce ปัจจุบันของบัญชี เมื่อธุรกรรมที่มีการอนุญาตนั้นถูกประมวลผลแล้ว การเรียกใช้บัญชีจะรันโค้ดของสัญญา เหมือนกับว่าบัญชีนั้นเป็น smart contract wallet ฟีเจอร์นี้มีขึ้นด้วยเหตุผลที่ชอบธรรม เช่น การรวมธุรกรรมเป็นชุด และการจ่ายค่าธรรมเนียมแทนผู้ใช้

รายละเอียดสามข้อจากข้อกำหนดที่เกี่ยวข้องกับเหตุการณ์นี้:

  • การอนุญาตถูกส่งผ่านธุรกรรมประเภทใหม่ คือ type 4 (0x04) ซึ่งบรรจุการอนุญาตได้หลายรายการ ใครก็ส่งธุรกรรมนี้ได้ ขอเพียงการอนุญาตมีลายเซ็นที่ถูกต้องจากบัญชี
  • การอนุญาตแต่ละรายการจะมีผลก็ต่อเมื่อ nonce ตรงกับ nonce ปัจจุบันของบัญชีเท่านั้น หากไม่ตรง รายการนั้นจะถูกข้ามไป และธุรกรรมจะดำเนินต่อกับรายการถัดไป
  • การมอบสิทธิ์นั้นคงอยู่ถาวร จนกว่าบัญชีจะลงนามการอนุญาตใหม่ที่ชี้ไปที่อื่น หรือชี้ไปที่ zero address ซึ่งจะล้างการมอบสิทธิ์

กระเป๋า Binance 14 ถูกยึดได้อย่างไร

hot wallet ของกระดานเทรดที่มีธุรกรรมคับคั่งจะส่งธุรกรรมอยู่ตลอดเวลา nonce จึงเปลี่ยนไปเรื่อย ๆ ผู้โจมตีที่เตรียมการอนุญาตที่ลงนามไว้ล่วงหน้าไม่อาจรู้ได้ว่า nonce ใดจะเป็นค่าปัจจุบันเมื่อธุรกรรมถูกบันทึก ตามการวิเคราะห์ของ Blockaid ผู้โจมตีแก้ปัญหานี้ด้วยการลงนามครอบคลุมเป็นช่วง แทนที่จะลงนามเพียงค่าเดียว

เวลา (UTC, 29 ตุลาคม)เหตุการณ์
15:59ผู้โจมตีติดตั้งสัญญา “sweeper” ซึ่งไม่ได้รับการยืนยัน (unverified) และมีเพียงแอดเดรสผู้ปฏิบัติการของผู้โจมตีเท่านั้นที่เรียกใช้ได้
20:20:59ธุรกรรม type 4 เพียงรายการเดียวบรรจุการอนุญาต EIP-7702 จำนวน 50 รายการ ทั้งหมดลงนามด้วยคีย์ของ hot wallet Binance 14 สำหรับ nonce ต่อเนื่องกัน 50 ค่า มีเพียงรายการเดียวที่ตรงกับ nonce ปัจจุบันของกระเป๋า และกระเป๋าก็ถูกมอบสิทธิ์ให้กับ sweeper
20:24:23การเรียก sweeper เพียงครั้งเดียวโอนประมาณ 167,464 ETH, 1,615 ล้าน USDT และโทเค็นอื่นอีกหลายสิบรายการออกจากกระเป๋า โดยเหลือ 1 ETH ไว้เป็นค่าธรรมเนียม
20:41ขณะที่ยังถูกมอบสิทธิ์อยู่ กระเป๋าถูกใช้โอนประมาณ 823 ล้าน USDC ออกจาก smart account อีกบัญชีหนึ่งที่ Binance 14 ควบคุม
21:04 ถึง 23:56กระเป๋าถูกกวาดอีกสี่ครั้งเมื่อมีเงินใหม่เข้ามา เฉพาะเวลา 21:44 ครั้งเดียว เงินฝากใหม่มากกว่า 200 ล้านดอลลาร์ถูกนำไปโดยไม่มีลายเซ็นใหม่
00:10 (30 ตุลาคม)การมอบสิทธิ์ถูกเพิกถอน ตามลำดับเหตุการณ์ของ Hypernative

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

ทำไมกระเป๋าที่ว่างแล้วยังอันตราย

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

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

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

สิ่งที่ยังไม่มีคำตอบ

การอนุญาตทั้ง 50 รายการมีลายเซ็นที่ถูกต้องจากคีย์ของ Binance 14 มีคำอธิบายกว้าง ๆ อยู่สองแบบ และหลักฐานที่เปิดเผยต่อสาธารณะยังไม่อาจชี้ขาดได้:

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

Binance กล่าวว่ายังไม่พบหลักฐานการรั่วไหลของ private key ของกระเป๋า และการสอบสวนยังดำเนินอยู่ CEO ของ Blockaid ให้สัมภาษณ์กับ Cointelegraph ว่ากิจกรรมนี้ดูเหมือนการเจาะโครงสร้างพื้นฐานด้านการลงนามมากกว่าคีย์ที่รั่วไหล แต่นั่นเป็นเพียงการประเมินเบื้องต้นจากภายนอก จนกว่า Binance จะเผยแพร่รายงานสรุปเหตุการณ์ (post-mortem) เราถือว่าคำถามนี้ยังเปิดอยู่

สิ่งที่ควรทำหากคุณดูแล hot wallet

1. เฝ้าติดตามสถานะการมอบสิทธิ์

บัญชีที่ถูกมอบสิทธิ์จะมีโค้ด ภายใต้ EIP-7702 โค้ดของบัญชีคือตัวบ่งชี้การมอบสิทธิ์ 0xef0100 ตามด้วยแอดเดรสขนาด 20 ไบต์ของสัญญาที่ได้รับมอบสิทธิ์ ส่วน EOA ทั่วไปไม่มีโค้ดเลย คุณตรวจสอบแอดเดรสใดก็ได้ด้วยการเรียก JSON-RPC มาตรฐาน:

curl -s -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYOUR_HOT_WALLET","latest"]}' \
  https://YOUR_RPC_ENDPOINT

ผลลัพธ์ 0x หมายถึงไม่มีการมอบสิทธิ์ ผลลัพธ์ที่ขึ้นต้นด้วย 0xef0100 หมายถึงแอดเดรสนั้นถูกมอบสิทธิ์ ตรวจสอบเรื่องนี้กับ hot wallet ทุกตัวในทุกบล็อกหรือเป็นช่วงสั้น ๆ และแจ้งเตือนทันทีเมื่อมีการเปลี่ยนแปลงที่ไม่ได้วางแผนไว้

2. เฝ้าดูธุรกรรม type 4 ที่เกี่ยวข้องกับแอดเดรสของคุณ

ธุรกรรมที่มอบสิทธิ์กระเป๋าของคุณไม่จำเป็นต้องส่งมาจากกระเป๋าของคุณ ใครก็ส่งได้ ขอเพียงมีการอนุญาตที่ถูกต้องซึ่งลงนามด้วยคีย์ของคุณ ให้เฝ้าดูธุรกรรม type 4 ที่รายการการอนุญาตมีลายเซ็นจากแอดเดรสใดแอดเดรสหนึ่งของคุณ ไม่ใช่เพียงธุรกรรมที่ส่งออกจากแอดเดรสเหล่านั้นเท่านั้น

3. จัดทำบัญชีรายการการมอบสิทธิ์

สำหรับแต่ละแอดเดรสที่คุณดูแล ให้บันทึกว่าควรถูกมอบสิทธิ์หรือไม่ และหากควร ให้มอบสิทธิ์แก่สัญญาที่ผ่านการตรวจสอบ (audit) ตัวใด การมอบสิทธิ์ใด ๆ ที่อยู่นอกรายการนี้ถือเป็นเหตุการณ์ด้านความปลอดภัย หากคุณไม่ได้ใช้ EIP-7702 สถานะที่คาดหวังของ hot wallet ทุกตัวก็ง่ายมาก คือ ไม่มีโค้ด

4. ปฏิเสธการอนุญาตที่ไม่คาดคิดตั้งแต่ที่ตัวลงนาม

การอนุญาตแบบ EIP-7702 มีรูปแบบการลงนามเฉพาะ คือแฮชของไบต์ 0x05 ตามด้วย chain ID แอดเดรสของสัญญา และ nonce ที่เข้ารหัสแล้ว บริการลงนามและนโยบายของ HSM สามารถตรวจจับรูปแบบนี้ได้ หากคุณไม่ได้ใช้การมอบสิทธิ์ ให้บล็อกข้อมูลเหล่านี้ทั้งหมด หากใช้ ให้อนุญาตเฉพาะแอดเดรสสัญญาที่รู้จักเท่านั้น และพึงทราบว่าการอนุญาตที่มี chain ID เป็น 0 จะมีผลบนทุกเชน

5. ใส่ขั้นตอนการเพิกถอนอย่างชัดแจ้งไว้ในคู่มือรับมือเหตุการณ์

เขียนวิธีเพิกถอนการมอบสิทธิ์สำหรับแต่ละกระเป๋าไว้ให้ชัดเจน: ใครเป็นผู้ลงนามการอนุญาตไปยัง zero address จากระบบใด และจะยืนยันอย่างไรว่ามีผลแล้ว (โค้ดของแอดเดรสกลับเป็น 0x) รวมถึงการหยุดการโอนเงินเข้าแอดเดรสที่ได้รับผลกระทบ และฝึกซ้อมขั้นตอนนี้ก่อนที่จะต้องใช้จริง

เคล็ดลับ: แนวคิดเดียวกันนี้ใช้ได้นอกโลกคริปโตด้วย สิทธิ์ใดก็ตามที่มีอายุยืนกว่าข้อมูลประจำตัวที่สร้างมันขึ้นมา เช่น OAuth refresh token, cloud role ที่ได้รับมอบสิทธิ์ หรือโทเค็น CI/CD ที่มีอายุยาว ต้องมีขั้นตอนการเพิกถอนของตัวเองอย่างชัดแจ้งในการรับมือเหตุการณ์

LOGIQ ช่วยคุณได้อย่างไร

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

แหล่งข้อมูล