แฮกเกอร์หวนคืนสู่ หลักการแรก วิกฤติ Curve ไม่ใช่การโจมตีธรรมดา
ผู้เขียนต้นฉบับ:Jaleel，BlockBeats
ผู้เขียนต้นฉบับ:Jack，BlockBeats
บรรณาธิการต้นฉบับ:
อุตสาหกรรม DeFi ตกอยู่ในความสับสนอลหม่านหลังจากเกิดเหตุการณ์ช่องโหว่ Curve Finance ซึ่งเป็นยักษ์ใหญ่ในอุตสาหกรรม DeFi ได้กลายเป็นเป้าหมายของ การโจมตี ที่ร้ายแรง และกลุ่มเหรียญ stablecoin หลายแห่ง เช่น alETH/msETH/pETH ตกอยู่ในความเสี่ยง จากสถิติที่ไม่สมบูรณ์ เหตุการณ์การหาช่องโหว่ดังกล่าวทำให้สูญเสียมูลค่ารวม 52 ล้านดอลลาร์สหรัฐในพูล Alchemix, JPEG'd, MetronomeDAO, deBridge, Ellipsis และ CRV/ETH และความเชื่อมั่นของตลาดทั้งหมดก็สั่นคลอนอย่างรุนแรง
การล็อคการเข้าซ้ำของ Vyper เวอร์ชัน 0.2.15, 0.2.16 และ 0.3.0 นั้นไม่ถูกต้อง และอินเทอร์เฟซการติดตั้งเอกสารอย่างเป็นทางการของ Vyper แนะนำเวอร์ชันที่ไม่ถูกต้อง ฝ่ายโครงการอื่นๆ ที่ใช้คอมไพเลอร์ Vyper ก็รีบทำการตรวจสอบตัวเองเช่นกัน โดยพยายามให้แน่ใจว่าพวกเขาจะไม่ตกเป็นเหยื่อรายต่อไป เนื่องจากแหล่งที่มาของเหตุการณ์ช่องโหว่ถูกเปิดเผย ตลาดจึงค่อยๆ ตระหนักได้ว่าวิกฤตนี้ไม่เพียงแต่หมายถึงเหตุการณ์การหาช่องโหว่ของแฮ็กเกอร์ธรรมดาเท่านั้น แต่ยังเผยให้เห็นถึงความเสี่ยงมหาศาลที่อาจเกิดขึ้นจากสแต็กที่ซ่อนอยู่ทั้งหมดต่ออุตสาหกรรม DeFi ทั้งหมด
เมื่อเปรียบเทียบกับที่ผ่านมาจำนวนเหตุการณ์การแฮ็กในช่วงก่อนหน้ามีน้อยลงเรื่อยๆ ซึ่งแยกออกจากความเจริญรุ่งเรืองของตลาดไม่ได้ ในช่วงฤดูร้อน DeFi และ NFT ฤดูร้อน มีการเปิดตัวข้อตกลงมูลค่าหลายพันล้านดอลลาร์ใหม่ทุกสัปดาห์ เมื่อเทียบกับตลาดในปัจจุบันที่หดตัวลงมาก ในขณะเดียวกัน โอกาสทางการตลาดสำหรับแฮกเกอร์ในการค้นหาช่องโหว่หรือสร้างการโจมตีขนาดใหญ่กำลังค่อยๆ ลดลง ซึ่งหมายความว่าแฮกเกอร์ต้องการจุดเริ่มต้นที่ใหม่กว่าและยังไม่ได้ใช้เพื่อสำรวจ@BoxMrChen) และนักวิจัย BTX Derek (@begas_btxcap）。
ชื่อระดับแรก
เหตุการณ์ Curve เกิดขึ้นได้อย่างไร?@StaniKulechovStani ผู้ก่อตั้ง Aave และ Lens (
) แสดงความคิดเห็นเกี่ยวกับเหตุการณ์ดังกล่าวบนโซเชียลมีเดีย: นี่เป็นความพ่ายแพ้ที่โชคร้ายสำหรับ Curve และ DeFi แม้ว่า DeFi จะเป็นพื้นที่เปิดโล่งที่สามารถมีส่วนร่วมได้ แต่ก็ยากที่จะแก้ไขให้ถูกต้องอย่างแน่นอน และเดิมพันก็สูง ใน Curve's ในกรณีนี้ พวกเขาทำถูกต้องในระดับโปรโตคอล”
การเอารัดเอาเปรียบที่ Curve ประสบนั้นเป็นหนึ่งในรูปแบบที่เก่าแก่ที่สุดและอาจเป็นรูปแบบการโจมตีที่พบบ่อยที่สุดในสัญญาอัจฉริยะของ Ethereum นั่นคือการโจมตีกลับคืนสู่สภาพเดิม การโจมตีซ้ำทำให้ผู้โจมตีสามารถเรียกใช้ฟังก์ชันของสัญญาอัจฉริยะซ้ำๆ ได้โดยไม่ต้องรอให้การเรียกฟังก์ชันนั้นเสร็จสมบูรณ์ก่อนหน้านี้ ด้วยวิธีนี้ พวกเขาสามารถใช้ช่องโหว่ในการถอนเงินต่อไปได้จนกว่าสัญญาของเหยื่อจะหมดเงินทุน
การล็อคการกลับเข้าใหม่และหลักการ CEI
ยกตัวอย่างง่ายๆ เพื่อแสดงให้เห็นการโจมตีซ้ำ: ธนาคารมีเงินสดทั้งหมด 100,000 เหรียญ แต่ธนาคารนี้มีช่องโหว่ใหญ่ เวลามีคนถอนเงิน เจ้าหน้าที่ธนาคารจะไม่อัพเดทยอดเงินในบัญชีทันที แต่ให้รอจนถึงสิ้นวันจึงจะตรวจสอบและอัพเดตได้ ในเวลานี้ มีคนค้นพบช่องโหว่นี้ เขาเปิดบัญชีในธนาคาร ฝากเงินครั้งแรก 1,000 หยวน จากนั้นถอนออก 1,000 หยวน จากนั้นถอนเงิน 1,000 หยวนหลังจากผ่านไป 5 นาที เนื่องจากธนาคารไม่อัพเดตยอดคงเหลือแบบเรียลไทม์ ระบบจะคิดว่าบัญชีของเขายังมีเงินอยู่ 1,000 หยวน ก่อนที่จะตรวจสอบและอัปเดต ด้วยการดำเนินการซ้ำแล้วซ้ำเล่า ในที่สุดผู้ใช้ก็นำเงินสดทั้งหมดจำนวน 100,000 ดอลลาร์สหรัฐออกจากธนาคาร จนกระทั่งสิ้นสุดวันที่ธนาคารค้นพบว่ามีการใช้ช่องโหว่ดังกล่าว
ความซับซ้อนของการโจมตีซ้ำนั้นอยู่ที่การใช้ประโยชน์จากการเรียกร่วมกันระหว่างสัญญาและช่องโหว่ทางตรรกะของสัญญาเอง และบรรลุพฤติกรรมที่ฉ้อโกงโดยจงใจกระตุ้นข้อยกเว้นและฟังก์ชันการย้อนกลับ ผู้โจมตีสามารถใช้ประโยชน์จากช่องโหว่ทางตรรกะในสัญญาซ้ำแล้วซ้ำอีกเพื่อขโมยเงิน วิธีแก้ปัญหาเพื่อป้องกันการโจมตีซ้ำนั้นเป็นเรื่องปกติมาก เนื้อหารหัสพิเศษที่กำหนดเป้าหมายได้รับการตั้งค่าไว้ล่วงหน้าสำหรับการป้องกัน และใช้กลไกการป้องกันดังกล่าวเพื่อให้มั่นใจในความปลอดภัยของเงินทุน สิ่งนี้เรียกว่าการล็อคการเข้าใหม่ความแข็งแกร่งกำหนด หลักการของ CEI
(Check Effects Interactions) ซึ่งสามารถป้องกันฟังก์ชันต่างๆ จากการโจมตีซ้ำได้เป็นอย่างดี เนื้อหาของหลักการ CEI ประกอบด้วย:
1. ลำดับของการเรียกใช้ส่วนประกอบของฟังก์ชันควรเป็น: อันดับแรก การตรวจสอบ ประการที่สอง ผลกระทบต่อตัวแปรสถานะ และสุดท้าย ปฏิสัมพันธ์กับหน่วยงานภายนอก
2. ก่อนที่จะโต้ตอบกับเอนทิตีภายนอก ควรอัปเดตตัวแปรสถานะทั้งหมด สิ่งนี้เรียกว่า การทำบัญชีในแง่ดี โดยที่ผลกระทบจะถูกเขียนก่อนที่ปฏิสัมพันธ์จะเกิดขึ้นจริง
3. ควรทำการตรวจสอบที่จุดเริ่มต้นของฟังก์ชันเพื่อให้แน่ใจว่าเอนทิตีที่เรียกมีสิทธิ์ในการเรียกใช้ฟังก์ชัน
4. ตัวแปรสถานะควรได้รับการอัปเดตก่อนการเรียกภายนอกเพื่อป้องกันการโจมตีซ้ำ
5. แม้แต่หน่วยงานภายนอกที่เชื่อถือได้ก็ควรปฏิบัติตามรูปแบบ CEI เนื่องจากอาจถ่ายโอนขั้นตอนการควบคุมไปยังบุคคลที่สามที่เป็นอันตราย
ตามเอกสารประกอบ หลักการ CEI ช่วยจำกัดขอบเขตการโจมตีของสัญญา โดยเฉพาะอย่างยิ่งการป้องกันการโจมตีซ้ำ สามารถใช้หลักการ CEI ได้อย่างง่ายดาย โดยส่วนใหญ่จะเรียงตามลำดับโค้ดฟังก์ชัน โดยไม่ต้องเปลี่ยนตรรกะใดๆ การใช้ประโยชน์ที่รู้จักกันดีของ The DAO ซึ่งนำไปสู่การแยก Ethereum นั้นก็เพิกเฉยต่อ หลักการ CEI เช่นกัน และผู้โจมตีก็ประสบความสำเร็จในการโจมตีกลับเข้ามาใหม่ ทำให้เกิดผลที่ตามมาที่ร้ายแรง
แต่พูล Curve ที่ถูกโจมตีไม่เป็นไปตามหลักการ CEI นี้ เนื่องจาก Curve ใช้คอมไพเลอร์ Vyper เนื่องจากคอมไพเลอร์มีช่องโหว่ในโค้ด Vyper การล็อคการกลับเข้าซ้ำจึงล้มเหลว ส่งผลให้การโจมตีการกลับเข้าซ้ำของแฮ็กเกอร์ประสบความสำเร็จ
คนส่วนใหญ่รู้จัก Solidity แต่ Solidity ไม่ใช่ภาษาเดียวสำหรับการสร้าง smart Contract ทางเลือกยอดนิยมสำหรับ Solidity คือ Vyper แม้ว่า Vyper จะไม่ทรงพลังและได้รับความนิยมเท่ากับ Solidity แต่ก็เหมาะอย่างยิ่งสำหรับนักพัฒนาที่คุ้นเคยกับ Python เนื่องจาก Vyper สามารถแปลโค้ดที่คล้ายกับ Python เป็นภาษาการเขียนโปรแกรมสัญญาอัจฉริยะ Ethereum
ตามข้อมูล GitHub นักพัฒนาที่สนับสนุนฐานโค้ด GitHub ของ Vyper เป็นรายแรกก็เป็นผู้พัฒนา Curve เช่นกัน อธิบายได้ไม่ยากว่าทำไม Curve ถึงใช้ Vyper แทน Solidity
เหตุใดการล็อคการกลับเข้าซ้ำของ Vyper จึงล้มเหลว@BoxMrChenแล้วการโจมตีครั้งนี้ Vyper มีปัญหาอะไร? เหตุใดการล็อคการเข้าซ้ำจึงล้มเหลว เป็นเพราะไม่มีการทดสอบใช่ไหม? BlockBeats สัมภาษณ์ผู้พัฒนาสัญญาอัจฉริยะ Box 826.eth (
) ตามที่เขาพูด การล็อคการกลับเข้าใหม่ของ Vyper ได้รับการทดสอบกับกรณีการใช้งาน แต่สาเหตุของความล้มเหลวก็คือกรณีทดสอบนั้นเน้นที่ผลลัพธ์ กล่าวคือ กรณีทดสอบก็ผิดเช่นกัน
กล่าวโดยสรุป สาเหตุที่ใหญ่ที่สุดว่าทำไมการล็อกกลับเข้าซ้ำของ Vyper จึงล้มเหลวก็คือ ผู้เขียนกรณีทดสอบเขียนกรณีทดสอบตามผลลัพธ์ โดยไม่คิดว่าเหตุใดช่องจึงข้าม 1 อย่างอธิบายไม่ได้
ในย่อหน้าต่อไปนี้ของรหัส Vyper ที่ใช้ร่วมกันโดย Box สามารถมองเห็นปัญหาได้ชัดเจน เมื่อชื่อล็อคปรากฏขึ้นเป็นครั้งที่สอง จำนวน storage_slots จะถูกเขียนทับ กล่าวคือ ในทางกลับกัน ช่องสำหรับการได้มาซึ่งการล็อคครั้งแรกจะเป็น 0 แต่หลังจากฟังก์ชันใช้การล็อคอีกครั้ง ช่องล็อคจะเพิ่มขึ้น หนึ่ง. หลังจากการคอมไพล์ มีการใช้สล็อตที่ไม่ถูกต้อง ส่งผลให้การล็อก reentrant ล้มเหลว
ด้านซ้ายคือโค้ดที่ถูกโจมตี และด้านขวาคือโค้ดที่ซ่อมแซมแล้ว
คาดว่าผลการทดสอบจะผิด และแน่นอนว่าไม่สามารถตรวจสอบข้อผิดพลาดได้ เพื่อยกตัวอย่างง่ายๆ เรากำลังแก้ไขปัญหาการคำนวณอยู่ในขณะนี้ 1+ 1 = 2 แต่คำตอบมาตรฐานที่ให้มานั้นผิด โดยบอกว่า 1+ 1 = 3 และนี่เพื่อนร่วมชั้นที่ทำคำถามก็ตอบผิดแล้วตอบ 1+ 1 = 3 แต่ก็เหมือนกับคำตอบมาตรฐานที่ให้ไว้ล่วงหน้าดังนั้นโปรแกรมย่อมไม่มีทางตัดสินได้ว่าผลการทดสอบนั้นเป็นอย่างไร ผิด Box กล่าวในการให้สัมภาษณ์กับ BlockBeats
ดาบแห่งดาโมเคิลส์ ถูกแขวนคอเป็นเวลาสองปีในการโจมตีกลับคืนสู่สภาพเดิมครั้งแรกที่บันทึกไว้โจมตีไวส์ โจมตีไวส์
ผู้โจมตีเป็นเพียงแฮกเกอร์ที่จงใจสร้างการโจมตีเพื่อให้นักพัฒนาให้ความสำคัญกับการโจมตีแบบกลับเข้ามาใหม่มากขึ้น เพื่อทำให้โครงการมีภูมิคุ้มกันต่อความเป็นไปได้ของการโจมตีซ้ำมากขึ้น ในบริบทของสัญญาอัจฉริยะ นักพัฒนาควรใช้กลไกทริกเกอร์ที่แตกต่างกัน เช่น การเรียกใช้ฟังก์ชันการเปลี่ยนแปลงสถานะเพื่อให้บรรลุการป้องกัน สิ่งนี้กำหนดให้นักพัฒนาต้องพิจารณาสถานการณ์การโจมตีที่เป็นไปได้อย่างเต็มที่เมื่อออกแบบสัญญาและใช้มาตรการป้องกันที่เหมาะสม
เพื่อให้เข้าใจอย่างลึกซึ้งเกี่ยวกับโปรแกรมแก้ไข Vyper BlockBeats ได้สัมภาษณ์นักวิจัย BTX Derek (@begas_btxcap) เขากล่าวว่าสำหรับนักพัฒนาที่คุ้นเคยกับ Python แล้ว Vyper เป็นตัวเลือกในอุดมคติมากกว่า Solidity โดยมีอินเทอร์เฟซ UI ที่สะดวกสบายกว่าและรวดเร็วกว่า การเรียนรู้. แต่เห็นได้ชัดว่าโค้ดตัวแก้ไข Vyper บางเวอร์ชันยังไม่ได้รับการตรวจสอบโดยบุคคลที่สามที่เชื่อถือได้ แม้แต่งานตรวจสอบบางอย่างก็อาจทำโดยนักพัฒนาเอง “เรื่องแบบนี้จะไม่เกิดขึ้นในอุตสาหกรรมไอทีแบบดั้งเดิม เพราะหลังจากภาษาใหม่ออกมา จะมีบริษัทตรวจสอบบัญชีนับไม่ถ้วนที่มองหาช่องโหว่ของคุณ”
ไม่ต้องพูดถึง ปล่อยให้แมลงมีอยู่อย่างเปิดเผยเป็นเวลาสองปี fubuloubu ผู้สนับสนุน Vyper
ยังกล่าวอีกว่า: คอมไพเลอร์ไม่ได้รับการตรวจสอบหรือตรวจสอบอย่างที่ทุกคนคิด คอมไพเลอร์ส่วนใหญ่มีการเปลี่ยนแปลงที่สำคัญและบ่อยครั้ง ซึ่งทำให้การตรวจสอบมีข้อเสีย แม้ว่าจะมีการตรวจสอบโค้ดเบสเต็มรูปแบบ แต่ก็จะล้าสมัยหากมีการเพิ่มเวอร์ชันเพิ่มเติมหลังจากนั้น การตรวจสอบคอมไพลเลอร์ไม่ใช่ความคิดที่ดี เนื่องจากมีความเหมาะสมมากกว่าที่จะตรวจสอบผลิตภัณฑ์ขั้นสุดท้าย (เช่น รหัส EVM แบบดิบ) ที่สร้างโดยผู้ใช้ปลายทางโดยใช้เครื่องมือ
ทั้งหมดนี้ชี้ให้เห็นถึงปัญหาสุดท้าย นั่นคือ แรงจูงใจ อย่างไรก็ตาม ไม่มีใครมีแรงจูงใจที่จะค้นหาข้อบกพร่องร้ายแรงในคอมไพเลอร์ โดยเฉพาะเวอร์ชันเก่าๆ ก่อนหน้านี้ fubuloubu ได้สร้างข้อเสนอที่จะช่วยปรับปรุง Vyper ด้วยการเพิ่มโปรแกรมค่าหัวที่ผู้ใช้ร่วมสนับสนุน แต่ก็ไม่ผ่าน
แฮกเกอร์กำลังกลับไปสู่ หลักการแรก
นี่เป็นอีกตัวอย่างหนึ่งของแนวทางปฏิบัติในการพัฒนาแบบปลอดภัยตามสัญญาสำหรับนักพัฒนาโปรโตคอลและโครงการ แต่ที่สำคัญที่สุด เหตุการณ์ Curve ทำให้เราทุกคนได้รับคำเตือนว่าความปลอดภัยของคอมไพเลอร์พื้นฐานนั้นถูกเพิกเฉยอย่างจริงจัง และแฮกเกอร์ที่กลับไปสู่ หลักการแรก ก็พบสิ่งที่สมบูรณ์แบบบนคอมไพเลอร์ด้านล่าง ตัดทางเข้า@StaniKulechovหลังจากนั้น Stani ผู้ก่อตั้ง Aave และ Lens (
) ยังโพสต์บทความขนาดยาวบนโซเชียลมีเดียเพื่อแสดงความรู้สึกของเขา: การโจมตี Curve หมายความว่าความเสี่ยงของ DeFi จะเกี่ยวข้องกับสแต็กพื้นฐาน ภาษาการเขียนโปรแกรม EVM ฯลฯ ทั้งหมดเสมอ สิ่งนี้เตือนให้เราระมัดระวังและละเอียดอ่อนมากขึ้น โดยเฉพาะอย่างยิ่งเมื่อใช้ EVM แบบกำหนดเองและสายโซ่แอปพลิเคชันในอนาคต
การโจมตีจากระดับที่ต่ำกว่า
สำหรับช่องโหว่ของคอมไพเลอร์ เป็นการยากที่จะค้นหาโดยการตรวจสอบตรรกะของซอร์สโค้ดสัญญาเท่านั้น การค้นคว้าความแตกต่างระหว่างเวอร์ชันและเวอร์ชันต่างๆ ก็เป็นโครงการขนาดใหญ่เช่นกัน จำเป็นต้องรวมเวอร์ชันของคอมไพลเลอร์เฉพาะเข้ากับรูปแบบโค้ดเฉพาะเพื่อตรวจสอบว่าสัญญาอัจฉริยะได้รับผลกระทบจากช่องโหว่ของคอมไพเลอร์หรือไม่
“ปัจจุบันมีคอมไพเลอร์เพียงสองตัวเท่านั้นที่ดีที่สุด ฐานโค้ดของ Vyper มีขนาดเล็กกว่า อ่านง่ายกว่า และมีการเปลี่ยนแปลงในการวิเคราะห์ประวัติน้อยกว่า ซึ่งอาจเป็นเหตุผลว่าทำไมแฮกเกอร์จึงเริ่มต้นที่นี่ ฐานโค้ดของ Solidity นั้นใหญ่กว่าเล็กน้อย” fubuloubu ยังสงสัยว่ารัฐ- แฮกเกอร์ที่ได้รับการสนับสนุนอาจเกี่ยวข้องกับการโจมตี Curve นี้: “จะใช้เวลาหลายสัปดาห์ถึงหลายเดือนเพื่อค้นหาช่องโหว่ และเมื่อพิจารณาถึงทรัพยากรที่ลงทุนไป มันอาจจะดำเนินการโดยกลุ่มเล็กๆ หรือทีม”
เนื่องจากเป็นภาษาการคอมไพล์ที่ใช้กันอย่างแพร่หลายที่สุดในอุตสาหกรรมการเข้ารหัส ความปลอดภัยของ Solidity จึงเป็นเรื่องที่ผู้ใช้กังวลมากขึ้น ท้ายที่สุด หากคอมไพเลอร์ Solidity มีปัญหาความล้มเหลวในการล็อกซ้ำในครั้งนี้ ประวัติความเป็นมาของอุตสาหกรรม DeFi ทั้งหมดก็อาจมี ที่จะถูกเขียนใหม่ตามการเผยแพร่เป็นประจำโดยทีมพัฒนา Solidityคำเตือนด้านความปลอดภัย
มีช่องโหว่ด้านความปลอดภัยในคอมไพเลอร์ Solidity หลายเวอร์ชัน
จุดบกพร่องของคอมไพเลอร์ล่าสุดที่บันทึกไว้คือวันที่ 26 มิถุนายน ขณะตรวจสอบรายงานความปลอดภัยที่เกี่ยวข้องกับการใช้ abi. error ตัวสร้างโค้ดแบบเก่าไม่ได้ประเมินนิพจน์ที่ซับซ้อน เช่น การมอบหมาย การเรียกใช้ฟังก์ชัน หรือเงื่อนไขที่มีการเข้าถึง .selector ซึ่งทำให้ไม่มีการดำเนินการผลข้างเคียงของนิพจน์ดังกล่าว ดังนั้นสัญญาที่คอมไพล์กับไปป์ไลน์เก่าอาจทำงานไม่ถูกต้องเรายังเห็น Solidity's อีกด้วยพื้นที่เก็บข้อมูล Githubbugs_by_version.jsonไฟล์ถูกวางไว้ใน ซึ่งแสดงรายการจุดบกพร่องที่เกี่ยวข้องกับความปลอดภัยที่ทราบบนคอมไพเลอร์ Solidity รายการกลับไปเป็นเวอร์ชัน 0.3.0 ซึ่งเป็นข้อบกพร่องที่มีอยู่ก่อนเวอร์ชันนี้เท่านั้นที่ไม่อยู่ในรายการ ที่นี่ยังมีอีก
เอกสาร. ไฟล์นี้สามารถใช้เพื่อค้นหาข้อบกพร่องที่คอมไพเลอร์เวอร์ชันใดได้รับผลกระทบ
โชคดีจริงๆ เป็นเพราะการใช้งานภาษา Solidity ในวงกว้างและความช่วยเหลือจาก Ethereum Foundation ทำให้โครงการและโปรโตคอลต่างๆ ชี้ให้เห็นถึงปัญหาที่มีอยู่มากมายในระหว่างกระบวนการปรับใช้ ดังนั้น Solidity จึงทำการปรับเปลี่ยนและปรับปรุงได้เร็วกว่า Vyper เพียงไม่กี่ขั้นตอน จากมุมมองนี้ นี่คือหนึ่งในเหตุผลที่ Solidity จึงมีมาตรฐานและปลอดภัยยิ่งขึ้น
เพื่อช่วยให้นักพัฒนา Solidity ทดสอบได้ดีขึ้นและป้องกันไม่ให้สิ่งเดียวกันเกิดขึ้น SunSec ผู้ร่วมก่อตั้ง UnitasProtocol (@ 1 nf 0 s 3 cpt) เผยแพร่คู่มือการทดสอบความปลอดภัย DeFiVulnLabs Solidity หลังจากการโจมตี Curve ซึ่งรองรับช่องโหว่ 47 ประเภท รวมถึงคำอธิบายช่องโหว่ สถานการณ์ การป้องกัน รหัสช่องโหว่ และมาตรการบรรเทาผลกระทบ และวิธีการทดสอบ .
จะหลีกเลี่ยงการโจมตีระดับต่ำให้ได้มากที่สุดได้อย่างไร?
ในเหตุการณ์ Curve นี้ Box เชื่อว่าความกระจ่างแจ้งสำหรับ Developer ทุกคนคือ: อย่าพยายามตามกระแสเทคโนโลยีและเลือกวิธีแก้ปัญหาที่ยังไม่บรรลุนิติภาวะ อย่าอนุมัติโค้ดของคุณเองโดยไม่เขียน Test Case (Vyper หลายเวอร์ชันที่มีปัญหาแม้แต่ กรณีทดสอบไม่ถูกต้อง) อย่าอนุมัติรหัสของคุณเอง โชคลาภบางอย่างอาจต้องใช้เวลาหลายปีกว่าจะค้นพบ การไม่สามารถอัปเกรดได้ถือเป็นความเย่อหยิ่งต่อตนเองและดูถูกผู้อื่น
โดยปกติแล้ว นักพัฒนาจะไม่คิดถึงข้อผิดพลาดใดๆ ที่นี่ และเลือกเวอร์ชันที่จะคอมไพล์ตามต้องการ ซึ่งอาจมองข้ามความเสี่ยงที่เกิดจากความแตกต่างระหว่างเวอร์ชันต่างๆ แม้แต่การอัปเกรดเวอร์ชันเล็กน้อยก็สามารถทำให้เกิดการเปลี่ยนแปลงที่สำคัญได้ ซึ่งมีความสำคัญอย่างยิ่งเมื่อพัฒนาแอปพลิเคชันแบบกระจายอำนาจ
คำเตือนสำหรับนักพัฒนาจากเหตุการณ์ Curve นี้คือ: ใช้ภาษาคอมไพเลอร์เวอร์ชันที่ใหม่กว่า สิ่งสำคัญคือต้องทำให้โค้ดเบส แอปพลิเคชัน และระบบปฏิบัติการของคุณทันสมัยอยู่เสมอ และเพื่อสร้างการป้องกันความปลอดภัยของคุณเองในทุกด้าน โดยทั่วไปจะมีปัญหาด้านความปลอดภัยที่ทราบน้อยกว่าเวอร์ชันเก่า แม้ว่าเวอร์ชันใหม่กว่าอาจแนะนำปัญหาด้านความปลอดภัยใหม่ก็ตาม แน่นอนว่าเราควรให้ความสนใจกับชุมชนและประกาศอัปเดตเวอร์ชันอย่างเป็นทางการให้ทันเวลา ทำความเข้าใจการเปลี่ยนแปลงที่เกิดขึ้นในแต่ละเวอร์ชัน และอัปเดตฐานโค้ดและสภาพแวดล้อมการทำงานของคุณเองตามความจำเป็น การทำตามขั้นตอนเหล่านี้อาจลดเหตุการณ์ด้านความปลอดภัยที่เกิดจากจุดบกพร่องของคอมไพเลอร์ได้อย่างมาก
นอกจากนี้หน่วยทดสอบกรณีให้กรอกรหัส ข้อผิดพลาดระดับคอมไพเลอร์ส่วนใหญ่จะนำไปสู่ผลลัพธ์การเรียกใช้โค้ดที่ไม่สอดคล้องกัน ซึ่งหาได้ยากจากการตรวจสอบโค้ดเท่านั้น แต่สามารถเปิดเผยได้ในการทดสอบ การปรับปรุงความครอบคลุมของโค้ดสามารถช่วยหลีกเลี่ยงปัญหาดังกล่าวได้ และพยายามหลีกเลี่ยงการใช้คุณลักษณะภาษาที่ซับซ้อน เช่น แอสเซมบลีแบบอินไลน์และการเข้ารหัสและถอดรหัสอาเรย์หลายมิติ เว้นแต่จะมีความจำเป็นที่ชัดเจน ในอดีตช่องโหว่ของภาษา Solidity ส่วนใหญ่เกี่ยวข้องกับฟีเจอร์ขั้นสูงเหล่านี้ นักพัฒนาควรหลีกเลี่ยงการใช้ฟีเจอร์ภาษาทดลองเพื่ออวดโดยไม่จำเป็น
แน่นอนว่าเราไม่จำเป็นต้องตื่นตระหนกมากเกินไปเกี่ยวกับความเสี่ยงของโครงสร้างพื้นฐานที่สำคัญ ในปัจจุบัน จุดบกพร่องของคอมไพเลอร์ส่วนใหญ่จะทริกเกอร์เฉพาะในรูปแบบโค้ดที่เฉพาะเจาะจงเท่านั้น และผลกระทบที่เกิดขึ้นจริงจำเป็นต้องได้รับการประเมินตามสถานการณ์ของโครงการ การอัพเกรดเวอร์ชันคอมไพเลอร์เป็นประจำและการทดสอบหน่วยที่เพียงพอสามารถช่วยป้องกันความเสี่ยงได้
เนื้อหาอ้างอิง:
2.https://github.com/pcaversaccio/reentrancy-attacks/issues/1
3.https://nipunp.medium.com/5-8-21-rari-capital-exploit-timeline-analysis-8beda31cbc1a
4.https://docs.Soliditylang.org/en/v0.8.21/
