สรุปเนื้อหางาน Blockchain Security Level Up 0x00

โดนเอาของสมนาคุณยัดใส่มือมา เลยต้องเขียน เง้ออออ… 555555

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

Blockchain Security Level Up เป็น public knowledge sharing จากทีม Inspex งาน 0x00 เป็นงานแรกเลย โดยครั้งนี้แบ่งเป็น 2 section หลักคือ

1. Hidden Risks in GameFi Era
2. How to Avoid a Lucky Hacker in the NFT Games

Hidden Risks in GameFi Era

เริ่มมาจากการเกริ่นก่อนว่า GameFi เนี่ย มันไม่ใช่เล่นๆ มันมี daily user, volume และ transaction มหาศาลเลย พอ impact ของทาง business มันสูง มันก็ทำให้ risk สูงตามไปด้วย โดยจากการ research ของทาง Inspex พบว่า ในเวลาเพียงแค่ 2 เดือน (Jan-Feb 2022) พบ incident ที่ significant ถึง 13 ครั้ง, มีความสูญเสียรวมมูลค่าประมาณ 48 ล้าน USD, โดย 4 ครั้งเป็น exit scams และ 6 ครั้งเป็น operational mistakes ซึ่งนับเป็น 80% ของ total lost เลยทีเดียว

Operational mistakes

คือความผิดพลาดในระดับ operation ที่พบเจอบ่อย ๆ และควร concern ได้แก่

1. Lack of security awareness — คาดไม่ถึงเรื่อง security
2. Improper key/wallet management — เก็บ key ไม่ดี
3. Human resource — การกรองบุคคลเข้าทำงาน ป้องกัน insider (หรือออกไปแล้ว แต่ไม่ revoke สิทธิต่างๆ)
4. Insufficient SDLC — ยังขาดกระบวนการพัฒนาอย่างปลอดภัย

Exploit

เคสที่เจอบ่อย ๆ ได้แก่ การที่ contract ปลอดภัย แต่ไม่ได้คำนึงถึงความปลอดภัยของ offchain หรือ ส่ง audit เฉพาะ contract บางตัว แต่ตัวที่ใช้งานบางตัวไม่ได้ผ่าน audit ครบทั้งวงจร ทำให้ส่วนที่ไม่ได้ตรวจสอบโดนโจมตีได้

Token audit != Platform audit

การทำ security assessment ที่ดีจึงควรครบทั้งวงจร

• Pentest (offchain)
• Vulnerability assessment (offchain)
• Smart contract audit (onchain)

Exit Scam

ที่พบเจอ มี 3 ประเภท (แต่ก็เป็น scam หมดนั่นแหละ)

1. Mint and Dump — ใน contract มี function ให้ mint ได้ — ใคร mint ได้บ้าง? ถ้าไม่ตรวจสอบให้ดี ก็โดนเขา mint ขึ้นลอย ๆ มาเทขาย มูลค่าหายหมด
2. Pull and Dump — เริ่มจาก seed Liquidity Pool ไว้ แล้วอยู่ดีดีก็ดึง token ออกมาจาก LP pool แล้วเทขาย หรือที่เรียกว่า รัก เอ้ย Rug pull มีทัั้งกรณีที่ชี้แจงแล้วก็มีเหมือนกัน เคสที่พฤติกรรมอาจจะไม่ชัดเจนก็มี ต้องระวังดี ๆ
3. Pull and Mint and Dump — รวมความฉิบหายของสองอันบน

Users Recommendation

• Review code, whitepaper
• Review audit result
• Subscribe to security news (Me: ส่วนตัวผมว่า blognone ก็ใช้ได้นะ)
• Avoid suspicious project, contract
• DYOR (Do Your Own Research) ศึกษาด้วยตัวเองก่อนลงทุน

Developers Recommendation

• Implement operational security controls
• Conduct integrity assessment — เช็คความถูกต้องของตัว contract
• Perform audit
• Security awareness of team — ทีมงานต้องมีความรู้เรื่อง security เช่นกัน

How to Avoid a Lucky Hacker in the NFT Games

เมื่อเราพูดถึง game เนี่ย ก็มักจะมี random เข้ามาเสมอ หัวข้อนี้จะเป็นการพูดถึงธรรมชาติของการ random, ปัญหา, การโจมตี, และวิธีแก้ไข

เริ่มจากการ mint (การสร้าง) NFT เนี่ยมีอยู่ 3 ท่าใหญ่ ๆ คือ

