ระบบนิเวศของ Cosmos ซึ่งมีชื่อเสียงไปทั่วโลกในฐานะหนึ่งในเครือข่ายบล็อกเชนที่ใหญ่ที่สุดและโดดเด่นที่สุดให้ความสําคัญกับการทํางานร่วมกันของบล็อกเชน การมุ่งเน้นนี้เป็นกุญแจสําคัญในการอํานวยความสะดวกในการสื่อสารที่ราบรื่นระหว่างบล็อกเชนที่หลากหลาย ระบบนิเวศเป็นที่ตั้งของโครงการชั้นนําหลายโครงการเช่น Celestia และ dYdX v4 ซึ่งทั้งหมดได้รับการพัฒนาโดยใช้โปรโตคอล Cosmos SDK และ IBC ความต้องการที่เพิ่มขึ้นของนักพัฒนาสําหรับส่วนประกอบของ Cosmos ได้นําไปสู่ผลกระทบที่เพิ่มขึ้นของปัญหาด้านความปลอดภัยภายในระบบนิเวศ กรณีในประเด็นคือช่องโหว่ของ Dragonfruit ใน Cosmos SDK ซึ่งขัดขวางการดําเนินงานในบล็อกเชนสาธารณะกระแสหลักจํานวนมาก

ด้วยลักษณะการกระจายอํานาจของส่วนประกอบหลักของ Cosmos นักพัฒนามักจะต้องปรับตัวและขยายส่วนประกอบเหล่านี้ตามความต้องการในการทํางานเฉพาะ สิ่งนี้นําไปสู่การกระจายตัวของความท้าทายด้านความปลอดภัยภายในระบบนิเวศของ Cosmos ดังนั้นจึงมีความจําเป็นเร่งด่วนสําหรับแนวทางที่มีโครงสร้างเพื่อทําความเข้าใจและจัดการกับข้อกังวลด้านความปลอดภัยเหล่านี้ บทความนี้มีจุดมุ่งหมายเพื่อให้การวิเคราะห์ที่ครอบคลุมเกี่ยวกับภูมิทัศน์ความปลอดภัยในปัจจุบันในระบบนิเวศของ Cosmos และเพื่อร่างกลยุทธ์การตอบสนองที่มีประสิทธิภาพ

ทีม CertiK มุ่งมั่นที่จะเสริมความปลอดภัยของเครือข่าย Cosmos และระบบนิเวศ Web3 ทั่ว ๆ ไปผ่านการวิจัยและพัฒนาต่อเนื่อง เราตื่นเต้นที่จะแบ่งปันข้อความและความเข้าใจกับคุณผ่านรายงานความปลอดภัยและอัปเดตการวิจัยเทคนิคเป็นประจำ หากคุณมีคำถาม ทีมของเราพร้อมให้บริการตลอดเวลา

นี่คือข้อความเต็มของ “คู่มือด้านความปลอดภัยของระบบนิวเคลียร์” 👇.

ภาพรวมของ Cosmos

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

Cosmos มีความแตกต่างโดยการนำเสนอโมเดล cross-chain ที่มีประสิทธิภาพ โดยเฉพาะอย่างยิ่งสำหรับโซลูชัน public chains ที่เน้นไปที่ด้านบนทางแนวตั้งเฉพาะ โครงสร้างพื้นฐาน blockchain แบบโมดูลาร์ของมัน ทำให้นักพัฒนาระบบประยุกต์สามารถเลือกและใช้โซลูชัน public chains ที่สอดคล้องกับความต้องการของพวกเขาได้อย่างยืดหยุ่น

ที่ใจกลางของนิเวศ Cosmos คือโปรโตคอล Inter-Blockchain Communication (IBC) ซึ่งเชื่อมต่อแอพพลิเคชันและโปรโตคอลที่ต่างกันบนบล็อกเชนอิสริยะ สิ่งนี้ทำให้การโอนทรัพย์และข้อมูลเป็นไปอย่างไร้รอยต่อและสอดคล้องกับวิสัยกรรมของ Cosmos ในการสร้าง 'อินเทอร์เน็ตของบล็อกเชน' แนวคิดนี้มองเห็นถึงเครือข่ายที่กว้างขวางของบล็อกเชนที่เป็นอิสระและสามารถพัฒนาได้อย่างง่าย ที่ถูกเชื่อมโยงเพื่อการขยายออกและการโต้ตอบ

การมีส่วนร่วมและการวิจัยของ CertiK ในด้านความปลอดภัยของ Cosmos

เป็นระยะเวลานาน CertiK มีส่วนร่วมอย่างลึกซึ้งในการวิจัยระบบนิเวศของ Cosmos ทีมงานของเราได้รับประสบการณ์มากมายในการจัดการกับความท้าทายด้านความปลอดภัยภายในสภาพแวดล้อมนี้ ในรายงานนี้ เราจะแบ่งปันข้อมูลเชิงลึกและการค้นพบของเราเกี่ยวกับความปลอดภัยของระบบนิเวศของ Cosmos โดยมุ่งเน้นไปที่สี่ประเด็นสําคัญ: การรักษาความปลอดภัย Cosmos SDK, ความปลอดภัยของโปรโตคอล IBC, ความปลอดภัยของ CometBFT และการรักษาความปลอดภัย CosmWasm การอภิปรายของเราจะครอบคลุมทุกอย่างตั้งแต่องค์ประกอบพื้นฐานของระบบนิเวศ Cosmos ไปจนถึงห่วงโซ่พื้นฐานและแอปพลิเคชัน โดยการตรวจสอบและคาดการณ์ปัญหาที่เกี่ยวข้องเรามุ่งมั่นที่จะนําเสนอการวิเคราะห์ที่ครอบคลุมจากล่างขึ้นบนของด้านความปลอดภัยที่สําคัญภายในระบบนิเวศของ Cosmos

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

พื้นหลัง

CometBFT: การเพิ่มประสิทธิภาพในการขยายขอบเขตของ Cross-Chain ที่รากฐานของมัน

ที่ใจกลางของความยืดหยุ่นของโตรงการ Interchain ตั้งอยู่ที่ CometBFT, อัลกอริทึมคอนเซนซัสขั้นสูงที่สำคัญสำหรับการรักษาความปลอดภัย การกระจายอำนวยความสะดวกและความสมบูรณ์ของระบบนิเวศ Interchain อัลกอริทึมนี้เป็นภาพรวมของสองส่วนหลัก: คอร์ของ CometBFT ซึ่งทำหน้าที่เป็นเครื่องยนต์คอนเซนซัสพื้นฐาน และอินเทอร์เฟซบล็อกเชนแอปพลิเคชันยูนิเวอร์แซล (ABCI) โดยผสมผสานองค์ประกอบของ PBFT (Practical Byzantine Fault Tolerance) และ Bonded Proof of Stake (PoS) CometBFT ทำให้โหนดซิงโครไนส์เพื่อรักษาบันทึกธุรกรรมที่แม่นยำ ดังนั้นมีบทบาทสำคัญในการตัดสินใจของผู้ตรวจสอบในสภาวะ Interchain

