ผู้แต่ง: Artela Chinese blog, medium# บทคัดย่อ

การโจมตีแบบ Re-entrancy ยังคงเป็นสิ่งที่ท้าทาย วิธีการป้องกันที่มีอยู่จะเน้นไปที่ระดับซอร์สโค้ดของโปรโตคอลเป็นหลัก ซึ่งจะมีผลก่อนที่สัญญาจะเข้าสู่สถานะรันไทม์

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

การออกแบบ EVM ไม่รองรับ “การป้องกันรันไทม์” เนื่องจากสัญญาอัจฉริยะไม่สามารถเข้าถึงข้อมูลบริบททั้งหมดของสถานะรันไทม์ได้

Artela สำรวจกระบวนทัศน์เลเยอร์การประมวลผล EVM+Extension ปรับปรุงเลเยอร์การดำเนินการเพื่อกำจัดการโจมตีซ้ำ

Artela ใช้ส่วนขยาย “การป้องกันรันไทม์” บนเครือข่ายผ่าน Aspect Programming

เราแสดงวิธีการป้องกันการโจมตีแบบย้อนกลับในสัญญา Curve ทีละขั้นตอนผ่าน Aspect

เหตุใดการโจมตีการกลับเข้าที่ใหม่จึงยังคงเป็นสิ่งที่ท้าทายแม้จะมีการควบคุมความเสี่ยงที่มีอยู่

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

Curve Finance Attack (กรกฎาคม 2023) — $60 ล้าน Curve ประสบกับการโจมตี reentrancy เนื่องจากข้อบกพร่องในการรวบรวมในภาษาโปรแกรมสัญญา Vyper

Origin Protocol Attack (พฤศจิกายน 2022) — โครงการ Stablecoin มูลค่า 7 ล้านดอลลาร์ Origin Dollar (OUSD) ประสบกับการโจมตีซ้ำ

การโจมตี Siren Protocol (กันยายน 2021) — 3.5 ล้านดอลลาร์ กลุ่ม AMM ประสบปัญหาการโจมตีซ้ำ

การโจมตี Cream Finance (สิงหาคม 2564) - 18.8 ล้านดอลลาร์ ผู้โจมตีใช้ช่องโหว่ในการกลับเข้าใช้ใหม่เพื่อกู้ยืมเงินสำรอง

ปัจจุบัน จุดเน้นของการป้องกันการโจมตี reentrancy อยู่ที่ระดับซอร์สโค้ดของสัญญาอัจฉริยะ มาตรการต่าง ๆ ได้แก่ การรวม ReentrancyGuard ของ OpenZeppelin และดำเนินการตรวจสอบความปลอดภัยในโค้ดตรรกะของสัญญาเพื่อหลีกเลี่ยงความเสี่ยงด้านความปลอดภัยที่กำหนดไว้ล่วงหน้า

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

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

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

เราต้องการการป้องกันรันไทม์

ซึ่งแตกต่างจากมาตรการควบคุมความเสี่ยงที่มีอยู่ซึ่งเข้มข้นที่ระดับซอร์สโค้ดของโปรโตคอลและมีผลก่อนการดำเนินการ การป้องกันรันไทม์เกี่ยวข้องกับนักพัฒนาโปรโตคอลที่เขียนกฎการป้องกันรันไทม์และการดำเนินการเพื่อจัดการกับสถานการณ์ที่ไม่คาดฝันของรันไทม์ สิ่งนี้อำนวยความสะดวกในการประเมินตามเวลาจริงและตอบสนองต่อผลการดำเนินการรันไทม์

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

ความท้าทายในการใช้การป้องกันรันไทม์

น่าเสียดายที่การออกแบบ EVM ไม่รองรับการป้องกันรันไทม์แบบออนไลน์ เนื่องจากสัญญาอัจฉริยะไม่สามารถเข้าถึงบริบทรันไทม์แบบเต็มได้

จะเอาชนะความท้าทายนี้ได้อย่างไร? เราเชื่อว่าข้อกำหนดเบื้องต้นต่อไปนี้มีความจำเป็น:

โมดูลเฉพาะที่ให้การเข้าถึงข้อมูลทั้งหมดในสัญญาอัจฉริยะ รวมถึงบริบทการทำธุรกรรมทั้งหมด

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

ตรวจสอบให้แน่ใจว่าการทำงานของโมดูลมีผลหลังจากดำเนินการสัญญาอัจฉริยะและก่อนที่จะส่งสถานะ

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

แนวคิดของ Artela คือ EVM + ส่วนขยายแบบเนทีฟ โดยการสร้างเลเยอร์ส่วนขยายแบบเนทีฟ WASM ของ EVM เพื่อให้ก้าวไปไกลกว่า EVM

บทนำการเขียนโปรแกรมด้าน

เราเปิดตัว Aspect Programming ซึ่งเป็นเฟรมเวิร์กการเขียนโปรแกรมสำหรับ Artela blockchain ที่รองรับการปรับขนาดแบบเนทีฟบนบล็อกเชน

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

คุณลักษณะของ Aspect คือสามารถเข้าถึง API ระดับระบบของเลเยอร์ฐานของบล็อกเชน และเพิ่มลอจิกส่วนขยายที่จุดเชื่อมต่อแต่ละจุดของวงจรชีวิตของธุรกรรม สัญญาอัจฉริยะสามารถผูกลักษณะที่ระบุเพื่อเรียกใช้ฟังก์ชันเพิ่มเติม เมื่อธุรกรรมเรียกใช้สัญญาอัจฉริยะ ธุรกรรมนั้นจะถูกประมวลผลตามลักษณะที่เกี่ยวข้องกับสัญญาด้วย

