การโจรกรรมโดยแฮ็กเกอร์ที่ใหญ่ที่สุดในประวัติศาสตร์ Web3 เกิดจากความผิดพลาดของการพัฒนา front-end หรือไม่?

การทบทวนเหตุการณ์

เมื่อวันที่ 21 กุมภาพันธ์ 2025 เวลา 14:16:11 น. UTC กระเป๋าเงินเย็น Ethereum ของ Bybit (0x1db92e2eebc8e0c075a02bea49a2935bcd2dfcf4) ถูกโจมตี และมีการถ่ายโอน ETH ประมาณ 401,346, 15,000 cmETH, 8,000 mETH, 90,375 stETH และ 90 USDT ไปยังที่อยู่ที่ไม่รู้จัก โดยมีมูลค่ารวมประมาณ 1.46 พันล้านดอลลาร์สหรัฐ

ผู้โจมตีหลอกผู้ลงนามในกระเป๋าสตางค์หลายลายเซ็นของ Bybit ให้ลงนามในธุรกรรมที่เป็นอันตรายผ่านการโจมตีแบบฟิชชิ่ง ขั้นตอนที่เฉพาะเจาะจงมีดังต่อไปนี้:

• ผู้โจมตีได้ใช้สัญญาที่เป็นอันตรายไว้ล่วงหน้า ซึ่งมีฟังก์ชันแบ็คดอร์สำหรับการโอนเงิน

• แก้ไขอินเทอร์เฟซส่วนหน้าของ Safe เพื่อให้ข้อมูลธุรกรรมที่ผู้ลงนามเห็นบน Safe ไม่สอดคล้องกับข้อมูลที่ส่งไปยังกระเป๋าเงินฮาร์ดแวร์ Ledger จริง

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

