อธิบายการโจมตี Reentrancy ในสัญญาอัจฉริยะ

ช่องโหว่ที่อาจเกิดขึ้นในสัญญาอัจฉริยะ

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

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

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

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

การโจมตีซ้ำในสัญญาอัจฉริยะคืออะไร

“การโจมตีซ้ำเกิดขึ้นในสัญญาอัจฉริยะเมื่อสัญญาทำการเรียกภายนอกไปยังสัญญาหรือฟังก์ชันอื่น ๆ ก่อนที่จะทำการแก้ไขสถานะของตนเองให้เสร็จสิ้น”

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

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

ในปี 2559 มีเหตุการณ์ฉาวโฉ่ที่เกี่ยวข้องกับองค์กรอิสระแบบกระจายอำนาจ (DAO) บนบล็อกเชน Ethereum แฮกเกอร์ใช้ประโยชน์จากช่องโหว่ในโค้ดสัญญาอัจฉริยะที่เรียกว่าการโจมตีซ้ำ ทำให้พวกเขาสามารถระบายเงินทุนจาก DAO ซ้ำๆ ได้ ผลที่ตามมาคือการสูญเสีย Ether (ETH) มูลค่าหลายล้านดอลลาร์

อธิบายการโจมตี Reentrancy ในสัญญาอัจฉริยะ

นอกจากนี้ แพลตฟอร์มการเงินแบบกระจายอำนาจ (DeFi) ต่างๆ เช่น Uniswap, Lendf.Me, BurgerSwap, SURGEBNB, Cream Finance และ Siren Protocol ประสบปัญหาทางการเงินจำนวนมากเนื่องจากการโจมตีซ้ำ ความเสียหายที่เกิดจากการบุกรุกเหล่านี้มีมูลค่าตั้งแต่ 3.5 ล้านดอลลาร์ถึง 25 ล้านดอลลาร์ โดยเน้นถึงความเสี่ยงอย่างต่อเนื่องของจุดอ่อนในการกลับเข้ามาใหม่ในภาค DeFi

การโจมตีซ้ำทำงานอย่างไร

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

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

อธิบายการโจมตี Reentrancy ในสัญญาอัจฉริยะ

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

เรามาดูรายละเอียดวิธีการทำงานของการโจมตีซ้ำโดยใช้ตัวอย่างง่ายๆ:

สัญญาอัจฉริยะพร้อมฟังก์ชัน “ถอนเงิน”

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

การโต้ตอบของผู้ใช้และการดำเนินการฟังก์ชัน

ผู้ใช้เริ่มการถอนเงินจากกระเป๋าเงินดิจิทัลอย่างอิสระ ด้วยการใช้ฟังก์ชันถอนเงิน พวกเขาจะป้อนจำนวนเงินที่ระบุที่ต้องการถอนออก

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

โทรภายนอก

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

โทรซ้ำ

หากรหัสของสัญญาภายนอกมีฟังก์ชันที่ทำให้สามารถเรียกใช้สัญญาเริ่มต้นได้อีกครั้ง เช่น ฟังก์ชัน “ถอนออก” ที่กำหนดไว้ใหม่ การตั้งค่านี้จะส่งผลให้เกิดการวนซ้ำแบบเรียกซ้ำ ด้วยเหตุนี้จึงสามารถเรียกใช้วิธี “ถอนออก” ซ้ำๆ ได้ก่อนที่จะดำเนินการเสร็จสิ้น

การแสวงประโยชน์กลับเข้ามาใหม่

ในฐานะนักวิจัยที่ศึกษาสัญญาอัจฉริยะ ฉันได้พบช่องโหว่ที่อาจเกิดขึ้นในการใช้งานกระเป๋าเงินบางประเภท ฝ่ายตรงข้ามสามารถใช้ประโยชน์จากสิ่งนี้โดยการสร้างสัญญาที่เป็นอันตรายและใช้ประโยชน์จากวงจรในการทำงานของกระเป๋าเงิน ต่อไปนี้เป็นวิธีเปิดเผย:

ฟังก์ชันสำรอง

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

การจัดการของรัฐและการถอนเงินซ้ำแล้วซ้ำเล่า

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

ผลที่ตามมาของการโจมตีซ้ำ

ผู้ใช้สัญญาอัจฉริยะเผชิญกับความเสี่ยงที่สำคัญจากการโจมตีซ้ำเนื่องจากอาจเกิดการสูญเสียทางการเงินจำนวนมาก

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

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

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

วิธีบรรเทาการโจมตีซ้ำ

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

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

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

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

Sorry. No data so far.

2024-05-16 15:45