Cosmos SDK: การเร่งความเร็วในการพัฒนาบล็อกเชนด้วยความเป็นโมดูล

Cosmos SDK เป็นชุดเครื่องมืออันทรงพลังที่ช่วยลดความซับซ้อนและเร่งการพัฒนาบล็อกเชน การออกแบบโมดูลาร์และคุณสมบัติแบบเสียบได้ช่วยให้นักพัฒนาสามารถสร้างบล็อกเชนหรือส่วนประกอบการทํางานของตนเองบนอัลกอริธึมฉันทามติของ CometBFT วิธีการนี้ไม่เพียง แต่ช่วยให้การพัฒนาง่ายขึ้น แต่ยังทําให้วงจรการพัฒนาสั้นลงอย่างมาก ประสิทธิภาพของ SDK เป็นหลักฐานจากการยอมรับในหลายโครงการรวมถึง Cronos, Kava และ dYdX V4 ที่เพิ่งเปิดตัว เมื่อมองไปข้างหน้า Cosmos SDK วางแผนที่จะปรับปรุงความเป็นโมดูลาร์และแนะนําคุณสมบัติใหม่ ๆ ทําให้สามารถสร้างแอปพลิเคชันที่ซับซ้อนและแยกส่วนได้มากขึ้นซึ่งจะช่วยบํารุงระบบนิเวศที่กว้างขวางและแข็งแกร่งยิ่งขึ้น

โปรโตคอล IBC: ขับเคลื่อนความสามารถในการทำงานร่วมกันและขยายขอบของบล็อกเชน

โปรโตคอล Inter-Blockchain Communication (IBC) มีความสําคัญในการอํานวยความสะดวกในการถ่ายโอนข้อมูลที่ปลอดภัยกระจายอํานาจและไม่ได้รับอนุญาตระหว่างบล็อกเชนภายในเครือข่าย Cosmos เนื่องจาก Cosmos เป็นเครือข่ายแบบกระจายอํานาจที่ประกอบด้วยบล็อกเชนอิสระและขนานหลายตัวที่เชื่อมต่อผ่านเทคโนโลยีรีเลย์บทบาทของโปรโตคอล IBC ในการเพิ่มความสามารถในการปรับขนาดและการทํางานร่วมกันจึงเป็นศูนย์กลาง จุดสนใจในปัจจุบันของ Interchain Foundation คือการปรับปรุงแง่มุมเหล่านี้ของโปรโตคอล IBC โดยมีเป้าหมายเพื่อส่งเสริมการโต้ตอบที่ราบรื่นในบล็อกเชน แอปพลิเคชัน และสัญญาอัจฉริยะภายในระบบนิเวศของ Cosmos

CosmWasm: สะดวกในการใช้ในการติดตั้งแอปพลิเคชันแบบกระจาย

CosmWasm (Cosmos WebAssembly) เป็นกรอบสัญญาอัจฉริยะที่ออกแบบมาสำหรับนิเวศ Cosmos โดยใช้ WebAssembly ทำให้นักพัฒนาสามารถ implement แอปพลิเคชันที่ไม่ต้องการการอนุญาตใน blockchain ได้ กรอบงานนี้ช่วยให้นักพัฒนา blockchain สามารถแยกการพัฒนาผลิตภัณฑ์จากการพัฒนา blockchain ลดภาระในการอัพเกรด validator ฟีเจอร์ของ CosmWasm รวมถึงโครงสร้างโมดูลาร์ การบูรณาการกับ Cosmos SDK และความสามารถในการสื่อสารข้ามเชน Cosmos SDK และโปรโตคอล IBC ซึ่งเป็นเทคโนโลยีที่ค่อนข้างเจริญรุ่งเรื่องในนิเวศ Cosmos ปัจจุบัน

การปรับปรุงและปรับแต่งภายในระบบนิทรรศการ

สําหรับนักพัฒนาโซ่ในระบบนิเวศของ Cosmos Cosmos SDK ตอบสนองความต้องการในการปรับแต่งส่วนใหญ่ ในระหว่างกิจกรรมข้ามสายโซ่นักพัฒนาห่วงโซ่อาจปรับแต่งโมดูล IBC สําหรับปฏิบัติการพิเศษหรือการเพิ่มประสิทธิภาพ ในขณะที่โซ่บางตัวปรับเปลี่ยนเครื่องยนต์พื้นฐานเช่น CometBFT Core ข้อ จํากัด ด้านพื้นที่ขัดขวางการอภิปรายโดยละเอียดเกี่ยวกับการปรับเปลี่ยนดังกล่าวในรายงานนี้ ดังนั้นการวิจัยนี้จึงมุ่งเน้นไปที่ความแตกต่างทางเทคนิคและการพิจารณาด้านความปลอดภัยของ Cosmos SDK และโปรโตคอล IBC เป็นหลัก

คู่มือความปลอดภัยของ Cosmos SDK

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

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

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

จุดศูนย์กลางภายใน Cosmos SDK คืออินเทอร์เฟซ ABCI ซึ่งเป็นส่วนสำคัญของนิเวศ Cosmos อินเทอร์เฟซนี้ประกอบด้วยสี่ส่วนหลัก: BeginBlock, EndBlock, CheckTx และ DeliverTx BeginBlock และ EndBlock มีส่วนร่วมโดยตรงในตรรกะการกระทำของบล็อกแต่ละอัน ในทวิติกับการกระทำของ CheckTx และ DeliverTx ที่เกี่ยวข้องกับการประมวลผล sdk.Msg โครงสร้างข้อมูลรากฐานสำหรับการส่งข้อความภายในนิเวศ Cosmos

เพื่อทําความเข้าใจและแก้ไขช่องโหว่ด้านความปลอดภัยที่กล่าวถึงก่อนอื่นเราต้องเข้าใจวงจรชีวิตของธุรกรรมในระบบนิเวศของ Cosmos ธุรกรรมมาจากตัวแทนผู้ใช้ซึ่งถูกสร้างขึ้นลงนามแล้วออกอากาศไปยังโหนดบล็อกเชน โหนดใช้วิธี CheckTx เพื่อตรวจสอบรายละเอียดธุรกรรม เช่น ลายเซ็น ยอดคงเหลือของผู้ส่ง ลําดับธุรกรรม และก๊าซที่ให้มา ธุรกรรมที่ถูกต้องจะถูกจัดคิวใน mempool รอการรวมไว้ในบล็อกในขณะที่ธุรกรรมที่ไม่ถูกต้องจะถูกปฏิเสธโดยมีข้อความแสดงข้อผิดพลาดที่ส่งต่อไปยังผู้ใช้ ในระหว่างการประมวลผลบล็อกจะใช้วิธีการ DeliverTx เพื่อให้แน่ใจว่ามีความสอดคล้องและการกําหนดธุรกรรม

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

1. การสร้างธุรกรรม: ผู้ใช้สร้างธุรกรรมโดยใช้เครื่องมือต่าง ๆ เช่น Command Line Interfaces (CLI) หรือลูกค้าฝั่งหน้า.

