简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

Partnered With:

SlowMist: ปัญหาความปลอดภัยเป็นปัญหาที่หนักหนาสาหัส การ์ดจะสามารถสร้างสัญญา Babel Tower ขึ้นมาใหม่ได้หรือไม่?

อ่านบทความนี้ใน 52 นาที

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

ชื่อต้นฉบับ: "การวิเคราะห์แบบ SlowMist | ปัญหาที่น่ากังวลใจ การ์ดสามารถสร้างสัญญา Babel ขึ้นมาใหม่ได้หรือไม่" 》

ผู้เขียนต้นฉบับ: flush & kong, SlowMist Technology

พื้นหลัง

เมื่อวันที่ 21 กุมภาพันธ์ 2025 อุตสาหกรรมสกุลเงินดิจิทัลต้องประสบกับวิกฤตการจัดการสินทรัพย์ที่เลวร้ายที่สุดในประวัติศาสตร์ กระเป๋าเงินลายเซ็นหลายรายการบนเครือข่ายของแพลตฟอร์มการซื้อขาย Bybit ตกเป็นเป้าหมาย และสินทรัพย์มูลค่าเกือบ 1.5 พันล้านดอลลาร์สหรัฐสูญหายไปอย่างเงียบ ๆ ผ่านธุรกรรมที่ "มีการลงนามตามกฎหมาย" การวิเคราะห์แบบออนเชนที่ตามมาแสดงให้เห็นว่าผู้โจมตีได้รับสิทธิ์การลงนามหลายลายเซ็นผ่านการโจมตีทางวิศวกรรมสังคมที่ซับซ้อน ฝังตรรกะที่เป็นอันตรายโดยใช้ฟังก์ชัน delegatecall ของสัญญา Safe และท้ายที่สุดก็หลีกเลี่ยงกลไกการตรวจสอบลายเซ็นหลายลายเซ็นเพื่อโอนเงินไปยังที่อยู่ที่ไม่ระบุชื่อ

เหตุการณ์นี้เปิดเผยความจริงอันโหดร้าย: "ลายเซ็นหลายลายเซ็น" ไม่ได้หมายถึง "ความปลอดภัยอย่างสมบูรณ์" แม้แต่กลไกความปลอดภัยเช่นกระเป๋าสตางค์ลายเซ็นหลายลายเซ็น Safe ก็ยังมีความเสี่ยงที่จะถูกแฮ็กได้หากไม่มีมาตรการป้องกันเพิ่มเติม นี่ไม่ใช่การโจมตีครั้งแรกต่อกระเป๋าเงินลายเซ็นหลายรายการของ Safe เมื่อปีที่แล้ว WazirX (230 ล้านดอลลาร์) และ Radiant Capital (50 ล้านดอลลาร์) ต่างก็ตกเป็นเหยื่อของการโจมตีที่คล้ายคลึงกัน ตามที่วิเคราะห์ในบทความ SlowMist: Hacker Methods and Questions Behind the Theft of Nearly $1.5 Billion from Bybit เหตุการณ์โจมตีกระเป๋าเงินลายเซ็นหลายรายการของ Safe แสดงให้เห็นถึงความคล้ายคลึงทางเทคนิคต่อไปนี้:

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

ขาดการป้องกันแบบไดนามิก:ขาดการสแกนความเสี่ยงแบบเรียลไทม์ก่อนดำเนินการธุรกรรม

การควบคุมการอนุญาตแบบละเอียดหยาบ: ไม่มีการจัดตั้งกลไกไวท์ลิสต์สำหรับการดำเนินการที่มีความเสี่ยงสูง เช่น การมอบหมายสาย

(กระบวนการขโมย Bybit: ใช้ Safe v1.1.1)

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

Safe

