Initia ถูกโจมตี: ขโมยข้อมูล cloud มูลค่า $3.27M

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

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

เหตุการณ์ $3.27 ล้านดอลลาร์ที่รายงานของ Initia เปิดเผยอะไรบ้าง?

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

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

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

การเปิดเผยตัวแปรสภาพแวดล้อมของ Initia ที่รายงานเป็นจุดสำคัญในวิเคราะห์ความปลอดภัย ตัวแปรสภาพแวดล้อมมักถูกใช้เพื่อจ่ายข้อมูลรับรอง API, access token, สตริงฐานข้อมูล, ค่า configuration ส่วนตัว และความลับเวลา deployment ดีไซน์นี้สะดวกสำหรับการปฏิบัติงาน แต่ทำให้กระบวนการบริการและสภาพแวดล้อมคลาวด์รอบข้างมีความอ่อนไหวสูง หากผู้โจมตีสามารถอ่านการตั้งค่า runtime ได้ พวกเขาอาจเข้าถึงข้อมูลรับรองที่ไม่ควรเปิดเผยโดยตรงจากอินเทอร์เน็ตสาธารณะ

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

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

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

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

การเข้าถึงคลาวด์อย่างไรที่รายงานว่าเข้าถึงทรัพย์สินใน escrow ของ Initia?

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

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

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

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

องค์ประกอบเหตุการณ์ที่รายงาน	รายละเอียด Initia ที่รายงาน	เขตความปลอดภัยที่เกี่ยวข้อง	การควบคุมป้องกันที่ควรประเมิน
การเข้าถึงเริ่มต้น	การฉีดคำสั่งผ่านกุญแจ GCP ที่ถูกเจาะ	ตัวตนคลาวด์และการดำเนินการแอปพลิเคชัน	บทบาทคลาวด์แบบ least-privilege, การหมุนเวียนกุญแจ, การแยกการดำเนินการคำสั่ง
ขยายข้อมูลรับรอง	ตัวแปรสภาพแวดล้อมถูกเปิดเผย	การจัดการความลับระหว่างรันไทม์	การเก็บความลับใน vault, ข้อมูลรับรองระยะสั้น, การควบคุมระดับกระบวนการ
การเข้าถึงที่เก็บซอร์สและโครงสร้างพื้นฐาน	การเข้าถึง GitHub และบัญชีคลาวด์	การบริหาร CI/CD และโครงสร้างพื้นฐาน	สาขาที่ป้องกัน, ตัวตนสำหรับ deployment แยกต่างหาก, การตรวจสอบการเข้าถึงสิทธิพิเศษ
การเข้าถึงโครงสร้างพื้นฐาน rollup	เข้าถึง Anvil	การปฏิบัติการ rollup และอำนาจผู้ดูแล	แยกสภาพแวดล้อม, กระบวนการอนุมัติการดำเนินการสิทธิพิเศษ
กลไกปล่อยสินทรัพย์	การถอนเงิน IBC ที่เป็นการฉ้อโกงถูกตรวจสอบ	การตรวจสอบข้าม chain และการปล่อย escrow	การตรวจสอบอย่างเป็นอิสระ, ขีดจำกัดอัตรา, เบรกเกอร์วงจรถอนเงิน
การควบคุมการระบาด	Initia หยุดชั้น-1 เมื่อวันอังคาร	อำนาจตอบสนองเหตุฉุกเฉิน	ขั้นตอนหยุดชั่วคราวที่ทดสอบและบันทึกการตัดสินใจฟื้นฟู

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

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

ทำไมการโจมตี Initia ครั้งที่สองจึงเปลี่ยนการประเมินความเสี่ยง?

จากรายงาน เหตุการณ์ $3.27 ล้านดอลลาร์ของ Initia เกิดขึ้นหลังจากการโจมตีเมื่อวันที่ 23 ต.ค. ที่ขโมยเงินประมาณ 2.7 ล้านดอลลาร์ผ่านช่องโหว่ใน MoveVM script cache ของ Initia เหตุการณ์ที่รายงานสองครั้งภายในเวลาน้อยกว่าสามสัปดาห์ชี้ให้เห็นพื้นผิวการโจมตีสองแบบที่แตกต่างกัน: หนึ่งเกี่ยวกับ MoveVM script cache อีกหนึ่งเกี่ยวกับข้อมูลรับรองคลาวด์, การฉีดคำสั่ง และการเข้าถึงเชิงปฏิบัติการ

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

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

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

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

เปรียบเทียบเหตุการณ์ Initia สองครั้งที่รายงานโดยไม่บอกว่าเกิดจากสาเหตุหรือผู้กระทำเดียวกัน

