ความเสี่ยงด้านความปลอดภัยของ THORChain (RUNE)

ตามรายงานการคลังของ THORChain สำหรับไตรมาสที่ 1 ปี 2022 ที่เผยแพร่เมื่อวันที่ 1 เมษายน พบว่าบริษัทมีรายได้เพิ่มขึ้น แม้ว่าจะมีผลกระทบถึง 2.17 เท่าจากความซบเซาของตลาดอย่างต่อเนื่องและปัจจัยทางภูมิรัฐศาสตร์ที่ไม่แน่นอนสูง ข้อมูลสาธารณะแสดงให้เห็นว่า THORChain ทำรายได้ 1 พันล้านดอลลาร์ในไตรมาส 2022 ปี XNUMX THORChain ซึ่งได้รับการยกย่องว่าเป็น “เวอร์ชันข้ามสายโซ่ของ UniSwap” ได้ตั้งหลักในตลาดการซื้อขายข้ามเครือข่ายโดยอาศัยข้อได้เปรียบที่เป็นเอกลักษณ์และได้รับการยอมรับอย่างกว้างขวางในหมู่นักลงทุน

เบื้องหลังความเย้ายวนใจเหล่านี้ THORChain ยังประสบปัญหาอย่างมากจากการแฮ็ก ห่วงโซ่ได้รับการละเมิดความปลอดภัยบ่อยครั้งตั้งแต่เปิดตัวบน Ethereum ซึ่งเป็นข้อเท็จจริงที่สร้างความสงสัยเกี่ยวกับความปลอดภัย เมื่อวันที่ 11 เมษายน THORChain ทวีตเกี่ยวกับการโจมตีแบบฟิชชิ่ง เตือนผู้ใช้ว่าอย่าโต้ตอบกับ [DeTHOR] หรือโทเค็นที่ไม่รู้จักอื่น ๆ ภายในกระเป๋าของพวกเขา ซึ่งทำให้เกิดความกังวลอีกครั้งเกี่ยวกับปัญหาด้านความปลอดภัย

ในขณะที่สร้างระบบความปลอดภัยเสียงสำหรับผลิตภัณฑ์ CoinEx ทีมรักษาความปลอดภัยของ CoinEx ยังติดตามเหตุการณ์ด้านความปลอดภัยในพื้นที่บล็อกเชนเพื่อช่วยให้ผู้ใช้เข้าใจความปลอดภัยของโครงการต่างๆ ได้ดีขึ้นจากมุมมองของความปลอดภัยทางเทคนิคและลดความเสี่ยงในการลงทุน ทีมรักษาความปลอดภัยของ CoinEx ได้วิเคราะห์ความเสี่ยงด้านความปลอดภัยของ THORChain (RUNE) เพื่อปรับปรุงเกณฑ์ความปลอดภัยสำหรับภาคบล็อคเชน ทีมงานหวังว่า THORChain สามารถบันทึกและลดความเสี่ยงต่อไปนี้ด้วยการปรับรหัสสัญญาอัจฉริยะที่เกี่ยวข้องให้เหมาะสม นอกจากนี้ บทความนี้ยังเป็นคำเตือนสำหรับผู้ใช้ เพื่อเตือนพวกเขาให้ตระหนักถึงความปลอดภัยของทรัพย์สินและหลีกเลี่ยงการสูญเสียทรัพย์สิน

THORChain (RUNE) ปลอดภัยแค่ไหน?

จากการวิเคราะห์รหัสสัญญาและตรรกะของ THORChain (RUNE) ทีมรักษาความปลอดภัยของ CoinEx ได้พบความเสี่ยงดังต่อไปนี้:

เริ่มต้นด้วยการตรวจสอบรหัสสัญญาของ THORChain (RUNE):

https://etherscan.io/address/0x3155ba85d5f96b2d030a4966af206230e46849cb#code

เราสามารถบอกได้ว่า RUNE เป็นโทเค็น ERC-20 ที่ค่อนข้างมาตรฐาน ควรสังเกตว่านอกเหนือจากอินเทอร์เฟซ ERC-20 แล้ว THORChain (RUNE) ยังมีอินเทอร์เฟซเพิ่มเติม:

ตาม transferTo (ดังแสดงในภาพด้านบน) THORChain (RUNE) ใช้ tx.origin ซึ่งเป็นหนึ่งในสาเหตุที่อยู่เบื้องหลังความเสี่ยงด้านความปลอดภัย ในที่นี้ เราควรอธิบายความแตกต่างระหว่าง tx.origin และ msg.sender:

ภาพด้านล่างอธิบายว่าเกิดอะไรขึ้นเมื่อที่อยู่ปกติเรียกสัญญาอัจฉริยะ:

ในกรณีเช่นนี้ msg.sender = account.address และ tx.origin = account.address ซึ่งหมายความว่า msg.sender จะเหมือนกับ tx.origin

ต่อไปนี้คือสิ่งที่เกิดขึ้นเมื่อบัญชีเรียกสัญญา A และสัญญา A โทรสัญญา B:

เมื่อสัญญา A เรียกสัญญา B (ดังที่แสดงด้านบน) เราสามารถบอกได้ว่า msg.sender เท่ากับ tx.origin ในสัญญา A

อย่างไรก็ตาม ในสัญญา B msg.sender = contractA.address ในขณะที่ tx.origin = account.address ดังนั้น tx.origin จึงเป็นเหมือนกับตัวแปรส่วนกลางที่ข้ามผ่าน call stack ทั้งหมดและส่งคืนที่อยู่ของบัญชีที่ส่งธุรกรรมในตอนแรก นี่คือประเด็นสำคัญ: จนถึงปัจจุบัน การโจมตี THORChain (RUNE) ที่รู้จักเกือบทั้งหมดเกี่ยวข้องกับ tx.origin

มาดูกันว่าผู้โจมตีขโมยโทเค็น RUNE ของผู้ใช้ผ่าน tx.origin ได้อย่างไร:

โจมตีหมายเลข 1: ขโมยแพะจากฝูง

ที่อยู่ใน Ethereum แบ่งออกเป็นที่อยู่ภายนอกและที่อยู่ตามสัญญา การโอน ETH ไปยังที่อยู่สองประเภทนี้ผ่านที่อยู่ภายนอกนั้นแตกต่างกันโดยพื้นฐาน ดิ เอกสารอย่างเป็นทางการ ของสถานะที่แน่นแฟ้นว่าที่อยู่ของสัญญาต้องใช้ฟังก์ชันรับ Ether ก่อนทำการโอน

ในแง่ของคุณสมบัติของ tx.origin แฮกเกอร์อาจสร้างสัญญาการโจมตี:

เมื่อสัญญา Attack ได้รับการโอน ETH จากผู้ใช้ มันจะ “ขโมยแพะจากฝูง” — สัญญาจะขโมยโทเค็น RUNE ของผู้ใช้ในกระบวนการ

การโจมตีครั้งที่ 2: การโจมตีภายใน

การโจมตีภายในเป็นการโจมตีประเภทพิเศษ เมื่อพยายามขโมย RUNE ของผู้ใช้ผ่าน Internal Attack แฮ็กเกอร์จะต้องมีโทเค็นขนาดกลาง นอกจากนี้ โทเค็นยังต้องเรียกสัญญาบุคคลที่สาม ตามบันทึกการโอนของ RUNE บน Ethereum ผู้โจมตีบางรายแฮ็ค RUNE ผ่านการโอน AMP Token

AMP Token ใช้มาตรฐาน ERC-1820 เพื่อจัดการการลงทะเบียน Hook และตรวจสอบว่า Hook ลงทะเบียนในการโอนแต่ละครั้งหรือไม่ หาก Hook ได้รับการลงทะเบียนแล้ว Hook จะถูกเรียก

รหัสสัญญาของ AMP Token แสดงว่าการดำเนินการโอนครั้งสุดท้ายคือ: _transferByPartition ในขณะเดียวกัน มี XNUMX สายที่เกี่ยวข้องกับ transferHook: _callPreTransferHooks (ก่อนการโอน) และ _callPostTransferHooks (หลังการโอน) โดยเฉพาะอย่างยิ่ง _callPreTransferHooks ใช้สำหรับที่อยู่ต้นทาง ในขณะที่ _callPostTransferHooks ใช้สำหรับที่อยู่ที่ถึง (เช่น ที่อยู่สำหรับรับ)

สำหรับผู้ใช้ทั่วไป การขโมยโทเค็นจากตัวเองนั้นไร้ประโยชน์ ดังนั้น ผู้โจมตีอาจใช้ประโยชน์จาก _callPostTransferHooks มาดูโค้ดของ _callPostTransferHooks กัน

IampTokensRecipient(ผู้รับการดำเนินการ).โทเค็นที่ได้รับ()