2. เพิ่มเข้า Mempool: เมื่อสร้างแล้วธุรกรรมจะเข้าสู่ mempool ที่นี่โหนดส่งข้อความ ABCI (Application BlockChain Interface) หรือที่เรียกว่า CheckTx ไปยังเลเยอร์แอปพลิเคชันเพื่อตรวจสอบความถูกต้อง ธุรกรรมผ่านการถอดรหัสจากรูปแบบไบต์เป็นรูปแบบ Tx แต่ละ sdk ข่าวสารภายในธุรกรรมอยู่ภายใต้การตรวจสอบแบบไร้สถานะเบื้องต้นโดยฟังก์ชัน ValidateBasic() นอกจากนี้ ถ้าโปรแกรมประยุกต์มี anteHandler ตรรกะของมันจะถูกดําเนินการก่อนฟังก์ชัน runTx ซึ่งนําไปสู่ฟังก์ชัน RunMsgs() สําหรับการประมวลผล sdk เนื้อหาข่าวสาร CheckTx ที่ประสบความสําเร็จส่งผลให้ธุรกรรมถูกจัดคิวใน mempool ท้องถิ่นพร้อมที่จะรวมไว้ในบล็อกถัดไปและออกอากาศไปยังโหนดเพียร์พร้อมกันผ่าน P2P

3. การรวมอยู่ในบล็อกที่เสนอ: ในตอนเริ่มต้นของรอบแต่ละรอบ ผู้เสนอจะรวบรวมบล็อกที่มีธุรกรรมล่าสุด ผู้ตรวจสอบซึ่งรับผิดชอบในการรักษาความเห็นอนุมัติบล็อกนี้หรือเลือกบล็อกว่าง

4. การเปลี่ยนแปลงสถานะ: คล้ายกับ CheckTx กระบวนการ DeliverTx จะวนซ้ําผ่านธุรกรรมบล็อก อย่างไรก็ตามมันทํางานในโหมด 'ส่งมอบ' โดยดําเนินการเปลี่ยนแปลงสถานะ MsgServiceRouter นําข้อความธุรกรรมที่แตกต่างกันไปยังโมดูลที่เกี่ยวข้อง ซึ่งแต่ละข้อความจะถูกประมวลผลในเซิร์ฟเวอร์ข่าวสารเกี่ยวกับ หลังจากดําเนินการข้อความการตรวจสอบเพิ่มเติมเพื่อให้แน่ใจว่าการทําธุรกรรมถูกต้อง หากการตรวจสอบใด ๆ ล้มเหลวรัฐจะเปลี่ยนกลับเป็นเงื่อนไขก่อนหน้า เครื่องวัดก๊าซจะติดตามก๊าซที่ใช้แล้วระหว่างการดําเนินการ ข้อผิดพลาดที่เกี่ยวข้องกับก๊าซเช่นก๊าซไม่เพียงพอนําไปสู่การพลิกกลับของการเปลี่ยนแปลงสถานะคล้ายกับความล้มเหลวในการดําเนินการ

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

)

[ส่วนนี้รวมถึงแผนภาพที่เป็นเรื่องเกี่ยวกับวงจรชีวิตของธุรกรรมในระบบนิพจน์]

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

)

หมวดหมู่ของช่องโหว่ทั่วไป

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

)

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

1. การดำเนินการหยุดโซ่
2. ความสูญเสียทางการเงิน
3. มีผลต่อสถานะของระบบหรือการทำงานปกติ

สาเหตุของความเสี่ยงเหล่านี้มักเป็นประเภทของช่องโหว่ด้านความปลอดภัยต่อไปนี้:

1. การปฏิเสธบริการ
2. การตั้งค่าสถานะไม่ถูกต้อง
3. ขาดหรือการตรวจสอบที่ไม่เหมาะสม
4. ปัญหาความเป็นเอกลักษณ์
5. ปัญหาของอัลกอริทึมความเห็นร่วม
6. ข้อบกพร่องทางตรรกะในการดำเนินการ
7. ปัญหาคุณลักษณะของภาษา

การวิเคราะห์ช่องโหว่ในระบบนิทรรศการของจักรวาล

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

การทำงานหยุดทราบ: สาเหตุและประเภท

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

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

Cosmos SDK และ CometBFT, โครงสร้างพื้นฐานสำคัญในระบบนิเวศ Cosmos, ไม่ใช่เพียงแค่ถูกใช้โดยเชื่อมโยงเริ่มต้นใน Cosmos แต่ยังใช้โดยโซ่แอปพลิเคชันต่าง ๆ ที่มีพื้นฐานสถาปัตยกรรมของตน. ทั้งหมดเขาตามกฎของอินเตอร์เฟซ ABCI ของ CometBFT. จุดศักดิ์สิทธิ์ของพื้นที่โจมตีของพวกเขายังอยู่ที่อินเตอร์เฟซ ABCI ของพวกเขา, และปัญหาความปลอดภัยส่วนใหญ่ที่สามารถทำให้โซ่หยุดทำงานเป็นปัญหาที่สามารถส่งผลตรงต่อการประมวลผลรหัสบล็อก. ดังนั้น, สายทางการเกิดขึ้นของพวกเขาสามารถสามารถทำการตรวจสอบได้โดยทั่วไปที่ BeginBlock และ EndBlock อินเตอเฟซ.

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

ตัวอย่างของชนิดแรก

ตัวอย่าง 1: การวิเคราะห์ช่องโหว่โปรเจกต์ SuperNova

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

ตำแหน่งช่องโหว่: SuperNova GitHub Link

โค้ดที่มีช่องโหว่:

เส้นทางเริ่มต้นของช่องโหว่:

BeginBlocker (/x/mint/keeper/abci.go)

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)

การแก้ไขช่องโหว่:

https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0

แพทช์ตั้งอยู่ในโมดูลการจัดการข้อความของ poolincentive (x/poolincentive/types/msgs.go) ไม่ใช่โมดูล mint มันเพิ่มการตรวจสอบที่อยู่ในข้อความ MsgCreateCandidatePool เพื่อกำจัดความเป็นไปได้ของที่อยู่ที่ไม่ถูกต้องจาก root

ตัวอย่าง 2: โคสมอส โครงการด้านความปลอดภัยระหว่างเชื่อม

Project address: Cosmos Interchain Security GitHub Link

