Recommended
More Related Content
What's hot
Similar to [Hi-Con 2018] smart contract vulnerabilities and other auditing tools
Similar to [Hi-Con 2018] smart contract vulnerabilities and other auditing tools (20)
[Hi-Con 2018] smart contract vulnerabilities and other auditing tools
- 1. Smart contract vulnerabilities & other auditing tools Hi-Con 2018 2018年11月10日 セキュリティエンジニア 田篭 照博 NRIセキュアテクノロジーズ株式会社 サイバーセキュリティサービス事業本部
- 5. 4 自己紹介 (スマートコントラクトのSecurity Monitoring Serviceを開発）
- 6. 5 スマートコントラクトのセキュリティ概観 ブロックチェーン = セキュア が真だとしても、スマートコントラクト = セキュア は真ではない。 Solidity はチューリング完全な言語であり、記述の自由度は高い。 つまり誰もが自由なロジックを実装できるため、バグや脆弱性を作り込 むという意味では従来のWebアプリケーション等と同じである。 WebアプリケーションにはWebアプリケーションならではの脆弱性が あるのと同じように、スマートコントラクトにはスマートコントラクト ならではの脆弱性がある。 Webアプリやスマホアプリと同じ感覚でスマコンを開発すると大変な ことになる。 以降では、如何にスマコンがセキュリティ上の脅威となるかについて、 事例、代表的な脆弱性をベースに解説する。
- 9. 8 Reentrancy 問題 // アドレス毎に残高を管理 mapping (address => uint) public userBalances; /// etherを引き出す時に呼ばれる関数 function withdrawBalance() public payable { // 1. 残高を確認 require(userBalances[msg.sender] > 0); // 2. 呼出し元に返金 msg.sender.call.value(userBalances[msg.sender])()) // 3. 残高を更新 userBalances[msg.sender] = 0; } // Fallback関数 function() payable{ // VictimBalanceのwithdrawBalanceを呼出し msg.sender.call .value(0)(bytes4(sha3("withdrawBalance()"))) } // 攻撃対象からの引出し時に利用する関数 function withdraw() public { target.call. value(0)(bytes4(sha3("withdrawBalance()")))) } 脆弱なスマコン（被害者） 攻撃用のスマコン
- 10. 9 Reentrancy 問題 // アドレス毎に残高を管理 mapping (address => uint) public userBalances; /// etherを引き出す時に呼ばれる関数 function withdrawBalance() public payable { // 1. 残高を確認 require(userBalances[msg.sender] > 0); // 2. 呼出し元に返金 msg.sender.call.value(userBalances[msg.sender])()) // 3. 残高を更新 userBalances[msg.sender] = 0; } // Fallback関数 function() payable{ // VictimBalanceのwithdrawBalanceを呼出し msg.sender.call .value(0)(bytes4(sha3("withdrawBalance()"))) } // 攻撃対象からの引出し時に利用する関数 function withdraw() public { target.call. value(0)(bytes4(sha3("withdrawBalance()")))) } 脆弱なスマコン（被害者） 攻撃用のスマコン ①スマコン経由で withdrawBalance 呼出し ② ③スマコンに送金 ④再呼出し！ ④の後も TRUE になる！ ⑤スマコンに再度送金！ 以降、スマコン内の Ether が尽きるまで続く
- 11. 10 fallback 関数を悪用する例（オークション） address public highestBidder; // 最高額提示アドレス uint public highestBid; // 最高提示額 /// Bid用の関数 function bid() public payable { // bidが現在の最高額よりも大きいことを確認する require(msg.value > highestBid); // 返金額退避 uint refundAmount = highestBid; // 最高額提示アドレス退避 address currentHighestBidder = highestBidder; // ステート更新 highestBid = msg.value; highestBidder = msg.sender; // 最高額を提示していたbidderに返金する currentHighestBidder.send(refundAmount) } // fallback関数 function() payable{ revert(); } // bid用の関数 function bid(address _to) public payable { _to.call.value(msg.value)(bytes4(sha3("bid()"))) } 脆弱なスマコン（被害者） 攻撃用のスマコン
- 12. 11 fallback 関数を悪用する例（オークション） ①. 参加者のアリスが、コントラクトに100円 相当を送金して買値を提示（ビッド） ②-1. 別の参加者のボブは200円相当を提示 ②-2. このタイミングで最高提示額者はボブに なり、アリスに対してコントラクトが自動で返 金する ③-1. イブが用意したコントラクト経由でイブ が300円相当でビッド ③-2. このタイミングでボブに200円返金され る ④-1. ボブが400円相当でビッド ④-2. 同時にイブが用意したコントラクトに対 して返金されようとするが、イブのコントラク トの fallback 関数にわざとエラーを発生させ る処理があるため、エラーに引きずられてボブ のビッドも成立しない。つまり、以降は誰も ビッドできなくなり、イブは必ずオークション に勝つことができる。 参考： https://www.nri.com/jp/journal/2017/10/20171018/
- 13. 12 Timestamp Dependence /// 抽選を行う function hold() public onlyOwner { // 応募者が3人に達していない場合は処理を終了 require(numApplicants == 3); // 抽選 winnerInd = block.timestamp % 3; winnerAddress = applicants[winnerInd]; } 脆弱なスマコン（抽選会） 抽選会をスマコンで表現 参加者はスマコンにトランザクションを発行するこ とで応募可能 block.timestamp という予約語が存在する。これ を当選者を決めるための乱数、またはシードにする 場合に問題となる block.timestampは、「ブロックにトランザクショ ンが取り込まれときのunixtime」であり、マイ ナーが一定レベルの操作が可能 つまり、マイナーが応募していた場合は必ず当選す ることができる。
- 14. 13 Ethereum Smart Contract Security Best Practices スマートコントラクト開発者は必ず参照し腹におとしこむことが大事。
- 15. ビジネスロジック関連の脆弱性 2
- 16. 15 Parity マルチシグウォレットの脆弱性 ・“Parity”： Ethereum専用のウォレットアプリケーショ ン。 ・Parity で生成されるマルチシグウォレットの 脆弱性が突かれ、34億円相当の Ether が不 正送金を受けたと発表される。 ・弊社の検証 (後述) によれば、これは正確には スマートコントラクトの脆弱性であり、アク セス制御の実装漏れと言える。 （※）詳細な状況報告がされている訳ではないため、一部に推測を含む内容であり、 実際に受けた攻撃とは異なる可能性があります。 参考： https://github.com/paritytech/parity/wiki/Accounts,-Wallets,-Vaults https://ethereum-japan.net/ethereum/parity-maltisig-vulnerability-hacked-150keth/ 問題のあったParityウォレット 報道の様子
- 17. 16 Parity マルチシグウォレットの脆弱性 ■前提知識：Ethereumのアカウント ・Ethereum のアカウントの種類は2つある。 Externally Owned Account (EOA) ・秘密鍵によって管理される ・アドレスを持つ ・紐づく残高がある Contract Account (CA) ・秘密鍵によって管理されない ・アドレスを持つ ・紐づく残高がある ・CAは他のアカウントから送金することで Ether を保持できる。 EOA と CA EOA CA 一般的な アカウント スマートコントラクト 用のアカウント CA へ Etherを 送金可能
- 18. 17 Parity マルチシグウォレットの脆弱性 ■前提知識：(Parityの) マルチシグウォレット ・“マルチシグウォレット”： もともとは Bitcoin における概念であり、ト ランザクション発行に際して、複数の秘密鍵 による署名を必要とする方式である。 (つまり通常よりセキュリティの高い方式) ・ところが Ethereum 自体にはマルチシグとい う概念はない。このため Parity は、独自にス マートコントラクト上で実装している。 ・スマートコントラクト上に通貨 (Ether) を持 たせ、複数のアドレスからのトランザクショ ンを求めることで実現している。 Parity マルチシグの送金イメージ CA ①送金依頼 Tx ②承認 Tx ③送金 送金される Ether は CA上の Ether
- 19. 18 Parity マルチシグウォレットの脆弱性 ■Parity マルチシグ脆弱性原理 ・一般論として、スマートコントラクトの関数 は「生成元のEOAのアドレスからのトランザ クションであれば許可する」といったアクセ ス制限を実装で制御する必要がある。 ・しかし本件マルチシグのスマートコントラク トでは M-of-N (N人の内、M人の署名が必要) と 許可アドレスを設定する関数についてアクセ ス制限の実装が無かった。(公開関数なうえ、ど のアドレスからでも実行可能であった) ・このため攻撃者は当該関数で自身のアドレス を1-of-1で設定することにより、スマートコ ントラクトからの送金が自由に出来た。 問題該当ソース 修正差分 問題の箇所 アクセス制限の実装がない上、 アクセス修飾子 (internal) がなく、 既定値 (public) であった。 問題の本質ではないが、 「一日の送金上限額設定関数」 も公開状態にありリミットを 解除できるようになっていた。 参考： https://github.com/paritytech/parity/commit/b640df8fbb964da7538eef268dffc125b081a82f#diff-8ea4aa7c2ba715c683bc764337f51585
- 25. 24 Question?