10 月 7 日，Avalanche 鏈上社交協議 Stars Arena 遭到駭客攻擊，損失約 290 萬美元，本文將簡析此次攻擊事件。
（前情提要：FTX駭客跨鏈洗錢》THORSwap轉成維護模式，暫停交易功能 ）
（背景補充：Friend.tech頻傳用戶遭駭客攻擊，慢霧警告：中心化又缺乏安全機制 ）
背景
據慢霧 MistEye 系統安全預警，2023 年 10 月 7 日，Avalanche 鏈上社交協議 Stars Arena 遭攻擊，損失約 290 萬美元。慢霧安全團隊簡析該攻擊事件並將結果分享如下。
相關資訊
攻擊者地址：
https://snowtrace.io/address/0xa2ebf3fcd757e9be1e58b643b6b5077d11b4ad7a
攻擊合約：
https://snowtrace.io/address/0x7f283edc5ec7163de234e6a97fdfb16ff2d2c7ac
https://snowtrace.io/address/dd9afc0e3c43951659c8ebe7aef9ee40879863ea
攻擊交易：
https://snowtrace.io/tx/0x4f37ffecdad598f53b8d5a2d9df98e3c00fbda4328585eb9947a412b5fe17ac5
攻擊核心
攻擊者利用重入漏洞，篡改自己存款份額所對應的價格。隨後在賣出時，又因該惡意操縱的價格計算依賴，導致類似的價格操控。通過精確計算重入時更新的份額價格，攻擊者竊取了合約中的資金。
交易分析
我們可以發現攻擊交易中存在一筆重入呼叫，我們通過反編譯程式碼逐步分析呼叫方式。
攻擊者先建立攻擊合約（0x7f283 和 0xdd9af），通過攻擊合約呼叫 Stars Arena: Shares 合約的 0xe9ccf3a3 方法，然後存入 1 枚 AVAX 代幣。
根據反編譯後的程式碼一步步追蹤，攻擊者首先用的 0xe9ccf3a3 方法是一個類似於存款的函式，其中會呼叫 0x326c 和 0x2058 方法。0x326c 方法僅作為引數返回的呼叫，而 0x2058 方法類似於一個處理某種代幣購買或交換的函式，該方法通過 0xe9ccf3a3 所傳入的 AVAX 代幣數額及地址來進行下一步操作及份額和費用的計算。
跟進 0x2058 方法第 92 行的呼叫邏輯，可以發現 0x1a9b 方法為一個計算函式，計算出的結果是一個類似於價格的值，其返回值為新計算出的 v24 / 0xde0b6b3a7640000 或者是 _initialPrice。
之後的 109 行，110 行及 116 行的 0x307c 和 0x30ef 方法中就存在 low-level call 的呼叫，而 0x30ef 的 call 還是對 varg1 也就是傳入的 0xdd9af 攻擊合約地址的外部呼叫。函式沒有防重入鎖的約束，並且在執行完外部呼叫後，此方法才會向下執行之後的 if 判斷來更新 field0.length 及 field0 引數。毫無疑問，重入就是在此處發生的。
我們再來看攻擊者在重入呼叫中構造的資料。
重入外部呼叫的是 0x5632b2e4 方法，並傳入攻擊者所構造的的 4 個引數，這些引數通過進位制轉化 153005ce00 為 91000000000。
正如上面講到的，對 0x5632b2e4 方法的外部呼叫是執行在 if (varg0 == _getMyShares [address (varg1)][msg.sender]) 判斷之前。這時 field0.lengt 值為 0， 並未更新。攻擊者正好通過這個方式繞過 0x5632b2e4 方法中的判斷，將 msg.sender 也就是攻擊合約 0xdd9af 的以下 4 個引數狀態都修改為了外部呼叫是時構造的資料。
通過以上操作之後，攻擊者呼叫了 sellShares 來賣出自己的份額，獲得了 266,102.97278 枚 AVAX。
深入 sellShares 函式，函式起先就呼叫了 0x1a9b 方法，而在之前的 0x2058 方法中就曾存在呼叫，是處理某種代幣購買或交換的函式。我們可以發現，在 0x1a9b 方法中的 0x2329 方法會更新 owner_9f [varg0]，而這個引數在重入時就已經被修改為攻擊者所構造的 91000000000。
回到 0x1a9b 方法中，根據之前惡意構造的值重新計算（計算數額見註釋）。
經過以上計算，新計算出的份額所對應的價格發生了改變，計算出的結果為 274,333.061476814e18。再經過一系列的費用收取過後，攻擊者在沒有修改份額的情況下使用惡意構造操縱的價格，賣出份額，成功獲利。
總結
本次攻擊的核心在於重入攻擊所造成的價格計算依賴更新，進而導致了類似惡意價格操控。慢霧安全團隊建議專案方應儘可能在經過多家安全公司審計後，再進行合約的部署釋出；同時在編碼時應儘可能滿足 Checks-Effects-Interactions 編碼規範，新增防重入鎖。