พื้นหลังช่องโหว่: ผู้ตรวจสอบความถูกต้องสามารถทําให้ห่วงโซ่ผู้ให้บริการช้าลงโดยการส่งข้อความ AssignConsumerKey หลายข้อความในบล็อกเดียวกัน ในไฟล์ x/ccv/provider/keeper/key_assignment.go ฟังก์ชัน AssignConsumerKey ช่วยให้ผู้ตรวจสอบสามารถกําหนด consumerKeys ที่แตกต่างกันให้กับเครือข่ายผู้บริโภคที่ได้รับอนุมัติ ผู้บริโภค AddrsToPrune AddressList เพิ่มขึ้นโดยองค์ประกอบหนึ่งเพื่อดําเนินการนี้ เนื่องจาก AddressList นี้ถูกทําซ้ําใน EndBlocker ใน x / ccv / provider / keeper / relay.go ผู้โจมตีสามารถใช้ประโยชน์จากมันเพื่อทําให้ห่วงโซ่ผู้ให้บริการช้าลง สําหรับการโจมตีนี้ผู้ประสงค์ร้ายสามารถสร้างธุรกรรมด้วยข้อความ AssignConsumerKey หลายข้อความและส่งไปยังเครือข่ายผู้ให้บริการ ความสําคัญของ consumerAddrsToPrune AddressList จะเหมือนกับข้อความ AssignConsumerKey ที่ส่ง ดังนั้นการดําเนินการของ EndBlocker จะใช้เวลาและทรัพยากรมากกว่าที่คาดไว้ชะลอตัวลงหรือแม้กระทั่งหยุดห่วงโซ่ผู้ให้บริการ

ตำแหน่งของความเป็นอยู่ที่มีช่องโหว่: ลิงก์ GitHub ของความปลอดภัยระหว่างโซมอส

รหัสช่วงช่องโหว่:

เส้นทางที่เปิดโอกาสให้เกิดช่องโหว่:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

EndBlockCIS

การจัดการแพ็คเกจที่เกิดขึ้นและถูกใช้งานไปแล้ว

HandleVSCMaturedPacket

PruneKeyAssignments

ตัวอย่าง 3: โครงการ Quicksilver - โมดูลการแจกจ่าย

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

ตำแหน่งของช่องโหว่: ลิงค์ Quicksilver GitHub

โค้ดช่วงช่องโหว่:

การซ่อมแซมช่องโหว่: AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

การซ่อมแซมช่องโหว่: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16

รหัสการจัดการความตื่นตระหนกถูกนำออกและถูกแทนที่ด้วยการบันทึกข้อผิดพลาด

ตัวอย่าง 4: โคสมอส โปรเจกต์ความปลอดภัยระบบร่วมสาย

Project address: Cosmos Interchain Security GitHub Link

พื้นหลังช่องโหว่: ผู้โจมตีสามารถทําการโจมตีแบบปฏิเสธการให้บริการได้โดยการส่งโทเค็นหลายรายการไปยังที่อยู่รางวัลของห่วงโซ่ผู้ให้บริการ ในขั้นตอนการดําเนินการ EndBlocker ของห่วงโซ่ผู้บริโภคฟังก์ชัน SendRewardsToProvider ที่กําหนดไว้ใน x / ccv / consumer / keeper / distribution.go จะดึงยอดคงเหลือของโทเค็นทั้งหมดใน tstProviderAddr และส่งไปยังห่วงโซ่ผู้ให้บริการ เพื่อให้บรรลุเป้าหมายนี้จะต้องทําซ้ําผ่านโทเค็นทั้งหมดที่พบในที่อยู่รางวัลและส่งแต่ละโทเค็นผ่าน IBC ไปยังเครือข่ายผู้ให้บริการ เนื่องจากทุกคนสามารถส่งโทเค็นไปยังที่อยู่รางวัลผู้โจมตีจึงสามารถสร้างและส่งโทเค็น denom ที่แตกต่างกันจํานวนมากเช่นใช้โซ่ที่มีโมดูลโรงงานโทเค็นเพื่อเริ่มการโจมตีแบบปฏิเสธการให้บริการ ดังนั้นการดําเนินการของ EndBlocker จะใช้เวลาและทรัพยากรมากกว่าที่คาดไว้ชะลอตัวลงหรือแม้กระทั่งหยุดห่วงโซ่ผู้บริโภค

ตำแหน่งช่องโหว่: Cosmos Interchain Security ลิงก์ GitHub

โค้ดช่วงช่องโหว่:

เส้นทางการเรียกใช้ช่องโหว่:

AppModule.EndBlock

EndBlock

EndBlockRD

ส่งรางวัลไปยังผู้ให้บริการ

สถานการณ์ประเภทที่สอง

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

ตัวอย่าง 1

ประวัติความเป็นอันตราย: คำแนะนำด้านความปลอดภัยของ Cosmos SDK Jackfruit

พฤติกรรมที่ไม่แน่นอนในวิธีการ ValidateBasic ของโมดูล x/authz ใน Cosmos SDK สามารถทำให้การยอมรับหยุดได้อย่างง่ายดาย โครงสร้างข้อความ MsgGrant ในโมดูล x/authz ประกอบด้วยฟิลด์ Grant ซึ่งประกอบด้วยเวลาหมดอายุที่ได้รับจากการอนุญาตที่กำหนดโดยผู้ใช้ ในกระบวนการตรวจสอบของ ValidateBasic() ในโครงสร้าง Grant มันเปรียบเทียบข้อมูลเวลาของมันกับข้อมูลเวลาท้องถิ่นของโหนด แทนที่ข้อมูลเวลาบล็อก โดยที่เวลาท้องถิ่นเป็นเวลาที่ไม่แน่นอน แท้จริงแล้ว ไทม์สแทมป์อาจแตกต่างกันระหว่างโหนด ซึ่งทำให้เกิดปัญหาในการยอมรับ

ประกาศช่องโหว่:

• Cosmos Forum Link 1

• Cosmos Forum Link 2

• Cosmos SDK GitHub ลิงก์คำแนะนำด้านความปลอดภัย

โค้ดช่วงช่องโหว่:

การแก้ไขช่องโหว่: ลิงค์เปรียบเทียบ GitHub ของ Cosmos SDK

ปัญหาเช่นการประทับเวลาไม่เพียงเท่านั้นที่เกิดขึ้นในส่วนประกอบพื้นฐานเช่น Cosmos SDK แต่ยังเกิดขึ้นในโซนแอปพลิเคชันต่าง ๆ

ตัวอย่าง 2

Vulnerability background: SuperNova, โครงการ nova

ที่อยู่โครงการ: SuperNova GitHub Link

การใช้ time.Now() จะคืนค่าแสตมป์เวลาของระบบปฏิบัติการ เวลาท้องถิ่นเป็นเรื่องจิตวิญญาณและเนื่องจากฉะนั้นไม่ตายตัว โดยเนื่องจากอาจมีความแตกต่างเล็กน้อยในแสตมป์เวลาของโหนดแต่ละโหนด การส่งธุรกรรมในโมดูล ICAControl ใช้ฟังก์ชันส่งเวลา time.Now() เพื่อรับแสตมป์เวลา

ตำแหน่งของช่องโหว่: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14

รหัสช่วงช่องโหว่:

การแก้ไขช่องโหว่:

เปลี่ยนจากใช้เวลาท้องถิ่นเป็นการใช้เวลาบล็อก

timeoutTimestamp := time.Now().Add(time.Minute * 10).UnixNano() _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp))

timeoutTimestamp := uint64(ctx.BlockTime().UnixNano() + 10*time.Minute.Nanoseconds()) _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp)

กรณีที่สาม:

พื้นหลังของช่องโหว่: Oracle Module ในโครงการ BandChain

URL โครงการ: BandChain GitHub ที่เก็บรวม

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