Bybit ได้มอบหมายให้ Sygnia ดำเนินการสืบสวนนิติเวชเพื่อระบุสาเหตุของการโจมตี โดยมีเป้าหมายเพื่อระบุขอบเขตและแหล่งที่มาของการโจมตี และบรรเทาความเสี่ยงในปัจจุบันและอนาคต สำหรับรายงานล่าสุด โปรดดู: รายงานการสอบสวนชั่วคราวของ Bybit (https://docsend.com/view/rmdi832mpt8u93s7/d/rwecw3rumhqtgs6a)

จนถึงปัจจุบัน การสอบสวนนิติเวชได้เน้นถึงการค้นพบต่อไปนี้:

• การตรวจสอบนิติเวชของโฮสต์ทั้งหมดที่ใช้ในการเริ่มต้นและลงนามธุรกรรมเผยให้เห็นว่าทรัพยากรในบัคเก็ต AWS S3 ของ Safe ถูกฉีดด้วยโค้ด JavaScript ที่เป็นอันตราย

• เวลาในการปรับเปลี่ยนทรัพยากรและไฟล์เก็บถาวรประวัติเครือข่ายที่สามารถเข้าถึงได้สาธารณะบ่งชี้ว่าการแทรกโค้ดที่เป็นอันตรายดำเนินการโดยตรงในบัคเก็ต AWS S3 ของ Safe

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

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

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

• ผลการค้นพบเบื้องต้นบ่งชี้ว่าการโจมตีมีต้นทางจากโครงสร้างพื้นฐาน AWS ของ Safe

• จนถึงขณะนี้ การสืบสวนทางนิติเวชยังไม่พบสัญญาณใดๆ ของการประนีประนอมโครงสร้างพื้นฐานของ Bybit

การสืบสวนนิติเวชของโฮสต์ผู้ลงนามทั้งสามรายเผยให้เห็นว่าสาเหตุของการโจมตีคือโค้ดที่เป็นอันตรายซึ่งมีต้นทางจากโครงสร้างพื้นฐานที่ปลอดภัย

ไม่พบสัญญาณการประนีประนอมใดๆ ในโครงสร้างพื้นฐานของ Bybit

การสืบสวนยังคงดำเนินต่อไปเพื่อยืนยันการค้นพบเหล่านี้ต่อไป

จากข้อมูลปัจจุบัน ดูเหมือนว่าปัญหาหลักของการโจมตีครั้งนี้จะไม่ใช่ปัญหาที่ส่วนหน้าอีกต่อไป สาเหตุหลักของการโจมตีครั้งนี้ก็คือบริการจัดเก็บข้อมูลบน AWS ถูกแฮ็ก และ JavaScript ถูกแทรกแซง ซึ่งส่งผลให้เนื้อหาธุรกรรมที่เริ่มต้นบนส่วนหน้าของ Safe ถูกแก้ไข แต่หาก Front-end ของ Safe ได้ทำการตรวจสอบ SRI ขั้นพื้นฐานแล้ว จะไม่มีอะไรผิดพลาดแม้ว่าจะเปลี่ยน JavaScript ไปแล้ว ดังนั้น Front-end จะต้องมีความรับผิดชอบในระดับหนึ่ง แน่นอนว่า Bybit ก็ต้องรับผิดชอบด้วยเช่นกัน ก่อนอื่นเลย พวกเขาได้ยืนยันว่ากระเป๋าเงินฮาร์ดแวร์ที่พวกเขาใช้ไม่ได้แสดงข้อมูลธุรกรรมที่เฉพาะเจาะจง ความไว้วางใจของพวกเขาที่มีต่อระบบ Safe front-end นั้นไม่น่าเชื่อถือเลย

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

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

ด้วยการพัฒนาอย่างรวดเร็วของเทคโนโลยี Web3 ขอบเขตระหว่างความปลอดภัยแบบ front-end และความปลอดภัยของบล็อคเชนก็เริ่มเลือนลางลงเรื่อยๆ จุดอ่อนแบบ front-end ดั้งเดิม (เช่น XSS, CSRF) ได้รับการโจมตีในมิติใหม่ในสถานการณ์ Web3 ในขณะที่ปัญหาต่างๆ เช่น จุดอ่อนของสัญญาอัจฉริยะและข้อบกพร่องในการจัดการคีย์ส่วนตัวทำให้ความเสี่ยงทวีความรุนแรงมากขึ้น

ถัดไปเราจะวิเคราะห์ความสัมพันธ์ระหว่างการพัฒนาส่วนหน้าและปัญหาด้านความปลอดภัยจากสองสถานการณ์

สถานการณ์ที่ 1: การแก้ไขพารามิเตอร์ธุรกรรม - อินเทอร์เฟซแสดงการโอน แต่การอนุญาตถูกดำเนินการจริง

ตัวอย่าง: การแยกการแสดงแบบฟรอนท์เอนด์และการดำเนินการแบบออนเชน

มุมมองของผู้ใช้:

✅ หน้าต่างป๊อปอัปของกระเป๋าเงินจะแสดง "โอน 1 ETH ไปยังผู้ใช้ 0x..."

ผลกระทบที่เกิดขึ้นจริงบนเชน:

⚠️ ดำเนินการ "อนุมัติ (ผู้โจมตี ไม่จำกัด)" เพื่อโอนทรัพย์สินได้ตลอดเวลา

ฉันควรทำอย่างไร? การตรวจสอบลายเซ็นโครงสร้าง EIP-712

1. ส่วนหน้าสร้างข้อมูลที่สามารถตรวจสอบได้

2. ลายเซ็นยืนยันสัญญาอัจฉริยะ

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

สถานการณ์ที่ 2: การแฮ็กลายเซ็นแบบ Blind Signature - เหตุใดกระเป๋าสตางค์ฮาร์ดแวร์จึงถูกแฮ็ก

ตัวอย่าง: การแก้ไขกฎการแยกวิเคราะห์ Ledger

1. ผู้โจมตีเข้ายึดโค้ดด้านหน้าและส่งข้อมูลการโทรปลอมไปยังกระเป๋าสตางค์ฮาร์ดแวร์:

2. หน้าจอแสดงผลบัญชีแยกประเภท:

การดำเนินการจริง: "อนุมัติ(ผู้โจมตี, ไม่จำกัด)"

ฉันควรทำอย่างไร? การวิเคราะห์ความหมายของกระเป๋าสตางค์ฮาร์ดแวร์ + การตรวจสอบรองแบบออนเชน

1. อัพเกรดเฟิร์มแวร์กระเป๋าสตางค์ฮาร์ดแวร์เพื่อรองรับ EIP-712

2. การจับคู่ความหมายแบบบังคับบนเครือข่าย

บทสรุป

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

แน่นอนว่าการตรวจสอบความปลอดภัยของสัญญาแบบออนเชนก็มีความจำเป็นสำหรับ Dapp ทุกตัวเช่นกัน ZAN AI Scan (https://zan.top/cn/home/ai-scan? chInfo=ch_WZ) สามารถรับรองความถูกต้องของโค้ดผ่านการตรวจสอบอย่างเป็นทางการและการสร้างข้อมูลจำเพาะด้านความปลอดภัยด้วยความช่วยเหลือของ AI ให้ความคล้ายคลึงของโค้ดและการวิเคราะห์ความเสี่ยงต่อทรัพย์สินทางปัญญาสำหรับสัญญาที่ปรับใช้หลายล้านฉบับ และให้การตรวจสอบตลอด 24 ชั่วโมงทุกวันและการแจ้งเตือนทันทีที่เกี่ยวข้องกับช่องโหว่แบบ zero-day และเหตุการณ์ด้านความปลอดภัยที่อาจส่งผลต่อโครงการที่ปรับใช้ของคุณ นอกจากนี้ยังมีโมเดล GPT ที่ได้รับการปรับให้เหมาะสมตามฐานข้อมูลความเสี่ยงขนาดใหญ่ เพื่อตรวจจับความเสี่ยงต่างๆ ในโลกแห่งความเป็นจริงในสัญญาอัจฉริยะ

บทความนี้เขียนโดย KenLee จาก ZAN Team (บัญชี X @zan_team )