Safe คือกระเป๋าเงินหลายลายเซ็นที่ใช้เป็นหลักในการจัดการการจัดเก็บข้อมูลที่ปลอดภัยและการโอนสินทรัพย์ที่มีมูลค่าสูงและสกุลเงินดิจิทัล เนื่องจากเป็นโครงสร้างพื้นฐานสำหรับการจัดการสินทรัพย์แบบกระจายอำนาจ จึงรับประกันความปลอดภัยของการดำเนินการกองทุนผ่านกลไกการตรวจสอบแบบร่วมมือกันของหลายฝ่าย ซึ่งป้องกันไม่ให้ผู้ดูแลระบบหรือแฮกเกอร์เพียงคนเดียวใช้ประโยชน์จากจุดล้มเหลวเพียงจุดเดียวเพื่อดำเนินการที่เป็นอันตราย มีการใช้กันอย่างแพร่หลายในสถานการณ์ต่างๆ เช่น การกำกับดูแล DAO การดูแลกองทุนขององค์กร และกลุ่มกองทุนแบบกระจายอำนาจ สัญญาดังกล่าวได้รับการพัฒนาโดยทีมงาน Safe (เดิมคือ Gnosis Safe) และเป็นโซลูชันการจัดการสินทรัพย์แบบออนเชนมาตรฐานอุตสาหกรรมปัจจุบัน สัญญาดังกล่าวใช้มาตรฐาน EIP-712 ในการใช้ลายเซ็นข้อมูลที่มีโครงสร้าง ซึ่งจะช่วยเพิ่มความปลอดภัยและการตรวจสอบข้อมูลธุรกรรม

จุดประสงค์หลัก

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

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

การขยายแบบโมดูลาร์: สัญญาใช้การออกแบบแบบโมดูลาร์ โดยการสืบทอดและรวมโมดูลการจัดการหลายโมดูล (เช่น OwnerManager, ModuleManager, GuardManager, FallbackManager เป็นต้น) ทำให้ฟังก์ชันต่างๆ มีความยืดหยุ่นและขยายได้ง่าย โดยให้การสนับสนุนแบบกำหนดเองสำหรับสถานการณ์การใช้งานที่แตกต่างกัน

การวิเคราะห์ฟังก์ชัน

ฟังก์ชัน execTransaction จะดำเนินการธุรกรรมที่ตรวจยืนยันด้วยลายเซ็นหลายรายการ:

· คำนวณค่าแฮชที่ไม่ซ้ำกันของธุรกรรม (รวมกับพารามิเตอร์ธุรกรรม nonce ฯลฯ);

· ตรวจสอบความถูกต้องของลายเซ็นทั้งหมดเพื่อให้แน่ใจว่าลายเซ็นแต่ละรายการมาจากเจ้าของที่ถูกต้องตามกฎหมายหรือที่อยู่ที่ได้รับการอนุมัติล่วงหน้า;

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

· รองรับการประมวลผลค่าธรรมเนียมก๊าซที่ยืดหยุ่นเพื่อให้แน่ใจว่าการคำนวณต้นทุนธุรกรรมมีความแม่นยำเมื่อจ่ายค่าตอบแทน

ฟังก์ชัน checkContractSignatures และ checkNSignatures ตรวจสอบข้อมูลลายเซ็นของธุรกรรมหรือข้อความ:

· ประมวลผลลายเซ็นบัญชี EOA ลายเซ็นสัญญา (EIP-1271) และแฮชที่ได้รับการอนุมัติล่วงหน้าแยกจากกัน;

· ตรวจสอบให้แน่ใจว่าลายเซ็นได้รับการจัดเรียงตามลำดับของเจ้าของ และลายเซ็นแต่ละอันมาจากที่อยู่ที่ถูกต้องเพื่อป้องกันการโจมตีซ้ำและการแก้ไขลายเซ็น

ฟังก์ชัน getTransactionHash สร้างแฮชธุรกรรมสำหรับการตรวจสอบลายเซ็นและป้องกันการโจมตีแบบรีเพลย์:

· ใช้มาตรฐาน EIP-712 เพื่อดำเนินการแฮชแบบมีโครงสร้างบนข้อมูลธุรกรรม;

· ใช้การประกอบแบบอินไลน์เพื่อปรับการทำงานของหน่วยความจำให้เหมาะสมและปรับปรุงประสิทธิภาพการประมวลผล;