ตำแหน่งของความเป็นอยู่ที่มีช่องโหว่: โค้ดตัวอย่าง GitHub ของ BandChain

โค้ดช่วงช่องโหว่:

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

Case Four:

ความเสี่ยงพื้นหลัง: โมดูล Accesscontrol ในโครงการ Sei Cosmos

URL โครงการ: Sei Cosmos GitHub Repository

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

ในการดำเนินการของ BuildDependencyDag ใน x/accesscontrol/keeper/keeper.go, มีการวนซ้ำเหนือโหนด anteDepSet โดยเนื่องจากพฤติกรรมที่ไม่แน่นอนของการวนซ้ำแผนที่ใน Go, ValidateAccessOp อาจทำให้เกิดข้อผิดพลาดสองประเภทที่แตกต่างกัน ซึ่งอาจทำให้เกิดความล้มเหลวในการตามความเห็นร่วม

ตำแหน่งของช่องโหว่: Sei Cosmos GitHub Code Snippet

โค้ดช่วงช่องโหว่:

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

ขาดทุน

ปัญหาของการสูญเสียเงินทุนมักพบเห็นได้ในการจัดการเชิงตรรกะของ SDK ข้อความ Msg และ IBC แน่นอนว่ายังมีช่องโหว่บางอย่างที่อาจทําให้เกิดการสูญเสียเงินทุนท่ามกลางสาเหตุที่สามารถหยุดการทํางานของบล็อกเชนได้ ผลกระทบที่เฉพาะเจาะจงขึ้นอยู่กับช่องโหว่เฉพาะและที่นี่เรามุ่งเน้นไปที่อดีต นอกจากนี้เนื่องจาก IBC เป็นองค์ประกอบที่สําคัญมากของระบบนิเวศ Cosmos จึงเกี่ยวข้องกับช่องโหว่บางอย่างใน IBC อย่างหลีกเลี่ยงไม่ได้ ข้อมูลเฉพาะเกี่ยวกับพื้นผิวการโจมตีของ IBC และช่องโหว่ที่เกี่ยวข้องจะกล่าวถึงในบทถัดไป

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

ที่นี่เราจะเริ่มต้นด้วยโครงการ SuperNova เพื่อวิเคราะห์ช่องโหว่ที่เกี่ยวข้องสามอย่าง

พื้นหลังของช่องโหว่: โครงการ SuperNova

URL โครงการ: https://github.com/Carina-labs/nova

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

ตำแหน่งของช่องโหว่: https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

รหัสช่องโหว่:

Vulnerability trigger path:

msgServer.ClaimSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

precisionMultiplier

• พื้นหลังของช่องโหว่: โครงการ SuperNova

Project address: https://github.com/Carina-labs/nova/

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

ตำแหน่งของช่องโหว่: https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

รหัสโค้ดที่มีช่องโหว่:

การแก้บั๊ก: เพิ่มการตรวจสอบ DenomDuplicateCheck

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

• พื้นหลังของช่องโหวด: โครงการ Supernova

ที่อยู่โครงการ: https://github.com/Carina-labs/nova/

การอัปเดตสถานะหายไป ในเมทอด IcaWithdraw() หากธุรกรรมล้มเหลวและสถานะเวอร์ชันไม่ได้รับการปรับเปลี่ยน บันทึกการถอนเงินจะไม่สามารถเข้าถึงได้และเงินที่เกี่ยวข้องจะไม่สามารถถอนได้ ความเข้าใจที่ได้รับความนิยมมากกว่าคือสถานะถูกตั้งไว้ก่อน SendTx และสถานะไม่ได้รับการปรับเปลี่ยนหลังจากความล้มเหลว ทำให้การถอนเงินล้มเหลวและไม่สามารถถอนได้อีกครั้งในครั้งถัดไป

ตำแหน่งของช่องโหว่: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

รหัสโค้ดที่เสี่ยง

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

กระทบสถานะระบบหรือการทำงานปกติ

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

- การตรวจสอบตัวแปรไม่สมบูรณ์ในประเภท sdk.Msg:

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

กรณีศึกษา: คำแนะนำด้านความปลอดภัยของ Cosmos SDK บาร์เบอร์รี่

พื้นหลังช่องโหว่: MsgCreatePeriodicVestingAccount.ValidateBasic ขาดกลไกในการประเมินสถานะของบัญชี เช่น มีการใช้งานอยู่หรือไม่ ใน PeriodicVestingAccount ที่กําหนด x/auth ผู้โจมตีสามารถเริ่มต้นบัญชีของเหยื่อไปยังบัญชีที่เป็นเจ้าของโดยมีเจตนาร้ายได้ บัญชีนี้อนุญาตให้ฝากได้ แต่ห้ามถอนเงิน เมื่อผู้ใช้ฝากเงินเข้าบัญชีเงินเหล่านี้จะถูกล็อคอย่างถาวรและผู้ใช้จะไม่สามารถถอนเงินได้

การแก้ไขช่องโหว่:

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-barberry/10825

https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-j2cr-jc39-wpx5

https://github.com/cosmos/cosmos-sdk/compare/v0.47.3-rc.0...v0.47.3

https://github.com/cosmos/cosmos-sdk/pull/16465

โค้ดที่มีช่องโหว่:

นอกเหนือจากนี้ ปัญหาในขั้นตอน ValidateBasic ยังปรากฏอยู่ใน Cosmos-SDK Security Advisory Elderflower และ Cosmos-SDK Security Advisory Jackfruit โดยรุนแรง ปัญหาแรกเกิดจากการละเมิดโดยตรงของการเรียก ValidateBasic ในขณะที่ปัญหาที่สองเกี่ยวข้องกับปัญหาการตรวจสอบตัวแปร timestamp ภายในข้อความ ในโซลูชันเชน ปัญหาเช่นนี้มีอยู่มากขึ้น โครงการเช่น ethermint, pstake-native, และ quicksilver ได้เผชิญกับช่องโหว่ด้านความปลอดภัยที่เหมือนกันในมาตรการการตรวจสอบการประมวลผลข้อความของพวกเขา

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

ประเภทของช่องโหว่ที่พบบ่อย

Excluding vulnerabilities unique to specific project operations, there are some more common vulnerability models. For instance, the third case of fund loss is an operation that changes the state before sending a message. This type of vulnerability is similar to those in smart contracts, where changing the state before transferring funds can lead to problems like re-entrance or lingering erroneous states. Scenarios where state setting is closely tied to message transmission are quite common in blockchain, and many significant vulnerabilities originate from such issues. Besides, there are computational security vulnerabilities like division-by-zero errors, gas consumption bypasses, and use of versions with known vulnerabilities, all of which can affect the system’s state or normal operation.

ปัญหาความไม่เหมือนใคร

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

ปัญหาคุณลักษณะทางภาษา

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

สรุป

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

• ให้ความสำคัญกับช่องโหว่ในโครงสร้างพื้นฐาน: ส่วนประกอบหลักเช่น CometBFT และ Cosmos SDK อาจมีช่องโหว่เช่นกัน ดังนั้นการอัปเดตและบำรุงรักษาเป็นประจำจำเป็นสำหรับความปลอดภัย

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

