BTC
ETH
HTX
SOL
BNB
ดูตลาด
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

CertiK: การวิเคราะห์เหตุการณ์การโจมตีของ PolyNetwork

CertiK
特邀专栏作者
2021-08-13 03:45
บทความนี้มีประมาณ 2334 คำ การอ่านทั้งหมดใช้เวลาประมาณ 4 นาที
"แฮ็กเกอร์นำใบรับรองของเจ้าของไปค้นหาทรัพย์สินเพื่อรับกุญแจ หลักฐานเป็นของปลอม แต่เขา
สรุปโดย AI
ขยาย
"แฮ็กเกอร์นำใบรับรองของเจ้าของไปค้นหาทรัพย์สินเพื่อรับกุญแจ หลักฐานเป็นของปลอม แต่เขา

"แฮ็กเกอร์นำใบรับรองของเจ้าของไปค้นหาทรัพย์สินเพื่อรับกุญแจ หลักฐานเป็นของปลอม แต่เขาได้กุญแจจริงจากทรัพย์สิน"

"แฮ็กเกอร์นำใบรับรองของเจ้าของไปค้นหาทรัพย์สินเพื่อรับกุญแจ หลักฐานเป็นของปลอม แต่เขาได้กุญแจจริงจากทรัพย์สิน"

ชื่อเรื่องรอง

ในวันที่ 10 สิงหาคม 2021 PolyNetwork ประสบกับการโจมตีข้ามสายโซ่ และมีการโอนทรัพย์สินที่เข้ารหัสมูลค่า 600 ล้านดอลลาร์สหรัฐ (จากนั้นผู้โจมตีก็เริ่มส่งคืนทรัพย์สินที่ถูกขโมยไปทีละราย) ผู้โจมตีทำธุรกรรมการโจมตีบนเครือข่ายสาธารณะหลายแห่ง และเสร็จสิ้นการโจมตีผ่านสัญญาการจัดการข้ามเครือข่ายและส่วนประกอบทวนสัญญาณ

จากตัวอย่างของทรัพย์สินข้างต้นเพื่ออธิบาย แฮ็กเกอร์ใช้ใบรับรองเจ้าของบ้านปลอม (ธุรกรรมที่ไม่ถูกต้องบนซอร์สเชน) เพื่อรับคีย์จริง (ใบรับรอง Merkle ที่ลงนามบน Alliance Chain) จากทรัพย์สิน (ตัวทำซ้ำ)

ชื่อเรื่องรอง

การวิเคราะห์การโจมตี

1. แฮ็กเกอร์เริ่มต้นธุรกรรมการโจมตีที่ควรจะไม่ถูกต้องบนซอร์สเชน

2. ธุรกรรมการโจมตีถูกเขียนลงในซอร์สเชนโดยไม่ได้รับการตรวจสอบอย่างครบถ้วน จากนั้นจึงรวมไว้ในแผนผัง Merkle ของ Alliance Chain โดยตัวทำซ้ำและลงนาม จากนั้นปล่อยไปยังบล็อก Alliance Chain

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

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

ชื่อเรื่องรอง

https://explorer.ont.io/tx/F771BA610625D5A37B67D30BF2F8829703540C86AD76542802567CAAFFFF280C#

การวิเคราะห์โดยละเอียด

1. แฮ็กเกอร์เริ่มทำธุรกรรมการโจมตีบนซอร์สเชนเมื่อเวลา 17:32:32 น. ของวันที่ 10 สิงหาคม 2564 ตามเวลาปักกิ่ง"66313231333138303933"เราถอดรหัสธุรกรรมและได้แมปพารามิเตอร์ต่อไปนี้

https://explorer.poly.network/tx/1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80

2. ธุรกรรมการโจมตีนี้เรียกเมธอด

และลายเซ็นที่เกี่ยวข้องมีค่าเท่ากับ 0x41973cd9 (เหมือนกับลายเซ็นของฟังก์ชัน putCurEpochConPubKeyBytes ที่เรียกในภายหลัง) ธุรกรรมนี้ควรเป็นธุรกรรมที่ไม่ถูกต้อง แต่ถูกเขียนลงในซอร์สเชนและรวมไว้ใน Merkle tree ของ Alliance Chain โดยทวน ลงนามแล้วเผยแพร่ไปยังบล็อก Alliance Chain Merkle tree ใช้เพื่อพิสูจน์ว่าธุรกรรมนั้นมีอยู่จริงหรือไม่ ผลลัพธ์ของธุรกรรมข้ามสายโซ่มีดังนี้:

https://etherscan.io/tx/0xb1f70464bd95b774c6ce60fc706eb5f9e35cb5f06e6cfe7c17dcda46ffd59581

4. ฟังก์ชันนี้จะวิเคราะห์ข้อพิสูจน์ของ Merkle และพบว่าข้อพิสูจน์นั้นถูกต้อง และธุรกรรมการโจมตีก็มีอยู่ในแผนภูมิ Merkle ที่ลงนามแล้ว จากนั้นเรียกใช้ฟังก์ชัน EthCrossChainManager._executeCrossChainTx() เพื่อดำเนินการธุรกรรม นั่นคือ เรียก toContract เพื่อชี้ไปที่เมธอด (0x6631313231333138303933) ในสัญญา (0xcf2afe102057ba5c16f899271045a0a37fcb10f2) และส่งผ่านพารามิเตอร์ args ( 010000000000000014a87fb85a93ca072cd4e5f0d4f178bc831df8a00b). และเมธอดนี้ชี้ไปที่ putCurEpochConPubKeyBytes(ไบต์) เนื่องจากลายเซ็นของฟังก์ชันนั้นเหมือนกับลายเซ็นของเมธอดที่กล่าวถึงในขั้นตอนที่ 2 (ทั้งคู่คือ 0x41973cd9 นี่คือการชนกันของแฮช) ดังนั้นจึงดำเนินการได้สำเร็จ และคีย์สาธารณะของผู้ดูแล ถูกเปลี่ยนเป็นรหัสสาธารณะของแฮ็กเกอร์ ธุรกรรมบน Ethereum มีดังนี้:

5. หลังจากแฮ็กเกอร์เปลี่ยนรหัสสาธารณะแล้ว พวกเขาสามารถปลดล็อกทรัพย์สินได้ตามต้องการ

ชื่อเรื่องรอง

สรุปเหตุการณ์

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

2. ผู้ทวนจะได้รับใดๆ

การทำธุรกรรมเหตุการณ์

3. Repeater เผยแพร่ธุรกรรมในขั้นตอนที่ 1 ไปยัง Alliance Chain

“The management contract fetches the block headers from chain A, verifies whether or not the cross chain parameters and the proof are valid, and then transmits the necessary information to chain B in the form of an event;”

"4. ในขั้นตอนที่ 2 ธุรกรรมการโจมตีจะรวมอยู่ใน Merkle tree ของ Alliance Chain สร้างหลักฐาน Merkle ที่ถูกต้อง"

5. สัญญา ECCM บนเชนเดิมได้ผ่านใบรับรอง Merkle ที่สร้างขึ้นในขั้นตอนที่ 2 ซึ่งยืนยันว่าธุรกรรม "มีอยู่จริง" บนเชนต้นทาง และข้อมูลดั้งเดิมไม่ได้ถูกทำลายหรือแก้ไข อย่างไรก็ตาม สิ่งสำคัญคือต้องเน้นย้ำว่าธุรกรรมควรได้รับการตรวจสอบอย่างครบถ้วนก่อนที่จะสร้างหลักฐานของ Merkle ที่จะถูกส่งไปยังห่วงโซ่เป้าหมาย ตามที่ปรากฏในเอกสารการออกแบบ

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

PolyNetwork
ความปลอดภัย
ยินดีต้อนรับเข้าร่วมชุมชนทางการของ Odaily
กลุ่มสมาชิก
https://t.me/Odaily_News
กลุ่มสนทนา
https://t.me/Odaily_CryptoPunk
บัญชีทางการ
https://twitter.com/OdailyChina
กลุ่มสนทนา
https://t.me/Odaily_CryptoPunk
ค้นหา
สารบัญบทความ
อันดับบทความร้อน
Daily
Weekly
ดาวน์โหลดแอพ Odaily พลาเน็ตเดลี่
ให้คนบางกลุ่มเข้าใจ Web3.0 ก่อน
IOS
Android