· ใช้ร่วมกับค่า nonce ปัจจุบัน เพื่อให้แน่ใจว่าธุรกรรมแต่ละรายการไม่ซ้ำกัน

ฟังก์ชั่น handlePayment จัดการการจ่ายเงินชดเชยแก๊สในระหว่างกระบวนการดำเนินธุรกรรม:

· คำนวณจำนวนเงินที่จ่ายโดยอิงจากค่าธรรมเนียมแก๊สที่ใช้จริงและค่าธรรมเนียมพื้นฐาน;

· รองรับการชำระเงิน ETH และโทเค็นอื่น ๆ เพื่อให้แน่ใจว่ามีการชดเชยค่าธรรมเนียมที่แม่นยำ

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

· ถึง:ที่อยู่ปลายทาง - ที่อยู่สัญญาหรือบัญชีที่จะถูกเรียกโดยธุรกรรม

· ค่า:ค่าอีเธอร์ - จำนวนอีเธอร์ที่ส่งพร้อมกับธุรกรรม

· ข้อมูล:เพย์โหลดข้อมูล - ข้อมูลการเรียกที่มีตัวเลือกฟังก์ชันและพารามิเตอร์

· การดำเนินการ:ประเภทการดำเนินการ - กำหนดว่าเป็น CALL หรือ DELEGATECALL

· safeTxGas:ขีดจำกัดแก๊สธุรกรรม - จำนวนแก๊สที่สำรองไว้สำหรับการดำเนินการธุรกรรม

· baseGas:แก๊สฐาน - ต้นทุนแก๊สที่ไม่ขึ้นอยู่กับการดำเนินการธุรกรรม

· gasPrice:ราคาแก๊ส - ราคาแก๊สที่ใช้ในการคำนวณค่าชดเชยค่าธรรมเนียมธุรกรรม

· gasToken：gas token - ที่อยู่โทเค็นที่ใช้ชำระค่าธรรมเนียมธุรกรรม

· refundReceiver：Refund recipient - ที่อยู่สำหรับรับค่าชดเชยค่าธรรมเนียมธุรกรรม

· signatures：Signature collection - ข้อมูลลายเซ็นของเจ้าของในธุรกรรม

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

Safe Guard

สัญญา Safe ได้แนะนำคุณลักษณะด้านความปลอดภัยที่สำคัญในเวอร์ชัน 1.3.0 - กลไก Safe Guard กลไกนี้ได้รับการออกแบบเพื่อเพิ่มข้อจำกัดให้กับรูปแบบลายเซ็นหลายลายเซ็นแบบ n-out-of-m มาตรฐาน ซึ่งจะช่วยเพิ่มความปลอดภัยของธุรกรรมอีกด้วย คุณค่าหลักของ Safe Guard อยู่ที่ความสามารถในการตรวจสอบความปลอดภัยในขั้นตอนต่างๆ ของการดำเนินการธุรกรรม:

· การตรวจสอบก่อนธุรกรรม (checkTransaction):กลไกของ Guard สามารถดำเนินการตรวจสอบทางโปรแกรมสำหรับพารามิเตอร์ธุรกรรมทั้งหมดก่อนที่จะดำเนินการธุรกรรมเพื่อให้แน่ใจว่าธุรกรรมเป็นไปตามกฎความปลอดภัยที่ตั้งไว้ล่วงหน้า

· การตรวจสอบหลังธุรกรรม (checkAfterExecution):หลังจากที่ดำเนินการธุรกรรมแล้ว Guard จะดำเนินการตรวจสอบความปลอดภัยเพิ่มเติมเพื่อตรวจสอบว่าสถานะสุดท้ายของกระเป๋าสตางค์ Safe หลังจากดำเนินการธุรกรรมแล้วเป็นไปตามที่คาดหวังหรือไม่

การวิเคราะห์สถาปัตยกรรม