• ระวังการโจมตีโหนดที่ไม่ดี: โหนดความเห็นสำคัญในระบบนิเวศ Cosmos อัลกอริทึมที่เกี่ยวกับความทนทานต่อบาดเจ็บของโหนดเหล่านี้อาจเป็นอ้อนวอนต่อการโจมตี ดังนั้นการรักษาความปลอดภัยของโหนดเป็นสิ่งสำคัญเพื่อป้องกันพฤติกรรมที่ไม่ดี

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

• ดำเนินการตรวจสอบรหัสที่จำเป็น: เนื่องจากความเปิดเผยของระบบ Cosmos SDK และระบบ CometBFT นักพัฒนาและผู้ตรวจสอบควรตรวจสอบทั้งรหัสหลักและรหัสที่เขียนในโมดูลที่กำหนดเพื่อระบุและแก้ไขปัญหาความปลอดภัยที่เป็นไปได้

• ให้ความสนใจกับเครื่องมือระบบนิเวศ: ระบบนิเวศของ Cosmos มีเครื่องมือและแอปพลิเคชันมากมายซึ่งจําเป็นต้องได้รับการตรวจสอบความปลอดภัยและการอัปเดตเป็นประจําเพื่อความปลอดภัย

คู่มือความปลอดภัยของโปรโตคอล IBC

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

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

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

ดังนั้น IBC จะตอบสนองความต้องการเหล่านี้อย่างไรและเล่นบทบาทที่สำคัญอย่างไร? เหตุผลพื้นฐานคือ IBC เป็น:

1. Trust-minimized

2. สามารถรองรับบล็อกเชนที่หลากหลาย

3. ปรับแก้ไขได้ที่ระดับแอปพลิเคชัน

4. เทคโนโลยีที่เจริญรุ่ง

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

โดยรวมโครงสร้างของโปรโตคอล IBC สามารถแบ่งออกเป็นสองชั้น: IBC TAO และ IBC APP

• IBC TAO: กำหนดมาตรฐานสำหรับการส่งข้อมูลแพ็คเก็ต การตรวจสอบและการเรียงลำดับ ซึ่งเป็นระดับพื้นฐานอย่างสำคัญ ใน ICS (Interchain Standards) ประกอบด้วยหมวดหมู่หลัก ลูกค้า และผู้เรียกร้อง

• IBC APP: กำหนดมาตรฐานสำหรับตัวจัดการแอปพลิเคชันของแพ็กเก็ตข้อมูลที่ถูกส่งผ่านชั้นโครงข่ายการขนส่ง ซึ่งรวมถึง การโอนเหรียญที่สามารถแลกเปลี่ยน (ICS-20) การโอนเหรียญไม่สามารถแลกเปลี่ยน (ICS-721) และบัญชีระหว่างโซ่ (ICS-27) และสามารถค้นพบได้ในหมวดหมู่แอปพลิเคชันของ ICS

โปรโตคอล IBC (จากโปรแกรมเมอร์ Cosmos)

โปรโตคอล IBC (Inter-Blockchain Communication) เป็นรากฐานที่สําคัญของวิสัยทัศน์ของระบบนิเวศ Cosmos เกี่ยวกับ "อินเทอร์เน็ตของบล็อกเชน" ในบริบทนี้ตัวเลือกการออกแบบของ IBC ได้รับอิทธิพลจากมาตรฐาน TCP / IP เช่นเดียวกับวิธีที่ TCP/IP กําหนดมาตรฐานสําหรับการสื่อสารด้วยคอมพิวเตอร์ IBC ระบุชุดของนามธรรมสากลที่ช่วยให้บล็อกเชนสามารถสื่อสารกันได้ เช่นเดียวกับที่ TCP / IP ไม่ได้ จํากัด เนื้อหาของแพ็กเก็ตข้อมูลที่ถ่ายทอดผ่านเครือข่าย IBC ทํางานในลักษณะเดียวกัน นอกจากนี้ เช่นเดียวกับวิธีที่โปรโตคอลแอปพลิเคชันเช่น HTTP และ SMTP สร้างขึ้นบน TCP/IP แอปพลิเคชันเช่นการถ่ายโอนสินทรัพย์ที่เป็นเนื้อเดียวกัน / ไม่สามารถเปลี่ยนได้หรือการโทรสัญญาอัจฉริยะข้ามสายโซ่ยังใช้โปรโตคอล IBC เป็นเลเยอร์พื้นฐาน

ปัญหาหลักที่เห็นในปัจจุบันกับโปรโตคอล IBC เกี่ยวข้องกับการส่งช่องสัญญาณและการประมวลผลแพ็กเก็ต มีปัญหาสําคัญในการตรวจสอบหลักฐาน แต่สิ่งเหล่านี้พบได้น้อยกว่า บทความนี้มุ่งเน้นไปที่ปัญหาทั่วไปของโปรโตคอล IBC ด้วยการออกแบบโมดูลาร์ของโปรโตคอล IBC นักพัฒนาแอปพลิเคชัน IBC ไม่จําเป็นต้องกังวลกับรายละเอียดพื้นฐานเช่นไคลเอนต์การเชื่อมต่อและการตรวจสอบหลักฐาน อย่างไรก็ตามพวกเขาจําเป็นต้องใช้อินเทอร์เฟซ IBCModule และวิธีการจัดการ Keeper ที่เกี่ยวข้อง ปัญหามากมายที่เกี่ยวข้องกับโปรโตคอล IBC เกิดขึ้นในพาธโค้ดของอินเทอร์เฟซ IBCModule สําหรับการรับและประมวลผลแพ็กเก็ต (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket เป็นต้น)

การจําแนกประเภทช่องโหว่ทั่วไป

ในระบบนิทรรศการของ Cosmos โปรโตคอล IBC ทำหน้าที่เป็นศูนย์ต่อขยาย ประเภทของช่องโหว่ที่เกี่ยวข้องกับโปรโตคอล IBC มีความหลากหลายและซับซ้อนเนื่องจากการผสมผสานอย่างใกล้ชิดของการนำมาใช้งานกับโมดูลเช่น Cosmos-SDK และ CometBFT อีกทั้งยังเนื่องจาก IBC ใช้งานโดยส่วนใหญ่ในระบบนิทรรศการของ Cosmos ซึ่งภาษาโปรแกรมหลักคือ Golang ตามที่ระบุไว้ในเอกสาร ibc-go

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

คลาสสิ่งที่เสี่ยง

1. ชื่อที่มีช่องโหว่

   ① ช่องโหว่การจัดการสตริง

   ② ช่องโหว่การจัดการ Bytecode

2. ช่องโหว่ในกระบวนการส่งผ่าน

   ① ช่องโหว่การสั่งซื้อแพ็กเก็ต

   ② ช่องโหว่การหมดเวลาของแพ็กเก็ต

   ③ ช่องโหว่ในการยืนยันส่งข้อมูล

   ④ ช่องโหว่แพ็กเก็ตอื่น ๆ