เหตุการณ์ Initia ที่รายงาน	วันที่หรือตอนไหน	การสูญเสียที่รายงาน	พื้นผิวการโจมตีที่รายงาน	ผลกระทบความปลอดภัยทันที
การโจมตี MoveVM script-cache	23 ต.ค.	ประมาณ 2.7 ล้านดอลลาร์	MoveVM script cache ของ Initia	ทบทวนโค้ดโปรโตคอล, พฤติกรรม cache, เส้นทางการอัปเกรด, การควบคุมการโจมตี
เหตุการณ์ข้อมูลรับรองคลาวด์และถอน IBC	รายงานว่าเข้าถึงวันจันทร์ และหยุดชั้น-1 วันอังคาร	ประมาณ 3.27 ล้านดอลลาร์	กุญแจ GCP ถูกเจาะ, command injection, ตัวแปรสภาพแวดล้อม, GitHub, บัญชีคลาวด์, Anvil, ถอน IBC	ทบทวนตัวตน, การจัดการความลับ, สิทธิ์คลาวด์, การปฏิบัติการ rollup, อำนาจการถอนเงิน

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

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

ควรตรวจสอบอะไรบ้างสำหรับผู้ปฏิบัติการ IBC และ rollup หลังรายงานนี้?

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

เงินที่ถอนที่รายงานประกอบด้วย 13,400 TIA, 8,000 USDC.inj, และ 597,000 Noble USDC รายงานยังระบุว่าไม่มีโทเค็น INIT ถูกถอน รายละเอียดสินทรัพย์เฉพาะนี้สำคัญเพราะการกู้คืนเหตุการณ์ไม่ใช่แค่การทำบัญชีมูลค่ารวม ทีมงานต้องปรับยอดสินทรัพย์แต่ละประเภท, เส้นทางการโอน, ภาระผูกพัน escrow, ยอดเงินที่หยุดชะงัก และภาระผูกพันกับผู้ใช้หรือคู่สัญญา

การตรวจสอบเชิงปฏิบัติควรเริ่มจากสายการอนุมัติหรือยืนยันการถอนเงินอย่างชัดเจน สำหรับเส้นทางสินทรัพย์แต่ละเส้นทางที่เกี่ยวข้องกับ cross-chain หรือ rollup ทีมงานควรระบุว่า

1. อัตลักษณ์โครงสร้างพื้นฐานที่สามารถเข้าถึงบริการที่เกี่ยวข้องคือใคร
2. ที่เก็บซอร์สหรือ pipeline deployment ใดที่สามารถเปลี่ยนแปลงพฤติกรรมบริการ
3. ความลับหรือตัวแปรสภาพแวดล้อมใดที่ยกระดับอำนาจของข้อมูลประจำตัวได้
4. ส่วนประกอบตรวจสอบใดที่ตัดสินใจว่าการถอน IBC นั้นถูกต้องตามกฎหมายหรือไม่
5. กลไก escrow ใดที่ปล่อยสินทรัพย์หลังการตรวจสอบผ่าน
6. กลไกฉุกเฉินใดที่สามารถหยุดการถอนเงินหรือหยุดการทำงานของเครือข่ายได้
7. กระบวนการที่ใช้คืนมูลค่าทรัพย์สินหลังจากการดำเนินการควบคุมเหตุการณ์

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

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

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

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

ควบคุมตอบสนองเหตุการณ์ใดสำคัญที่สุดหลังจากโครงสร้างพื้นฐานถูกเจาะ?

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

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

สำหรับเหตุการณ์ที่สอดคล้องกับลำดับรายงานของ Initia ทีมตอบสนองควรให้ความสำคัญกับลำดับปฏิบัติการดังนี้

1. แยกเส้นทางเข้าถึงที่สงสัย ปิดใช้งานหรือหมุนเวียนกุญแจ GCP ที่ถูกเจาะ และลบเส้นทางเข้าถึงที่เกี่ยวข้องกับการฉีดคำสั่ง

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

3. เก็บรักษาหลักฐาน รักษาบันทึก, ประวัติการตั้งค่า, เส้นทางตรวจสอบคลาวด์, เหตุการณ์ที่เก็บซอร์ส, บันทึก CI/CD และข้อมูลโทรเมตริกส์ระดับบริการก่อนเปลี่ยนหรือสร้างระบบที่ได้รับผลกระทบใหม่

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

5. ปรับปรุงความถูกต้องของมูลค่าทรัพย์สิน ระบุการถอนเงินที่ได้รับรายงาน, สินทรัพย์ที่ถูกแช่แข็ง, ตำแหน่ง escrow และภาระผูกพันที่เกี่ยวข้องกับแต่ละ rollup และประเภทสินทรัพย์ที่กระทบ

6. สร้างเขตความน่าเชื่อถือขึ้นใหม่ คืนค่าบริการโดยใช้ข้อมูลรับรองใหม่, ตรวจสอบสิทธิ์, การตั้งค่าโครงสร้างพื้นฐานที่สะอาด และเส้นทาง deployment ที่ผ่านการตรวจสอบอย่างอิสระ

7. ทดสอบการฟื้นฟูภายใต้อำนาจจำกัด ยืนยันว่าการฟื้นฟูไม่สร้างความสัมพันธ์สิทธิ์กว้างขวางเหมือนกับที่ทำให้เกิดการเจาะครั้งแรก

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

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

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