ใน Safe ธุรกรรมลายเซ็นหลายรายการโดยทั่วไปจะดำเนินการผ่านฟังก์ชัน execTransaction เมื่อเปิดใช้งาน Safe Guard เมื่อผู้ใช้ดำเนินการธุรกรรมที่มีลายเซ็นหลายรายการ สัญญา Safe จะเรียกใช้ฟังก์ชัน checkTransaction ของสัญญา Guard เพื่อดำเนินการตรวจสอบก่อนทำธุรกรรม หลังจากธุรกรรมที่มีลายเซ็นหลายรายการเสร็จสมบูรณ์ สัญญา Safe จะเรียกใช้ฟังก์ชัน checkAfterExecution ของสัญญา Guard เพื่อตรวจสอบผลลัพธ์การดำเนินการของธุรกรรม การใช้งานที่เฉพาะเจาะจงมีดังนี้:

เมื่อสัญญา Safe ดำเนินการตรวจสอบล่วงหน้าสำหรับธุรกรรมลายเซ็นหลายรายการผ่านกลไก Guard ฟังก์ชัน checkTransaction จะได้รับข้อมูลบริบทธุรกรรมที่สมบูรณ์ รวมถึงที่อยู่สัญญาเป้าหมาย วิธีการเรียก ข้อมูลการดำเนินการ (เช่น delegatecall) ข้อมูลลายเซ็นของเจ้าของ การกำหนดค่า Gas และข้อมูลการชำระเงิน กลไกนี้ช่วยให้นักพัฒนาสามารถนำกลยุทธ์การควบคุมความเสี่ยงแบบหลายมิติไปใช้ได้ เช่น การควบคุมรายการที่อนุญาตของสัญญา (จำกัดที่อยู่แบบโต้ตอบ) การจัดการการอนุญาตในระดับฟังก์ชัน (การปิดใช้งานตัวเลือกฟังก์ชันที่มีความเสี่ยงสูง) การจำกัดความถี่ในการทำธุรกรรม และกฎแบบไดนามิกที่อิงตามกระแสเงินทุน การกำหนดค่ากลยุทธ์ Guard อย่างเหมาะสมจะทำให้สามารถบล็อกผู้โจมตีจากการใช้เลเยอร์ที่ไม่ใช่สัญญาในการโจมตีได้อย่างมีประสิทธิภาพ

จากเหตุการณ์ด้านความปลอดภัยที่เกิดขึ้นล่าสุด ฝ่ายต่างๆ ต่างให้ความสนใจกับความปลอดภัยของสัญญากระเป๋าสตางค์หลายลายเซ็นมากขึ้น ผู้ให้บริการกระเป๋าสตางค์ฮาร์ดแวร์ เช่น KeyStone, OneKey, RigSec ฯลฯ เรียกร้องให้ปรับปรุงความสามารถในการแยกวิเคราะห์และการปกป้องของสัญญา Safe เพื่อป้องกันไม่ให้ความเสี่ยงที่คล้ายกันเกิดขึ้นอีก หลังจากเหตุการณ์ Bybit ฝ่ายโครงการจำนวนมากเริ่มมุ่งเน้นไปที่สัญญา Safe และสำรวจโซลูชันการอัพเกรดและการขยายตามกลไก Guard

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

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

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

ในห่วงโซ่การโจมตีเหตุการณ์ Bybit ถ้าสัญญา Safe ใช้กลไก Guard ที่กำหนดค่าอย่างถูกต้อง การเรียกตัวแทนที่เป็นอันตรายซึ่งเริ่มต้นโดยผู้โจมตีผ่าน execTransaction จะถูกสกัดกั้นโดยกลยุทธ์ต่างๆ มากมายในขั้นตอนก่อนการตรวจสอบ: ฟังก์ชัน checkTransaction ของ Guard จะระบุประเภทการดำเนินการเรียกตัวแทนก่อน จากนั้นจึงกระตุ้นกฎการปิดการใช้งาน (เช่น จำกัดการทำงานให้เฉพาะการเรียกปกติเท่านั้น) จากนั้นจึงวิเคราะห์ฟิลด์ข้อมูลเพื่อตรวจหาที่อยู่สัญญาที่ไม่ธรรมดา (0x4622...7242) และตัวเลือกฟังก์ชันที่มีความเสี่ยงสูง จากนั้นจึงย้อนธุรกรรมกลับโดยตรงผ่านกลยุทธ์รายการขาวของสัญญาที่ตั้งไว้ล่วงหน้าและรายการดำของฟังก์ชัน สุดท้ายจึงสร้างระบบป้องกันแบบ "การสกัดกั้นกลยุทธ์ → การบล็อกตรรกะ" ซึ่งจะบล็อกการแทรกแซงที่เก็บข้อมูลและเส้นทางการโอนเงินทุนอย่างสมบูรณ์