3. ช่องโหว่ทางตรรกะ

   ① อัปเดตสถานะช่องโหว่

   ② การลงคะแนนเสียงและความบกพร่องในการเชื่อมั่น

   ③ ช่องโหว่ตรรกะอื่น ๆ

4. ช่องโหว่ในการบริโภคแก๊ส

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

การวิเคราะห์ช่องโหว่

การสูตร IBC Protocol

Case Study 1: ICS-07 Protocol, ช่องโหว่ทางตรรกะ

พื้นหลังของช่องโหว่: การใช้งานไม่ถูกต้องของช่่วงเวลาการยกเลิก

ในโค้ดมีการตรวจสอบต่อไปนี้:

if currentTimestamp.Sub(consState.Timestamp) >= clientState.UnbondingPeriod

ตามโมเดลความปลอดภัยของ Tendermint สำหรับบล็อก (หัวเรื่อง) ณ เวลา t ผู้ตรวจสอบใน NextValidators ต้องทำงานให้ถูกต้องก่อน t+TrustingPeriod หลังจากนั้นพวกเขาอาจแสดงพฤติกรรมอื่น ๆ อย่างไรก็ตามการตรวจสอบที่นี่เป็นสำหรับ UnbondingPeriod ไม่ใช่ TrustingPeriod ที่ UnbondingPeriod > TrustingPeriod หากวันกำหนดสำหรับ consState อยู่ระหว่าง TrustingPeriod และ UnbondingPeriod แล้วหัวเรื่องนี้จะได้รับการยอมรับเป็นเกณฑ์สำหรับการตรวจสอบหนึ่งในหัวเรื่องที่ขัดแย้งกันที่เป็นพฤติกรรมไม่เป็นธรรม ระหว่างช่วงเวลานี้ ผู้ตรวจสอบใน consState.NextValidators จะไม่ได้รับการพิจารณาว่าน่าเชื่อถืออีกต่อไป และผู้ตรวจสอบที่เคยเป็นที่ต้องการอาจปิดการใช้งานไคลเอ็นต์โดยไม่มีความเสี่ยงใด ๆ

Project Address: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client

ตำแหน่งของช่องโหว่:

• https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client#misbehaviour-predicate

• https://github.com/cosmos/cosmos-sdk/blob/6344d626db1fbdba5e0f67425703c1584021bf5b/x/ibc/light-clients/07-tendermint/types/misbehaviour_handle.go#L96

รหัสโปรแกรมที่มีช่องโหว่:

ฟังก์ชันกำหนดโปรโตคอล

รหัส

การประยุกต์ของโปรโตคอล IBC

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

1. ความกังวลและปัญหาที่ไม่เป็นมาตรฐานในการปฏิบัติตามข้อบังคับ

2. ข้อผิดพลาดในการตั้งค่าโปรโตคอล

ปัญหาความกังวลและปัญหาที่ไม่มีมาตรฐานในการนำ Protocol ในการปฏิบัติงาน

Case Study 1: ICS-20 Protocol, ชื่อของช่องโหว่

ประวัติของช่องโหว่: ความขัดแย้งของที่อยู่ผู้ดูแลGetEscrowAddress()ฟังก์ชันสร้าง SHA256 ที่ถูกตัดเหลือ 20 ไบต์ (Port ID + Channel ID) วิธีนี้มีปัญหาสามข้อ

1. ขาดการแยกโดเมนระหว่างพอร์ตและช่อง วิธีการต่อสตริงไม่ได้แยกโดเมนของพอร์ตและช่อง ตัวอย่างเช่น คู่สมการพอร์ต/ช่อง ("โอน" "ช่อง") และ ("ทรานส์" "เฟอร์ชาแนล") จะทำให้ได้ที่อยู่การรับรองเดียวกันคือ การตัด SHA256 ("ทรานส์เฟอร์ชาแนล") หากโมดูลบางอย่างที่มีฟังก์ชันไลบรารีถูกอนุญาตให้เลือก ID พอร์ตและช่อง อาจเกิดช่องโหว่

2. ความขัดแย้งระหว่างที่อยู่บัญชีโมดูล สตริงตัวอักษรและตัวเลขโดยพลการใช้ในภาพก่อนของ SHA-256 โดยมีขนาดหลังภาพ 160 บิต โพสต์ภาพขนาดเล็กนี้รวมกับฟังก์ชันแฮชที่รวดเร็วทําให้การโจมตีวันเกิดเป็นไปได้เนื่องจากความปลอดภัยของมันลดลงเหลือเพียง 80 บิตเท่านั้น หมายความว่าต้องใช้การคาดเดาประมาณ 2 ^ 80 ครั้งเพื่อค้นหาการชนกันระหว่างที่อยู่บัญชีผู้ดูแลที่แตกต่างกันสองแห่ง ในปี 2018 มีการวิเคราะห์ต้นทุนโดยละเอียดของการโจมตีการตัดทอน SHA256 ในบริบทของ Tendermint ซึ่งพิสูจน์ให้เห็นว่าการโจมตีดังกล่าวเป็นไปได้จากมุมมองด้านต้นทุน การค้นหาการชนกันหมายความว่าบัญชีผู้ดูแลที่แตกต่างกันสองบัญชีจะแมปไปยังที่อยู่บัญชีเดียวกัน สิ่งนี้อาจนําไปสู่ความเสี่ยงที่เงินจะถูกขโมยจากบัญชีที่ดูแล สําหรับรายละเอียดเพิ่มเติม โปรดดูโดเมนก่อนรูปภาพ ICS20 GetEscrowAddress ทับซ้อนกับคีย์สาธารณะ T:BUG

3. ความขัดแย้งระหว่างที่อยู่บัญชีโมดูลและที่อยู่ที่ไม่ใช่โมดูล การสร้างที่อยู่บัญชีสาธารณะจะเหมือนกับคีย์สาธารณะ SHA-256 ขนาด 20 ไบต์ของ Ed25519 แม้ว่าการรักษาความปลอดภัย 160 บิตจะเพียงพอที่จะป้องกันการโจมตีแบบชนกันในที่อยู่สาธารณะที่เฉพาะเจาะจง แต่การรักษาความปลอดภัยจากการโจมตีวันเกิดมีเพียง 80 บิตเท่านั้น สถานการณ์นี้คล้ายกับโหมดการโจมตีกึ่งวันเกิดโดยที่ที่อยู่หนึ่งถูกสร้างขึ้นโดย SHA-256 ที่รวดเร็วและอีกที่อยู่หนึ่งถูกสร้างขึ้นโดยการคํานวณคีย์สาธารณะ Ed25519 ที่ค่อนข้างช้า แม้ว่าสถานการณ์นี้จะปลอดภัยกว่า แต่ก็ยังก่อให้เกิดการโจมตีที่อาจเกิดขึ้นกับผู้ดูแลและบัญชีสาธารณะ

Project address: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-020-fungible-token-transfer

ตำแหน่งของความเสี่ยง: https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/types/keys.go#L40-L47

https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/keeper/relay.go

โค้ดที่มีช่องโหว่:

ปัญหาการตั้งค่าโปรโตคอล

