การทบทวนเหตุการณ์
เมื่อวันที่ 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 )