(เมื่อใช้ Safe เวอร์ชัน ≥ v1.3.0 การดำเนินการตรวจสอบโมดูล Safe Guard https://excalidraw.com/#room=fd1df67dd09b3dab6bd8,Q1jeb1MZW7vwbY4NuxaV5A)

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

บทสรุปและแนวโน้ม

การโจมตี Bybit เน้นย้ำถึงความสำคัญของการอัปเดตโครงสร้างพื้นฐานด้านความปลอดภัยอย่างทันท่วงที Bybit ใช้สัญญา Safe เวอร์ชัน v1.1.1 (<1.3.0) ซึ่งหมายความว่าพวกเขาไม่สามารถใช้กลไก Guard ซึ่งเป็นคุณลักษณะด้านความปลอดภัยที่สำคัญได้ หาก Bybit อัปเกรดเป็นเวอร์ชั่น 1.3.0 หรือสูงกว่าของสัญญา Safe และใช้กลไก Guard ที่เหมาะสม เช่น การระบุที่อยู่ไวท์ลิสต์ที่เป็นที่อยู่เดียวที่รับเงิน และดำเนินการตรวจสอบ ACL ของฟังก์ชันสัญญาที่เข้มงวด การสูญเสียนี้อาจหลีกเลี่ยงได้ แม้ว่านี่จะเป็นเพียงสมมติฐาน แต่ก็ให้แนวคิดที่สำคัญสำหรับการจัดการความปลอดภัยสินทรัพย์ในอนาคต

กลไก Safe Guard เปรียบเสมือนระบบรักษาความปลอดภัยอัจฉริยะที่เพิ่มเข้าไปในตู้นิรภัยสินทรัพย์ดิจิทัล ประสิทธิภาพของกลไกนี้ขึ้นอยู่กับความเข้มงวดของการออกแบบกฎเกณฑ์และคุณภาพของการนำไปใช้งาน เมื่อเผชิญกับวิธีการโจมตีที่ซับซ้อนมากขึ้นเรื่อยๆ เราต้องการ: · การตรวจสอบอัตโนมัติ: สร้างกลไกการตรวจสอบธุรกรรมอัตโนมัติ · การปรับนโยบายแบบไดนามิก: การปรับนโยบายความปลอดภัยแบบเรียลไทม์ตามข้อมูลภัยคุกคาม · การป้องกันแบบหลายชั้น: รวมกลไกความปลอดภัยหลายชั้นเพื่อสร้างระบบป้องกันเชิงลึก · การตรวจสอบอย่างต่อเนื่อง: ดำเนินการตรวจสอบความปลอดภัยเป็นประจำในการใช้งาน Guard อนาคตของการจัดการสินทรัพย์ดิจิทัลจะเป็นกระบวนการวิวัฒนาการร่วมกันของกลไกความปลอดภัยของสัญญาอัจฉริยะและวิวัฒนาการของการโจมตีและการป้องกันอย่างต่อเนื่อง เราจะสร้างกำแพงความปลอดภัยที่แท้จริงในเกมระหว่าง "หอก" ของแฮ็กเกอร์และ "โล่" ของผู้พิทักษ์ได้โดยการบูรณาการแนวคิดด้านความปลอดภัยเข้ากับทุกลิงก์เท่านั้น