• Case 1: คำแนะนำด้านความปลอดภัย IBC Dragonberry, ช่องโหว่ของกระบวนการส่งข้อมูล

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

1. สถานการณ์ปกติ: สำเร็จภายในเวลาที่กำหนด

2. สถานการณ์หมดเวลา: ล้มเหลวเนื่องจากหมดเวลา

แผนภูมิการส่งมอบแพ็กเกจแอปพลิเคชัน IBC

เมื่อหมดเวลาหมายความว่าการส่งล้มเหลวและโปรโตคอล IBC จะเริ่มกระบวนการคืนเงิน ควรสังเกตว่า IBC มีกลไกการหมดเวลาที่ผู้ใช้กําหนดค่าได้ ช่องโหว่ของ Dragonberry มาจาก ICS-23 (IBC) สาเหตุหลักของช่องโหว่นี้คือผู้ใช้สามารถปลอมแปลงหลักฐานที่ไม่มีอยู่ในกระบวนการตรวจสอบ (นั่นคือหลักฐานเท็จว่าไม่ได้รับแพ็กเก็ตข้อมูล) ดังนั้นการข้ามการตรวจสอบความปลอดภัยและการสร้างสถานการณ์การหมดเวลา IBC ที่ "สมเหตุสมผล" ถูกใช้เพื่อหลอกลวงโปรโตคอล IBC ทําให้ตัวทําซ้ําส่งแพ็กเก็ตหมดเวลาด้วยใบรับรองเท็จ และอาจบานปลายเป็นปัญหาการใช้จ่ายซ้ําซ้อนของ ICS-20 กระบวนการทริกเกอร์เฉพาะของช่องโหว่สามารถดูได้ในรูปด้านล่าง

กระแสช่อเท้าของช่อเท้าของพริ้นซิเพิลของเจ้ามังกร

Project address: https://github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel

ตำแหน่งของช่องโหว่: https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/timeout.go#L117C28-L117C54

โค้ดชุบชีวิต:

• Case 2: IBC Security Advisory Huckleberry, transmission process vulnerability

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

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

แผนภูมิการไหลของหลักการช่องโหว่ Huckleberry

Project address: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/

ตำแหน่งของช่องโหว่: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/keeper/grpc_query.go#L408

รหัสโปรแกรมที่มีช่องโหว่:

การใช้งานและขยายขอบเขตของโปรโตคอล IBC

• Case 1: ช่องโหว่การแจกจ่าย Stride, ช่องโหว่ตรรกะ

พื้นฐานของความเป็นอ่อนTryUpdateAirdropClaimแปลงที่อยู่ผู้ส่งของแพ็กเก็ต IBC เป็นที่อยู่ Stride ชื่อsenderStrideAddress, และสกัดairdropIdและที่อยู่ airdrop ใหม่newStrideAddressจากเมตาดาต้าแพ็คเก็ต จากนั้นโทรอัปเดตที่อยู่การแจกจ่ายอัปเดตsenderStrideAddressและบันทึกการเรียกร้อง. ด้วยการอัปเดตของ บันทึกการเรียกร้องค่าสินไหมทดแทน, newStrideAddressจะสามารถขอรับเหรียญแอร์ดรอปได้ อย่างไรก็ตาม ฟังก์ชันการอัปเดตนี้จะตรวจสอบเฉพาะว่าที่อยู่ผู้ส่งของคำขอว่างเปล่าหรือไม่ และไม่ตรวจสอบnewStrideAddress. เนื่องจาก IBC อนุญาตให้การเชื่อมต่อเครื่องเดียวกันในการนำไปใช้งาน IBC-enabled chains ซึ่งสร้างความเสี่ยงด้านความปลอดภัยโดยมีอาจารย์ที่สามารถอัปเดตที่อยู่บัญชีใด ๆ อื่น ๆ ให้เป็นที่อยู่ของการแจกแจงเหรียญ

ที่อยู่โครงการ: https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot

ตําแหน่งช่องโหว่: https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/module_ibc.go#L119

https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/keeper/airdrop.go#L17

โค้ดที่มีช่องโหว่:

• Case 2: ชุดโมดูล neutron ibc vulnerability, ชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลชุดโมดูลผู้ที่บริโภคแก๊ส

พื้นหลังช่องโหว่: ในบริบทของสัญญาอัจฉริยะมีปัญหากับวิธีการตรวจสอบค่าธรรมเนียมสําหรับการยืนยันหรือกําหนดเวลาเหตุการณ์ IBC (Inter-Blockchain Communication) ข้อบกพร่องนี้ช่วยให้สัญญาอัจฉริยะที่เป็นอันตรายทําให้เกิดความผิดพลาด 'ErrorOutOfGas' ความผิดพลาดนี้เกิดขึ้นระหว่างการประมวลผลข้อความ 'OnAcknowledgementPacket' และ 'OnTimeoutPacket' เมื่อข้อผิดพลาดนี้เกิดขึ้นไม่สามารถแก้ไขได้ด้วยวิธี 'outOfGasRecovery' ตามปกติ เป็นผลให้ธุรกรรมที่ได้รับผลกระทบไม่สามารถรวมอยู่ในบล็อกบล็อกเชนได้ ความล้มเหลวนี้อาจทําให้ผู้ถ่ายทอด IBC พยายามส่งข้อความเหล่านี้ซ้ําๆ การส่งซ้ําดังกล่าวอาจนําไปสู่การสูญเสียทางการเงินสําหรับผู้ถ่ายทอดและโอเวอร์โหลดเครือข่ายด้วยแพ็กเก็ตที่ยังไม่ได้ประมวลผล ('ละทิ้ง') จํานวนมากเกินไปซึ่งก่อให้เกิดความเสี่ยงต่อความเสถียรของเครือข่าย

Project address: https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/

ตำแหน่งของช่องโหว่:

https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/x/interchaintxs/keeper/ibc_handlers.go#L62

โค้ดชุบชีวิต:

สรุป

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

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

สรุป

การตรวจสอบความปลอดภัยของระบบนิเวศ Cosmos ของเราซึ่งเกี่ยวข้องกับการตรวจสอบโดยละเอียดการสรุปและการจัดหมวดหมู่มีศูนย์กลางอยู่ที่องค์ประกอบที่สําคัญที่สุดสองประการ: Cosmos SDK และโปรโตคอล IBC จากประสบการณ์จริงที่กว้างขวางของเราเราได้รวบรวมความเชี่ยวชาญด้านการตรวจสอบทั่วไปที่ครอบคลุม

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

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

คำปฏิเสธ：

1. บทความนี้ถูกคัดลอกจาก [GateCertiK]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [CertiK]. หากมีข้อโต้แย้งใดๆ เกี่ยวกับการพิมพ์ซ้ำนี้ กรุณาติดต่อ Gate Learnทีม และพวกเขาจะดำเนินการโดยเร็ว
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นๆ โดยทีม Gate Learn นอกจากที่จะได้ระบุไว้ การคัดลอก การกระจาย หรือการลอกเลียนบทความที่ถูกแปลนั้นถูกห้าม