คุณคิดว่า「การโจมตีด้วย Flash Loan」เป็นฉากแฮกเกอร์ที่มีแต่ในหนังใช่ไหมซึ่งเป็นคนละเรื่องกับการที่คุณฝากเงินเข้า Vault เพื่อรับดอกเบี้ย?ครั้งนี้ Summer.fi ขาดทุนสุทธิ 6 ล้านดอลลาร์ และที่สำคัญคือมันเริ่มต้นจากขั้นตอนฝากเงินและไถ่ถอนที่ถูกกฎหมายทั้งหมด บทความนี้จะไม่ทำให้เรื่องนี้ดูเป็นเทคโนโลยีลึกลับ แต่จะพาคุณไปแกะความเข้าใจผิด ช่องโหว่การบันทึกบัญชี และขั้นตอนการโจมตีทีละขั้น สุดท้ายจะบอกคุณว่าเงินที่ฝากไว้ใน Vault ควรกังวลแค่ไหน
การโจมตีด้วย Flash Loan คือแฮกเกอร์บุกรุกกระเป๋าเงินของคุณหรือไม่? 3 ความเข้าใจผิดที่มือใหม่พบบ่อยที่สุด
การโจมตีด้วย Flash Loan ฟังดูเหมือนฉากในหนังไหม—แฮกเกอร์จ้องมองกระเป๋าเงินของคุณ แล้วถอดรหัสคีย์ส่วนตัวและโอนเงินออกไปภายในไม่กี่วินาที?ในเหตุการณ์ครั้งนี้ของ Summer.fiไม่มีกระเป๋าเงินของใครถูกบุกรุกเลยผู้โจมตีใช้ฟังก์ชันปกติที่โปรโตคอลเปิดให้ใช้งานได้เต็มที่ เพียงแต่ปั่นข้อมูลบัญชีให้พองจนระบบคำนวณผิดพลาดเข้าใจความเข้าใจผิดเหล่านี้ให้ชัดก่อน คุณถึงจะเข้าใจขั้นตอนการโจมตีในส่วนถัดไปได้ นี่คือจุดที่ผมเห็นมือใหม่เข้าใจผิดมากที่สุด
ความเข้าใจผิดที่ 1: คิดว่าต้องคีย์ส่วนตัวรั่วไหลเท่านั้นถึงจะเรียกว่าถูกขโมย
หลายคนพอได้ยินว่า「โปรโตคอลถูกโจมตี」ปฏิกิริยาแรกคือคิดว่าคีย์ส่วนตัวถูกขโมยหรือกระเป๋าเงินถูกแฮก สัญชาตญาณแบบนี้ใช้ได้กับกรณีฟิชชิงหรือแอปกระเป๋าเงินปลอม แต่ใช้ไม่ได้กับโปรโตคอลประเภท Vault อย่าง Summer.fi ผู้โจมตีไม่เคยได้คีย์ส่วนตัวของใครเลยตั้งแต่ต้นจนจบ และไม่ได้ใช้สิทธิ์ผู้ดูแลระบบใดๆ—ไม่ว่าจะเป็น Flash Loan ที่กู้มา เงินที่ฝาก หรือการไถ่ถอน ทั้งหมดล้วนเป็นฟังก์ชันปกติที่ Summer.fi เปิดให้ผู้ใช้ทุกคนใช้งานได้
พูดง่ายๆ คือช่องโหว่ครั้งนี้ไม่ได้อยู่ที่「ใครถูกขโมยกุญแจ」แต่อยู่ที่โปรโตคอลคำนวณสินทรัพย์ใน Vault อย่างไรต่อให้เก็บรักษาคีย์ส่วนตัวดีแค่ไหน แต่ถ้าตรรกะการบันทึกบัญชีมีช่องโหว่ สินทรัพย์ก็ยังถูกปั่นจนไร้ค่าได้เหมือนเดิม นี่คือเหตุผลว่าทำไมการระวังแค่ฟิชชิงหรือลิงก์ปลอมยังไม่พอ ความเสี่ยงจากการออกแบบตัว Vault เองต่างหากคือบทเรียนที่แท้จริงที่ควรจำจากเหตุการณ์นี้
ความเข้าใจผิดที่ 2: คิดว่าการโจมตีด้วย Flash Loan เหมือนกับการฉ้อโกงเงินกู้ทั่วไป
ความเข้าใจผิดที่พบบ่อยอีกอย่างหนึ่งคือการมอง Flash Loan เป็นเวอร์ชันขยายของการฉ้อโกงหนี้เสีย เหมือนกู้เงินก้อนใหญ่ไปทำเรื่องไม่ดีแล้วทิ้งหนี้หนีไป แต่กติกาของ Flash Loan แตกต่างไปโดยสิ้นเชิง มันกำหนดให้การกู้และการคืนต้องเสร็จสิ้นภายในบล็อกเดียวกันและธุรกรรมเดียวกัน ถ้าคืนไม่ครบ ธุรกรรมทั้งหมดจะล้มเหลวทันที เหมือนไม่เคยเกิดขึ้นมาก่อน
นี่หมายความว่าผู้โจมตีไม่มีทางรับความเสี่ยงจาก「การเบี้ยวหนี้」ได้เลย ต้องดำเนินการภายในกรอบเวลาสั้นมากให้เงิน 65.4 ล้านดอลลาร์ที่กู้มาทำกำไรได้มากกว่าเงินต้น ถึงจะรอดตัวได้สิ่งที่ท้าทายการโจมตีแบบนี้คือการหาช่องโหว่ในตรรกะการบันทึกบัญชีให้เจอไม่ใช่ความกล้าได้กล้าเสีย。มือใหม่ที่โฟกัสแค่「กู้เงินมาเท่าไหร่」กลับพลาดจุดที่ควรให้ความสำคัญจริงๆ คือกลวิธีการปั่นตัวเลข และยังประเมินความพยายามเบื้องหลังการโจมตีแบบนี้ต่ำเกินไปด้วย
ความเข้าใจผิดที่ 3: คิดว่าโปรโตคอลระงับการถอนเงินหมายความว่าเงินทุนถูกกู้คืนมาแล้ว
หลังเหตุการณ์ Summer.fi เปิดเผยออกมา โปรโตคอลรีบระงับการถอนเงินของ Vault ทั้งหมดทันที การกระทำนี้มักถูกมือใหม่เข้าใจผิดว่า「เงินปลอดภัยแล้ว」หรือ「หยุดความเสียหายได้แล้ว」แต่ในความเป็นจริง การระงับถอนเงินเป็นเพียงการป้องกันไม่ให้ช่องโหว่ถูกใช้ซ้ำ หยุดไม่ให้สินทรัพย์ของผู้ใช้รายอื่นถูกดูดออกไปด้วยวิธีเดียวกันซึ่งเป็นคนละเรื่องกับการที่เงินทุนถูกกู้คืนมาหรือยัง。
เงิน 6 ล้านดอลลาร์ที่ถูกขโมยไป ได้ถูกแลกผ่านCurveเป็นDAIแล้วไหลไปยังTornado Cashซึ่งเป็นเครื่องมือผสมเหรียญ (Mixer) ประเภทนี้ จนถึงตอนนี้ยังไม่มีความคืบหน้าการกู้คืนที่เปิดเผยต่อสาธารณะ คำว่า「ระงับแล้ว」「กำลังสอบสวน」ที่คุณเห็นในประกาศของโปรโตคอล บอกได้แค่ว่าโปรโตคอลกำลังหยุดความเสียหาย ไม่ได้แปลว่าเงินของคุณจะได้คืน พูดอีกอย่างคือ การระงับถอนเงินปกป้องผู้ใช้ที่ยังไม่ได้รับผลกระทบ ส่วนเงินที่ถูกขโมยไปแล้วเป็นคนละเรื่องกันโดยสิ้นเชิง อย่าเอาสองเรื่องนี้มาปนกัน
ทำไมการบันทึกบัญชีของ Vault ถึงถูกปั่นให้พองได้ง่ายขนาดนี้? มาทำความเข้าใจ totalAssets() จุดเจาะช่องโหว่หลักกันก่อน
Vault ก็แค่เอาเงินของทุกคนมารวมกันไปหาผลตอบแทน ทำไมการบันทึกบัญชีถึงพังง่ายขนาดนี้?แก่นของปัญหาอยู่ที่「โปรโตคอลคำนวณมูลค่าปัจจุบันของคุณอย่างไร」ไม่ใช่วิธีการเก็บรักษาเงินมีปัญหา。เข้าใจการแปลงค่า Share และฟังก์ชันสำคัญ totalAssets()คุณถึงจะเข้าใจว่าช่องโหว่ของ Summer.fi อยู่ที่ขั้นตอนไหน
Vault ใช้ Share แปลงเป็นสินทรัพย์ของคุณอย่างไร
เงินที่คุณฝากเข้า Vault โปรโตคอลจะไม่บันทึกบัญชีแยกทีละรายการ แต่จะแปลงเป็นจำนวน「Share」หนึ่ง สินทรัพย์รวมของ Vault หารด้วยจำนวน Share ที่หมุนเวียนอยู่ ก็คือมูลค่าของ Share หนึ่งหน่วย เวลาไถ่ถอนก็เอา Share คูณกลับด้วยราคาต่อหน่วยนี้ เพื่อคำนวณว่าจะได้สินทรัพย์คืนเท่าไหร่ การออกแบบแบบนี้สะดวกและนำไปต่อยอดได้ง่าย แต่ต้องแลกกับการที่ทั้งระบบยึดตัวเลขเดียวเป็นหลัก—นั่นคือสินทรัพย์รวมของ Vault มีเท่าไหร่กันแน่
ตราบใดที่ตัวเลขสินทรัพย์รวมถูกคำนวณผิดหรือถูกบิดเบือนโดยคนบางกลุ่ม ไม่ว่าตอนฝากคุณจะระมัดระวังแค่ไหน จำนวนเงินที่คำนวณได้ตอนไถ่ถอนก็จะคลาดเคลื่อนตามไปด้วย ในสถาปัตยกรรมของ Summer.fi งานคำนวณนี้อยู่ในความดูแลของสัญญาFleetCommanderซึ่งด้านล่างเชื่อมต่อกับโมดูลกลยุทธ์หลายตัวที่เรียกว่าArkนำเงินไปลงทุนในโปรโตคอลกู้ยืมต่างๆ เพื่อหาผลตอบแทนตรรกะการแปลงค่า Shareเองไม่ได้มีปัญหาอะไร ที่ผิดคือตัวเลขสินทรัพย์รวมที่ถูกนำไปใช้คำนวณ。
totalAssets() คืออะไร ทำไมคนไม่หวังดีถึงปั่นให้พองได้
totalAssets() เป็นฟังก์ชันหนึ่งในสัญญาของ Vault มีหน้าที่รายงานแบบเรียลไทม์ว่า「ตอนนี้ Vault นี้ถือสินทรัพย์รวมทั้งหมดเท่าไหร่」ราคาต่อ Share ก็คำนวณจากตัวเลขนี้ ตอนที่ผมเห็นคำอธิบายช่องโหว่นี้ครั้งแรก ก็แปลกใจที่ปัญหาอยู่ที่จุดพื้นฐานขนาดนี้ นั่นคือตอนที่โมดูล Ark ของ Summer.fi คำนวณ ได้เอา「สินทรัพย์ที่ถูกฝากเข้าที่อยู่ของสัญญาโดยตรง」มานับรวมในสินทรัพย์รวมด้วย โดยไม่แยกแยะว่าเงินก้อนนี้เข้ามาผ่านขั้นตอนการฝากปกติหรือไม่
การออกแบบแบบนี้เท่ากับเปิดประตูหลังไว้ ตราบใดที่มีคนยอมบริจาคสินทรัพย์ให้ Ark โดยตรงโดยไม่ผ่านช่องทางฝากปกติ totalAssets() ก็ยังคงนับเงินก้อนนี้รวมเข้าไป ดันมูลค่าของแต่ละ Share ให้สูงขึ้นวิธีการของผู้โจมตีเรียบง่ายมาก คือสะสม Share ด้วยต้นทุนต่ำก่อน แล้วบริจาคสินทรัพย์เข้าไปเพื่อดันราคาต่อหน่วยให้สูงขึ้น สุดท้ายเอา Share ที่มีอยู่ไปแลกเป็นเงินก้อนที่ถูกปั่นให้พองแล้วโดยไม่ต้องขโมยเงินสักบาทเดียวที่อยู่ใน Vault เดิม。จุดเจาะช่องโหว่นี้ คือแก่นแท้ของเหตุการณ์ทั้งหมด
ทำไม Flash Loan ถึงทำการปั่นตัวเลขทั้งชุดให้เสร็จภายในบล็อกเดียวได้
ถ้าไม่มี Flash Loan วิธีการปั่นตัวเลขข้างต้นจะเกิดขึ้นได้ยากมาก เพราะผู้โจมตีต้องเตรียมเงินต้นก้อนใหญ่ไว้ล่วงหน้าเพื่อสะสม Share และปั่นสินทรัพย์ให้พอง ต้นทุนเงินทุนสูงและความเสี่ยงก็สูงตาม Flash Loan แก้ปัญหานี้ได้พอดี—กู้เงินก้อนมหาศาลมาในพริบตา แล้วทำทุกอย่างให้เสร็จภายในบล็อกเดียวกัน ทั้งสะสม Share บริจาคสินทรัพย์ ไถ่ถอนทำกำไร แล้วคืนเงินกู้พร้อมดอกเบี้ยครบถ้วน ทั้งกระบวนการเสร็จสิ้นในคราวเดียว
นี่คือเหตุผลที่การโจมตีแบบนี้มักจบลงภายในไม่กี่วินาที หรือแค่บล็อกเดียว คุณแทบไม่มีเวลาตอบสนองเลยสำหรับผู้ใช้ทั่วไปจุดสำคัญไม่ใช่การเข้าใจวิธีปล่อย Flash Loan แต่คือการเข้าใจเรื่องหนึ่งนั่นคือการออกแบบ Vault ที่พึ่งพาการคำนวณสินทรัพย์รวมแบบเรียลไทม์ และยังเปิดให้บริจาคเงินเข้าจากภายนอกโดยตรง ในทางทฤษฎีก็มีโอกาสถูกเล็งด้วยวิธีเดียวกันได้นี่ก็เป็นเหตุผลที่บริษัทตรวจสอบ (Audit) ในช่วงหลังให้ความสำคัญเป็นพิเศษกับรูปแบบการโจมตี「ทำกำไรให้เสร็จภายในบล็อกเดียว」แบบนี้
เหตุการณ์ 6 ล้านดอลลาร์ของ Summer.fi เกิดขึ้นได้อย่างไรกันแน่? แกะรอยขั้นตอนการโจมตีด้วย Flash Loan ทั้งหมด
หลังจากเข้าใจหลักการแล้ว การโจมตี Summer.fi ครั้งนี้เกิดขึ้นทีละขั้นตอนอย่างไรกันแน่? เมื่อย้อนดูกระบวนการทั้งหมด คุณจะพบว่าแต่ละขั้นตอนสอดคล้องกับช่องโหว่ที่พูดถึงก่อนหน้านี้อย่างแม่นยำนี่คือแผนที่คำนวณผลตอบแทนของแต่ละขั้นตอนไว้ล่วงหน้าอย่างครบถ้วน ตั้งแต่กู้เงิน ปั่นตัวเลข ไปจนถึงทำกำไรและฟอกเงินแทบจะราบรื่นเป็นชิ้นเดียว ไม่เหมือนการคิดสดหน้างานเลย。แกะขั้นตอนทั้งสามนี้ให้ดี คุณจะเข้าใจชัดขึ้นว่าทำไมการโจมตีแบบนี้ถึงป้องกันได้ยากมาก
ขั้นที่ 1: กู้ Flash Loan 65.4 ล้านดอลลาร์มาสะสม Share ของ Silo ก่อน
ขั้นตอนแรกของผู้โจมตีคือกู้ Flash Loan มา 65.4 ล้านดอลลาร์ เงินก้อนนี้ไม่ได้เอาไปโจมตี Vault โดยตรง แต่เอาไปซื้อสินทรัพย์ตัวหนึ่งชื่อSilo: Varlamore USDC Growthก่อน สะสมจนได้ Share จำนวนหนึ่งขั้นตอนนี้ดูเหมือนเป็นแค่การซื้อขายในตลาดปกติไม่ได้ใช้ช่องโหว่ใดๆ และไม่ได้กระตุ้นสัญญาณเตือนใดๆ เพราะโปรโตคอลเองก็อนุญาตให้ผู้ใช้ซื้อสินทรัพย์ตัวนี้ได้อยู่แล้วจากบันทึกบนเชน ขั้นตอนนี้เองถูกต้องตามกฎทุกอย่าง เพิ่งถูกปะติดปะต่อความเชื่อมโยงกับการปั่นตัวเลขในภายหลัง ตอนที่มีการแกะรอยกระบวนการโจมตีย้อนหลัง
ขั้นตอนนี้เป็นการปูทางให้การปั่นตัวเลขในขั้นต่อไป ทำให้ตัวเองถือ Share ในมือมากพอ จึงจะมีทุนพอที่จะได้ประโยชน์สูงสุดจาก Share เหล่านี้หลังจากมูลค่าสินทรัพย์ถูกปั่นให้พองแล้ว ถ้าไม่สะสมขั้นตอนนี้ไว้ก่อน ต่อให้ปั่น totalAssets() สำเร็จ ผู้โจมตีก็จะได้ประโยชน์ไม่มากนัก แผนทั้งหมดก็ใช้ไม่ได้
ขั้นที่ 2: บริจาคเข้า Ark เพื่อปั่น totalAssets() ของ FleetCommander ให้พอง
หลังจากได้ Share มาแล้ว ผู้โจมตีก็เอาสินทรัพย์ที่สะสมไว้บริจาคเข้าสัญญา Ark โดยตรง ข้ามขั้นตอนฝากเงินปกติไปเลย ตามที่พูดไปก่อนหน้านี้ วิธีคำนวณ totalAssets() ของ FleetCommander ไม่ได้แยกแยะระหว่าง「การฝากตามปกติ」กับ「การบริจาคโดยตรง」สินทรัพย์ที่ถูกบริจาคเข้ามาก้อนนี้ ถูกนับรวมเข้าไปในสินทรัพย์รวมของ Vault ทันที
สินทรัพย์รวมของ Vault พุ่งขึ้นทันที แต่จำนวน Share ที่หมุนเวียนอยู่ไม่ได้เพิ่มตาม ผลคือมูลค่าสินทรัพย์ที่แต่ละ Share แลกได้ถูกดันขึ้นอย่างจงใจขั้นตอนนี้คือการปั่นตัวเลขที่สำคัญที่สุดของเหตุการณ์ทั้งหมด ส่วนก่อนหน้านี้การสะสม Share เป็นแค่การเตรียมการตรงนี้ต่างหากคือแก่นแท้ของการแตะต้องตัวเลขบัญชีจำนวนผู้ฝากมากน้อยแค่ไหน หรือสภาวะตลาด ล้วนไม่เกี่ยวข้องกับกระบวนการปั่นตัวเลขนี้เลย ทั้งกระบวนการก็ไม่ได้ใช้สิทธิ์ประตูหลังใดๆ เป็นเพียงช่องโหว่ในตรรกะการคำนวณที่ถูกจับได้และถูกขยายผลใช้ประโยชน์
ขั้นที่ 3: ไถ่ถอนทำกำไร 70.9 ล้านดอลลาร์ เงินไหลผ่าน Curve แลกเป็น DAI ไปยัง Tornado Cash
หลังจาก totalAssets() ถูกปั่นให้พองแล้ว Share ในมือของผู้โจมตีก็มีมูลค่าสูงขึ้นทันที เขาเอา Share ที่สะสมไว้ก่อนหน้านี้ไปไถ่ถอน แลกกลับมาเป็นสินทรัพย์มูลค่า 70.9 ล้านดอลลาร์หักลบเงินต้นและค่าธรรมเนียม Flash Loan ที่กู้มา 65.4 ล้านดอลลาร์ บวกกับต้นทุนการดำเนินการที่ฝากไว้ก่อนหน้านี้ 64.8 ล้านดอลลาร์ กำไรสุทธิ 6 ล้านดอลลาร์เข้ากระเป๋าไปเต็มๆ และทั้งหมดนี้เกิดขึ้นภายในบล็อกเดียวกันและธุรกรรมเดียวกัน
หลังจากได้กำไรมาแล้ว ผู้โจมตีไม่ปล่อยให้เงินอยู่บนเชนเดิม รีบใช้ Curve แลกสินทรัพย์เป็นเหรียญ Stablecoin อย่าง DAI เพื่อลดความเสี่ยงที่จะถูกติดตามหรือถูกกระดานเทรดอายัด จากนั้นเอา DAI ไปฝากเข้าเครื่องมือผสมเหรียญ (Mixer) อย่าง Tornado Cash เพื่อตัดการติดตามเส้นทางเงิน จนถึงตอนนี้ เงิน 6 ล้านดอลลาร์ก้อนนี้ยังไม่มีความคืบหน้าการกู้คืนที่เปิดเผยต่อสาธารณะ
BONK DAO ก็เกิดเหตุในช่วงเวลาเดียวกัน โปรโตคอลประเภท Vault/Treasury อันตรายเป็นพิเศษหรือไม่?
ในช่วงเวลาเดียวกับที่เหตุการณ์ Summer.fi เกิดขึ้น คลังทุน (Treasury) ของ BONK DAO ก็มีข่าวว่าถูกดูดเงินไปประมาณ 20 ล้านดอลลาร์เช่นกัน สองเหตุการณ์นี้หมายความว่าโปรโตคอลประเภท Vault และ Treasury มีปัญหาง่ายเป็นพิเศษหรือไม่?คำตอบไม่ได้ง่ายขนาดนั้นวิธีการโจมตีของทั้งสองเหตุการณ์แตกต่างกันโดยสิ้นเชิงอันหนึ่งคือช่องโหว่การบันทึกบัญชี อีกอันคือกลไกธรรมาภิบาลถูกหาช่องโหว่เข้าใจความแตกต่างนี้ให้ชัด คุณถึงจะรู้ว่าควรดูอะไรตอนประเมินความเสี่ยงของโปรโตคอล
การโจมตีด้านธรรมาภิบาลของ BONK DAO ต่างจากวิธีการโจมตีของ Summer.fi อย่างไร
ปัญหาของ Summer.fi อยู่ที่สัญญาอัจฉริยะคำนวณสินทรัพย์อย่างไร ส่วนปัญหาของ BONK DAOไม่ได้อยู่ที่ช่องโหว่ในโค้ดเลย แต่อยู่ที่กลไกการลงคะแนนเสียงด้านธรรมาภิบาลเอง。ผู้โจมตีใช้เงินเพียงประมาณ 4 ล้านดอลลาร์ซื้อเหรียญ BONKสะสมน้ำหนักโหวตให้เพียงพอ แล้วนำไปสนับสนุนข้อเสนอที่มีเจตนาร้าย โอนเหรียญ BONK ในคลัง Treasury มูลค่าประมาณ 20 ล้านดอลลาร์ หรือคิดเป็นจำนวนสูงถึง 4.426 ล้านล้านเหรียญ ไปยังกระเป๋าเงินที่ตัวเองควบคุมอยู่
ทั้งกระบวนการดำเนินไปตามกฎของโปรโตคอลอย่างครบถ้วนจนจบขั้นตอนการโหวต ไม่ได้แฮกเข้าระบบใดๆ และไม่ได้ใช้คีย์ส่วนตัวใดๆ เลย ปัญหาอยู่ที่ข้อเสนอนั้นไม่ถูกสกัดกั้น นี่คล้ายกับรูปแบบ「ใช้ฟังก์ชันปกติ ปั่นตัวเลข」ของ Summer.fi ล้วนเป็นการหาช่องโหว่จากกฎเกณฑ์เอง เพียงแต่ Summer.fi หาช่องจากตรรกะการบันทึกบัญชี ส่วน BONK DAO หาช่องจากเกณฑ์การโหวต
การโจมตีด้านธรรมาภิบาลกับช่องโหว่สัญญาอัจฉริยะ อะไรป้องกันยากกว่ากัน
ในแง่ความยากของการป้องกัน ช่องโหว่ในสัญญาอัจฉริยะอย่างน้อยก็ยังตรวจจับได้ด้วยการตรวจสอบ (Audit) การจำลองบน Testnet และการรีวิวโค้ด เพราะช่องโหว่ถูกเขียนตายตัวอยู่ในโค้ด ตราบใดที่มีคนยอมเสียเวลาตรวจสอบ ในทางทฤษฎีก็จับได้ส่วนความยุ่งยากของการโจมตีด้านธรรมาภิบาลคือกลไกการโหวตเองไม่ได้ผิดอะไร ที่ผิดคือไม่ได้ออกแบบ Time Lockเกณฑ์องค์ประชุมขั้นต่ำ (Quorum) และการตรวจสอบด้วยหลายลายเซ็น (Multisig) ซึ่งเป็นกลไกความปลอดภัยเหล่านี้ไว้
ครั้งนี้ BONK DAO ไม่มี Time Lock เลย พอข้อเสนอผ่านก็ดำเนินการทันที ไม่เปิดโอกาสให้ใครตอบสนองได้ทัน และก็ไม่มีเกณฑ์องค์ประชุมขั้นต่ำ ทำให้คนที่ใช้เงินแค่ 4 ล้านดอลลาร์สามารถกำหนดทิศทางการตัดสินใจของคลังทุนมูลค่า 20 ล้านดอลลาร์ได้ เมื่อเทียบกันแล้ว การโจมตีด้านธรรมาภิบาลแก้ไขด้วยแพตช์ภายหลังได้ยากกว่า เพราะปัญหาอยู่ที่แนวคิดการออกแบบกลไกการตัดสินใจทั้งระบบ ไม่ใช่แค่แก้โค้ดไม่กี่บรรทัดแล้วจบ
จะดูอย่างไรว่าการออกแบบ Vault/Treasury ของโปรโตคอลมีตัวรองรับความเสี่ยงหรือไม่
เมื่อเจอโปรโตคอลประเภท Vault หรือ Treasury คุณสามารถดูสามเรื่องนี้ก่อนได้ อย่างแรก ตรรกะการคำนวณสินทรัพย์ได้รับผลกระทบจากเงินที่บริจาคเข้ามาโดยตรงจากภายนอกหรือไม่ อย่างที่สอง การดำเนินการสำคัญมี Time Lock ให้ชุมชนมีเวลาตอบสนองหรือไม่ อย่างที่สาม ข้อเสนอด้านธรรมาภิบาลมีเกณฑ์องค์ประชุมขั้นต่ำและการตรวจสอบด้วยหลายลายเซ็นหรือไม่ เพื่อป้องกันไม่ให้คนกลุ่มน้อยกำหนดทิศทางเงินทุนก้อนใหญ่ได้
ถ้าทั้งสามข้อนี้ไม่มีเลย แปลว่าโปรโตคอลให้「ประสิทธิภาพ」มาก่อน「ระบบเบรกความปลอดภัย」พอมีคนหาช่องโหว่เจอ ก็จะไม่มีตัวรองรับใดๆ ให้เวลาแก้ไขได้เลยคุณไม่จำเป็นต้องเข้าใจรายละเอียดโค้ด แต่ผมแนะนำให้สร้างนิสัยอย่างน้อยที่สุด คือก่อนฝากเงินให้ลองไปดูเอกสารธรรมาภิบาลและคำอธิบายการออกแบบสัญญาของโปรโตคอลว่ามีพูดถึงกลไกเหล่านี้หรือไม่ นี่คือวิธีที่ตรงไปตรงมาและประหยัดแรงที่สุดในการประเมินสุขภาพของโปรโตคอล
หลังเกิดเหตุ สถานะเงินทุนของผู้ใช้ที่ได้รับผลกระทบและการจัดการดำเนินไปถึงขั้นไหนแล้ว?
หลังจากเงินถูกขโมยไป โปรโตคอลมักจะออกประกาศทันทีว่าได้จัดการแล้วหรือกำลังสอบสวนอยู่ แต่คำเหล่านี้แปลว่าความคืบหน้าจริงๆ อยู่ตรงไหนกันแน่?ช่วงนี้จะสรุปว่า Summer.fi และ BONK DAO แต่ละรายดำเนินไปถึงขั้นไหนแล้ว ให้คุณรู้ว่าการกระทำอย่าง「ระงับ」「อายัด」「แจ้งเตือน」เหล่านี้ จะช่วยให้ได้เงินคืนจริงหรือไม่
ความคืบหน้าการจัดการของ Summer.fi ในตอนนี้ (การระงับ Vault และการติดตามเส้นทางเงิน)
guardian ของโปรโตคอล Summer.fi หลังเกิดเหตุก็รีบระงับ Vault ทั้งหมดภายใต้Lazy Summer Protocolทันที เพื่อป้องกันไม่ให้ช่องโหว่ถูกใช้ซ้ำและขยายความเสียหาย นักวิจัยอิสระทยอยเผยแพร่การวิเคราะห์ ยืนยันว่าการโจมตีครั้งนี้อาศัยฟังก์ชันที่ถูกกฎหมายอย่างการฝาก การไถ่ถอน และการถอนเงินจาก Ark เท่านั้น ไม่ได้เกี่ยวข้องกับคีย์ส่วนตัวรั่วไหลหรือสิทธิ์ผู้ดูแลระบบเลย
จนถึงตอนนี้ Summer.fi อย่างเป็นทางการยังไม่ได้ออกแถลงการณ์เกี่ยวกับเหตุการณ์นี้ การติดตามเส้นทางเงินส่วนใหญ่มาจากการสังเกตอย่างต่อเนื่องของชุมชนนักวิเคราะห์ On-chain ที่ยืนยันว่าเงิน 6 ล้านดอลลาร์ที่ถูกขโมยไปถูกแลกผ่าน Curve เป็น DAI แล้วไหลเข้าสู่ Tornado Cash ในที่สุดการระงับ Vault แก้ปัญหาแค่「ไม่ให้เสียเลือดต่อ」ไม่ได้แปลว่ากู้คืนสินทรัพย์ก้อนไหนมาได้แล้ว。
ความคืบหน้าของ BONK DAO (กระดานเทรดระงับฝากถอน แจ้งหน่วยงานบังคับใช้กฎหมาย)
ฝั่ง BONK DAO ดำเนินการเชิงรุกมากกว่า ทีมงานเปิดเผยว่ากำลังประสานงานกับมูลนิธิ Solana และกระดานเทรดหลายแห่ง เพื่อติดตามและอายัดเงินที่ไหลเข้ากระดานเทรด พร้อมกับเริ่มแจ้งหน่วยงานบังคับใช้กฎหมายเกี่ยวกับการโจมตีด้านธรรมาภิบาลครั้งนี้ เหรียญ BONK บางส่วนที่ถูกขโมยไป ถูกสังเกตเห็นว่าเริ่มเคลื่อนย้ายไปยังที่อยู่ของกระดานเทรดแล้ว แสดงว่าผู้โจมตีอาจกำลังเตรียมแปลงเป็นเงินสด
การที่กระดานเทรดระงับฝากถอนและหน่วยงานบังคับใช้กฎหมายเข้ามาสอบสวน สามารถทำให้ผู้โจมตีแปลงเป็นเงินสดได้ช้าลง และเพิ่มโอกาสกู้คืนเงินทุนบางส่วนได้ในภายหลัง แต่ทั้งหมดนี้ไม่ได้เป็นการรับประกันว่า「เงินได้คืนแล้ว」。BONK ร่วงลงประมาณ 8% ถึง 10% จากเหตุการณ์นี้ สำหรับผู้ถือเหรียญหรือผู้ที่เคยนำเงินไปฝากในระบบธรรมาภิบาลของคลังทุน นี่คือความเสียหายที่เกิดขึ้นจริง ไม่ได้หายไปเองแค่เพราะทางการออกแถลงการณ์
ทำไมเงินถูกอายัด/ทำเครื่องหมาย ไม่เท่ากับจะได้เงินคืนแน่นอน
การที่กระดานเทรดอายัดบัญชี หรือนักวิเคราะห์ On-chain ทำเครื่องหมายที่อยู่กระเป๋าเงิน ฟังดูเหมือนมีความคืบหน้า แต่จะกู้คืนเงินทุนได้หรือไม่ ขึ้นอยู่กับหลายเงื่อนไข เช่น ผู้โจมตีโอนสินทรัพย์ไปยังกระดานเทรดที่ยอมให้ความร่วมมือในการสอบสวนหรือไม่ ผ่านเครื่องมือผสมเหรียญเพื่อตัดการติดตามไปก่อนหรือไม่ และหน่วยงานบังคับใช้กฎหมายในพื้นที่มีความสามารถและความเต็มใจในการร่วมมือข้ามพรมแดนหรือไม่
เงิน 6 ล้านดอลลาร์ของ Summer.fi เข้าไปอยู่ใน Tornado Cash แล้ว—เครื่องมือประเภทนี้มีอยู่เพื่อทำให้การติดตามเส้นทางเงินใช้ไม่ได้ผล ความยากในการกู้คืนในภายหลังจึงเพิ่มขึ้นมาก ในทางกลับกัน BONK DAO เนื่องจากเงินทุนบางส่วนยังไม่ได้ถูกโอนออกไปหมด โอกาสที่จะถูกกระดานเทรดสกัดไว้ได้จึงสูงกว่าจริงๆคำว่า「กำลังอายัด」「กำลังสอบสวน」เหมือนกัน แต่เบื้องหลังนั้นโอกาสกู้คืนอาจแตกต่างกันราวฟ้ากับดินมือใหม่ไม่ควรเหมารวมว่าเหมือนกันหมด
ก่อนฝากเงินเข้า Vault ของ DeFi ข้อผิดพลาดในการตัดสินใจ 3 อย่างที่มือใหม่มักทำ
ดูสองเหตุการณ์นี้จบแล้ว คุณอาจคิดว่าไม่ยุ่งกับผลิตภัณฑ์ประเภท Vault เลยจะปลอดภัยกว่าไหม แต่จริงๆ แล้วจุดสำคัญไม่ได้อยู่ที่จะยุ่งหรือไม่ยุ่ง แต่อยู่ที่ก่อนฝากเงินคุณตัดสินใจถูกหรือไม่หลายคนที่พลาดไม่ใช่เพราะเงินทุนไม่ระมัดระวังพอ แต่เพราะวิธีประเมินโปรโตคอลใช้ตัวชี้วัดผิดตั้งแต่แรกแล้วช่วงนี้จะสรุปข้อผิดพลาดในการตัดสินใจที่พบบ่อยที่สุด 3 อย่าง ช่วยปรับทัศนคติของคุณให้ถูกต้อง
ข้อผิดพลาดที่ 1: ดูแค่ APY โดยไม่ดูองค์ประกอบสินทรัพย์เบื้องหลังและการออกแบบเลเวอเรจของ Vault
ตัวเลข APY ที่สวยงาม เป็นเกณฑ์ตัดสินใจข้อแรกหรือแม้แต่ข้อเดียวที่หลายคนใช้ตัดสินใจว่าจะฝากเงินหรือไม่แต่ APY บอกคุณแค่「คาดว่าจะได้กำไรเท่าไหร่」เท่านั้น—ไม่บอกเลยว่าผลตอบแทนนี้มาจากไหนมาจากส่วนต่างดอกเบี้ยเงินกู้เบื้องหลัง การใช้เลเวอเรจ หรือมาจากกลไกบางอย่างที่ต้องมีเงินใหม่เข้ามาต่อเนื่องถึงจะพยุงอยู่ได้แหล่งที่มาของผลตอบแทนต่างกัน ความเสี่ยงที่ต้องแบกรับก็ต่างกันราวฟ้ากับดิน
Vault ของ Summer.fi เองก็กระจายเงินทุนไปยังโมดูลกลยุทธ์ Ark หลายตัวเพื่อหาผลตอบแทน ยิ่งโมดูลกลยุทธ์มากขึ้น เชื่อมต่อกับโปรโตคอลกู้ยืมที่ซับซ้อนมากขึ้นเท่าไหร่ พื้นที่ที่ระบบเสี่ยงถูกโจมตีก็ยิ่งกว้างขึ้นเท่านั้น ซึ่งเป็นคนละเรื่องกับ APY สูงหรือต่ำโดยสิ้นเชิง ก่อนฝากเงินลองใช้เวลาสิบนาทีไปดูคำอธิบายการจัดสรรสินทรัพย์ของ Vault จะช่วยให้คุณประเมินความเสี่ยงได้ดีกว่าการจ้องแค่ตัวเลข APY มาก
ข้อผิดพลาดที่ 2: คิดว่าโปรโตคอลชื่อดังรับรอง = สัญญาอัจฉริยะไม่มีความเสี่ยงเลย
Summer.fi ไม่ใช่โปรโตคอลเล็กๆ ที่ไม่มีใครรู้จัก เบื้องหลังมีชื่อเสียงและขนาดเงินทุนระดับหนึ่ง นี่ก็เป็นเหตุผลที่ผู้ใช้จำนวนไม่น้อยยอมฝากเงินเข้าไปตั้งแต่แรกแต่เหตุการณ์ครั้งนี้พิสูจน์ให้เห็นว่าชื่อเสียงและภูมิหลังของทีมไม่ได้เท่ากับโค้ดไม่มีช่องโหว่เลยแม้แต่ทีมที่มีประสบการณ์มากที่สุดก็ยังอาจทิ้งช่องโหว่ในตรรกะการคำนวณสินทรัพย์ที่ยังไม่ถูกค้นพบไว้ได้ยิ่งขนาดใหญ่ คนใช้เยอะ กลับยิ่งทำให้คนการ์ดตก ลืมทำการบ้านด้านความปลอดภัยขั้นพื้นฐานที่สุด
การเอา「ทุกคนก็ใช้กันอยู่」「เปิดมานานแล้ว」มาเป็นหลักประกันความปลอดภัยเพียงอย่างเดียว คือกับดักทางความคิดที่พลาดง่ายที่สุด วิธีที่เป็นจริงมากกว่าคือไปดูว่าโปรโตคอลมีการตรวจสอบ (Audit) เป็นประจำหรือไม่ รายงานการตรวจสอบเปิดเผยโปร่งใสแค่ไหน เคยมีประวัติ Bug Bounty หรือเปล่า ตัวผมเองเวลาประเมินโปรโตคอลใหม่ จะหารายงานการตรวจสอบก่อนเสมอ ถ้าหาไม่เจอก็ข้ามไปเลย
ข้อผิดพลาดที่ 3: มองข้ามว่าปุ่มระงับฉุกเฉินเองก็คือการที่โปรโตคอลยอมรับว่ามีความเสี่ยง
โปรโตคอล DeFi กระแสหลักแทบทุกตัวมีกลไกระงับฉุกเฉิน ให้ guardian สามารถสั่งหยุดได้ทันทีเมื่อตรวจพบความผิดปกติ เพื่อป้องกันไม่ให้ความเสียหายขยายตัว การออกแบบแบบนี้จริงๆ แล้วกำลังบอกคุณเรื่องหนึ่ง คือทีมโปรโตคอลเองก็คิดว่าระบบมีโอกาสผิดพลาดได้ ถึงต้องเผื่อระบบเบรกนี้ไว้ ลองมองอีกมุมหนึ่ง ถ้าระบบหนึ่งไม่มีทางผิดพลาดได้เลย ก็ไม่จำเป็นต้องออกแบบปุ่มฉุกเฉินแบบนี้ตั้งแต่แรก
หลายคนพอเห็นว่า「มีกลไกระงับ」กลับรู้สึกอุ่นใจ เข้าใจผิดว่ามีคนคอยจับตาดูตลอดเวลาและเงินทุนปลอดภัยแน่นอนแต่กลับมองข้ามไปว่าเงื่อนไขที่ทำให้กลไกระงับนี้มีอยู่ ก็เพราะความเสี่ยงมีอยู่จริงตั้งแต่แรก。ก่อนฝากเงินลองเปลี่ยนมุมมองดูสักนิด ถ้าแม้แต่โปรโตคอลเองยังเผื่อระบบเบรกฉุกเฉินไว้ คุณได้เผื่อระบบเบรกให้เงินทุนของตัวเองไว้บ้างหรือยัง เช่น กระจายไปหลายโปรโตคอล หรือตั้งค่าแจ้งเตือนติดตามสินทรัพย์?
เช็คลิสต์ป้องกันตัวเองที่ผู้ใช้ทั่วไปทำได้ ลดความเสี่ยงให้เหลือน้อยที่สุด
พูดถึงความเข้าใจผิดและช่องโหว่มาเยอะแล้ว กลับมาที่คำถามที่เป็นจริงที่สุด คือคุณทำอะไรได้บ้าง เพื่อลดความเสี่ยงให้อยู่ในระดับที่ตัวเองยอมรับได้?ช่วงนี้จะสรุปสิ่งที่ควรทำในสามช่วง คือก่อนฝากเงิน ระหว่างฝากเงิน และตอนเกิดเหตุ ช่วยเปลี่ยนความตระหนักด้านความเสี่ยงที่เป็นนามธรรม ให้เป็นการกระทำที่จับต้องได้และทำตามได้จริง ต่อไปเราจะเรียงตามลำดับเวลาไปทีละขั้นตอน
ก่อนฝากเงิน ตรวจสอบรายงานการตรวจสอบและประวัติ Bug Bounty ของโปรโตคอลอย่างไร
ก่อนฝากเงินเข้า Vault ไหนก็ตาม ให้ใช้เวลาตรวจสอบสามเรื่องนี้ก่อน คือโปรโตคอลเคยให้บริษัทตรวจสอบชื่อดังทำการตรวจสอบหรือไม่ รายงานการตรวจสอบเปิดเผยให้ตรวจดูได้หรือไม่ มีโครงการ Bug Bounty ที่ดำเนินการมาต่อเนื่องระยะยาวหรือไม่ ข้อมูลเหล่านี้มักหาได้จากเว็บไซต์หรือเอกสารทางการของโปรโตคอล ถ้าโปรโตคอลใดไม่มีรายงานการตรวจสอบให้ดูเลย หรือโครงการรางวัลมีแต่ในนาม คุณควรเพิ่มความระมัดระวัง จำนวนเงินรางวัลสอดคล้องกับขนาดเงินทุนที่โปรโตคอลบริหารอยู่อย่างสมเหตุสมผลหรือไม่ ก็เป็นเรื่องที่ควรสังเกตด้วย
การตรวจสอบไม่ใช่ยาวิเศษช่องโหว่ของ Summer.fi ก่อนเกิดเหตุก็ไม่ใช่ว่าไม่เคยถูกตรวจสอบเลย แต่อย่างน้อยประวัติการตรวจสอบและ Bug Bounty ก็สะท้อนได้ว่าทีมโปรโตคอลยินดีทุ่มทรัพยากรหาช่องโหว่หรือไม่การตรวจสอบเรื่องนี้ใช้เวลาไม่มาก แต่ช่วยคัดกรองโปรโตคอลจำนวนมากที่ไม่ได้ทำการบ้านพื้นฐานเลยออกไปได้
ระหว่างฝากเงิน กระจายการลงทุนและตั้งค่าแจ้งเตือนติดตามสินทรัพย์
ต่อให้คุณคัดกรองโปรโตคอลมาแล้ว ก็ไม่แนะนำให้เอาเงินทุนทั้งหมดไปกระจุกไว้ใน Vault เดียว การกระจายไปยังโปรโตคอลและประเภทสินทรัพย์ที่แตกต่างกัน ช่วยลดความเสี่ยงที่ช่องโหว่เดียวจะทำให้เงินทุนทั้งหมดของคุณเหลือศูนย์ในคราวเดียวได้อย่างมีประสิทธิภาพ ตรรกะนี้เหมือนกับการลงทุนแบบดั้งเดิมที่ว่า「อย่าใส่ไข่ทั้งหมดไว้ในตะกร้าใบเดียว」ทุกประการ เพียงแต่ตะกร้าของ DeFi เปลี่ยนมาเป็นสัญญาอัจฉริยะแทน
นอกจากนี้ แนะนำให้ตั้งค่าแจ้งเตือนติดตามสินทรัพย์ของตัวเอง เช่น ตัวชี้วัดอย่างการเปลี่ยนแปลงผิดปกติของ totalAssets() ของ Vault หรือธุรกรรมเดี่ยวที่มีมูลค่าสูงเกินไป พอถูกกระตุ้นก็จะแจ้งเตือนคุณทันทีเครื่องมือติดตามแบบนี้ในแพลตฟอร์มวิเคราะห์ On-chain มักตั้งค่าได้ด้วยตัวเอง แม้จะป้องกันการโจมตีไม่ได้ แต่ช่วยให้คุณรู้ความผิดปกติได้ทันทีแทนที่จะมาเห็นข่าวทีหลังแล้วถึงรู้ว่าตัวเองก็เป็นหนึ่งในเหยื่อด้วย。
3 สิ่งที่ควรทำทันทีเมื่อเกิดเหตุ
ถ้าโปรโตคอลที่คุณฝากเงินไว้เกิดเหตุขึ้นจริง ตื่นตระหนกไปก็ไม่ช่วยอะไร การจัดการตามลำดับขั้นตอนที่แน่นอนต่างหากที่จะควบคุมความเสียหายให้อยู่ในขอบเขตน้อยที่สุด และยังเก็บหลักฐานที่จำเป็นสำหรับการเรียกร้องค่าเสียหายหรือช่วยการสอบสวนในภายหลังได้ต่อไปนี้คือ 3 สิ่งที่แนะนำให้ทำตามลำดับ:
- ตรวจสอบสถานะสินทรัพย์ของตัวเองทันที: ดูประกาศทางการและบันทึกกระเป๋าเงินบน Blockchain Explorer เพื่อยืนยันว่าเงินทุนได้รับผลกระทบจริงหรือไม่ ป้องกันไม่ให้ตัวเองตกใจไปเอง และป้องกันไม่ให้พลาดส่วนที่ได้รับผลกระทบ
- แคปหน้าจอเก็บบันทึกธุรกรรมและประกาศทางการทั้งหมด: รวมถึงเวลาที่เกิดการโจมตี จำนวนเงิน บันทึกการฝากถอนของตัวคุณเอง ข้อมูลเหล่านี้ไม่ว่าจะใช้ในการให้ความร่วมมือกับการสอบสวนของโปรโตคอลในภายหลัง หรือแจ้งความกับหน่วยงานบังคับใช้กฎหมาย ล้วนเป็นหลักฐานประกอบที่จำเป็น
- ติดตามช่องทางทางการ ไม่ใช่ข่าวลือในชุมชน: ช่วงที่โปรโตคอลระงับการทำงาน มักมีการฉ้อโกงซ้ำซ้อนอย่างแอดมินปลอมหรือลิงก์เคลมค่าเสียหายปลอม ควรยืนยันความคืบหน้าล่าสุดผ่านช่องทางที่ได้รับการยืนยันจากทางการเท่านั้น อย่ากดลิงก์「ช่วยกู้คืนเงินทุน」ที่ส่งมาทางข้อความส่วนตัวเด็ดขาด
ทำสามเรื่องนี้ให้เสร็จก่อน แล้วถึงจะมาประเมินว่าจะถือส่วนอื่นต่อไปหรือไม่ จะปรับการจัดสรรสินทรัพย์หรือไม่สิ่งที่ห้ามทำที่สุดตอนเกิดเหตุ คือรีบร้อนหาทางแก้แบบไม่ทันคิด เชื่อบริการ「รับกู้คืนเงินทุน」ที่ไม่รู้ที่มาแบบมั่วๆ ซึ่งจะยิ่งทำให้ตัวเองตกเป็นเหยื่อซ้ำสอง
บทสรุป
เหตุการณ์ Summer.fi ครั้งนี้ ตั้งแต่ต้นจนจบไม่มีขั้นตอนไหนใช้วิธีบุกรุกแบบที่เห็นในหนังแฮกเกอร์เลย อาศัยแค่ฟังก์ชันที่โปรโตคอลเปิดให้ใช้เอง บวกกับช่องโหว่การบันทึกบัญชีที่ไม่มีใครจับได้ บทเรียนของ BONK DAO ก็เหมือนกัน ปัญหาไม่ได้อยู่ที่โค้ดถูกเจาะ แต่อยู่ที่กฎเกณฑ์เองมีช่องโหว่หลงเหลืออยู่จุดประสงค์ของบทความนี้ไม่ใช่ให้คุณหันหลังให้ Vault ของ DeFi ไปตลอดกาลแต่เพื่อเตือนคุณว่าก่อนฝากเงิน เสียเวลาสิบนาทีเพิ่มไปตรวจสอบ Audit และดูการออกแบบธรรมาภิบาล คุ้มค่ากว่าการมาตามหาเงินของตัวเองในบันทึกของ Tornado Cash ทีหลังมากนัก