เราสามารถบอกได้ว่าการติดต่อกลับเพียงอย่างเดียวที่ผู้โจมตีสามารถใช้ประโยชน์ได้คือ IAmpTokensRecipient(recipientImplementation).tokensReceived()

ต่อไป เราจะอธิบายวิธีการใช้การโทรนี้เพื่อโอน RUNE ของผู้ใช้ในขณะที่ทำการโอน AMP Token

ขั้นตอนที่ 1: จำเป็นต้องมีสัญญาการโทร (ตามที่แสดงด้านล่าง):

ขั้นตอนที่ 2: ปรับใช้สัญญาเพื่อรับที่อยู่การโจมตี

ขั้นตอนที่ 3: เรียกอินเทอร์เฟซสัญญา ERC-1820 (setInterfaceImplementer) เพื่อลงทะเบียนอินเทอร์เฟซ

ERC-1820 ที่อยู่: 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24

อินเทอร์เฟซของสัญญา: setInterfaceImplementer (ที่อยู่ไปยัง Addr, bytes32 interfaceHash, ตัวดำเนินการที่อยู่)

โดยเฉพาะอย่างยิ่ง toAddr คือที่อยู่รับของการโอน AMP

interfaceHash为AmpTokensRecipient แฮช:

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

interfaceHash คือแฮชของ AmpTokensRecipient:

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

Implementer คือที่อยู่การโจมตีที่ได้รับในขั้นตอนที่ 2

ขั้นตอนที่ 4: ล่อผู้ใช้ให้โอน AMP ไปยัง toAddr เพื่อเรียกการโทรกลับ และขโมย RUNE ของเขาไปพร้อม ๆ กัน

การโจมตีครั้งที่ 3: การโจมตีแบบฟิชชิ่ง

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

ขั้นตอนที่ 1: ผู้โจมตีจะออกโทเค็น ERC-20 และอาจเขียนลงในอินเทอร์เฟซของสัญญาที่เกี่ยวข้องกับลายเซ็น

ขั้นตอนที่ 2: สร้างคู่ซื้อขายบน Uniswap หรือสวอปอื่น ๆ

ขั้นตอนที่ 3: เสนอ airdrops ให้กับผู้ใช้/ที่อยู่ทั้งหมดที่ถือโทเค็น RUNE

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

นอกจากนี้ เพื่อตรวจสอบความเสี่ยงด้านความปลอดภัยของรหัสสัญญา THORChain เพิ่มเติม CoinEx ได้พูดคุยกับทีมรักษาความปลอดภัยจาก SlowMist และ PeckShield สองหน่วยงานด้านความปลอดภัยที่มีชื่อเสียงในอุตสาหกรรม ยืนยันโดย SlowMist และ PeckShield ความเสี่ยงด้านความปลอดภัยที่กล่าวถึงข้างต้นมีอยู่

จนถึงตอนนี้ เราได้ครอบคลุมการโจมตีหลายประเภท รวมถึงความเสี่ยงด้านความปลอดภัยที่ผู้ใช้ได้รับ

ทีมงานโครงการควรเพิ่มประสิทธิภาพรหัสสัญญาอย่างไรเพื่อให้ตัวเองปลอดภัยยิ่งขึ้นและปกป้องทรัพย์สินของผู้ใช้

คำตอบเดียวคือต้องระมัดระวังเกี่ยวกับการใช้ tx.origin

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

1. สำหรับการโจมตีครั้งที่ 1: เมื่อทำการถ่ายโอน ให้ติดตามปริมาณการใช้ก๊าซโดยประมาณ สำหรับการโอน ETH ปกติ ค่าธรรมเนียมแก๊ส 21,000 ก็เพียงพอแล้ว ระวังถ้าปริมาณการใช้ก๊าซเกินกว่าตัวเลขนั้น
2. สำหรับการโจมตีครั้งที่ 2: แยกโทเค็นของคุณโดยใช้กระเป๋าเงินที่แตกต่างกัน คุณสามารถจัดเก็บโทเค็นที่แตกต่างกันในที่อยู่ที่แตกต่างกัน ต้องใช้ความระมัดระวังเป็นพิเศษเมื่อพูดถึงที่อยู่กระเป๋าเงินด่วนที่บริษัทแลกเปลี่ยนเสนอให้
3. For Attack No.3: ความโลภเป็นที่มาของความชั่วร้ายทั้งหมด อย่าสุ่มสี่สุ่มห้าเข้าร่วมกิจกรรม airdrop

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