1. Point URI to offchain เก็บข้อมูลไว้ที่ offchain
2. Set NFT Information from offchain ดึงมาจาก offchain อีกที
3. Smart contract mint ให้ทั้งหมด (นั่นหมายถึง process ในการ random จะอยู่บน smart contract ด้วย)

ในหัวข้อนี้ เราจะพูดถึง ข้อ 3 คือการ random บน blockchain

เริ่มจากธรรมชาติการ random ก่อน ใน computer ส่วนใหญ่จะเป็น pseudo random คือ เป็นการคำนวณ function math นั่นแหละ โดยเริ่มจาก seed และ state ที่คาดเดาได้ยาก จนออกมาได้ผลลัพธ์ random สุดท้ายที่คาดเดาได้ยาก แต่ในทางกลับกัน ถ้า seed หรือ state นั้นหลุดออกไป หรือถูกเดาได้ ก็จะถูกเดาผลลัพธ์สุดท้ายได้

แล้ว seed บน blockchain สามารถเป็นอะไรได้บ้างล่ะ ก็คือ data ต่าง ๆ บน blockchain นั่นแหละ แล้วเอามาเข้า hash เช่น keccak256

• blockhash (ถ้าเรียกเอาของ block ปัจจุบันจะได้ค่าเป็น 0)
• coinbase (current miner address)
• difficulty
• gas limit
• number (เลข block)
• timestamp (หน่วยเป็นวินาที เป็น Unix Epoch)

เริ่มจากท่าปกติของการ random ใน mint NFT ก็ไม่มีอะไร จ่ายตัง แล้ว machine contract ก็จะสั่ง mint ให้เรา

แต่เรารู้ว่าใน smart contract เนี่ย เราสามารถ revert transaction ได้เมื่อเกิด error!!

จึงเกิดเป็น Hacker #1 ขึ้นมา

ต่างจากข้างบนแค่ตอนแรกกับตอนสุดท้าย คือ

• ตอนแรก แทนที่จะให้ user call ตรง ๆ ให้มี evil contract คั่นกลางไป call ให้
• ก่อนจบที่ได้ผลลัพธ์ random แล้ว ให้ evil contract ดูเลยว่าพอใจกับผลลัพธ์หรือปล่าว ถ้าไม่พอใจ ก็ revert transaction ทั้งหมด ซึ่งรวมถึงตอนจ่ายตังตอนแรกก็ได้เงินคืนด้วย

ถ้าไปดู transaction จะออกมาอุบาทลูกกะตามาก

วิธีแก้ (ที่ยังไม่ถูกต้อง): Dev เลยใส่เงื่อนไขตรวจสอบเข้าไปว่าห้าม contract เรียก โดยใช้ isContract…

แต่มันไม่เพียงพอ เพราะ isContract นั้นจริง ๆ เช็คจาก code.length อีกที ซึ่งแม้ contract ส่วนใหญ่จะมี แต่ contract ที่ยังสร้างไม่เสร็จ จะยังไม่มี code.length

เกิดเป็น Hacker #2

ย้าย logic การโจมตีทั้งหมด ไปอยู่ในส่วน contract construction แทน

วิธีแก้ (ที่ก็ยังไม่ถูกต้องทั้งหมด): Dev เลยใส่เงื่อนไขตรวจสอบเพิ่ม

Tx.origin == msg.sender

• Tx.origin จะเป็นค่าของคนที่ส่ง transaction ต้องมี private key ซึ่ง contract ไม่มี ค่านี้เลยเป็น 0 (**เฉพาะ ณ ปัจจุบันเท่านั้น**)
• msg.sender คือ evil smart contract

แปลว่าถ้าใช้ smart contract ยิงจะไม่สำเร็จแล้ว!! หรือปล่าว

Hacker #3

ในเมื่อเราใช้ smart contract ไม่ได้ ก็ไม่ต้องใช้ คำนวณ random กันสด ๆ เลยแล้วค่อยยิง ทำได้ไหม

• Timestamp — รู้ เดาได้ เป็นไปได้ไม่กี่ค่าเอง หน่วยวินาที
• block number — รู้
• msg sender — รู้

ดังนั้นเราก็ calculate ก่อน ถ้าโอเคแล้วค่อยยิง โดยให้มัน roll ภายใน block เดียวกัน

ใครอยากไปลองเล่น CTF ก็มี platform ให้ลองด้วย https://gachalab.inspex.co/ (ไม่ต้องถามผมนะ ผมเล่นไม่เป็นนนนน)

Users Recommendation

