โปรโตคอล DeFi Abracadabra สูญเสียเงิน 1.8 ล้านดอลลาร์
โปรโตคอล DeFi Abracadabra สูญเสียเงิน 1.8 ล้านดอลลาร์ หลังจากที่ผู้โจมตีใช้ประโยชน์จากข้อผิดพลาดทางตรรกะที่ง่ายในฟังก์ชันแบตช์ของมัน นักวิเคราะห์จาก Hacken กล่าวว่าผู้โจมตีได้ฟอกเงินผ่าน Tornado Cash แล้ว
การโจมตีและการฟอกเงิน
ในต้นเดือนตุลาคม Abracadabra ซึ่งเป็นโปรโตคอลการให้ยืม DeFi ที่อนุญาตให้ผู้คนยืมเหรียญ stablecoin MIM โดยใช้โทเค็นที่ฝากเป็นหลักประกัน เคยประสบกับการโจมตีจากแฮ็กเกอร์หลายครั้ง ก่อนหน้านี้โปรโตคอลนี้สูญเสียเงินประมาณ 1.8 ล้านดอลลาร์ อีกครั้ง หลังจากที่ผู้โจมตีใช้ข้อผิดพลาดทางตรรกะในฟังก์ชันแบตช์ของโปรโตคอลเพื่อยืมโดยไม่ต้องวางหลักประกัน
“ผู้โจมตีใช้ประโยชน์จากข้อบกพร่องทางตรรกะในฟังก์ชันการทำอาหารของ Abracadabra ซึ่งพวกเขาสามารถยืมโทเค็น MIM และจากนั้นรีเซ็ตธงการตรวจสอบความถูกต้องที่ควรตรวจสอบว่าพวกเขามีหลักประกันเพียงพอหรือไม่”
การทำงานของระบบ
ระบบนี้ประกอบด้วยสองส่วน: Cauldrons ซึ่งจัดการกฎการยืม และ DegenBox ซึ่งเป็นห้องเก็บรวมที่เก็บโทเค็นจริงๆ สั้นๆ คือ คุณวางหลักประกันใน Cauldron และ DegenBox จะติดตามเงินในเบื้องหลัง
เวอร์ชันสั้นของสิ่งที่ผิดพลาดคือ: ธงความปลอดภัยที่ควรบังคับให้มีการตรวจสอบขั้นสุดท้ายว่าผู้ยืมมีหลักประกันจริงหรือไม่ ถูกปิดในธุรกรรมเดียว
วิธีการโจมตี
นักวิเคราะห์กล่าวว่าผู้โจมตีโจมตี Cauldrons หกตัวในครั้งเดียว โดยนำ MIM ประมาณ 1.79 ล้านตัว และแลกเปลี่ยนเป็น ETH ผู้โจมตีใช้ประโยชน์จากช่องโหว่และดำเนินการผ่าน Cauldrons หกตัวอย่างเป็นระบบและระบายแต่ละตัว “โดยใช้เทคนิคเดียวกันกับการเรียกฟังก์ชันการทำอาหารที่กำหนด”
การฟอกเงินผ่าน Tornado Cash
หลังจากการแลกเปลี่ยน ผู้โจมตีได้ส่งเงินผ่าน Tornado Cash ซึ่งเป็นโปรโตคอลการผสม crypto โดยส่วนใหญ่ 10 ETH ต่อครั้ง ส่งไปเรื่อยๆ ในวันถัดไป
ปัญหาที่เกิดขึ้นกับ CauldronV4
และนี่ไม่ใช่ครั้งแรกที่โค้ด CauldronV4 ของ Abracadabra เกี่ยวข้องกับปัญหา เหตุการณ์อื่นๆ ในปีนี้ใช้กรณีขอบที่แตกต่างกันในสัญญาเดียวกัน
สิ่งที่น่าสนใจในตอนนี้คือการตอบสนองของการปรับฟอร์คอย่างรวดเร็ว ตามรายงาน ฟอร์คที่เรียกว่า Synnax ได้หยุดหรือไม่อนุญาตให้ใช้ CauldronV4 master ของตนใน DegenBox ของตนเองไม่กี่วันก่อนการระบายของ Abracadabra
ดังนั้นโดยพื้นฐานแล้วทีมฟอร์คได้ดึงเบรกฉุกเฉินหลังจากสังเกตเห็นรูปแบบที่อ่อนแอเดียวกัน ซึ่งแสดงให้เห็นว่าความเสี่ยงนั้นมองเห็นได้สำหรับทีมที่เฝ้าดูโค้ด แม้ว่าจะไม่ได้รับการแก้ไขก็ตาม
