เมื่อวันที่ 18 มกราคม 2022 ระบบตรวจสอบการทำธุรกรรมที่ผิดปกติของเราตรวจพบการโจมตีในโครงการ AnySwap (เช่น Multichain) เนื่องจากฟังก์ชัน anySwapOutUnderlyingWithPermit() ไม่สามารถนำกลไกการตรวจสอบที่เกี่ยวข้องไปใช้ได้อย่างถูกต้อง ผู้โจมตีจึงนำโทเค็นที่ได้รับอนุญาตจากผู้ใช้ไปยังโครงการออกได้ สำหรับรายละเอียดเกี่ยวกับช่องโหว่และรายละเอียดการกำจัดที่เกี่ยวข้อง โปรดดูคำชี้แจงอย่างเป็นทางการของ ฝ่ายโครงการ (https://medium.com/multichainorg/multichain-contract-vulnerability-post-mortem-d37bfab237c8)

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

ขณะที่การโจมตีดำเนินต่อไป ทีมงานของ BlockSec ตัดสินใจใช้มาตรการรับมือเหตุฉุกเฉินเพื่อปกป้องผู้ที่อาจตกเป็นเหยื่อ การช่วยเหลือนี้มุ่งเป้าไปที่บัญชีที่ได้รับผลกระทบบน Ethereum โดยเฉพาะ ที่อยู่ของสัญญาโครงการที่เกี่ยวข้องคือ 0x6b7a87899490EcE95443e979cA9485CBE7E71522 เราจะโอนเงินบัญชีที่เกี่ยวข้องไปยังบัญชีหมวกขาวแบบหลายลายเซ็นที่สร้างขึ้นเป็นพิเศษของเรา (0xd186540FbCc460f6a3A9e705DC6d240 6cBcc 1C47).

เพื่อให้มั่นใจว่าการดำเนินการมีความโปร่งใส เราได้อธิบายแผนปฏิบัติการที่เกี่ยวข้องในไฟล์ pdf และเผยแพร่แฮชไฟล์ (ไม่ใช่เนื้อหา) แก่ชุมชนทันที สิ่งนี้ทำให้มั่นใจได้ว่าการกระทำของเราสามารถแยกความแตกต่างจากการกระทำของผู้โจมตีโดยไม่ต้องเปิดเผยรายละเอียดใด ๆ (เนื่องจากการโจมตียังดำเนินอยู่)

ปฏิบัติการกู้ภัยของเราเริ่มต้นอย่างเป็นทางการในวันที่ 21 มกราคม 2022 และจะสิ้นสุดอย่างเป็นทางการในวันที่ 11 มีนาคม 2022 ข้อความสาธารณะที่เกี่ยวข้องแสดงในรูปที่ 2 และรูปที่ 3 ตามลำดับ

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

สรุปสั้นๆ (ยาวเกินกว่าจะอ่านฉบับได้)

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

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

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

• จากมุมมองของความโปร่งใส หมวกขาวสามารถประกาศการกระทำของตนต่อสาธารณะต่อชุมชนโดยไม่ต้องเปิดเผยข้อมูลที่ละเอียดอ่อน วิธีการได้รับความไว้วางใจจากชุมชนนี้ใช้ได้ดีในทางปฏิบัติ

• ทุกฝ่ายในชุมชนสามารถทำงานร่วมกันเพื่อให้ปฏิบัติการบรรเทาทุกข์รวดเร็วและมีประสิทธิภาพมากขึ้น ตัวอย่างเช่น การประสานงานระหว่างหมวกขาวสามารถดำเนินการเพื่อลดหรือหลีกเลี่ยงการแข่งขันที่ไม่ถูกต้อง

ชื่อระดับแรก

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

0x1.1 ผลลัพธ์โดยรวม

ภายในช่วงการสังเกตของเรา (จากความสูงของบล็อก 14028474 ในวันที่ 18 มกราคม 2022 ถึงความสูงของบล็อก 14421215 ในวันที่ 20 มีนาคม 2022) สถานการณ์การโจมตีและการช่วยเหลือโดยรวมแสดงในตารางที่ 1 ตาม Ethereum ที่เกี่ยวข้องกับการโจมตีหรือช่วยเหลือ สถิติที่อยู่บัญชี (เพื่อความสะดวกในการแสดง ให้แสดงเฉพาะ 4 หลักแรกของที่อยู่) โดยเฉพาะอย่างยิ่ง ที่อยู่บัญชีอาจเป็นบัญชีช่วยเหลือหรือบัญชีโจมตี และประเภทจะพิจารณาจากแท็ก Etherscan.io และที่อยู่การโอนเงิน นอกจากนี้ ในระหว่างขั้นตอนการโจมตีและช่วยเหลือ ทั้งหมวกสีขาวและผู้โจมตีใช้ Flashbots เพื่อส่งธุรกรรมในปริมาณมาก ดังนั้นพวกเขาจึงต้องจ่ายค่าธรรมเนียมเพิ่มเติมให้กับคนงานเหมือง ซึ่งเราเรียกว่าค่าธรรมเนียม Flashbots

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

0x1.2 แนวโน้มค่าธรรมเนียม Flashbots

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

ชื่อระดับแรก

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

0x2.1 เราจะดำเนินการช่วยเหลือได้อย่างไร

แนวคิดพื้นฐานของการกู้ภัยนั้นเรียบง่ายและตรงไปตรงมา โดยเฉพาะอย่างยิ่ง เราจำเป็นต้องตรวจสอบชุดบัญชีของผู้ที่อาจเป็นเหยื่อซึ่งอนุญาตให้ใช้ WETH โดยสัญญาฝ่ายโครงการที่มีปัญหา เมื่อมีการโอน WETH ไปยังบัญชีนี้ เราจะใช้ช่องโหว่ของสัญญาเพื่อโอนโดยตรงไปยังกระเป๋าเงินแบบหลายลายเซ็นของหมวกขาวของเรา กุญแจสำคัญที่นี่คือการปฏิบัติตามข้อกำหนดสามประการต่อไปนี้:

• R1: ค้นหาธุรกรรมที่โอนไปยังบัญชีของเหยื่ออย่างมีประสิทธิภาพ เพื่อความสะดวกในการอธิบาย เราจะตั้งชื่อธุรกรรมเหล่านี้เป็นธุรกรรมที่โอน (Transfered TXs) ด้านล่าง

• R2: สร้างธุรกรรมอย่างถูกต้องเพื่อใช้กู้ภัย เพื่อความสะดวกในการอธิบาย เราจะตั้งชื่อธุรกรรมเหล่านี้เป็นธุรกรรมกู้ภัย (rescue TXs) ด้านล่าง

• R3: ยึดครองธุรกรรมของผู้โจมตี (หรือบุคคลที่สาม) ได้สำเร็จ เพื่อความสะดวกในการอธิบาย เราจะตั้งชื่อธุรกรรมเหล่านี้เป็นธุรกรรมการโจมตี (Attack TX) ด้านล่าง

R1 และ R2 ไม่เป็นอุปสรรคต่อเรา เนื่องจากเราได้สร้างระบบภายในเพื่อตรวจสอบ mempool เราจึงสามารถค้นหาธุรกรรมการโอนได้ทันท่วงที พร้อมกันนี้ เรายังได้พัฒนาชุดเครื่องมือเพื่อสร้างธุรกรรมช่วยเหลือโดยอัตโนมัติ

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

0x2.2 การแข่งขันที่เรามีส่วนร่วม

โดยรวมแล้ว เราพยายามปกป้องบัญชีผู้ที่อาจเป็นเหยื่อจำนวน 171 บัญชี ในจำนวนนี้มี 10 บัญชีที่ป้องกันตนเองได้โดยการเพิกถอนการอนุญาตทันเวลา และในบรรดาบัญชีที่เหลืออีก 161 บัญชี เนื่องจากการแข่งขันต่างๆ ที่กล่าวมาข้างต้นทำให้เราสามารถช่วยเหลือได้สำเร็จเพียง 14 บัญชีเท่านั้น เราสรุปความล้มเหลวในตารางด้านล่าง ซึ่งเกี่ยวข้องกับบัญชีช่วยเหลือ 3 บัญชี และบัญชีโจมตี 16 บัญชี

ชื่อระดับแรก

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

0x3.1 จะกำหนดค่าธรรมเนียม Flashbots ได้อย่างไร?

ตลอดกระบวนการช่วยเหลือ เราพ่ายแพ้อย่างต่อเนื่องโดยคู่แข่ง 12 รายที่ใช้ประโยชน์จาก Flashbots รวมถึงบัญชีช่วยเหลือ 2 บัญชีและบัญชีโจมตี 10 บัญชี

กลยุทธ์ของเราในการตั้งค่าค่าธรรมเนียม Flashbots นั้นค่อนข้างอนุรักษ์นิยม โดยเฉพาะอย่างยิ่ง เรามักจะกำหนดค่าธรรมเนียม Flashbots ให้ต่ำที่สุดเท่าที่จะเป็นไปได้ เพื่อปกป้องผลประโยชน์ของผู้ที่ตกเป็นเหยื่อ ดังนั้น เว้นแต่จะมีการโจมตีสำเร็จโดยใช้ Flashbots เราจะไม่ใช้ Flashbots หรือเพิ่มค่าธรรมเนียม Flashbots ตัวอย่างเช่น ธุรกรรมการโจมตีที่ประสบความสำเร็จจะกำหนดอัตราค่าธรรมเนียม Flashbots ที่ 10% และเราอาจตั้งค่าเป็น 11% ในการทำธุรกรรมการช่วยเหลือครั้งต่อไป อย่างไรก็ตาม กลยุทธ์ดังกล่าวยังไม่ได้รับการพิสูจน์ว่าประสบความสำเร็จมากนัก และผู้โจมตี (แม้แต่หมวกขาวบางคน) มักจะหันไปใช้กลยุทธ์ที่ก้าวร้าวมากขึ้นเพื่อกำหนดค่าธรรมเนียมเพื่อชนะการแข่งขัน เช่น:

• รูปที่ 5 แสดงธุรกรรมการโจมตีที่ความสูงบล็อก 14071986 และผู้โจมตี 0x5738** ตั้งอัตราส่วนเป็น 70%

• รูปที่ 6 แสดงธุรกรรมการโจมตีที่ความสูงบล็อก 14072255 และหมวกสีขาว 0x14ca** กำหนดสัดส่วนเป็น 79%

• รูปที่ 7 แสดงธุรกรรมการโจมตีที่ความสูงบล็อก 14072385 และหมวกสีขาว 0x14ca** กำหนดอัตราส่วนเป็น 80%

• รูปที่ 8 แสดงธุรกรรมการโจมตีที่ความสูงบล็อก 14072417 และหมวกสีขาว 0x9117** กำหนดสัดส่วนเป็น 81%

• รูปที่ 9 แสดงธุรกรรมการโจมตีที่ความสูงบล็อก 14073395 และผู้โจมตี 0x5738** ตั้งอัตราส่วนเป็น 86%

ชื่อระดับแรก

0x3.2 จะจัดเรียงตำแหน่งธุรกรรมใน mempool ได้อย่างไร?

ขณะนี้ดูเหมือนว่าความสำเร็จของการช่วยเหลือขึ้นอยู่กับการแข่งขันด้านอาวุธในราคาของ Flashbots อย่างไรก็ตาม เราพบว่า Flashbots ไม่ได้มีประสิทธิภาพเสมอไปเนื่องจากมีการแข่งขันที่รุนแรงจากหลายฝ่าย จากผู้ส่งธุรกรรมรายอื่นที่ไม่เกี่ยวข้องกับการโจมตี/การช่วยเหลือ เช่น การเก็งกำไร เป็นต้น ในกรณีนี้ แม้แต่ค่าธรรมเนียมสูงสุดของ Flashbots (เมื่อเทียบกับธุรกรรมการโจมตีและช่วยเหลืออื่นๆ) ที่กำหนดโดยการแลกเปลี่ยนการโจมตีก็ไม่รับประกันว่าจะชนะการแข่งขัน Flashbots

อีกวิธีหนึ่งที่เป็นไปได้คือใช้การส่งธุรกรรมปกติผ่าน mempool ซึ่งเป็นไปได้ที่จะบรรลุเป้าหมายหากธุรกรรมถูกจัดเรียงในตำแหน่งที่ถูกต้อง ตำแหน่งที่เหมาะสมในที่นี้หมายความว่าธุรกรรมการโจมตี/กู้ภัยตั้งอยู่หลังธุรกรรมการโอนและใกล้กับธุรกรรมการโอนมาก (ยิ่งใกล้ยิ่งดี หากบังเอิญอยู่ในตำแหน่งถัดไปของธุรกรรมการโอน) ในความเป็นจริง ผู้โจมตี 0x48e9** ใช้กลยุทธ์นี้เพื่อเก็บเกี่ยว 312.014657 ETH ได้สำเร็จโดยไม่ต้องจ่ายค่าธรรมเนียม Flashbots กราฟทั้งสี่ต่อไปนี้แสดงการโจมตีที่สร้างผลกำไรสูงสุดสองรายการของผู้โจมตี:

• รูปที่ 10 และรูปที่ 11 ตามลำดับแสดงให้เห็นว่าที่ความสูงของบล็อก 14051020 ธุรกรรมการโอนของเหยื่อ 0x3acb** (โอน 50 ETH) อยู่ที่ 65 ในขณะที่ธุรกรรมการโจมตี (กำไร 50 ETH) อยู่ที่ 66

• รูปที่ 12 และรูปที่ 13 ตามลำดับแสดงให้เห็นว่าที่ความสูงของบล็อก 14052155 ธุรกรรมการโอนของเหยื่อ 0xbea9** (โอน 200 ETH) อยู่ที่ 161 ในขณะที่ธุรกรรมการโจมตี (กำไร 200 ETH) อยู่ที่ 164

ชื่อระดับแรก

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

0x4.1 จะแยกความแตกต่างระหว่างหมวกขาวและผู้โจมตีได้อย่างไร

การระบุหมวกขาวและการกระทำของพวกเขาอาจไม่ตรงไปตรงมาอย่างที่คิด ตัวอย่างเช่น ที่อยู่บัญชี 0xfa27 ถูกตั้งค่าสถานะโดย Etherscan.io เป็นหมวกสีขาว: Multichain Exploiter 4 (Whitehat) อย่างไรก็ตาม ในตอนแรกที่อยู่นี้ถูกระบุว่าเป็นผู้โจมตี: Multichain Exploiter 4 การเปลี่ยนแปลงนี้มาจากการโต้ตอบระหว่างฝ่ายโครงการและผู้โจมตี หลังจากการเจรจาหลายรอบ ผู้โจมตีตกลงที่จะเก็บกำไร 50 ETH ไว้เป็นรางวัลและคืนกำไรอื่นๆ (หักค่าธรรมเนียม Flashbots เป็นต้น):

• ในธุรกรรม 0x3c3d** ฝ่ายโครงการติดต่อผู้โจมตี:

• ในธุรกรรม 0xd360** ผู้โจมตีตอบกลับ:

• ในการทำธุรกรรม 0x354f** ฝ่ายโครงการแสดงความขอบคุณหลังจากได้รับเงินคืน:

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

0x4.2 การแข่งขันระหว่างหมวกขาว

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

0x4.3 จะปฏิบัติการกู้ภัยได้ดีขึ้นอย่างไร?

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

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

• Flashbots/Miners มอบช่องทางสีเขียวให้กับ White Hat ที่ผ่านการตรวจสอบและน่าเชื่อถือ ซึ่งสามารถใช้เพื่อเร่งการทำธุรกรรมการโจมตีและหลีกเลี่ยงการแข่งขันระหว่าง White Hat

• ฝ่ายโครงการที่ถูกโจมตีต้องรับผิดชอบค่าธรรมเนียม Flashbots

• ฝ่ายโครงการใช้กลไกที่สะดวกและรวดเร็วกว่าในการเตือนผู้ใช้อย่างทันท่วงที

• ฝ่ายโครงการใช้มาตรการฉุกเฉินที่จำเป็นบางอย่างในรหัส