• Review code ว่าด้านในนั้น random ทำงานยังไง
• Observe mint behavior ของคนอื่น ๆ เช่น ถ้ามี error แปลก ๆ เยอะ ๆ ก็น่าจะมีอะไรผิดปกติ
• Review audit

Developers Recommendation

• ใช้ VRF
• หลีกเลี่ยงการใช้ seed ที่เดาได้

VRF (Verifiable Random Function)

ไอเดียหลัก ๆ เลยคือ เป็น zero-knowledge proof (อันนี้ขออธิบายเอง อาจจะไม่ตรงกับที่พูดในงาน แต่ขอแต๊บรูปมาช่วยอธิบายนะ 555)

• ฝั่ง generator สร้าง function และ proof ขึ้นมา ตัว function เนี่ยเก็บไว้เอง ส่วน proof เปิด public ให้ verifier
• generator รับ seed เข้ามาเป็น parameter สำหรับ function ข้างบน โดยปกติคนให้ seed ก็จะเป็น smart contract
• ได้ผลออกมาเป็น value ค่านึง ส่งกลับไปให้ smart contract ซึ่งสามารถเอา proof และ random value ไปตรวจกับ verifier ได้ว่า generator มันคำนวณ function ได้ถูกต้องจาก seed ที่รับเข้าไปหรือปล่าว
  - ถ้า generator มันตุกติก แอบโกง ส่งค่าอื่นให้ ที่ไม่ตรงกับ function ที่แจก proof ไว้ตอนแรก ตัว verifier proof ก็จะพบทันทีเลยว่าถูกโกง
  - ตัว generator เอง ต้องประกาศ function และ proof ตั้งแต่แรก ก็ไม่รู้ด้วยว่า seed ที่เข้ามาตอนไหน หรือเป็นอะไร จึงโกงตั้งแต่ตอนสร้าง proof ไม่ได้
  - ตัว smart contract ไม่รู้ว่า function ฝั่ง generator คืออะไร ต่อให้บังคับ seed ได้ก็เท่านั้น เพราะคุมผลลัพธ์ที่ออกมาไม่ได้
  ดังนั้นเมื่อรวมกับแล้วมันจึงเป็น random ที่ทั้งสองฝั่งกำหนดค่าขึ้นมาไม่ได้

แต่มันก็ยังมีข้อควรพึงระวังอยู่นะ เช่น seed ก็ต้องเลือกตัวที่ oracle เดาไม่ได้ (ไม่งั้น oracle ที่รู้ function อยู่แล้ว อาจเป็น hacker ที่คำนวณ random value ล่วงหน้าได้) ส่วนค่าที่น่าใช้ เช่น การระบุว่าให้ใช้ค่า hash ของ 10 block ในอนาคต เป็นต้น

ตัว product ที่น่าสนใจตัวนึงก็คือ chainlink ครับ

Introduction to Chainlink VRF | Chainlink Documentation

ส่วนถ้าใครสนใจเรื่อง VRF ใน link ข้างบนก็มีอธิบายไว้อย่างละเอียดเหมือนกัน

ส่วนที่เป็นคำถามจากทางบ้าน ผมมองว่าเป็นการวิเคราะห์ threat model ต่าง ๆ เช่น เกิด chainlink เป็นคนร้ายเอง จะมีข้อมูลอะไร leak ออกไป ส่งผลให้ predict random value ง่ายขึ้นขนาดไหนบ้าง เป็นต้น ก็เป็นรายละเอียดค่อนข้างลึก ไม่เหมาะจะพิมพ์ใน blog ละกัน (และ scenario แนวนี้อาจจะพบเจอได้ยาก อาจจะไม่ต้องกังวลมากนัก)

แล้วก็จบท้ายด้วย connection กินพิซซ่า (ที่เหลือเยอะมาก) และแยกย้ายกันกลับบ้าน จบ public knowledge sharing งานแรกของ Inspex ครับ ภาพรวมเนื้อหางานก็กำลังดี ไม่แน่นหรือยากจนเกินไป และการ random ก็เป็นส่วนที่สำคัญมากสำหรับ GameFi ทีเดียว

อยากให้ทาง team จะจัดงาน share knowledge ใน public บ่อย ๆ นะครับ แง่มๆ หิว knowledge จัดจัด อย่า private มาก คนนอกอิจฉาครับ 555

ผมก็เป็น noob ที่พยายามศึกษา blockchain ผิดพลาดตรงไหน แจ้งได้เลยนะครับ

- 4 March 2022 -