สำรวจหลักการทางเทคนิคเบื้องหลังช่องโหว่สุ่มตัวเลข: เกมตอบคำถาม EOS.WIN ถูกแฮ็กได้อย่างไร

ในเดือนที่ผ่านมา บริษัทรักษาความปลอดภัยบล็อกเชน PeckShield ได้ค้นพบและเปิดเผยว่าเกมตอบคำถาม EOS มากกว่า 8 เกม เช่น EOSBet, EOSCast, FFgame, EOSDice, EOSWin, MyEosVegas, LuckyGo และ EOS Lelego ถูกแฮ็ก และแฮ็กเกอร์ได้ทำการ กำไรรวม 170,503.5 EOS จากราคาเฉลี่ยในตลาดก่อนหน้านี้ที่ 35 หยวนต่อชิ้น แฮ็กเกอร์ทำกำไรได้มากกว่า 5,967,662.5 หยวนจากเกมดังกล่าว ซึ่งคุกคามระเบียบระบบนิเวศ EOS ปกติอย่างร้ายแรง

เจ้าหน้าที่รักษาความปลอดภัยของ PeckShield ได้ดึงคุณลักษณะการโจมตีของเกมต่างๆ ออกมา และในเบื้องต้นพบว่า: 1. มีกลุ่มแฮ็กเกอร์หลายกลุ่มที่อยู่เบื้องหลังผู้โจมตีที่ดำเนินการโจมตีแบบเป็นระบบและกำหนดเป้าหมาย 2. สาเหตุส่วนใหญ่ของการโจมตีที่ประสบความสำเร็จเกี่ยวข้องกับช่องโหว่จำนวนสุ่ม ; 3. การโจมตีในลักษณะเดียวกันนี้อาจเกิดขึ้นบ่อยขึ้น และประสิทธิภาพการโจมตีของพวกมันจะแสดงสัญญาณของการค่อยๆ ดีขึ้น

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

เมื่อวันที่ 12 พฤศจิกายน ตามข้อมูลของแพลตฟอร์มการรับรู้สถานการณ์ของ PeckShield: ตั้งแต่ 08:59 น. ถึง 09:00 น. ในตอนเช้า ในเวลาไม่ถึงนาที แฮกเกอร์เปิดการโจมตี 10 ครั้งในสัญญาเกม EOS.WIN (eosluckydice) ซึ่งทำรายได้มากขึ้น มากกว่า 9,180 EOS . เจ้าหน้าที่รักษาความปลอดภัยของ PeckShield ติดตามและวิเคราะห์ว่าแฮ็กเกอร์ทำการทดสอบการโจมตีเล็กน้อยครั้งแรกเมื่อเวลา 22:46 น. เมื่อคืนที่ผ่านมา และหลังจากการโจมตี 165 ครั้งและเชี่ยวชาญในวิธีการโจมตี เขาเลือกที่จะใช้บัญชีที่เกี่ยวข้องหลายบัญชีเพื่อทำการโจมตีอย่างรวดเร็วในเวลา 9:00 น. วันถัดไป. แม้ว่าเกมยังใช้ข้อมูลการทำธุรกรรมสองรายการที่ถูกเลื่อนออกไปซึ่งมีความปลอดภัยมากกว่าเป็นส่วนประกอบของตัวเลขสุ่ม แต่แฮ็กเกอร์ก็ยังข้ามผ่านข้อจำกัดเหล่านี้อย่างชาญฉลาดและดำเนินการโจมตีได้สำเร็จ

หลักการแฮ็กและกระบวนการลอตเตอรี:

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

คำอธิบายภาพ

(ภาพประกอบ 1: ขั้นตอนการจับสลากเกม DICE)

เจ้าหน้าที่รักษาความปลอดภัยของ PeckShield วิเคราะห์และพบว่าหมายเลขสุ่มของสัญญาได้มาจากฟังก์ชัน get_random และปัจจัยที่ส่งผลต่อการสร้างหมายเลขสุ่มคือ: txid คือ ID แฮชของธุรกรรม, ความสูงของบล็อกธุรกรรม tapos_block_num, คำนำหน้า ID บล็อกของ tapos_block_prefix หมายเลขลอตเตอรี่ทั่วโลก bet_id เป็นต้น

เพื่อให้เข้าใจในเชิงลึกยิ่งขึ้น ขั้นแรกให้มีความรู้พื้นฐานบางประการเกี่ยวกับวิทยาศาสตร์ยอดนิยม:

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

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

3. คำนวณ ID แฮชของธุรกรรม: ธุรกรรม (ธุรกรรม) สามารถมีการกระทำหลายอย่างได้ หากข้อมูลพารามิเตอร์การกระทำทั้งหมดได้รับการยืนยัน เมื่อรวมกับข้อมูล tapos_block_prefix (ref_block_prefix) ที่กล่าวมาแล้ว คุณสามารถคำนวณ ID แฮชของธุรกรรมได้ด้วยตัวเอง

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

กระบวนการโจมตีเฉพาะมีดังนี้ (ดังแสดงในรูปด้านล่าง):

1. ผู้โจมตีใช้สัญญาการโจมตี 6 บัญชี เมื่อเรียกใช้วิธีการโจมตี บัญชี 6 บัญชีจะถูกส่งคำขอการทำธุรกรรมในสัญญาการโจมตีพร้อมกัน ดังนั้นคำขอเหล่านี้จะถูกวาดในบล็อกเดียวกัน เนื่องจากกระบวนการนี้สอดคล้องกัน ธุรกรรมในธุรกรรมลอตเตอรี tapos_block_num และ tapos_block_prefix เหมือนกัน เฉพาะ bet_id เท่านั้นที่อาจแตกต่างกัน

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

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

คำอธิบายภาพ

(ภาพประกอบ 2: กระบวนการโจมตีหลายบัญชีของผู้โจมตี)

ความน่าจะเป็นที่จะชนะ:

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

คำแนะนำด้านความปลอดภัย:

ในเกมเช่น EOS.Win หมายเลขสุ่มจะได้รับผลกระทบจากตัวแปรที่ผู้โจมตีสามารถควบคุมได้ นั่นคือ หมายเลขลอตเตอรีของเกม (bet_id) ดังนั้น PeckShield จึงแนะนำให้นักพัฒนาจำเป็นต้องลบตัวแปรที่ผู้โจมตีควบคุมได้ใน การสร้างตัวเลขสุ่มของ DApp ตัวแปรต่างๆ เช่น หมายเลขลอตเตอรีในเกม เป็นต้น ในขณะที่หลีกเลี่ยงการดำเนินการลอตเตอรีและการดำเนินการแจ้งเตือน (ใบเสร็จรับเงิน) ในการทำธุรกรรมเดียวกัน ดังนั้น จึงหลีกเลี่ยงการย้อนกลับของสถานะการทำธุรกรรม ดังนั้น จึงป้องกันการโจมตีจากแฮ็กเกอร์