Aspect Programming ใช้การป้องกันรันไทม์อย่างไร

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

Aspect ใช้คุณสมบัติหลักสำหรับการป้องกันรันไทม์:

สามารถทริกเกอร์ได้หลังจากการดำเนินการตามสัญญาอัจฉริยะและก่อนการส่งสถานะ: สามารถตั้งค่าโมดูล Aspect ให้เปิดใช้งานหลังจากการดำเนินการสัญญาอัจฉริยะ แต่ก่อนที่จะส่งสถานะ

การเข้าถึงบริบทของธุรกรรมโดยสมบูรณ์: Aspect สามารถเข้าถึงบริบทของธุรกรรมที่สมบูรณ์ รวมถึงข้อมูลธุรกรรมทั้งหมด (วิธีการ พารามิเตอร์ ฯลฯ) call stack (การเรียกใช้สัญญาภายในทั้งหมดระหว่างการดำเนินการ) การเปลี่ยนแปลงบริบทสถานะ และเหตุการณ์ที่ทริกเกอร์ธุรกรรมทั้งหมด

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

การผูกมัดและการอนุญาตด้วยสัญญาอัจฉริยะ: สัญญาอัจฉริยะสามารถผูกมัดกับ Aspect และให้สิทธิ์แก่ Aspect เพื่อเข้าร่วมในการประมวลผลธุรกรรม

ใช้ Aspect เพื่อการป้องกันการกลับเข้ามาใหม่

ในบทนี้ เราจะพูดถึงวิธีการใช้การป้องกันรันไทม์ของ Aspect ในห่วงโซ่

สามารถนำลักษณะ “เจตนาในการป้องกันสัญญา” ไปใช้งานจริงในจุดรวมของ “preContractCall” และ “postContractCall” เพื่อป้องกันการโจมตีซ้ำ

preContractCall: ทริกเกอร์ก่อนดำเนินการโทรข้ามสัญญา

postContractCall: ทริกเกอร์หลังจากดำเนินการโทรข้ามสัญญา

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

ใน pointcut “preContractCall” Aspect จะตรวจสอบสแตกการเรียกสัญญา หากมีการโทรที่ซ้ำกันใน call stack (หมายถึงการกลับมาใหม่โดยไม่คาดคิดในการโทรที่ล็อคไว้) ลักษณะจะย้อนกลับการโทร

ปรับใช้สัญญา Curve และป้องกันการโจมตีซ้ำ

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

จะเห็นได้ว่าทั้ง add_liquidity และ remove_liquidity ของสัญญาข้างต้นได้รับการปกป้องโดย re-entry lock lock เดียวกัน ซึ่งหมายความว่าหากการป้องกัน re-entry ทำงานตามปกติ ฟังก์ชันที่ได้รับการป้องกันจะไม่สามารถกลับเข้ามาใหม่ได้โดยการเปลี่ยน การล็อก (เช่น ในการลบ _liquidity เรียกเพิ่ม_liquidity)

รวบรวมสัญญาข้างต้นด้วยคอมไพเลอร์ vyper 0.2.15, 0.2.16 หรือ 0.3.0 (เวอร์ชันเหล่านี้ทราบปัญหาการป้องกันการกลับเข้าที่)

จากนั้นเราจะใช้สัญญาของเหยื่อข้างต้นและโจมตีด้วยสัญญาต่อไปนี้:

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

ตอนนี้ มาใช้ Aspect เพื่อป้องกันสัญญาที่ถูกโจมตี ก่อนทำสิ่งต่อไปนี้ โปรดทำตามขั้นตอนต่อไปนี้:

1. ปรับใช้ Aspect

2. ผูกมัดเหยื่อสัญญากับ Aspect

หากคุณไม่คุ้นเคยกับการทำงานของ Aspect โปรดดูคู่มือสำหรับนักพัฒนาของเราก่อน

หลังจากดำเนินการข้างต้นแล้ว ให้เราลองเรียกวิธีโจมตีอีกครั้งเพื่อตรวจสอบว่าการดำเนินการจะสำเร็จหรือไม่

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

สรุปแล้ว

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

เพื่อเพิ่มความปลอดภัยของ DeFi การป้องกันรันไทม์จึงมีความสำคัญ ด้วยการป้องกันโปรโตคอลในลักษณะ “กล่องดำ” เพื่อให้แน่ใจว่าการดำเนินการของโปรโตคอลนั้นสอดคล้องกับการออกแบบที่ตั้งใจไว้ จึงสามารถป้องกันการโจมตีแบบย้อนกลับในขณะรันไทม์ได้อย่างมีประสิทธิภาพ

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

ด้วย Aspect Programming นักพัฒนาไม่เพียงสามารถบรรลุการป้องกันรันไทม์บนเครือข่ายในพื้นที่การรักษาความปลอดภัยเท่านั้น แต่ยังเปิดใช้งานกรณีการใช้งานที่เป็นนวัตกรรมอย่างที่ไม่เคยมีมาก่อน เช่น Intent, JIT และระบบอัตโนมัติบนเครือข่าย นอกจากนี้ เฟรมเวิร์กทั่วไปที่ใช้ Cosmos SDK นี้ไม่เพียงแต่รองรับบล็อกเชน Artela เท่านั้น แต่ยังรองรับบล็อกเชนอื่น ๆ เพื่อสร้างส่วนขยายแบบเนทีฟโดยอิงจากชั้นการดำเนินการของตนเอง